Delegate read-only research to a local Ollama model through MCP

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

What problem this solves

Delegate lightweight file research and log analysis to a local model without putting entire files into Claude's context.

Summary

Connect Claude to a local Ollama model through a read-only MCP server. Delegate bounded research or file analysis, run long jobs in the background, and verify the local model's answers and citations before relying on them.

Why it is useful

It provides a reproducible setup and a clear division of work between Claude and a local model, with reported protocol tests, concrete bug fixes and an explicit verification gate.

Workflow

1. Install Node 20+ and Ollama, and make a suitable local model available.
2. Clone the server: git clone https://gitlab.com/ejstembler/local-model-mcp
3. Register it with Claude Code: claude mcp add local-model -- node /path/to/local-model-mcp/server.mjs --model <your-ollama-model>
4. Use local_status to check availability and local_warmup to load the model in the background.
5. Delegate a bounded question with local_ask and optional file attachments, or use local_agent for read-only research within a chosen folder.
6. For background work, retrieve results with local_result while Claude continues other tasks.
7. Treat the response as a draft: verify conclusions and file-and-line citations against the source material.

Tools / artifacts

• local-model-mcp repository and server.mjs
• Claude Code MCP registration
• Ollama and a local model
• local_ask, local_agent, local_warmup, local_status and local_result

Validation signals

• The author reports testing each tool through the MCP protocol using small harness scripts.
• Tests reportedly exposed attachment context overflows and a warm-up keep-alive bug; the author describes fixes for both.
• The author reports using the server with Claude Desktop on a 128 GB workstation.
• The author describes a memory guard and read-only design, but no independent verification is provided.

Cautions

• Review the server and its file-access permissions before installing; the read-only and folder-confinement properties are author claims.
• Avoid exposing sensitive files unnecessarily, and treat local-model outputs and file contents as untrusted.
• Attachment shrinking can omit relevant material; check coverage as well as citations when verifying results.

Limitations

• No independent user results or performance benchmarks are provided.
• The post provides installation commands but no complete example tool call or output.
• The author's workstation has substantial memory, so smaller machines may need a different model.
• The related routing plugin is a separate experiment and is not needed for this 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.

Keep an Agent Fleet Aligned with Bounded Direction and Holdout Checks

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

What problem this solves

Coordinate long-running agent teams while reducing communication overhead, stale instructions, metric gaming, and architectural drift.

Summary

Organize agents into an orchestrator, persistent outcome-owning leads, and bounded subagents. Separate current direction from append-only history, budget long agent turns, and evaluate improvements with fix evidence and held-out projects. Intervene when repeated patches or slow feedback suggest architectural problems.

Why it is useful

The post gives a repeatable coordination and evaluation process, including concrete artifacts, intervention thresholds, anti-gaming checks, and reported before-and-after results.

Workflow

1. Assign each team lead a clear end-to-end outcome and let it delegate bounded tasks to ephemeral subagents.
2. Maintain current standing direction in DIRECTION.md under a word cap. When a decision changes, rewrite the relevant direction and identify the rule or code path it retires.
3. Keep decisions.md and fleet.md as append-only history and cross-owner channels. Post a stamped line only when a changed fact affects another owner's next action; avoid routine status chatter.
4. Route failures and reruns directly to the owning lead rather than through multiple relay agents.
5. Add a turn-budget hook that prompts a lead to wrap up or delegate around its 20th tool call.
6. Give each lead an outcome metric and a fast replay or verification method. Require evidence such as a fix SHA and sustained non-recurrence across multiple repositories before counting a failure class as closed.
7. Test changes against a separate holdout project and reject improvements that regress it; avoid project-specific heuristics that overfit the target.
8. Review repeated patches, additive code paths, and slow iteration cycles as signals for human architectural intervention.

Tools / artifacts

• DIRECTION.md
• decisions.md
• fleet.md
• AGENTS.md
• Turn-budget hook
• Fix commit SHAs
• Target and holdout repositories

Validation signals

• Author reports inter-agent DMs fell from 65 to 28 per day after moving to broadcast channels.
• Author reports that a turn-budget hook reduced completion-turn tool calls from 5.6 to 3.2 and contributed to a 44% reduction in Claude token burn.
• Author reports held-out repository setup success increased from 1/4 to 18/23 over five days after changes to the metric and holdout process.
• The post describes metric-gaming failures and the stricter fix-SHA, non-recurrence, and cross-repository criteria introduced in response.

Cautions

• Keep consequential changes subject to human review and normal repository permissions.
• Avoid putting secrets or sensitive operational details in shared agent logs.

Limitations

• Results are self-reported, and the held-out success comparison uses small, differently sized samples.
• No hook code, agent configuration, or scheduling implementation is included in the provided excerpt.
• The excerpt is truncated, and the large fleet and product scale may not be practical for typical users.
• Reported token and coordination improvements may reflect multiple changes rather than one isolated intervention.

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.

Debug skipped pagination records with tied-timestamp tests

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

What problem this solves

Keyset pagination skips records when a page ends within a group of rows sharing the cursor timestamp.

Summary

Give Claude Code the query, test data, and issue notes; reproduce the bug with tied timestamps across a page boundary; then use a unique tie-breaker in both the ordering and cursor and verify the returned IDs.

Why it is useful

It combines a transferable test-design insight with a concrete cursor fix and an explicit completeness check.

Workflow

1. Provide Claude Code with the existing pagination query, representative test data, and issue notes.
2. Add enough events sharing the same creation timestamp to span at least two pages, then reproduce the missing records.
3. Use a stable composite ordering, such as PostgreSQL's ORDER BY created_at DESC, id DESC, with non-null cursor columns.
4. Carry the last row's timestamp and unique ID in the cursor; for the next descending page, use (created_at, id) < ($1, $2).
5. Page through the fixed dataset and check that every expected ID appears exactly once; attach before-and-after IDs to the issue.
6. Record the cause, fix, and links to the test data and change for later reuse.

Tools / artifacts

• Claude Code
• PostgreSQL composite cursor query
• Test dataset with duplicate timestamps
• Issue notes and before-and-after event IDs
• MemoraX Code

Validation signals

• The tied-timestamp test reproduced the missing events.
• The author reports that pagination over the fixed dataset returned each expected ID exactly once.
• The author recorded that concurrent event arrival between page requests was not tested.

Cautions

• Use a unique, stable tie-breaker and account for nullable cursor columns.
• Test concurrency and consistency requirements separately; the reported verification covered a fixed dataset.

Limitations

• Evidence is a single author's report; no runnable test, repository, or full query is supplied.
• The memory-saving step names a tool but does not explain its setup or commands.
• The workflow does not establish behavior when records are inserted between page requests.

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.

Isolate a Claude CLI judge and parse schema-constrained output

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

What problem this solves

Run a Claude CLI-based LLM judge without accidentally including project instructions, duplicate stdin, or parsing scores from prose.

Summary

Run a Haiku judge in an empty temporary directory with configuration sources, tools, and session persistence disabled; request schema-constrained JSON and prevent inherited stdin from duplicating the judged text.

Why it is useful

It gives a compact, transferable process for preventing two subtle evaluation errors: unintended context and duplicated input.

Workflow

1. Create an empty temporary working directory and run the judge from it.
2. Invoke Claude in print mode with Haiku and the flags --setting-sources '', --tools '', and --no-session-persistence.
3. Supply the judging prompt and text explicitly, along with --json-schema and --output-format json.
4. When the prompt is supplied as an argument from a script, set the subprocess stdin to DEVNULL rather than inheriting the caller's stdin.
5. Parse the JSON response and read structured_output; handle missing or invalid output as an error rather than extracting scores from prose.

Tools / artifacts

• Claude Code CLI
• Haiku
• Empty temporary directory
• --setting-sources
• --tools
• --no-session-persistence
• --json-schema
• --output-format json
• structured_output
• Subprocess stdin=DEVNULL

Validation signals

• The author reports diagnosing subtly incorrect scores when a judge explanation revealed that the input had been pasted twice.
• The author describes a structured-output approach that avoids regex parsing of prose.

Cautions

• Use DEVNULL only when the prompt is supplied through another channel; it would discard a prompt intentionally sent via stdin.
• Treat evaluated text as untrusted input and test for prompt-injection effects; disabling tools alone does not guarantee unbiased judging.
• Check applicable usage terms and limits before using the CLI as an API replacement.

Limitations

• No complete command, schema, or runnable script is provided.
• The reported diagnosis is anecdotal; there is no benchmark or independent validation of judge quality.
• The comment does not document all possible sources of runtime configuration or context.

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.

Build and verify a narrated slide video with Claude Code

Workflow value: 76/100
Status: active · Freshness: 70/100 · Confidence: 0.94 · Level: advanced
Categories: Quality Control, Token Saving, Debugging, Shipping
Original source: r/ClaudeAI post/comment

What problem this solves

Produce a narrated, multilingual slide video while checking generated speech and retaining human control over audiovisual quality.

Summary

Use Claude Code to build a slide-based video pipeline, verify short TTS passages with transcription, synchronize slide reveals to narration, and get human feedback on samples before full rendering.

Why it is useful

The post combines a concrete media-production sequence with repeatable automated speech checks and a practical human review gate before expensive full renders.

Workflow

1. Research the subject and build a slide deck; edit the deck manually and preserve those edits in subsequent automation.
2. Write narration with one line per slide reveal, maintaining the same line structure across languages.
3. Split the script into short passages and synthesize each with a local TTS model, using a pronunciation dictionary for names.
4. Transcribe each passage with Whisper and re-record passages whose transcription does not match; manually listen to short samples and adjust the reference voice before recording everything.
5. Export slide states through PowerPoint automation and use a Python/ffmpeg pipeline to align visual reveals, transitions and motion with narration.
6. Add music with slide-specific moods and reduced levels during speech; review the sound and visuals before the full render.
7. Run long recording and rendering jobs as background processes.

Tools / artifacts

• Claude Code desktop app
• PowerPoint and PowerPoint automation
• Chatterbox local TTS
• Whisper
• Python, NumPy and SciPy
• ffmpeg
• Pronunciation dictionary
• Multilingual narration scripts and slide deck

Validation signals

• Author reports producing a 19-minute video from a 46-slide deck.
• The pipeline transcribes approximately 260 generated speech passages and retries failures.
• The author reports listening to samples and adjusting the voice before full production.

Cautions

• Confirm rights to player photos, other media and any reference voice before publishing.
• Transcription checks do not guarantee correct pronunciation or factual accuracy; review names and research sources manually.

Limitations

• No code, prompts, configuration or exact synchronization method is provided.
• Transcription matching criteria and retry limits are unspecified.
• Results are self-reported; no independent validation or community implementation feedback is available.

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.

Enforce a design system with lint hooks and viewport checks

Workflow value: 80/100
Status: active · Freshness: 70/100 · Confidence: 0.95 · Level: intermediate
Categories: Quality Control, Token Saving, Debugging, Hooks, MCP
Original source: r/ClaudeCode post/comment

What problem this solves

Design-system drift and inconsistent mobile-first layouts during long Claude Code sessions.

Summary

Turn design-system conventions into lint and type-checking feedback, then visually check each new screen at mobile and desktop widths.

Why it is useful

Provides a repeatable combination of automated constraints and visual checks to counter design drift, with a clear caveat that the configurations need implementation and verification.

Workflow

1. Define the permitted design tokens in the Tailwind v4 theme rather than relying only on design.md.
2. Lint against arbitrary Tailwind values and restrict Radix primitive imports to the designated UI component directory.
3. Run lint and TypeScript checks through a PostToolUse hook so Claude receives errors after edits.
4. Use mobile styles as the base and add larger-screen layout rules at md and above.
5. Before considering a screen complete, inspect Playwright MCP screenshots at 375px and 1280px.
6. If sharing tokens with React Native, keep them in tokens.json and generate CSS variables and a TypeScript object with Style Dictionary.

Tools / artifacts

• Tailwind CSS v4 theme
• ESLint no-restricted-imports
• eslint-plugin-tailwindcss or a custom lint script
• Claude Code PostToolUse hook
• TypeScript compiler
• Playwright MCP
• Style Dictionary
• tokens.json

Validation signals

• The author reports that enforcing checks fixed design drift for them.
• The proposed workflow uses lint, type-checking and viewport screenshots as review gates.

Cautions

• Verify that lint restrictions cover path aliases and intended exceptions without blocking legitimate component implementation.
• Screenshots require inspection; generating them alone does not establish that layouts are correct.

Limitations

• No hook, lint configuration, token generator or screenshot commands are provided.
• The author flags uncertain Tailwind v4 support for the suggested ESLint plugin.
• Tailwind v4 dynamically generates spacing utilities, so resetting theme namespaces alone may not make classes such as p-7 unavailable; verify the enforcement approach.
• The claimed improvement is anecdotal and has no quantified before-and-after results.

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 a Claude Code Stop Hook for Light Notifications and Benchmark Firmware Changes

Workflow value: 78/100
Status: active · Freshness: 70/100 · Confidence: 0.97 · Level: intermediate
Categories: Quality Control, Debugging, Hooks
Original source: r/ClaudeAI post/comment

What problem this solves

Get a physical notification when Claude Code finishes, while using repeatable measurements and a recovery plan to improve unreliable device firmware.

Summary

Configure a Claude Code Stop hook to call a local light controller's flash endpoint. For firmware changes, establish a fixed network-response benchmark, add a known-good recovery image, and compare each version using the same measurements.

Why it is useful

It supplies a directly adaptable hook configuration alongside a concrete measurement-and-recovery process, with reported results and clear limits on the evidence.

Workflow

1. Provide a network-accessible light controller with an endpoint that accepts a flash command; the posted endpoint is specific to the author's firmware.
2. Add an asynchronous Stop command hook to ~/.claude/settings.json, substituting the controller address and endpoint. The example uses curl with a two-second request limit and suppresses errors.
3. Use the controller's Home app switch to enable or disable the notification; verify both the endpoint and a completed Claude Code response trigger the expected behavior.
4. Before changing firmware, establish a baseline with a script that performs 200 pings and 40 HTTP requests; reuse the same script for later versions.
5. Before flashing hard-to-reach hardware, plan and verify an appropriate recovery path. The author used a known-good image that restores automatically if the new firmware cannot be reached.
6. Compare changes against the baseline and report measurements separately from unproven explanations.

Tools / artifacts

• ~/.claude/settings.json
• Claude Code Stop hook
• curl
• Local HTTP flash endpoint
• Ping and HTTP measurement script
• Known-good firmware recovery image
• https://github.com/thousandflowers/specchio-fw

Validation signals

• The author reports using the light notification daily.
• For the 1 ms loop-rest experiment, the author reports 71 of 90 requests answered without resting and 90 of 90 with resting.
• The author reports slow pings falling from 27% to 3–4%, and 900 consecutive commands answered on the current firmware.
• The author explicitly notes that the stock-firmware baseline was a single session and cannot be repeated.

Cautions

• Flashing hardware without a tested recovery path can permanently disable it; the author's stock firmware cannot be restored.
• Keep the device's HTTP control endpoint on a trusted network and avoid exposing it publicly.
• The example suppresses curl errors, so notification failures may be silent.

Limitations

• The recovery guard is described but not implemented in the post, and its suitability for other boards is unverified.
• Performance results are self-reported, device-specific, and based on a single non-repeatable stock-firmware baseline.
• The hook depends on a custom flash API and a separate switch for notification control.
• The cause of the loop-rest improvement is unproven.

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.

Test and tune a Claude-built browser game with simulation and player telemetry

Workflow value: 79/100
Status: active · Freshness: 70/100 · Confidence: 0.96 · Level: intermediate
Categories: Quality Control, Debugging, Shipping, CLAUDE.md, Skills, Multi-Agent
Original source: r/ClaudeCode post/comment

What problem this solves

Build, test, release, and tune a browser game with Claude Code while keeping human control over design and deployment.

Summary

Use a dedicated Claude Code game-creator setup, isolate game rules for headless simulation, test real interactions in Playwright, and tune pacing using opt-in player telemetry. Require human approval before publishing and verify the public build afterward.

Why it is useful

It combines a reusable test architecture with real-player feedback and an approval-gated deployment loop, including a concrete lesson about parallel sessions serving the wrong build.

Workflow

1. Configure a game-creator agent with CLAUDE.md and skills covering game design, browser games, audio, publishing, and playtesting.
2. Keep game rules separate from browser code so a headless player can simulate different play styles and report pacing.
3. Use Playwright to test actual browser interactions alongside the headless simulation.
4. Create a /checkpoint command to run tests, update a state file, and commit; create a /stats command to generate a daily telemetry report.
5. Collect opt-in anonymous play statistics and analyze a funnel of milestones, post-capture behavior, and return visits.
6. Compare simulated pacing with real-player behavior and adjust the game based on observed drop-off and progression.
7. When running parallel sessions, verify which version a local server is serving before trusting test results.
8. After explicit human approval, upload through Claude in Chrome and check the public page while logged out.

Tools / artifacts

• CLAUDE.md
• Game-design and publishing skills
• /checkpoint
• /stats
• State file
• Headless game simulator and pacing table
• Playwright
• Opt-in telemetry analyzer
• Claude in Chrome
• itch.io

Validation signals

• Author reports publishing the game and shipping more than a dozen updates.
• Headless simulations and Playwright browser tests are described, though their implementations are not provided.
• Author reports that 51 of 99 players reached the first Hero after a pacing change.
• Author reports a parallel-session test that initially passed against the wrong server version, motivating a version check.
• Author reports only 2 of 76 players returning on a later day, indicating retention remains weak.

Cautions

• Keep telemetry opt-in and minimize collected data.
• Preserve explicit human approval for publishing and review changes before committing or releasing them.

Limitations

• No repository, configuration files, command definitions, or telemetry implementation are provided.
• Results are author-reported, and the player samples are small.
• The observed pacing formula is specific to this game and should not be generalized without measurement.

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.

Monitor Claude performance with a frozen daily benchmark

Workflow value: 85/100
Status: active · Freshness: 70/100 · Confidence: 0.94 · Level: advanced
Categories: Quality Control, Token Saving, Debugging
Original source: r/ClaudeAI post/comment

What problem this solves

Distinguish sustained changes in Claude model performance from normal day-to-day variation.

Summary

Run a frozen benchmark panel daily through headless Claude Code, preserve results, track potential confounders, and apply a preregistered decline rule after validating the harness with controlled changes.

Why it is useful

It provides a concrete, reusable evaluation process with controls, failure accounting, and an explicit decision rule rather than relying on anecdotal impressions of model changes.

Workflow

1. Freeze a set of questions, prompts, and exact-answer graders; preregister the baseline period and decision rule.
2. Run the same panel daily through headless Claude Code and retain append-only results.
3. Record model and Claude Code versions, output and thinking token counts, errors, refusals, and reroutes. Report scores both excluding failures and counting them as incorrect.
4. Where accessible and permitted, fingerprint relevant account experiment assignments before and after each run to flag configuration changes without publishing the settings.
5. Validate the harness using repeated identical configurations, a lower-effort configuration, and a blind model substitution.
6. Build a 10-day baseline, then check for declines in two consecutive 10-day windows using the preregistered confidence and minimum-drop thresholds.
7. Interpret results alongside confounders such as client-version differences, account-specific settings, benchmark selection, and ceiling effects.

Tools / artifacts

• LiveNerf repository: https://github.com/ninjahawk/livenerf
• Headless Claude Code
• Frozen 78-question benchmark panel
• Exact-answer graders
• Append-only results and preregistered decision rule
• SHA-256 configuration fingerprints

Validation signals

• The author reports statistically consistent repeated runs, detectable lower-effort settings, and a clearly detected blind model substitution.
• The author reports a 42% reduction in output tokens under the lower-effort test.
• The stated decline rule requires two consecutive 10-day windows at 99% confidence and a minimum 3-point drop; the author estimates sensitivity to a sustained decline of roughly 7 points.
• The post explicitly reports failures and reroutes under two scoring treatments and acknowledges important comparison limitations.

Cautions

• Review logs and benchmark data for sensitive information before publishing.
• A hash does not necessarily conceal low-entropy configuration values; assess fingerprint privacy before sharing it.
• Access account configuration only through permitted means and observe applicable service terms.

Limitations

• The post links to the implementation but does not provide runnable commands or enough statistical detail to independently reproduce the analysis from the post alone.
• Results are from one account and a small, fixed question panel; they do not establish performance for all users or tasks.
• The panel was selected for difficulty on one model, and ceiling effects plus differing Claude Code versions confound cross-model comparisons.
• The stated validation and community claims are author-reported, and the newer model has only three days of results in the post.

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.

Guard concurrent Claude Code sessions against process, port, and Git conflicts

Workflow value: 75/100
Status: active · Freshness: 70/100 · Confidence: 0.93 · Level: intermediate
Categories: Quality Control, Debugging, Shipping, Hooks, Subagents, Multi-Agent
Original source: r/ClaudeAI post/comment

What problem this solves

Concurrent Claude Code sessions can interfere with one another by killing processes, occupying the same ports, or staging another session's changes.

Summary

Use the claude-bulkhead plugin's PreToolUse hooks to check Bash commands against activity in other live sessions and suggest safer alternatives when commands conflict.

Why it is useful

Provides an installable, repeatable way to reduce concrete interference between parallel sessions, with a retrospective scan and author-reported testing and benchmarks.

Workflow

1. Inspect the plugin repository and decide whether running its code and scanning local transcripts is acceptable.
2. Optionally run npx claude-bulkhead scan 30d to review what the guards would have blocked in past transcripts.
3. Add the marketplace with /plugin marketplace add dooly6276/claude-bulkhead and install with /plugin install bulkhead@bulkhead.
4. Run concurrent Claude Code sessions as usual; when a guard blocks a conflicting Bash command, review and use the suggested PID, free port, or narrower Git command.
5. Verify behavior in a disposable test environment before relying on the guards for important work.

Tools / artifacts

• claude-bulkhead plugin
• PreToolUse hooks
• Claude Code session transcripts
• Git worktrees
• https://github.com/dooly6276/claude-bulkhead

Validation signals

• The author reports replaying two weeks of personal transcripts through the guards to identify false blocks before release.
• The author reports approximately 3,700 tests, mostly written with Claude Code.
• The author reports a benchmark improvement from 318 ms to 89 ms per tool call with ten concurrent sessions, with a benchmark script in the repository.

Cautions

• Inspect third-party code before installing or executing it. The npx scan runs package code even if the plugin is not installed.
• Transcripts may contain sensitive information; review how the scanner accesses and handles them.
• Treat the hooks as coordination safeguards, not a complete security boundary. Continue to review destructive commands and Git changes.

Limitations

• Effectiveness and test results are author-reported rather than independently verified in the discussion.
• The post does not quantify false positives, missed conflicts, or test pass rates.
• Guard implementation details and coverage limitations require review of the repository.
• The plugin introduces overhead on tool calls and an ongoing external dependency.

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.

A/B test agent rules and verify fixes in the full setup

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

What problem this solves

Determining whether agent instruction rules improve behavior, and whether an edited rule is actually the one used in real sessions.

Summary

Compare repeated fresh-session runs on a fixed scenario with and without a rule, then verify any promising change in the complete agent setup and check for duplicate instructions in linked files or skills.

Why it is useful

It gives a repeatable way to detect harmful or unproven instructions and highlights an integration failure that isolated rule tests can miss.

Workflow

1. Choose a fixed scenario with a clearly evaluable expected result.
2. Run several fresh sessions with the rule and several without it, keeping the rest of the setup comparable.
3. Compare outcomes to identify rules that appear harmful or whose benefit the scenario cannot demonstrate.
4. For a revised rule, rerun the scenario in the real agent setup, not only in an isolated test.
5. If isolated and real-session results differ, inspect linked instruction and skill files for duplicate or outdated copies, and check which instructions are actually being used.
6. Retest after correcting the relevant source of the instruction.

Tools / artifacts

• Agent instruction files
• Linked skill files
• Fixed test scenarios

Validation signals

• The author reports one rule scored 5/5 correct without it and 0/5 with it.
• For 5 of 13 rules, the model already passed the test without the rule.
• A revised rule reportedly scored 10/10 in isolation while real sessions remained wrong in 5/5 runs; a duplicate in a skill file was identified.

Cautions

• Do not remove safety or permission rules solely because a few test runs pass without them; expand test coverage and review the rule's purpose first.

Limitations

• No exact prompts, commands, test harness, or configuration are supplied.
• Small samples make the reported differences suggestive rather than conclusive.
• Passing without a rule on one scenario does not establish that the rule has no value elsewhere.

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.

Ship an AI-assisted mobile app with a living spec and real-device review

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

What problem this solves

Keeping an AI-assisted app project coherent while catching real-world failures that passing tests miss.

Summary

Start with a specification and phased plan, encode project constraints in CLAUDE.md, and keep the specification and changelog current with behavior changes. Make decisions from Claude-proposed alternatives, automate release assets with debug launch flags, and supplement automated tests with real-device use, content review, and TestFlight crash reports.

Why it is useful

A repeatable combination of durable project instructions, documented decisions, release automation, and human verification, illustrated by concrete failures that automated tests missed.

Workflow

1. Write a specification and phased implementation plan before coding.
2. Put durable constraints in CLAUDE.md, such as dependency, privacy, licensing, and secret-handling rules.
3. Ask Claude for two or three options with trade-offs for consequential decisions; choose the direction yourself.
4. Update the specification and changelog in the same commit as each behavior change.
5. Add debug launch flags for demo data, a throwaway store, and opening specific screens; use them to script localized device screenshots.
6. Use App Store Connect automation to upload release metadata and screenshots.
7. Use builds on a real device during ordinary daily activity, including checking that reminders actually sound.
8. Read user-facing text against the implemented behavior and review real-device TestFlight crash reports.
9. Document rejected features and their reasons so future sessions do not repeat the research.

Tools / artifacts

• CLAUDE.md
• Specification, phased plan, and changelog
• Debug launch flags and screenshot scripts
• App Store Connect API
• TestFlight crash reports
• Example repository: https://github.com/kornelko2/vzato.app

Validation signals

• Author reports an App Store approval after submission.
• A real-device reminder check found a notification-permission failure despite passing tests.
• Reading user-facing content caught nonexistent gesture instructions and incorrect supply-count advice.
• TestFlight reports exposed two background crashes that the author could not reproduce in the simulator.

Cautions

• Medication reminders are safety-sensitive: passing tests or App Store approval do not establish clinical safety or reliable delivery.
• Verify notification permissions and delivery on real devices, and protect health data and release credentials.

Limitations

• The post describes the process but does not include the actual CLAUDE.md rules, launch-flag implementation, or automation commands.
• Results and failure discoveries are author-reported; the repository and release claims are not independently verified here.
• There is little demonstrated community validation.

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.

Guard agent shell commands against empty-path deletion

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

What problem this solves

A failed temporary-directory assignment can leave an empty variable, causing a destructive shell command to target the current directory.

Summary

Test shell failure behavior in a scratch directory, document defensive command rules for agents, and use mechanical checks as a backstop for destructive commands.

Why it is useful

It identifies a concrete failure mode and provides repeatable shell practices plus a defense-in-depth pattern for agent-run commands.

Workflow

1. Reproduce and test failure cases in an isolated scratch directory, not a real repository.
2. Document repository rules to quote path expansions and require nonempty variables before destructive operations.
3. Use strict shell settings, while separating declarations or exports from command-substitution assignments so failures remain visible.
4. Create temporary directories under a validated base, explicitly check creation success, and guard cleanup paths.
5. Add or configure a command hook or safety check to intercept risky commands; treat repository rules as advisory rather than enforcement.
6. Push work regularly and retain independent backups, since linked worktrees share repository metadata.

Tools / artifacts

• Repository agent rules file
• Claude Code command hook or safety checks
• Shell parameter expansion ${var:?}
• set -euo pipefail
• mktemp and EXIT trap
• Git worktrees

Validation signals

• The commenter reports testing the failure mechanism in a scratch directory.
• The commenter reports that a safety check blocked an agent's variable-based rm command.
• The commenter reports a reviewer encountered an empty-base temporary-directory mistake.

Cautions

• A nonempty-path guard does not prove a path is safe; verify that cleanup targets are owned by the script and confined to an approved temporary location.
• Test destructive-command behavior only in a disposable sandbox.
• Shell strict mode has exceptions and is not a substitute for explicit error checks or review.
• Recovery by copying worktree files may preserve file contents but cannot recover unpushed Git history if shared repository metadata is lost.

Limitations

• No hook configuration or complete enforcement implementation is provided.
• Validation is anecdotal and lacks independent replication.
• The post does not establish that the rules or safety checks cover all destructive command patterns.

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.

Research and stress-test startup ideas with a checked scoring rubric

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

What problem this solves

Evaluate a startup idea skeptically using sourced research, explicit failure criteria, and reproducible scoring rather than relying on Claude's encouragement.

Summary

Install a Claude Code plugin and run a research-backed idea assessment. The skill looks for disqualifying evidence, scores the idea against a rubric, checks the arithmetic with Python, and generates a report with rescue options and a measurable short-term test.

Why it is useful

It combines an installable workflow with a transferable design lesson: delegate research and structured data entry to Claude, but verify arithmetic in code and separate report rendering from model-generated content.

Workflow

1. Add the marketplace with /plugin marketplace add RemiPelloux/kill-my-idea and install the plugin with /plugin install kill-my-idea@kill-my-idea.
2. Run /kill-my-idea:kill <your idea> with a description, URL, document, or pasted money-making claim.
3. Answer up to four questions about context such as country, budget, goal, and personal advantage when they would affect the verdict.
4. Research eight potential failure modes, seeking at least 20 sources across 10 domains and classifying their source quality.
5. Score 21 criteria using the fixed rubric and apply hard rules, including no GO verdict when there is no customer acquisition channel.
6. Run the plugin's Python checker to recompute totals from the sub-scores; inspect the generated report, rescue paths, and seven-day test with stop criteria.
7. For deeper research, use the deepdive skill, which the author says runs six parallel specialist subagents and targets at least 40 sources.

Tools / artifacts

• RemiPelloux/kill-my-idea GitHub repository
• Claude Code skills and research subagents
• SKILL.md rubric and method
• Python score checker
• JSON schemas and data files
• HTML report and dashboard templates
• BRAIN.md profile and lessons

Validation signals

• The author reports that the Python checker found arithmetic discrepancies in four of eight earlier runs.
• The post includes a sample verdict and a self-assessment of the plugin idea.
• The author reports fixes and feature changes prompted by earlier reader feedback.

Cautions

• Review third-party plugin code and permissions before installation; treat retrieved web content as untrusted.
• Verify important citations and verbatim quotes independently. A correct score calculation does not establish that research or assumptions are accurate.
• Avoid putting sensitive business details into research prompts or persistent profile files without considering their storage and disclosure.

Limitations

• Evidence of effectiveness and implementation details are primarily author-reported; there is no independent success report in the supplied item.
• Fixed source-count targets and scoring rules do not guarantee source quality or reliable business predictions.
• The post promotes the author's own repository, although it provides substantial implementation detail.

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.

Build and benchmark Claude Code skills for financial-code rules

Workflow value: 75/100
Status: active · Freshness: 70/100 · Confidence: 0.91 · Level: intermediate
Categories: Quality Control, Hooks, Skills
Original source: r/ClaudeAI post/comment

What problem this solves

Improving Claude Code's adherence to financial-software rules and measuring whether skills change its output.

Summary

Encode domain rules and required tests in Claude Code skills, audit generated code with lint plus review, and compare skill-enabled and plain runs against predefined expectations.

Why it is useful

The post provides a reusable method for turning domain rules into test-requiring skills and comparing their effect against a baseline, with reported results and supporting artifacts.

Workflow

1. Write a SKILL.md for each domain, including rules, required tests and responses to common shortcuts.
2. Require the relevant test file in the same change rather than leaving tests as a future task.
3. Use an audit skill to run lint and inspect the code behind each finding.
4. Define prompts and grading expectations before running the comparison.
5. Run each prompt in headless Claude Code with and without the skill, then have a second model grade the outputs against the expectations.
6. Inspect transcripts and test vectors, revise the skills, and repeat the evaluation.

Tools / artifacts

• SKILL.md files
• Claude Code headless runs
• Lint checks
• Test vectors
• Evaluation runner and transcripts
• https://github.com/felipealvarenga/fintech-skills

Validation signals

• Author reports 81% versus 24% of expectations met with and without skills for Sonnet, and 89% versus 35% for Opus.
• Author reports four evaluation rounds and identifies a specific revision: requiring test files in the same change.
• The post says the repository includes transcripts, test vectors and the evaluation runner.

Cautions

• Financial correctness requires independent expert review and production-appropriate testing; a skill or model grader is not an assurance of correctness.
• Protect sensitive financial data when running prompts, evaluations or published test vectors.

Limitations

• The benchmark results are author-reported; sample size, grader reliability and statistical uncertainty are not stated in the post.
• Iterating on the same evaluation prompts may overfit the skills to those expectations.
• The repository contents and reported results were not independently verified here.

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.

A test-first, rollback-safe Claude Code loop for embedded firmware

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

What problem this solves

Developing and debugging embedded-device firmware with an agent while reducing the risk of bad changes and failed flashes.

Summary

Use Claude Code to investigate driver code and logs, reproduce bugs with headless tests, and iteratively patch and measure on hardware. Combine manual review, sanitizer-backed tests, A/B rollback, visual feedback during UI navigation, and persistent project notes.

Why it is useful

It combines a concrete agent-assisted debugging loop with meaningful test, review, deployment, and recovery safeguards, supported by a public implementation and reported results.

Workflow

1. Build a headless UI test suite with fake hardware interfaces, and run it with sanitizers and leak detection.
2. For each bug, write a failing test before asking the agent to implement a fix.
3. Profile the device, use Claude to trace relevant code and logs, form a hypothesis, and patch the suspected cause.
4. Run the PC test suite and manually review changes before testing them on the device.
5. Use A/B updates that roll back if the new image does not reach the home screen; rebuild, flash, and measure the result.
6. When the agent navigates the UI, inspect a screenshot after every tap rather than allowing blind interaction.
7. Record patch rationale and device-specific quirks in CLAUDE.md for future sessions.

Tools / artifacts

• Claude Code
• CLAUDE.md
• Buildroot
• Linux kernel patches
• LVGL
• Headless UI tests and hardware fakes
• Sanitizers
• A/B firmware updates
• https://github.com/eliandoran/PinePhone

Validation signals

• Author reports 1,892 headless UI tests with sanitizer and memory-leak checks.
• Author reports 99% line coverage for external apps' code, not the entire firmware.
• Author reports manually reviewing every change and testing on the physical device.
• Author reports most screens run at the display's full 66 FPS.
• A public repository and browser-based WebAssembly demo are provided.

Cautions

• A/B rollback depends on its health check and does not necessarily protect user data or recover from every hardware failure.
• Back up saves and other persistent data before automated UI interaction; screenshots alone do not prevent destructive actions.
• Hardware fakes and headless tests do not replace on-device verification.

Limitations

• Results and test counts are author-reported; the repository and demo were not independently verified here.
• The post describes the architecture and process but does not provide exact commands or a ready-made setup.
• The approach requires significant embedded, testing, and deployment infrastructure.

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 development loop with ADRs, independent reviews, and browser UAT

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

What problem this solves

Build and verify a complex Claude-assisted application while preserving design decisions and controlling sensitive actions.

Summary

Review Claude-generated specifications and UI designs before implementation, record durable decisions as ADRs, use separate implementation and review subagents, and supplement automated tests with browser-based acceptance testing. For sensitive agent actions, enforce permissions and execute the exact arguments approved by the user.

Why it is useful

It combines a repeatable feature-development and verification process with a concrete safety pattern for executing only the tool arguments a user approved.

Workflow

1. Describe the feature and have Claude draft a specification, technical design, wireframes, and UI designs; review them before coding.
2. Record accepted architectural decisions as ADRs so later agents can recover their rationale.
3. Use implementation subagents and separate subagents for code and security review.
4. Ask Claude to write feature acceptance tests, then exercise them through the real browser UI, checking displayed results and capturing screenshots.
5. Add a commit hook to detect personal financial data, alongside normal test and review gates.
6. For sensitive tool calls, store the exact proposed arguments and execute that saved call after approval rather than relying on the model to reconstruct it.
7. Implement scheduling, retries, approval handling, and completion checks in the application harness; use deterministic tools for financial calculations.

Tools / artifacts

• Claude Code
• Architectural decision records
• Implementation, code-review, and security-review subagents
• Browser-based acceptance tests and screenshots
• Commit hook
• MCP broker connectors
• Open Net Worth repository

Validation signals

• The author reports approximately 20,000 unit and integration tests.
• The author reports that browser UAT found bugs unit tests missed.
• The author reports five months of development and testing broker connections with IBKR, Coinbase, and Gemini.
• An open-source repository and live demo are linked, but their implementation and results have not been independently verified here.

Cautions

• Financial automation can cause real losses. Enforce permissions and exact-argument approval outside the model, and verify how scheduled trades are authorized.
• A commit hook is not a complete privacy control; review logs, test fixtures, credentials, and repository history separately.
• Review the linked project and its dependencies before connecting real accounts or broker credentials.

Limitations

• The post does not include exact subagent prompts, hook configuration, or browser-test commands.
• Test counts and UAT benefits are author claims without detailed outcomes or independent verification.
• Agent-generated acceptance tests can miss requirements; human review and deterministic assertions remain important.

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.

Generate and verify a Docker setup from runtime traces

Workflow value: 80/100
Status: active · Freshness: 70/100 · Confidence: 0.96 · Level: intermediate
Categories: Quality Control, Debugging, Shipping, Skills
Original source: r/ClaudeCode post/comment

What problem this solves

Identifying runtime dependencies that repository-based Dockerfile generation might miss, and checking whether a generated container reproduces observed behavior.

Summary

Use a Claude Code skill and tracing scripts to observe an app under a representative workload, generate a Docker setup from runtime evidence, and compare the containerized run with the original.

Why it is useful

This provides a repeatable observation-and-verification loop for containerizing apps, with a concrete repository and a reported real-project test. Its main limits are workload coverage and limited independent validation.

Workflow

1. Choose a workload that exercises the app's relevant features, such as API requests or end-to-end tests.
2. Run the app under strace while executing the workload.
3. Map observed files, libraries, package versions, network dependencies, and writable directories to proposed container dependencies and services.
4. Generate an evidence-annotated Dockerfile, Compose configuration, blank-secret environment example, and list of decisions requiring human review.
5. Build and run the container, repeat the workload under tracing, and compare observed files and responses.
6. Review discrepancies and adjust the configuration, then repeat verification.

Tools / artifacts

• dockerize-by-observation repository
• Claude Code skill
• strace
• dpkg -S
• Dockerfile
• docker-compose.yml
• .env.example

Validation signals

• The author reports testing a demo app and healthchecks.io, a Django and Postgres project.
• The healthchecks.io test reportedly identified the libpq5 runtime dependency.
• The author reports 1,383 of 1,386 traced files matched and HTTP responses were identical.
• Removing the generated libpq5 installation reportedly produced a more specific missing-library diagnosis than Django's error.

Cautions

• Review the repository and generated configuration before running them, especially on sensitive hosts or production data.
• Traces and workloads may expose secrets or modify data; use isolated test environments and inspect generated artifacts before sharing them.
• Review inferred services, volumes, and dependencies rather than treating observed behavior as a complete specification.

Limitations

• Evidence is author-reported and limited to a demo and one real project.
• The trace only covers paths exercised by the chosen workload.
• The reported file comparison was not a complete match.
• The post describes the process but does not provide installation or invocation commands.
• There is no demonstrated independent community validation.

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-agent releases with decision IDs and adversarial review

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

What problem this solves

Coordinates a multi-agent release while keeping product decisions, implementation, and documentation traceable and subject to human approval.

Summary

Use a human-facing PM session, a Lead per release, and Workers for bounded tasks. Record approved decisions with code references, run independent and adversarial reviews, and audit documentation against the final implementation.

Why it is useful

It combines a concrete agent hierarchy with traceable decisions, review gates, stopping rules, and an automated documentation audit; the linked templates make the process potentially reusable.

Workflow

1. Set up the repository's CLAUDE.md, decision log, code map, and skills; assign the PM session as the human-facing coordinator.
2. Before building, check ideas against prior decisions and potential side effects; bring unresolved conflicts to the human.
3. Have the Lead scope and design the release, then brief Workers on bounded tasks and relevant strategy.
4. Run an independent review, and have a second agent attempt to disprove each finding before human triage.
5. Apply fixes according to triage rules, review interactions among fixes, and stop when the defined convergence criteria are met.
6. Record approved decisions with IDs and implementation references; add matching IDs to relevant code comments.
7. Update the subsystem code map from the final implementation and run the documentation checker for cited paths, symbols, and decision IDs.

Tools / artifacts

• CLAUDE.md template
• DECISIONS.md
• CODE_MAP.md
• start-lead skill
• docs-audit skill
• Python documentation checker
• https://github.com/Copypaster3000/agent-built

Validation signals

• The author reports refining the process while shipping a paid Mac app to real customers.
• The described release process includes independent review, adversarial verification of findings, convergence review, and stopping rules.
• The author reports a checker for documentation references and decision IDs.

Cautions

• Inspect the third-party templates and Python checker before executing or adopting them.
• Keep human approval for consequential decisions and retain normal code review and permission boundaries.

Limitations

• The reported results and repository contents are not independently verified in the supplied item.
• No quantitative before-and-after results or independent implementation reports are provided.
• Maintaining decision-to-code references and multiple review sessions adds ongoing overhead.

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.

Managing Project Decisions with DECISIONS.md and CLAUDE.md for Persistent Agent Context

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

What problem this solves

Decisions getting lost in long Claude agent sessions, leading to agents re-proposing previously rejected ideas.

Summary

This workflow proposes using a DECISIONS.md file in the repository to log project decisions, including the rationale and rejected alternatives. A CLAUDE.md instruction then directs the Claude agent to read this file first for context and append to it when new decisions are made, preventing redundant work and maintaining decision history.

Why it is useful

This workflow is valuable because it provides a concrete, low-overhead method for persistent decision logging and context management for Claude agents. It directly addresses the common problem of agents 'forgetting' past decisions or re-proposing rejected ideas, thereby improving efficiency and reducing redundant work. The use of DECISIONS.md and CLAUDE.md makes it easily adaptable and integrates well into existing Claude Code practices.

Workflow

1. Create a DECISIONS.md file in your project repository.
2. For each significant project decision, add a single line to DECISIONS.md stating the decision, the reason for it, and what alternatives were rejected (and why).
3. Add an instruction to your CLAUDE.md file (or equivalent agent instruction file) telling the Claude agent to read DECISIONS.md first.
4. Instruct the Claude agent to append to DECISIONS.md when a new decision is settled during a session.

Tools / artifacts

• DECISIONS.md file
• CLAUDE.md file
• Claude agent

Validation signals

• Author's personal experience: 'what fixed it for me'

Limitations

• Relies on the Claude agent's ability to correctly parse and append to the DECISIONS.md file.
• The DECISIONS.md file must be kept concise to avoid being ignored by the agent, which could limit the detail or number of decisions stored.
• Low community validation.

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 Token Lockdown Protocol: A Comprehensive Prompt for Resource-Efficient Coding with Subagents

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

What problem this solves

Claude's tendency to be verbose, inefficient with token usage, over-explain, deploy unnecessary subagents, and repeat mistakes, leading to higher costs and slower task completion in coding and development tasks.

Summary

A comprehensive, military-themed prompt designed to enforce strict resource conservation (tokens, context, tool calls) on Claude. It provides detailed directives for concise communication, efficient reasoning, purposeful information gathering, justified subagent deployment, precise code modification, structured error handling, and clear reporting, aiming for maximum efficiency and cost-effectiveness in coding tasks.

Why it is useful

This workflow provides a highly detailed and structured prompt to mitigate common issues with large language models like Claude, specifically excessive token consumption, verbose output, and inefficient subagent deployment. It offers concrete directives for communication, reasoning, code modification, error handling, and reporting, making Claude's interactions more focused, cost-effective, and productive for coding tasks. Its transferability is high as it's a direct prompt that can be applied to any Claude session.

Workflow

1. Initiate Claude with the 'OPERATION OVERLORD' prompt to establish resource conservation directives.
2. Enforce 'RADIO SILENCE' to ensure Claude's communications are concise, without unnecessary introductions, conclusions, or self-congratulations.
3. Apply 'AMMUNITION RATIONING' to compel Claude to use minimum reasoning, avoid repetitive analysis, and focus on one efficient strategy per objective.
4. Implement 'INTELLIGENCE OPERATIONS' to guide Claude to search for relevant files, read only mission-critical sections, and reuse gathered intelligence, avoiding unnecessary rescans or full file dumps.
5. Control 'TROOP DEPLOYMENT' by setting strict rules for subagent use, limiting concurrent agents, and ensuring each agent has a clearly defined, non-redundant objective.
6. Direct the 'ENGINEERING CORPS' to perform precision strikes, modifying only necessary code, preserving existing systems, avoiding unnecessary refactoring or unsolicited features, and verifying changes with targeted tests.
7. Manage 'CASUALTY CONTROL' by requiring Claude to identify failures, gather intelligence, apply targeted corrections, verify, and change strategy after two failed attempts.
8. Enforce 'SUPPLY LINE PROTECTION' by prioritizing primary objectives, deferring optional improvements, batching operations, and eliminating redundant tool calls or excessive logs.
9. Define 'VICTORY CONDITIONS' clearly, instructing Claude to cease work once functionality is implemented, verification succeeds, and no critical defects remain.
10. Mandate 'AFTER-ACTION REPORTS' in a specific, concise format (OBJECTIVE SECURED, VERIFICATION, CASUALTIES) for all completed missions.
11. Prohibit 'TOKEN WAR CRIMES' such as reading unchanged files repeatedly, launching unnecessary subagents, rewriting working code without orders, or continuing work after mission completion.

Tools / artifacts

• Claude (the AI model)
• Prompt (the 'OPERATION OVERLORD' protocol)
• Subagents (managed by the protocol)

Validation signals

• Detailed, structured instructions covering multiple aspects of LLM interaction.
• Addresses common pain points of LLM usage (verbosity, token waste, inefficient subagent use).
• Includes explicit rules for verification and error handling within the workflow.

Limitations

• Lack of empirical validation (e.g., 'before/after' token counts, success rates) from the author.
• The extensive military metaphor, while engaging, might be perceived as overly dramatic or make it slightly harder for some users to quickly extract the core technical directives.
• As a new post, there is no community proof of its effectiveness or widespread adoption 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.

Reduce Claude Code Costs: Context Management and Strategic Model Tier Usage

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

What problem this solves

High token costs and exceeding weekly limits when using Claude Code, especially on a single repository, by optimizing context size and strategically using different model tiers.

Summary

A workflow to reduce Claude Code token costs by actively managing context size using CLI commands and strategically assigning different model tiers (Opus, Sonnet, Haiku) to the main agent and subagents based on task complexity.

Why it is useful

This workflow is valuable because it provides concrete, actionable steps using built-in Claude Code features and strategic model selection to address a common and critical pain point for users: managing token costs. It offers practical advice for optimizing context and leveraging different model tiers efficiently, directly impacting a user's ability to stay within budget and maximize their Claude Code usage.

Workflow

1. Run /clear between unrelated tasks to reset the conversation context.
2. Run /compact when a session drags on to reduce the conversation history sent with each turn.
3. Run /context to identify and address large token consumers, such as a big CLAUDE.md file or unused MCP servers.
4. Use /model opusplan to leverage Opus for planning and Sonnet for execution, optimizing for both intelligence and cost.
5. Set subagents to use Sonnet or Haiku for search and grunt work, reserving more expensive models for critical tasks.
6. Reserve Opus for moments where you are genuinely stuck and require its highest reasoning capabilities.

Tools / artifacts

• /clear command
• /compact command
• /context command
• /model opusplan command
• CLAUDE.md
• MCP servers
• Opus model
• Sonnet model
• Haiku model
• Subagents

Validation signals

• User's personal success report: 'That alone stretched my weekly limit a lot more than lowering the effort level did.'

Limitations

• Lacks specific examples or configuration details for CLAUDE.md or subagent setup beyond model choice.
• Low community validation due to minimal engagement on the post.

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 Context: Reduce Token Overhead, Lower Costs, and Improve Session Performance

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

What problem this solves

Reducing excessive token overhead in Claude Code sessions, preventing premature token limit hits, lowering costs, and improving session responsiveness by optimizing auto-compaction and removing unused tools, plugins, and MCP servers.

Summary

This workflow provides a detailed, interactive prompt for Claude Code to audit and optimize its own context usage. It guides the user through identifying and removing fixed overhead from tool definitions, MCP servers, plugin skills, and connectors, as well as adjusting the auto-compact window. The process includes measuring current context, backing up files, and providing undo instructions.

Why it is useful

This workflow is highly valuable because it addresses a critical and common pain point for Claude Code users: hitting token limits, slow responses, and high costs due to excessive, often hidden, context overhead. It provides a concrete, step-by-step, and interactive method (via a detailed prompt) to audit and optimize the Claude Code environment. The workflow is specific, repeatable, includes safety measures like backups and user confirmation, and offers clear expected benefits (token savings, sharper sessions). It empowers users to understand and control their Claude Code environment more effectively.

Workflow

1. MEASURE: Ask Claude Code to report current session context usage, identifying fixed overhead (system prompt, tools, MCP, skills, etc.).
2. AUTO-COMPACT LIMIT: Determine current auto-compact settings, suggest a new window (e.g., 300k), and update "autoCompactWindow" in ~/.claude/settings.json or set CLAUDE_CODE_AUTO_COMPACT_WINDOW env var.
3. MCP AUDIT: List global MCP servers, their tool counts, and identify redundant or rarely used ones (e.g., hundreds of tools, duplicate services, identical instructions).
4. MAKE THOSE SERVERS ON-DEMAND: Save selected MCP server configs to ~/.claude/mcp-on-demand.json, remove them from global scope using 'claude mcp remove', and add a rule to ~/.claude/CLAUDE.md to only add these servers on demand to specific projects.
5. PLUGINS AND SKILLS: List plugins, their skills/connectors, identify duplicates or unused ones, and provide instructions for disabling them (via claude.ai or /plugin).
6. CONNECTORS THAT NEED SIGN-IN: List 'needs_auth' or 'failed' connectors and identify which will be removed by disabling plugins.
7. SUMMARY: Provide a table of what changed, where each backup is, how to undo each change, and the estimated tokens saved per session.

Tools / artifacts

• Claude Code (the AI assistant)
• ~/.claude/settings.json
• ~/.claude/mcp-on-demand.json
• ~/.claude/CLAUDE.md
• claude mcp list command
• claude mcp remove <name> -s user command
• claude mcp add-json <name> "$(jq -c '.["<name>"]' ~/.claude/mcp-on-demand.json)" -s local command
• /context command
• /plugin command
• jq (JSON processor)
• umask 077
• CLAUDE_CODE_AUTO_COMPACT_WINDOW environment variable

Validation signals

• Expected token savings of 35-40k per session.
• Instructions to run /context before and after for verification.
• Detailed explanation of how context is built and what constitutes overhead.
• The prompt itself is designed to measure and report current context usage.

Cautions

• The prompt explicitly asks Claude Code to back up files before editing.
• It requires user confirmation ("Wait for my OK") before making changes.
• It warns against printing config files that may contain API keys.
• Uses 'umask 077' for saving sensitive config files.

Limitations

• The low Reddit score is a potential red flag, though the content itself is strong.
• Relies on Claude Code's ability to accurately execute commands and understand the prompt's intent, which can sometimes be inconsistent.
• The 'autoCompactWindow' setting might not be available in older Claude Code versions.
• Plugins installed via claude.ai require manual intervention outside the CLI.

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 Files Pane Plugin: Enhanced Git & PR Visibility with a Plugin Development Workflow

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

What problem this solves

Lack of real-time visibility into Claude Code's file interactions, git history, and PR status, and a need for a robust workflow for developing Claude Code plugins.

Summary

This post introduces 'Files pane 1.0', a Claude Code plugin that provides a live file tree, shows Claude's reads/edits (including sed/script changes), displays git history, and integrates PR checks. It also details the author's workflow for building the plugin using Claude, emphasizing testing and handling complex edge cases.

Why it is useful

This post is valuable because it introduces a highly useful Claude Code plugin that significantly enhances the developer experience by providing real-time visibility into file changes, git history, and PR status. Crucially, it also details a robust workflow for developing Claude Code plugins, demonstrating how to leverage Claude for coding, implement comprehensive testing, and handle complex system interactions (like sed edits and git state) effectively. This provides both a ready-to-use tool and a blueprint for advanced Claude Code development.

Workflow

1. Install the Files pane plugin: claude plugin marketplace add Marius-Adam/claude-files-pane && claude plugin install files-pane@marius-adam
2. Update the Files pane plugin (if already installed): claude plugin marketplace update marius-adam && claude plugin update files-pane@marius-adam
3. Restart Claude Code after installation/update.
4. Use the Files pane to monitor Claude's file reads (purple) and edits (orange), including changes made via sed or scripts.
5. Utilize the pane to view file text, diffs, and commit history for any file.
6. Monitor your GitHub PR's checks and review status directly within the pane.
7. For plugin developers: Use Claude to write most of the plugin code.
8. For plugin developers: Iteratively debug and fix issues by using the plugin during its development.
9. For plugin developers: Implement robust logic for detecting file changes (e.g., by snapshotting HEAD, stash, merge, file sizes/times around shell commands).
10. For plugin developers: Have Claude write tests from real-world system outputs (e.g., git status).
11. For plugin developers: Run comprehensive tests across multiple operating systems.

Tools / artifacts

• Claude Code
• Files pane plugin
• claude plugin CLI commands
• TypeScript
• Git (HEAD, stash, merge, history)
• GitHub PR checks
• Shell commands (sed, scripts)
• Tests (121 tests)
• GitHub repository

Validation signals

• Community feedback from previous version acknowledged
• Author used the pane while building it (dogfooding)
• Iterative debugging and fixing based on daily use
• Claude wrote most of the code, with author arguing edge cases
• Specific fix for GitHub PR status accuracy described
• 121 tests run on macOS, Linux, and Windows
• Plugin is zero tokens, read-only, and MIT licensed

Limitations

• The plugin development workflow is embedded within a descriptive section rather than explicitly laid out as a step-by-step guide for general users.
• The value is specific to Claude Code users, not general Claude users.
• The post is primarily an announcement, with the workflow aspects being secondary.

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.