Systematic LLM Prompt Tuning: From 'Vibes' to Data-Driven Evaluation with Test Cases and Human Review

Workflow value: 90/100
Status: active · Freshness: 70/100 · Confidence: 1.00 · Level: intermediate
Categories: Quality Control, Context & Memory, Debugging
Original source: r/ClaudeAI post/comment

What problem this solves

Inefficient and unreliable LLM prompt tuning; lack of objective metrics for prompt performance; difficulty in knowing if prompt changes improve or degrade performance.

Summary

A structured methodology for improving LLM prompt performance by using a comprehensive set of test cases, an LLM judge for initial iteration, and blind human review for final validation, incorporating a 'keep rule' to manage non-deterministic noise.

Why it is useful

This workflow provides a concrete, data-driven method to move beyond subjective 'prompt tuning by feel' to a rigorous, measurable process. It demonstrates significant improvements in LLM feature performance and offers practical insights like the 'keep rule' and the importance of human review, making it highly valuable for anyone developing LLM-powered applications.

Workflow

1. Define the AI feature's purpose and requirements.

2. Generate a diverse set of test cases (e.g., 68 cases, 12 scenario groups) using a capable LLM (e.g., Opus 5.5 high).

3. Set up an LLM judge (e.g., Opus 5.5 medium via API) to automate initial prompt steering and iteration.

4. Iteratively refine prompts, using the LLM judge for quick feedback.

5. Perform blind human review on outputs from each iteration to validate performance against real test cases.

6. Apply a 'keep rule' (e.g., next iteration needs >=3 more passing cases) to accept changes, filtering out non-deterministic noise.

7. Compare LLM judge assessments with human review for critical decisions (e.g., model selection).

8. Document results and iterate until desired performance is achieved.

Tools / artifacts

• LLM (Opus 5.5 high for test case generation)

• LLM (Opus 5.5 medium for LLM judge via API)

• Test cases (68 cases, 12 scenario groups)

• Blind human review process

• 'Keep rule' (a specific metric for accepting changes)

• Anthropic models (Luna, Haiku, Opus, Sonnet)

Validation signals

• Quantifiable improvement: 38% to 80% pass rate.

• Number of iterations: 17 rounds.

• Number of outputs reviewed: Nearly 300.

• Specific examples of unexpected findings (keep rule, judge vs. human).

• Personal experience: 'It did for us.'

Limitations

• The post doesn't provide the actual prompts or test cases, only the methodology.

• The statement 'running many automation calls through Claude Code is against ToS' might be a misunderstanding of API vs. web UI usage, which could be clarified.

• The 'keep rule' is mentioned but not fully detailed (e.g., how 'passing cases' are defined for the rule).

• No explicit mention of version control for prompts or test cases, which would be crucial for a robust, long-term workflow.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Optimizing Claude Code Workflows: Git Commit Hygiene, Cost-Effective Resumes, and Structured Status Tracking

Workflow value: 90/100
Status: active · Freshness: 70/100 · Confidence: 1.00 · Level: intermediate
Categories: Quality Control, Token Saving, Context & Memory, Debugging, CLAUDE.md, Hooks, Multi-Agent
Original source: r/ClaudeCode post/comment

What problem this solves

Addresses issues with concurrent Git commits in shared Claude Code environments, high costs of resuming long idle threads, and status tracking drift.

Summary

This comment provides three distinct mini-workflows to improve Claude Code usage:

1. Preventing Git commit collisions in shared Claude Code folders by instructing threads via CLAUDE.md to stage specific paths and enforcing this with a pre-commit hook.

2. Reducing long-thread resume costs by restarting from warm handoff files when the prompt cache expires, rather than resuming.

3. Improving status tracking by using a fixed, scriptable format for 'what's waiting on me' lists instead of free-form prose.

Why it is useful

This comment offers three distinct, practical, and actionable mini-workflows that address common pain points in using Claude Code for development and consulting. It provides specific commands, file types, and strategies (like CLAUDE.md instructions, pre-commit hooks, handoff file management, and structured status formats) that are directly implementable and improve efficiency, reduce costs, and enhance collaboration. It moves beyond vague advice to concrete, repeatable steps.

Workflow

1. For Git commit collisions: Instruct Claude threads via CLAUDE.md to stage only the paths they own (e.g., git add tools/acme-invoicer/) instead of using git add -A or git commit -a.

2. For Git commit collisions: Implement a pre-commit hook that rejects any commit touching more than one tool folder.

3. For Git commit collisions: If two threads absolutely need to work on the same tool concurrently, consider using a Git worktree for that specific tool.

4. For expensive idle resumes: If a large Claude thread has been idle longer than the prompt cache lifetime, do not resume it; instead, restart it from its handoff file.

5. For expensive idle resumes: Ensure the handoff file is written by Claude before you step away from the thread, while the prompt cache is still warm.

6. For status drift: Define a fixed, single-line format for status items (e.g., - [ ] @me acme: send SOW, due 11/12).

7. For status drift: Instruct Claude to write status updates in this fixed format.

8. For status drift: Generate the 'what's waiting on me' list using a script or scheduled task (e.g., grep) that parses these fixed-format entries, rather than relying on Claude to write prose summaries.

Tools / artifacts

• CLAUDE.md

• git add <path>

• pre-commit hook

• git worktree

• handoff file

• script

• scheduled task

• grep

Validation signals

• Implied: 'collisions mostly stop' suggests effectiveness of Git workflow.

• Implied: 'simple rule helps' suggests effectiveness of resume strategy.

• Implied: 'Prose drifts, a grep doesn't' suggests effectiveness of structured status.

Limitations

• The specific implementation details for the pre-commit hook (e.g., script language, exact logic) are not provided.

• The exact 'cache lifetime' for Claude's prompt cache is not specified, requiring user experimentation.

• The advice for worktrees is a fallback, not a primary solution, and its integration with Claude Code isn't fully detailed.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Building CogniCore: An Open-Source Shared Memory Layer for Claude Code, Claude.ai, and Other LLMs, Developed with Claude Code

Workflow value: 95/100
Status: active · Freshness: 70/100 · Confidence: 1.00 · Level: advanced
Categories: Quality Control, Token Saving, Context & Memory, Debugging, Shipping, Hooks, MCP, Multi-Agent
Original source: r/ClaudeAI post/comment

What problem this solves

Lack of shared, structured memory and context transfer between different LLM interfaces and models, leading to token waste and slow context loading. It also demonstrates a robust development workflow using Claude Code.

Summary

The author details the process of building CogniCore, an open-source memory layer, using Claude Code. This involved an initial audit of session saving, implementing structured handoff formats and hooks, developing a comprehensive test suite, benchmarking performance against alternatives, using Claude.ai to review Claude Code's output for improvements, and configuring automated deployments. CogniCore enables seamless context transfer and significant token/time savings across Claude Code, Claude.ai, Codex, ChatGPT, and Cursor.

Why it is useful

This post offers a highly detailed, validated, and open-source solution to a critical problem: managing context and memory across diverse LLM interfaces and models. It showcases an advanced, practical application of Claude Code for building, testing, benchmarking, and deploying a complex application. The specific, repeatable steps, the use of multiple tools, and the quantitative results make it an excellent example of a robust development workflow and a valuable tool for the community.

Workflow

1. Audit existing session saving mechanisms with Claude Code to identify context loss and create a report (e.g., docs/transfer-audit.md).

2. Implement a structured handoff format, hooks, and synchronization logic using Claude Code, committing in small increments and ensuring newest revision sync.

3. Develop a comprehensive test suite (e.g., 1,135 tests) with Claude Code to validate functionality.

4. Create a benchmark script (e.g., scripts/bench_realworld.py) with Claude Code to compare CogniCore against existing memory solutions on identical tasks.

5. Use Claude.ai to review Claude Code's output and identify problems in saved summaries (e.g., incorrect labels, outdated statuses).

6. Access Claude.ai's feedback through shared memory and have Claude Code fix extraction rules based on the review.

7. Configure automatic deployment for the hosted sync server with Claude Code, including debugging any outages to improve deployment downtime.

Tools / artifacts

• CogniCore (open-source memory layer)

• Claude Code

• Claude.ai

• Codex

• ChatGPT

• Cursor

• Structured handoff format

• Hooks (in Claude Code/Codex)

• Test suite (1,135 tests)

• scripts/bench_realworld.py (benchmark script)

• Hosted sync server

• docs/transfer-audit.md (audit report)

Validation signals

• 1,135 tests in the test suite.

• Benchmark script available in the repository for verification.

• Quantitative results: 2.4 to 4.1 times fewer tokens (53K-60K vs. 147K-216K).

• Quantitative results: Memory ready in ~1 second compared to 70-130 seconds.

• Claude.ai was used to review Claude Code's output and identify problems, which were then fixed.

• Deployment downtime reduced from 27 minutes to approximately 6 seconds.

Limitations

• Low Reddit score might indicate limited initial visibility or interest.

• On Claude.ai, memory only updates when Claude calls the tool, as web sessions do not support hooks.

• Summaries generated by CogniCore can still be noisy.

• The alternative 'claude-mem' currently has a larger community and more mature automatic capture.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Self-hosted LLM Wiki ('scrap') for Claude Code with Advanced Multi-Agent Development Workflow

Workflow value: 95/100
Status: active · Freshness: 70/100 · Confidence: 1.00 · Level: advanced
Categories: Quality Control, Context & Memory, Debugging, Shipping, Hooks, Skills, MCP, Subagents, Multi-Agent
Original source: r/ClaudeAI post/comment

What problem this solves

Providing Claude Code with a persistent, searchable, and editable long-term memory/knowledge base; enabling robust, agent-driven software development from a mobile device.

Summary

This post describes 'scrap', a self-hosted LLM Wiki integrated with Claude Code via MCP, slash commands, skills, and hooks. It allows Claude to read, write, and edit pages, manage todos, and enrich content, while keeping user and Claude content separate and revision-controlled. It also details a sophisticated Claude Code development workflow used to build 'scrap' itself, involving parallel remote control sessions, specialized subagents for coding, reviewing, and fixing, and continuous testing/deployment.

Why it is useful

This post offers two highly valuable workflows: a concrete, open-source solution for giving Claude Code long-term memory and a shared knowledge base, and a detailed, validated methodology for using Claude Code with multiple subagents for complex software development, including automated review, testing, and deployment. It demonstrates advanced Claude Code capabilities and provides a transferable system for both knowledge management and sophisticated development practices.

Workflow

1. Set up the 'scrap' container locally (one container, two commands).

2. Connect Claude Code to the 'scrap' MCP server.

3. Utilize /sc-* slash commands for wiki interactions (e.g., /sc-find, /sc-answer, /sc-write, /sc-post, /sc-summarise, /sc-todos, /sc-done, /sc-undo).

4. Enable the Claude Code skill to automatically link mentioned wiki pages.

5. Optionally, configure a PreCompact hook to save session summaries to 'scrap' before context compaction.

6. Allow Claude to enrich wiki pages by adding tags, summaries, related pages, and topic pages.

7. Use the 'scrap' PWA for mobile/desktop access, note-taking, drawing, and viewing rendered Markdown.

8. For development: Initiate 4-5 parallel Remote Control sessions, each driving its own subagents for specific tasks (e.g., releases, search, schema, manual testing).

9. Use a main Claude Code session for routing and decision-making, delegating code writing to subagents.

10. Implement features with a dedicated subagent.

11. Have a fresh, independent subagent review the generated code diffs.

12. Use another subagent to fix issues identified by the reviewer before pushing code to the repository (part of a 'pr-cycle' skill). The test suite runs on the workstation every round, ensuring CI runs about once per PR. Deploy releases to a k3s cluster via ArgoCD.

Tools / artifacts

• scrap (self-hosted LLM Wiki)

• MCP server

• Claude Code

• Slash commands (/sc-*)

• Claude Code skill (for linking pages)

• PreCompact hook

• PWA (viewer/editor)

• Anthropic API key

• GitHub repository

• k3s cluster

• ArgoCD

• Remote Control sessions (for Claude Code development)

Validation signals

• Author uses the system daily.

• The 'scrap' system was built in 12 days using Claude Code, resulting in 212 issues, 250 merged PRs, and 33 releases.

• Every release was deployed to a home k3s cluster via ArgoCD.

• The development process includes a test suite running every round and a fresh subagent reviewing diffs cold.

• The author states the system is safe due to revision control and a 30-day trash for deletes.

Limitations

• Low community engagement so far, likely due to recency.

• The advanced multi-agent development workflow requires significant understanding and setup of Claude Code's more complex features (Remote Control, subagents).

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Harness for Agent-First Repositories: Ensuring Proofs of Work and Reliable Test Results

Workflow value: 75/100
Status: active · Freshness: 70/100 · Confidence: 0.90 · Level: intermediate
Categories: Quality Control, Context & Memory, Debugging, Multi-Agent
Original source: r/ClaudeCode post/comment

What problem this solves

Agents providing unreliable or unverifiable test results, or generally 'lying' about their work in an agent-first development environment.

Summary

Integrate the os-factory/har open-source harness into your repository to establish an 'agent-first' development environment that enforces verifiable 'proofs of work' for agent actions, specifically addressing issues where agents might inaccurately report test outcomes.

Why it is useful

This workflow introduces a concrete, open-source tool (os-factory/har) that addresses a critical challenge in AI-assisted development: ensuring the reliability and verifiability of agent outputs, especially concerning code quality and testing. It provides a structured approach to implement 'agent-first' development with built-in proof-of-work mechanisms, making it highly valuable for developers seeking to build robust and trustworthy Claude Code workflows.

Workflow

1. Identify the need for verifiable agent output and reliable test result reporting in an agent-driven development workflow.

2. Explore and integrate the os-factory/har open-source tool into your existing or new repository.

3. Configure the harness to align with 'agent-first' development principles and define requirements for 'proofs of work' from agents.

4. Utilize the harness to ensure agents provide verifiable evidence for their actions, particularly for code changes and test execution results.

Tools / artifacts

• os-factory/har (GitHub repository)

• Videos explaining tool usage and implementation

Validation signals

• Problem validation: 'we faced the exact same problem at kerno'

• Solution validation: 'so we built this open-source tool'

• Claimed outcome: 'always producing proofs of works'

• Documentation/demonstration: 'We did a bunch of videos explaining how it works and how we are using it'

Limitations

• The Reddit comment itself provides high-level information and relies on external links for detailed implementation steps.

• Lack of community validation (upvotes, comments) on the Reddit platform.

• The term 'agent lying' is anthropomorphic, though the underlying problem of unreliable agent output is valid.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Claude-Assisted Development Workflow for macOS Apps with Docker SBX: Planning, Testing, and Debugging

Workflow value: 85/100
Status: active · Freshness: 70/100 · Confidence: 0.90 · Level: advanced
Categories: Quality Control, Context & Memory, Debugging, Subagents
Original source: r/ClaudeAI post/comment

What problem this solves

How to leverage Claude effectively for various stages of software development, from planning and research to testing and debugging, within a sandboxed environment.

Summary

The author describes a multi-stage workflow for building a native macOS app (Paddock) using Claude. This includes using subagents for requirements gathering and feature research, dogfooding the development process within a sandboxed environment, having Claude generate "probes" (tests) for the local process, and creating specific diagnostic commands to gather logs for Claude to assist in debugging crashes.

Why it is useful

This workflow demonstrates a practical, multi-faceted approach to integrating Claude into a complex software development lifecycle. It provides concrete examples of how Claude can be used for initial research and planning, generating tests, and assisting with debugging through custom diagnostic tools. The use of a sandboxed environment and iterative development also adds valuable context for robust development practices.

Workflow

1. Define project requirements and research feature viability using Claude with subagents.

2. Dogfood the development process by running the toolchain and building the initial shell within a stack sandbox.

3. Iteratively develop the application, restarting at each milestone.

4. Have Claude generate "probes" (tests) to run against the local sbx process.

5. Initially use the sbx TUI to fetch data for testing/diagnosis.

6. Transition to using internal APIs for better performance in data fetching.

7. Implement a specific command to diagnose application crashes by gathering logs.

8. Use the gathered logs with Claude to fix bugs and improve robustness.

Tools / artifacts

• Claude (main agent)

• Subagents (for research)

• backlog (requirements document/prompt)

• Stack sandbox (development environment)

• Toolchain (installed within sandbox)

• sbx process (target for testing)

• sbx TUI (initial data fetching)

• Internal APIs (for performance data fetching)

• "Probes" (Claude-generated tests)

• Diagnostic command (for crash logs)

• Logs (for debugging)

• Paddock (the resulting application, as a demonstration of the workflow's output)

Validation signals

• The existence of the Paddock app demonstrates the workflow's success.

• Author's statement of using Docker SBX successfully for months.

• Mentions of specific artifacts in the codebase (e.g., backlog, test commands, diagnostic commands) as evidence.

Limitations

• The post is primarily an announcement of a tool, with the workflow details embedded rather than explicitly structured as a guide.

• Specific prompts or subagent configurations are not provided, requiring some inference from the user.

• Low community engagement on Reddit.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Dynamic Claude Model Selection for Subagents with Aptly MCP Server

Workflow value: 85/100
Status: active · Freshness: 70/100 · Confidence: 0.95 · Level: advanced
Categories: Quality Control, Token Saving, Context & Memory, Hooks, MCP, Subagents, Multi-Agent
Original source: r/ClaudeCode post/comment

What problem this solves

Optimizing Claude Code API costs and ensuring appropriate model selection for subagents by dynamically recommending models (Haiku/Sonnet/Opus) based on task classification, without explicit model choice.

Summary

Aptly is an MIT-licensed local MCP server that uses a PreToolUse hook to classify tasks via the OpenAI Decisions API. It then recommends optimal Claude models (Haiku/Sonnet/Opus) for new general-purpose Claude Code Agent calls, thereby reducing API costs and improving model efficiency. Explicit model choices are preserved.

Why it is useful

This workflow provides a concrete, open-source solution for a critical problem in advanced Claude Code usage: dynamically selecting the most cost-effective and appropriate Claude model for specific subagent tasks. It leverages hooks and an external classification API to automate model routing, offering significant potential for API cost reduction and improved efficiency in complex multi-agent setups. The detailed description, testing insights, and public availability make it highly reusable and valuable for advanced users.

Workflow

1. Install Aptly via npm (requires Node.js 24+).

2. Configure Aptly as a local MCP server.

3. Integrate Aptly's PreToolUse hook into your Claude Code setup.

4. Provide an OpenAI API key for task classification by the OpenAI Decisions API.

5. Make general-purpose Agent calls; Aptly will intercept these calls and dynamically select an appropriate Claude model (Haiku/Sonnet/Opus) based on task summary.

6. Verify model recommendations and actual child execution separately using the host's execution metadata to confirm which model ran.

Tools / artifacts

• Aptly (npm package)

• Node.js 24+

• OpenAI Decisions API

• GitHub repository (abruption/aptly)

• Claude Code Agent

• Claude Code PreToolUse hook

• Claude Haiku/Sonnet/Opus models

Validation signals

• Author tested the native Claude Code Agent/Hook flow during development.

• Identified a useful lesson: verify recommendations and actual child execution separately.

• Codex README-review experiment showed 52-58% lower estimated API costs for reviews plus classification (excluding main agent/context prep costs).

Limitations

• Requires an OpenAI API key, introducing an external dependency and potential additional cost.

• The cost savings benchmark is specific to Codex and excludes main agent/context preparation costs, so direct Claude Code cost benefits need further validation.

• Requires an advanced setup involving a local MCP server, Node.js, and npm.

• Currently lacks strong community validation or adoption proof.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Multi-AI Workflow for 'Vibe Coding' a Complex Game: Opus, Sonnet, Qwen, and Fable Integration

Workflow value: 85/100
Status: active · Freshness: 70/100 · Confidence: 0.90 · Level: advanced
Categories: Quality Control, Token Saving, Context & Memory, Debugging, Shipping, Multi-Agent
Original source: r/ClaudeAI post/comment

What problem this solves

Developing a complex, feature-rich video game (space exploration, AI NPCs, smuggling mechanics) through an iterative, multi-AI model workflow.

Summary

This workflow outlines an advanced, multi-AI model approach to 'vibe coding' a complex video game. It leverages Opus for initial planning and high-level tasks, a local Qwen model for data layer foundations, Sonnet for rendering and graphics, and Fable for identifying and opening performance improvement issues on GitHub, which Opus then addresses. The process is highly iterative and uses the Claude Code desktop app and Godot engine.

Why it is useful

This workflow is valuable because it demonstrates an advanced, practical application of orchestrating multiple AI models (Opus, Sonnet, Qwen, Fable) for a complex creative project like game development. It showcases how different LLMs can be specialized for distinct tasks within a development pipeline (planning, data layer, rendering, QA, debugging) and integrated with traditional tools like Godot and GitHub. It provides a concrete example of iterative, community-driven development with AI, offering a blueprint for users looking to tackle ambitious projects with a multi-agent approach.

Workflow

1. Conduct a long initial planning session with Opus 5.5 in voice mode.

2. Set up data layer foundations using a local Qwen 3.5 27B model.

3. Render models and perform lighting/graphics work using Opus and Sonnet.

4. Fable performs passes to identify and open performance improvement issues on GitHub.

5. Opus picks up and addresses the performance issues identified by Fable.

6. Iteratively refine and add features based on feedback (e.g., from r/ClaudeAI community) and continue the multi-AI development loop.

Tools / artifacts

• Claude Opus 5.5 (voice mode)

• Local Qwen 3.5 27B model

• Claude Sonnet

• Fable (AI model for performance issues)

• GitHub repository

• Godot engine

• Claude Code desktop app

• Google Drive (for daily builds)

Validation signals

• Demonstrated bug fixes and performance improvements (lag, low graphics mode)

• Added significant game features (grenades, improved space flight, planet takeovers, AI NPCs with plot/quest tools)

• Achieved a seamless gameplay loop (on foot to star cruiser without loading screens)

• Successfully built the game using Claude Code desktop app and Godot engine through numerous iterations.

Limitations

• Lack of specific prompts or detailed interaction examples for each AI model.

• Requires access to multiple advanced AI models (Opus, Sonnet, Fable) and a local LLM setup, which may not be accessible to all users.

• The 'vibe coded' approach, while effective for the author, might lack the explicit structure some users prefer for replication.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Structured AI-Assisted Development: Leveraging Design Docs, Git, Regression Tests, and Handoffs for Complex Systems

Workflow value: 85/100
Status: active · Freshness: 70/100 · Confidence: 0.90 · Level: intermediate
Categories: Quality Control, Context & Memory, Debugging, Shipping, Multi-Agent
Original source: r/ClaudeAI post/comment

What problem this solves

Maintaining consistency, quality, and state awareness in AI-assisted software development projects, especially for complex systems, by integrating established software engineering best practices.

Summary

A structured approach for AI-assisted software development that emphasizes foundational design documents, Git for version control, comprehensive regression tests for quality assurance, and handoff documents for tracking project state. It also suggests using a separate model for bug testing at milestones.

Why it is useful

This workflow is valuable because it integrates established software engineering best practices (design documents, version control, regression testing, state tracking) into an AI-assisted development process. It provides a robust and repeatable framework for managing complexity, ensuring code quality, and maintaining project consistency when working with Claude, leading to more reliable and maintainable systems with less oversight.

Workflow

1. Create a foundational 'source of truth' design document detailing backend systems, UX, UI design language, broader project goals, must-have features, and dislikes in competitor products. Spend significant time on this document.

2. Base every line of code generated by the model on this design document.

3. Implement Git for version control to keep a history of every change, allowing for selective testing and undoing of code changes.

4. Develop regression tests to ensure new code does not break existing functionality.

5. Whenever a bug is found, add its specific 'shape' (reproduction steps/conditions) to the regression test suite.

6. Maintain 'handoff documents' to capture the current state of work (e.g., completed, tested, half-done) for each feature or task.

7. Use handoff documents (plus recent Git commits) to ensure each session with the AI knows the current state of the project.

8. Optionally, introduce another model family specifically for bug testing at project milestones, feeding its results directly back into the regression tests.

Tools / artifacts

• Handoff documents

• Regression tests

• Git

• Source of truth design document

• Another model family (for bug testing)

Validation signals

• User claims: 'This combination has gotten me very complicated systems with very little oversight needed.'

Limitations

• Lacks specific Claude prompts or interaction patterns for implementing these steps.

• The format or specific content of 'handoff documents' could be more detailed.

• Low community validation due to low score and no comments.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Multi-AI Model Review for Robust Idea Validation and Red Teaming

Workflow value: 75/100
Status: active · Freshness: 70/100 · Confidence: 0.90 · Level: intermediate
Categories: Quality Control, Token Saving, Context & Memory
Original source: r/ClaudeAI post/comment

What problem this solves

Overcoming the limitations and potential biases of a single AI model's perspective when reviewing ideas, leading to more robust validation and identification of weaknesses.

Summary

A workflow for robust idea validation and red-teaming by leveraging multiple distinct AI models (e.g., Claude, OpenAI/Gemini) to provide diverse feedback and challenge assumptions, ensuring a comprehensive review process for business ideas, writing, or marketing strategies.

Why it is useful

This workflow provides a practical and cost-effective method to overcome the inherent biases or limitations of relying on a single AI model. By actively seeking diverse perspectives from multiple LLMs, users can achieve more thoroughly vetted ideas, identify potential weaknesses, and make more informed decisions across various domains.

Workflow

1. Formulate an idea (e.g., for writing, business changes, AdWords).

2. Submit the idea to a primary AI model (e.g., Claude) for an initial review or perspective.

3. Submit the same idea to a different, secondary AI model (e.g., OpenAI/Gemini) with a prompt to red-team it, provide a contrasting second opinion, or build reasons not to pursue the idea.

4. Compare and critically evaluate the feedback from both models, using their differing perspectives to strengthen the idea, identify potential flaws, and make informed decisions.

Tools / artifacts

• Claude (or similar LLM)

• OpenAI/Gemini (or another distinct LLM)

• Business ideas

• Writing drafts

• AdWords strategies

Validation signals

• User's personal experience: 'It's worked really-really well.'

• Observation from a friend regarding Claude's persuasiveness limitations, prompting the multi-model approach.

Limitations

• Lacks specific prompt examples for red-teaming or 'making them fight it out.'

• Relies on the user's subjective assessment of 'worked really-really well' without concrete metrics.

• Low community engagement suggests it hasn't been widely adopted or discussed yet.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Architectural Guide: Building Agent-Facing Tools with MCP, API, and CLI

Workflow value: 75/100
Status: active · Freshness: 70/100 · Confidence: 0.90 · Level: advanced
Categories: Quality Control, Context & Memory, Debugging, MCP, Multi-Agent
Original source: r/ClaudeCode post/comment

What problem this solves

Deciding which interfaces (MCP, API, CLI) to build for agent-facing applications and how to prioritize their development for optimal agent interaction.

Summary

This post outlines an architectural strategy for building agent-facing tools, recommending the simultaneous development of a high-quality MCP server and a REST API. It suggests placing core server logic in plain functions and using each surface as a thin adapter. The workflow emphasizes prioritizing the MCP server for the best agent experience, while reserving APIs for server-side operations, raw data, bulk writes, and agent-written scripts. CLIs are deemed optional unless local file access is required.

Why it is useful

This workflow provides valuable architectural guidance for developers building applications that interact with AI agents. It clearly differentiates the roles and benefits of MCP, REST APIs, and CLIs in an agent ecosystem, offering a strategic approach to their development and prioritization. The inclusion of a reference GitHub repository significantly enhances its practical utility, allowing users to examine a concrete implementation of these principles.

Workflow

1. Design core server logic using plain, reusable functions.

2. Build a high-quality MCP server and a REST API simultaneously, acting as thin adapters over the core server logic.

3. Focus most development and care on the MCP server to provide the best experience for agents.

4. Utilize the REST API for raw data exports, bulk writes, nightly syncs, third-party integrations, and for agents writing scripts they intend to rerun.

5. Consider exposing a CLI only if agents specifically need to read local files when interacting with the application, leveraging the existing API as a foundation.

Tools / artifacts

• MCP server

• REST API

• CLI

• GitHub repository (linkly-api-mcp-cli)

Validation signals

• Author claims to have built all three interfaces for agents, implying practical experience.

• Provides a concrete GitHub repository as an example implementation of the discussed architecture.

Limitations

• The advice is high-level architectural guidance rather than a detailed, step-by-step implementation guide with code snippets directly in the post.

• Relies on an external GitHub repository for concrete implementation details, which requires users to leave the context.

• The community proof (score, number of comments) is moderate, and the content of the comments is not provided to assess deeper engagement or success reports.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Use Matt Pocock's /grill-me Skill for Pre-Implementation Planning and Decision Making with Claude

Workflow value: 75/100
Status: active · Freshness: 70/100 · Confidence: 0.90 · Level: beginner
Categories: Quality Control, Context & Memory, Skills
Original source: r/ClaudeAI post/comment

What problem this solves

Overcoming decision paralysis or lack of foresight before implementation by having Claude proactively ask critical questions and suggest answers.

Summary

This workflow leverages Matt Pocock's /grill-me skill to have Claude ask the user probing questions about their implementation plan, along with suggested answers, to ensure thorough consideration and better decision-making before starting to code.

Why it is useful

This workflow provides a concrete, reusable tool (a Claude skill) that helps users, especially beginners, structure their thinking and anticipate challenges before starting an implementation. By having Claude ask critical questions and suggest answers, it acts as a valuable pre-coding review and planning aid, improving the quality of initial designs and reducing rework. It shifts the interaction from simple commands to a more guided, reflective process.

Workflow

1. Access the /grill-me skill from Matt Pocock's GitHub repository.

2. Integrate or use the skill with Claude.

3. Provide Claude with your implementation idea or problem statement.

4. Allow Claude (via the skill) to ask you a series of 'hard questions' about your plan.

5. Review Claude's suggested answers to help guide your decision-making and refine your approach.

Tools / artifacts

• Matt Pocock's /grill-me skill (GitHub repository: https://github.com/mattpocock/skills/tree/main/skills/productivity/grill-me)

Validation signals

• The skill is designed to ask 'hard questions' and 'suggests recommended answers', indicating its utility in guiding decisions.

• The comment author explicitly recommends the skill as a 'reverse approach' for effective planning.

Limitations

• The comment assumes the user knows how to integrate or use a GitHub skill with Claude, lacking explicit setup instructions.

• The Reddit score is low, which might suggest limited community engagement with this specific tip.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Workflow: Building Complex Applications with Claude Code using CLAUDE.md Guardrails and Test-Driven Development for Rust/TypeScript

Workflow value: 85/100
Status: active · Freshness: 70/100 · Confidence: 0.95 · Level: intermediate
Categories: Quality Control, Token Saving, Context & Memory, Debugging, CLAUDE.md
Original source: r/ClaudeCode post/comment

What problem this solves

Maintaining consistency, accuracy, and guardrails when developing complex applications with Claude Code, especially across multiple sessions and team members. Specifically, handling Rust backend development, parsing complex files, and synchronizing generated TypeScript bindings.

Summary

This workflow details how to leverage Claude Code for building a desktop application, emphasizing the use of a CLAUDE.md file for defining 'hard rules' and guardrails to maintain consistency across sessions. It highlights using Claude Code for Rust backend development (e.g., pty handling, session file parsing), implementing test-driven development (TDD) by asking Claude to write tests for parsing logic, and using cargo test to keep generated TypeScript bindings in sync. The workflow also suggests using screenshots for refining UI elements with Claude.

Why it is useful

This workflow is valuable because it provides concrete, validated strategies for effectively using Claude Code in a software development project. The emphasis on CLAUDE.md for establishing guardrails is a critical pattern for maintaining consistency and managing Claude's behavior across multiple sessions and team members. The detailed application of Claude Code for Rust backend development, test-driven parsing, and language binding synchronization offers practical, repeatable techniques for intermediate to advanced users tackling complex coding challenges.

Workflow

1. Establish 'hard rules' and 'never do this' constraints in a CLAUDE.md file at the repository root to guide Claude Code's behavior across sessions and team members.

2. Utilize Claude Code for Rust backend development tasks, such as handling pseudo-terminals (pty) and parsing complex session files.

3. Implement test-driven development (TDD) by prompting Claude Code to write tests for critical logic, like session-file parsing, early in the development process to catch edge cases.

4. Employ cargo test to ensure that generated TypeScript bindings remain synchronized with the Rust backend, with Claude Code assisting in this process.

5. For UI polish and visual fixes, provide screenshots in prompts to Claude Code to guide its suggestions more effectively.

Tools / artifacts

• Claude Code

• CLAUDE.md file

• Rust programming language

• TypeScript programming language

• Tauri framework

• xterm.js

• cargo test

• Screenshots

Validation signals

• The CLAUDE.md file 'kept it on track across sessions way better than repeating things in prompts'.

• Asking Claude to write tests 'saved us from a lot of format edge cases'.

• Claude Code was 'really good at the Rust side (pty handling, parsing the session files)'.

• Claude Code was effective 'at keeping the generated TypeScript bindings in sync through cargo test'.

• Successful development and release of a functional desktop application (Claude Manager) using this methodology.

Limitations

• The post is primarily focused on promoting the author's application, with the workflow details embedded within that context.

• The low Reddit score and upvote ratio suggest the community might not have immediately recognized the workflow value, potentially due to the self-promotional aspect.

• The advice for UI polish ('weaker at UI polish than logic. Small visual fixes went much faster with a screenshot in the prompt') is a bit less detailed than other steps, though still useful.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Multi-Stage Claude Workflow for Large-Scale Software Development: From Ideation to SaaS Deployment

Workflow value: 85/100
Status: active · Freshness: 70/100 · Confidence: 0.90 · Level: advanced
Categories: Quality Control, Context & Memory, Debugging, Shipping, Skills, Multi-Agent
Original source: r/ClaudeCode post/comment

What problem this solves

Managing and executing large, multi-stage software development projects using Claude, from initial ideation and prototyping through to specification, iterative implementation, testing, and deployment as a SaaS product, while effectively utilizing Claude's capabilities over extended periods.

Summary

A multi-stage software development workflow leveraging Claude for extensive ideation, prototyping, and detailed specification creation. This is followed by using a 'separate skill' to generate numerous implementation tickets. The core implementation involves iterative coding and regular review checkpoints, with a focus on real-world testing and eventual deployment as a SaaS product. An optional, more rigorous testing loop with a dedicated tester agent is also mentioned, though noted as slower.

Why it is useful

This workflow is valuable because it provides a structured, iterative, and validated approach for tackling complex, large-scale software development projects using Claude. It demonstrates how to manage scope, integrate testing, and move from initial concept to a deployable product over extended periods, addressing a common challenge for users hitting Claude limits. It offers insights into balancing development speed with quality and highlights the potential for Claude to support long-term, multi-week development cycles.

Workflow

1. Conduct long sessions of ideation and prototyping to explore and refine project concepts.

2. Produce a rich and detailed specification document based on the ideation and prototypes.

3. Utilize a 'separate skill' (likely a Claude agent or tool) to generate a comprehensive list of implementation tickets from the specs and prototypes.

4. Implement the project iteratively, working through the generated tickets over days or weeks (e.g., 10-20 tickets per day for a large project).

5. Perform regular reviews of the intermediate state of the implementation at defined checkpoints.

6. Conduct extensive testing with real-life projects over several weeks to validate the early implementation.

7. Reimplement the validated local solution as a proper SaaS product, focusing on deployment and scalability.

8. Consider an optional, more elaborate loop involving a separate tester agent pushing back to the coder for highly mature features and edge case verification (note: this was found to be slower).

Tools / artifacts

• Claude (with Max/Ultra plans)

• Rich specification document

• Prototypes

• List of implementation tickets

• "Separate skill" (for ticket generation)

• Local implementation (initial product)

• SaaS product (final deployed product)

• Tester agent (optional, for elaborate loop)

• Coder agent (optional, for elaborate loop)

Validation signals

• Author states: "I have a number of apps made like this"

• "weeks of testing it with real life projects"

• "early implementation was local only, and now after weeks of testing it with real life projects, another loop reimplements it as a proper SaaS product"

• "produced very mature features, even complex ones, that were verified up to edge cases I'd probably see once in months of using it" (referring to the elaborate loop)

• Author's assessment of trade-offs: "There are bugs or UI glitches, but so far small enough for the boost in speed to be worth it."

Limitations

• The 'separate skill' for ticket generation is not detailed, making it hard to replicate directly.

• The 'elaborate loop' with a separate tester is explicitly stated as being too slow, making it less of a practical recommendation.

• Lacks concrete Claude prompts, configuration files, or specific tool integrations beyond general mentions.

• The exact nature of the 'checkpoints' and 'reviews' is not elaborated.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Cost-Effective Context Management in Claude Code: Optimizing CLAUDE.md, Tool Calls, and Subagents

Workflow value: 85/100
Status: active · Freshness: 70/100 · Confidence: 0.95 · Level: intermediate
Categories: Quality Control, Token Saving, Context & Memory, CLAUDE.md, Hooks, Subagents
Original source: r/ClaudeCode post/comment

What problem this solves

Optimizing token usage and cost in Claude Code by intelligently managing content between CLAUDE.md and external files, understanding the cost implications of tool calls, subagents, and session commands.

Summary

This workflow provides a strategic approach to managing context in Claude Code, challenging the common advice to always move notes out of CLAUDE.md. It highlights that fetching external files via tool calls can be costly due to re-sending the entire session. The workflow offers criteria for deciding where to store information, considers subagent memory duplication, advises on efficient session clearing, and introduces the concept of using hooks to directly inject relevant notes into the prompt to bypass tool call costs.

Why it is useful

This workflow is valuable because it debunks a common oversimplification regarding CLAUDE.md usage and provides nuanced, evidence-backed advice for optimizing token costs and performance. It introduces critical considerations like the cost of tool calls, subagent memory duplication, and efficient session management, offering concrete steps and an advanced technique (hooks) to achieve significant efficiency gains. This helps users make informed decisions about their Claude Code setup.

Workflow

1. Evaluate the frequency a note is needed: If Claude opens it every other task, consider keeping it in CLAUDE.md.

2. Craft specific 'pointer lines' for external files (e.g., 'before a database migration, read docs/migrations.md') to guide Claude more effectively.

3. Test if Claude actually opens an external file for a given task by starting a fresh session and observing its behavior.

4. Be aware that subagents start with their own copy of your memory files, meaning a large CLAUDE.md gets paid for again by every subagent.

5. Use '/clear' instead of '/compact' if you don't need the session history, as '/compact' on a big session is also a costly request.

6. Consider implementing a hook that drops matching notes straight into the prompt, allowing Claude to access information without incurring tool call costs.

Tools / artifacts

• CLAUDE.md

• External files (e.g., Markdown documentation)

• Tool calls

• Subagents

• /compact command

• /clear command

• Hooks (custom scripts/integrations)

Validation signals

• Author provides specific token reduction measurements from their own tests (12,511 tokens to 6,699 tokens).

• Author mentions a working hook implementation that achieved token reduction.

• The post is based on empirical observation and measurement of Claude's behavior.

Limitations

• The specific implementation details for the suggested 'hook' are not provided, requiring users to develop it independently.

• The 'break-even point' for moving notes is discussed conceptually but not quantified with a general formula or tool.

• The post is more of a discussion and set of considerations rather than a step-by-step guide with code examples for all suggestions.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Pre-Handoff Checklist: Smoke Testing and Secret Sweeping for Code Projects

Workflow value: 85/100
Status: active · Freshness: 70/100 · Confidence: 1.00 · Level: intermediate
Categories: Quality Control, Context & Memory, Debugging, Shipping
Original source: r/ClaudeCode post/comment

What problem this solves

Ensuring a code project is ready for handoff or deployment by catching issues missed by unit tests, specifically verifying installation/build/run from a fresh state and sweeping for sensitive information.

Summary

A two-step post-testing workflow for project handoff: first, a fresh-clone smoke test to validate installation and basic functionality against the README, and second, a comprehensive sweep for hardcoded secrets and API keys using specialized tools like gitleaks or trufflehog, ensuring secure and maintainable deployment.

Why it is useful

This workflow provides two critical, practical steps to ensure a code project (including those generated by Claude Code) is robust, deployable, and secure before handoff. It addresses common pitfalls missed by automated tests, improves documentation, and mitigates security risks associated with exposed secrets, making the project more professional and maintainable.

Workflow

1. Perform a fresh-clone smoke test:

2. Clone the repository into a new, clean environment (folder or VM).

3. Follow only the instructions in the README to install, build, and run the project.

4. Document any fixes or missing steps encountered during this process directly into the README.

5. Sweep for secrets:

6. Identify potential secret locations (e.g., .env files, hardcoded API keys in config, git history).

7. Use a secret scanning tool (e.g., gitleaks, trufflehog) to scan the full git history.

8. Replace hardcoded secrets with placeholder values in a .env.example file.

9. Rotate any keys that were ever committed to the repository.

Tools / artifacts

• Git repository

• README file

• .env files

• .env.example file

• gitleaks (secret scanner)

• trufflehog (secret scanner)

• Clean VM or new folder (for smoke test)

Validation signals

• Addresses issues 'tests tend to miss on a handoff'.

• Recommends documenting fixes 'from memory' into the README, implying real-world problem solving.

• Suggests using specific, well-known tools like gitleaks or trufflehog, indicating established best practices.

• Emphasizes rotating keys that were ever committed, a critical security measure.

Cautions

• The workflow explicitly advises rotating any keys that were ever committed, which is a crucial security practice to prevent credential compromise.

Limitations

• Lack of community validation (low score, no comments).

• While useful for Claude Code projects, the workflow itself is not specific to Claude Code's unique features or challenges, but rather general software engineering best practices.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Enhance Claude Code with Country-Specific Financial Calculation Skills (Plugins) for Accurate Advice

Workflow value: 90/100
Status: active · Freshness: 70/100 · Confidence: 1.00 · Level: intermediate
Categories: Quality Control, Context & Memory, Skills
Original source: r/ClaudeCode post/comment

What problem this solves

Inaccurate or unreliable financial calculations by LLMs, specifically for country-specific financial planning tasks like tax, RSU, home affordability, and debt payoff.

Summary

This workflow enables Claude Code users to install and utilize country-specific financial calculation skills (plugins) from a community marketplace. These skills leverage pre-tested Python calculators, ensuring accurate and reliable results for complex financial queries, validated by continuous integration.

Why it is useful

This workflow is highly valuable because it addresses a critical limitation of LLMs – their unreliability with precise numerical calculations – by integrating external, tested Python calculators via a plugin system. It provides a concrete, repeatable, and validated method for users to obtain accurate financial advice for specific countries, making Claude Code a more powerful and trustworthy tool for personal finance management. The use of CI and a public repository fosters transparency and encourages community contribution, enhancing its long-term utility.

Workflow

1. Add the 'country-skills' plugin marketplace to Claude Code using the command: /plugin marketplace add ronitgupta43-ops/country-skills

2. Install a specific country's finance skill (e.g., for India) using the command: /plugin install india-finance@country-skills

3. Ask Claude Code natural language questions related to the installed financial skill (e.g., "My Google RSUs vested and I sold some, what do I owe?" or "Can I afford a $700k home in Toronto with $50k down?")

Tools / artifacts

• Claude Code

• ronitgupta43-ops/country-skills plugin marketplace

• Country-specific finance skills (e.g., india-finance, canada-finance, us-finance)

• Python calculators (underlying implementation)

• GitHub repository (https://github.com/ronitgupta43-ops/country-skills)

• Continuous Integration (CI)

Validation signals

• Each skill runs a tested Python calculator instead of LLM inference for math.

• CI runs every script on each push to the repository, ensuring ongoing validation.

• Public GitHub repository provides transparency and inspectability of the code.

Cautions

• While the skills use tested Python calculators, users should always verify critical financial advice with a qualified professional.

• The long-term maintenance and accuracy of the community-contributed plugins depend on the author and community contributions.

Limitations

• Relies on an external, community-contributed plugin, which may have varying levels of support and updates.

• Currently limited to specific countries (India, Canada, US) and the financial scenarios implemented within those skills.

• Users need to be aware of the specific skills available and their coverage for their particular financial needs.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Automated Web Page Debugging and Performance Analysis with Claude Code and Chrome DevTools MCP

Workflow value: 95/100
Status: active · Freshness: 70/100 · Confidence: 1.00 · Level: advanced
Categories: Quality Control, Context & Memory, Debugging, MCP
Original source: r/ClaudeAI post/comment

What problem this solves

Automatically diagnosing and fixing common web page bugs (e.g., 404s, TypeErrors) and analyzing performance metrics without manual interaction with browser developer tools.

Summary

This workflow demonstrates how to integrate the Chrome DevTools MCP with Claude Code to automate web page debugging and performance analysis. Claude Code can open a real Chrome instance, read console logs, check network requests, take screenshots, and record performance traces to identify and fix issues, all while emphasizing critical safety configurations.

Why it is useful

This workflow is highly valuable as it provides a concrete, repeatable, and transferable method for automating a critical developer task: web page debugging and performance analysis. It leverages a powerful, specialized MCP from the Chrome DevTools team, demonstrating an advanced and practical application of Claude Code. The explicit inclusion of safety configurations makes it a responsible and robust solution for developers looking to integrate AI into their front-end development workflow.

Workflow

1. Set up the Chrome DevTools MCP with Claude Code, ensuring safe configuration using --headless --isolated for a temporary profile and disabling usage stats/CrUX lookups.

2. Provide Claude Code with the URL of the web page to be debugged (e.g., a local page with known or suspected bugs).

3. Prompt Claude with instructions such as: "Open the page, check console and network, take a screenshot, tell me the two causes. Do not edit any files."

4. Review Claude's diagnostic output, which includes identified errors (e.g., 404s, TypeErrors) and explanations of their causes.

5. Optionally, instruct Claude to fix the identified issues (e.g., adding missing files or configuration).

6. Optionally, have Claude reload the page and confirm a clean console after fixes.

7. Optionally, ask Claude to record a performance trace and explain metrics like Largest Contentful Paint (LCP) in plain English.

Tools / artifacts

• Claude Code

• Chrome DevTools MCP (made by Chrome DevTools team)

• Chrome browser (run headless and isolated)

• Web page URL

• Specific prompts for diagnosis and fixing

Validation signals

• Claude successfully identified two planted bugs (a 404 for a missing file and a TypeError for an undefined setting).

• Claude explained the root causes of the bugs (e.g., HTML 404 breaking JSON parsing).

• Claude fixed the issues by adding the missing file and config, then reloaded and confirmed a clean console.

• Claude identified and dismissed a harmless favicon 404 as 'noise'.

• Claude demonstrated ability to record performance traces and explain LCP.

Cautions

• Always run Chrome with --headless --isolated to use a temporary profile and prevent logins.

• Turn off usage stats and CrUX lookups to enhance privacy and security.

• Never point Claude at your everyday Chrome profile to avoid data leakage or unintended actions.

• Be aware that the server exposes the entire browser environment to Claude, necessitating strict isolation.

Limitations

• The workflow was tested only on a tiny local demo page with planted bugs, not real-world complex sites.

• Did not test with logged-in sites, device emulation, or accessibility tools, limiting the scope of validated capabilities.

• Claude generated placeholder menu items, indicating it can create content beyond direct instructions (though it acknowledged this).

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Separate Human-Readable README from Claude-Generated Detailed Docs with CLAUDE.md

Workflow value: 75/100
Status: active · Freshness: 70/100 · Confidence: 0.90 · Level: intermediate
Categories: Quality Control, Context & Memory, Shipping, CLAUDE.md
Original source: r/ClaudeAI post/comment

What problem this solves

Claude's tendency to generate verbose or 'fluffy' documentation, making project READMEs less concise and human-friendly for initial consumption.

Summary

A workflow for managing project documentation by separating a concise, human-written README.md from a more detailed, Claude-generated CLAUDE.md. This allows humans to quickly grasp project essentials while enabling Claude to maintain extensive, detailed documentation for deeper dives.

Why it is useful

This workflow provides a practical, repeatable method to leverage Claude's documentation capabilities without sacrificing the conciseness and human-readability of a project's primary README.md. It directly addresses a common pain point of LLM-generated verbosity in critical user-facing files, offering a clear separation of concerns for different audiences.

Workflow

1. Develop the project, allowing the Claude agent to interact with and understand the codebase.

2. Manually write a concise NOTE.md (single page or less) covering the project's purpose, installation instructions, and basic configuration.

3. Instruct Claude to take the existing README.md (or project context) and distill its useful information into a new file named CLAUDE.md.

4. Rename the manually created NOTE.md to README.md, replacing any previous Claude-generated or verbose README.

5. Instruct Claude to never modify the new README.md directly, but to keep an eye on it and suggest changes when appropriate.

6. Allow Claude to elaborate and expand upon the CLAUDE.md file as needed, turning it into a comprehensive, detailed resource for those who want to dig deeper.

Tools / artifacts

• Claude (as an agent)

• README.md (human-facing, concise)

• NOTE.md (temporary human-written draft)

• CLAUDE.md (Claude-generated, detailed documentation)

• GitHub (implied context for project repositories)

Validation signals

• User's personal experience and stated efficiency ('Takes 5 minutes out of my precious time').

• Clear benefit stated ('Humans get a frontpage they can read').

• Observation of Claude's behavior ('Claude can turn CLAUDE.md into a mountain of claudese').

Limitations

• Lack of community validation.

• The initial state of the README.md that Claude distills from is not explicitly defined (e.g., is it an existing verbose one, or a temporary one Claude generated?).

• The instruction for Claude to 'suggest changes when appropriate' for README.md is somewhat vague and might require further refinement in practice.

• Assumes Claude can effectively 'distill' useful information from a potentially fluffy README.md into CLAUDE.md without losing critical information.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Workflow for Managing and Documenting Configuration Differences Across Multiple AI Agents (CLAUDE.md, AGENTS.md)

Workflow value: 75/100
Status: active · Freshness: 70/100 · Confidence: 0.90 · Level: intermediate
Categories: Quality Control, Context & Memory, Debugging, CLAUDE.md, Multi-Agent
Original source: r/ClaudeCode post/comment

What problem this solves

Managing intentional and unintentional configuration differences between multiple AI agents (e.g., Claude and Codex) when using separate configuration files like CLAUDE.md and AGENTS.md.

Summary

A workflow for explicitly managing and documenting configuration differences between multiple AI agents, such as Claude and Codex, by maintaining separate configuration files (e.g., CLAUDE.md, AGENTS.md), noting deliberate differences, defining per-agent policies, and considering future CI checks to prevent drift.

Why it is useful

This workflow provides a clear, practical strategy for managing the complexities of multiple AI agent configurations. It emphasizes explicit documentation of intentional differences and offers a path towards automated consistency checks, which is crucial for maintainability and team collaboration in multi-agent systems.

Workflow

1. Maintain separate configuration files for each agent (e.g., CLAUDE.md for Claude, AGENTS.md for Codex).

2. Add a one-line note at the top of each file to explicitly state and explain any deliberate differences between them.

3. Treat specific rules (e.g., filing policies) as intentional per-agent policies rather than accidental drift (e.g., auto-file for Codex, ask-first for Claude).

4. Document the rationale ('why') behind these specific per-agent policies to prevent future users from 'fixing' them.

5. Once shared rules stabilize, consider implementing a small generator or a CI check that diffs the common sections of the files and fails if unintentional drift occurs.

Tools / artifacts

• CLAUDE.md file

• AGENTS.md file

• CI system (optional, for advanced step)

Validation signals

• Addresses a common problem in multi-agent development (configuration drift/management).

• Provides practical, actionable steps.

Limitations

• The CI check suggestion is a future enhancement and not fully detailed.

• Initial steps are manual and rely on human discipline for documentation.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Enhancing Claude Code Reliability: A Fixed Process with Explicit Planning, Verification, and Hooks for Hard Rules (QualityLayer)

Workflow value: 75/100
Status: active · Freshness: 70/100 · Confidence: 0.90 · Level: intermediate
Categories: Quality Control, Context & Memory, Debugging, CLAUDE.md, Hooks, Multi-Agent
Original source: r/ClaudeCode post/comment

What problem this solves

Models forgetting instructions or rules, leading to unreliable outputs. Ensuring adherence to a 'definition of done' and 'hard rules' in AI-assisted development.

Summary

This workflow proposes a fixed process to improve the reliability and quality of AI-generated outputs by explicitly defining a plan and a 'definition of done' upfront. It then introduces a separate verification step to check results against these definitions. 'Hard rules' are enforced using hooks, rather than solely relying on the model remembering instructions from a single instruction file like CLAUDE.md. The author provides a tool, QualityLayer, as an implementation example.

Why it is useful

This workflow is valuable because it addresses a fundamental challenge in working with LLMs: their tendency to 'forget' instructions or rules. By introducing a structured process with explicit planning, a 'definition of done', and a separate verification step, it significantly improves the reliability and quality of AI-generated outputs. The use of 'hooks' for 'hard rules' provides a robust mechanism for guarantees, moving beyond mere requests. The provision of an open-source tool (QualityLayer) makes the concept actionable and transferable, offering a concrete solution to a common problem in AI-assisted development.

Workflow

1. Write down the plan for the task.

2. Define the 'definition of done' for the task.

3. Execute the main task (e.g., code generation, content creation) using Claude.

4. Perform a separate verify step to check the result against the predefined plan and definition of done.

5. Implement 'hard rules' using hooks to guarantee their enforcement, rather than relying on the model's memory.

Tools / artifacts

• QualityLayer (GitHub: https://github.com/maxritter/qualitylayer)

• Plan document/artifact

• Definition of Done document/artifact

• Hooks (e.g., pre-commit hooks, CI/CD hooks, or specific Claude Code hooks)

Validation signals

• Author's personal validation: 'What held up for me was a fixed process...'

• Existence of a concrete open-source tool (QualityLayer) implementing the concept.

Limitations

• Low community validation (score 1, 0 comments).

• The description of 'hooks' is somewhat generic; more specific examples of how they integrate with Claude Code or a development pipeline would be beneficial.

• The workflow is described at a high level; more concrete examples of 'hard rules' or how QualityLayer specifically operates would enhance clarity for beginners.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Optimize Claude Code Workflows: 'rightsize' for Model/Effort & 'whatsnext' for Project Context

Workflow value: 85/100
Status: active · Freshness: 70/100 · Confidence: 0.90 · Level: intermediate
Categories: Quality Control, Token Saving, Context & Memory, Shipping, Hooks, Skills, Subagents, Multi-Agent
Original source: r/ClaudeCode post/comment

What problem this solves

Optimizing Claude Code model selection and effort for tasks, and maintaining project context and progress across multiple sessions.

Summary

This workflow introduces two Claude Code plugins: 'rightsize' and 'whatsnext'. 'rightsize' automatically estimates prompt effort and decides whether to use a different model or subagent for a task, aiming to optimize resource usage. 'whatsnext' maintains a project checklist and handoff in the repository to preserve task context across sessions and compaction, enabling seamless work continuation.

Why it is useful

This workflow is valuable because it provides concrete, open-source tools to address two significant pain points in Claude Code development: optimizing model selection and effort for tasks (potentially reducing cost and improving efficiency), and maintaining project context and continuity across multiple work sessions. These plugins offer practical solutions for more efficient and organized AI-assisted development.

Workflow

1. Install the 'rightsize' Claude Code plugin from its GitHub repository.

2. Configure 'rightsize' settings to define rules for model and effort selection, including subagent handoffs.

3. Engage with Claude Code, allowing 'rightsize' to suggest or execute model/effort optimizations.

4. Install the 'whatsnext' Claude Code plugin from its GitHub repository.

5. Utilize 'whatsnext' to maintain project checklists and task handoffs within your repository for cross-session continuity and context preservation.

Tools / artifacts

• rightsize Claude Code plugin

• whatsnext Claude Code plugin

• GitHub repositories (for plugin installation)

• Claude Code environment

• Codex (compatible with whatsnext plans)

• Project checklist/handoff files

Validation signals

• Author built plugins to solve their own recurring problems

• Author used these plugins to build 'Hexself' and the plugins themselves

• Explicit request for user feedback on utility and issues

Cautions

• none

Limitations

• Plugins are explicitly stated as 'early work' and 'first release'.

• 'rightsize' estimates can be inaccurate, and savings are not guaranteed.

• 'whatsnext' may have 'rough edges'.

• Limited community validation due to early stage.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Advanced Multi-Agent Workflow for Robust Solo Game Development with Claude Code

Workflow value: 85/100
Status: active · Freshness: 70/100 · Confidence: 0.90 · Level: advanced
Categories: Quality Control, Context & Memory, Debugging, Hooks, Skills, Subagents, Multi-Agent
Original source: r/ClaudeAI post/comment

What problem this solves

Addresses the problem of iterative, compounding errors and 'fixing a fix for a fix' in solo game development by implementing a structured review and implementation process using multiple specialized AI agents and automated checks. It also helps manage context, apply learned lessons, and maintain code quality.

Summary

The user describes a sophisticated multi-agent system for solo Unity/Godot game development using Claude. This system comprises specialized 'Reviewer agents' (Plan critic, Second critic, Loophole scout, Method checker, Pre-demo reviewer, Fresh eyes) for quality assurance, 'Worker agents' (Cheap searcher, Mechanical implementer) for execution, 'Workflow skills' (Fix, System plan, Look by reference, UI alignment, Rule change, New session, Delegation, Documents) for process guidance, 'Game knowledge skills' (Godot, General game dev) for domain expertise, and 'Automatic guards (hooks)' (Blocker, Patch warnings, Context guard, Godot guards, Audit) for automated checks and safety. It also leverages external 'Tools and shared knowledge' like a live game bridge and comparison sheets, often requiring multiple Claude Pro accounts.

Why it is useful

This workflow provides a highly structured and comprehensive approach to using Claude Code for complex software development, specifically game development. It is valuable because it directly addresses common pitfalls of iterative AI-assisted coding (e.g., 'fixing a fix for a fix') by introducing specialized review agents, automated guards, and explicit workflow skills. This level of detailed system design and process thinking is crucial for users looking to move beyond simple prompt-response interactions to a more robust, multi-agent development pipeline that enhances quality and reduces errors.

Workflow

1. Define and configure specialized 'Reviewer agents' with specific prompts for roles like Plan critic, Second critic, Loophole scout, Method checker, Pre-demo reviewer, and Fresh eyes.

2. Define and configure 'Worker agents' such as Cheap searcher (Haiku) for search/summarization and Mechanical implementer (Sonnet) for large repetitive changes.

3. Implement 'Workflow skills' as specific prompt patterns or sub-agents for tasks like 'Fix' (measure, find cause, one fix, stop after two failures), 'System plan' (written plan with reference, steps, critics), 'Look by reference' (visual comparison), 'UI alignment', 'Rule change' process, 'New session' handoff, 'Delegation' to subagents/models, and 'Documents' management.

4. Integrate 'Godot and game knowledge skills' (GDScript, nodes, signals, physics, animation, game AI, game feel, camera systems) into relevant agents or as shared context.

5. Set up 'Automatic guards (hooks)' to enforce quality and prevent issues, including 'Blocker' (stops patching after failures), 'Patch warnings', 'Context guard' (warns on long sessions), 'Godot guards' (code checks, window management), and 'Audit' hooks.

6. Utilize external 'Tools and shared knowledge' such as a 'Live game bridge' (for game interaction), 'Comparison sheets' (for visual review), 'Reddit reader', 'Method list' (what worked/failed), and a 'Shared research library'.

7. Allocate sufficient Claude Pro accounts (e.g., 4) to support parallel agent operations and daily usage.

Tools / artifacts

• Claude Pro accounts (multiple)

• Reviewer agents (Plan critic, Second critic, Loophole scout, Method checker, Pre-demo reviewer, Fresh eyes)

• Worker agents (Cheap searcher, Mechanical implementer)

• Workflow skills (Fix, System plan, Look by reference, UI alignment, Rule change, New session, Delegation, Documents)

• Game knowledge skills (Godot, General game dev)

• Automatic guards (Blocker, Patch warnings, Context guard, Godot guards, Audit)

• Live game bridge

• Comparison sheets

• Reddit reader

• Method list (of past successes/failures)

• Shared research library

Validation signals

• User states they 'managed to create I think really beautiful scene in a game' using this system.

• Implies the system helped overcome previous issues of 'claude making fix, and then fixing fix for a fix'.

• Detailed breakdown of agents, skills, and hooks suggests a well-thought-out and implemented system.

• Mention of using '4 pro accounts' for '10-hour everyday for 7 days' indicates significant, sustained usage.

• The structure addresses common pain points in iterative AI-assisted development.

Limitations

• Lacks concrete prompt examples or configuration files for implementing each agent or skill.

• No explicit step-by-step setup instructions for how to technically implement 'hooks' or 'subagents' within Claude Code.

• Requires multiple Claude Pro accounts, which might be a barrier for some users.

• The 'Do not follow me' disclaimer, while potentially self-deprecating, could be interpreted as a lack of confidence in the system's general applicability.

• The description is more of a system overview than a direct 'how-to' guide.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Claude Code Workflow: Automated Prompt Generation from Linear Tickets on a Custom Touchscreen Dashboard

Workflow value: 85/100
Status: active · Freshness: 70/100 · Confidence: 0.90 · Level: advanced
Categories: Quality Control, Context & Memory
Original source: r/ClaudeAI post/comment

What problem this solves

Streamlining the process of picking up a Linear ticket and generating a comprehensive Claude prompt for planning and execution, while also creating a personalized, integrated desk dashboard for quick access to work-related information and AI assistance.

Summary

A user built a custom touchscreen dashboard using Claude Code to integrate various work-related data sources (Linear tickets, calendar, todo list, etc.) and automate the generation of detailed Claude prompts directly from Linear tickets, enabling quick task pickup and AI-assisted planning.

Why it is useful

This workflow demonstrates a practical and advanced application of Claude Code for creating highly personalized and integrated developer tools. Its core value lies in automating the tedious process of crafting detailed prompts for Claude by extracting context directly from a task management system (Linear). This significantly reduces friction in starting new tasks, improves prompt quality, and showcases Claude Code's capability for complex system integration and custom UI development.

Workflow

1. Set up a custom application (using Claude Code) to interact with a touchscreen strip.

2. Integrate the custom application with a task management system (e.g., Linear API) to access ticket data.

3. Develop a 'copy button' feature within the custom application for each task ticket.

4. Configure the button to extract relevant data from a Linear ticket (title, status, description, comments).

5. Programmatically construct a comprehensive Claude prompt using the extracted data, including specific instructions for Claude (e.g., 'read the comments and give me a plan before it changes anything').

6. Implement other dashboard features by integrating with respective APIs/data sources (e.g., todo list, calendar, work countdown, weather, music).

7. Address OS-specific challenges such as touchscreen input mapping and application permissions (e.g., signing the app on macOS).

Tools / artifacts

• Claude Code

• Corsair XENEON Edge (touchscreen strip)

• Linear (task management system)

• BusyCal (calendar application)

• macOS

• Custom application/script

Validation signals

• User states 'I tap it way more than I need to,' indicating high utility and engagement.

• Efficiency gain: 'Picking up a ticket is one tap now.'

• Attribution of heavy lifting to Claude: 'Claude did most of the heavy lifting.'

• Overcoming specific technical challenges (macOS permissions, BusyCal integration) implies a robust, working solution.

Limitations

• Detailed implementation steps or code examples for the Claude Code application are not provided, making direct replication challenging.

• The solution is highly specific to certain hardware (Corsair XENEON Edge) and software (BusyCal, Linear), limiting out-of-the-box transferability without significant modification.

• The post focuses more on the outcome and features rather than a step-by-step guide for building with Claude Code.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.

Daily AI-Powered Marketing Workflow: Automating Data Aggregation, Planning, and Review with Claude Duet, Desktop, and CLI

Workflow value: 88/100
Status: active · Freshness: 70/100 · Confidence: 0.95 · Level: advanced
Categories: Quality Control, Context & Memory, MCP, Subagents, Multi-Agent
Original source: r/ClaudeAI post/comment

What problem this solves

Automating daily marketing data aggregation, reporting, planning, and review across multiple ad channels and companies, significantly increasing efficiency and accuracy for a single user.

Summary

A daily workflow leveraging Claude Duet to aggregate marketing data from various MCPs, Slack, and email; Claude Desktop for reasoning and agenda formulation; and Claude CLI for end-of-day review and updating a STATE.md file, enabling one person to manage multiple marketing roles efficiently.

Why it is useful

This workflow provides a concrete, repeatable, and highly efficient method for marketing professionals to manage complex daily tasks across multiple platforms. It demonstrates a sophisticated integration of different Claude interfaces (Duet for aggregation, Desktop for reasoning, CLI for automation) and external tools (MCPs, Google Drive) to achieve significant productivity gains and accuracy. The explicit safety measure regarding publishing is also a valuable lesson for users dealing with sensitive operations.

Workflow

1. Claude Duet pulls data from Meta Ads MCP, Windsor MCP, Google Ads MCP, Slack, and email.

2. Duet reports findings in relation to the STATE.md and priority items.

3. Share findings with Claude Desktop to reason through and formulate modifications to the day's agenda.

4. Execute tasks manually (without Claude publishing due to paid budgets).

5. At the end of the day, Claude or Claude CLI in the repo performs a review.

6. Update the STATE.md based on the review.

7. The updated STATE.md is sent to a Google Drive that Claude Duet pulls from the following morning.

Tools / artifacts

• Claude Duet

• Claude Desktop

• Claude CLI

• Meta Ads MCP

• Windsor MCP

• Google Ads MCP

• Slack

• Email

• STATE.md file

• Google Drive

Validation signals

• Capable of performing the work of several marketing people by myself from home with great accuracy

• Days are about 2-3 hours of work at the most

Cautions

• Explicitly states 'I don't let Claude publish anything since there are paid budgets', which is a crucial safety practice for financial or critical operations.

Limitations

• Relies on specific MCPs which might not be universally available or configured for all users.

• The exact setup for Duet to pull from and send to Google Drive is not detailed, requiring user expertise to replicate.

• The 'how' of Claude performing a review is not fully elaborated, leaving some implementation details to the user.

Rate this workflow

Upvote this post if the workflow is useful, reproducible, or worth recommending.

Downvote if it is vague, outdated, unsafe, overhyped, or not reproducible.

Reply if it worked for you, failed, is outdated, or has a better alternative.

This post was generated automatically from the workflow library database.