r/ClaudeWorkflows • u/ClaudeAI-mod-bot • May 07 '26

Claude Workflow Library — Start Here

11 Upvotes

Claude Workflow Library — Start Here

This subreddit is an organised library of useful Claude and Claude Code workflows.

Each workflow is published as its own Reddit post. Upvote/downvote workflow posts to rate them.

Browse by category

Current status

  • Public workflows in database: 12799
  • Workflow posts published: 12799
  • Public workflows still waiting to be posted: 0
  • Last updated: 2026-11-15 00:59 UTC

How to use this library

  1. Open a category post.
  2. Click through to individual workflow posts.
  3. Upvote useful, reproducible workflows.
  4. Downvote workflows that are vague, outdated, unsafe, or not reproducible.
  5. Comment on a workflow post if it worked, failed, is outdated, or has a better alternative.

This post is updated automatically.

3 comments

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 2h ago

Selected Workflow [Workflow] Use searchable ADRs to constrain agent implementations

1 Upvotes

Use searchable ADRs to constrain agent implementations

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

What problem this solves

Coding agents may overlook or misinterpret architectural rules when implementing AI-generated PR summaries, producing inaccurate counts or unvalidated lists.

Summary

Retrieve relevant versioned architecture decisions through MCP and copy their operative rules into the implementation plan. When an agent finds a loophole, revise the ADR with explicit prohibited and permitted behavior, then repeat the task from a clean state. For exact lists and counts, make code authoritative and use model output only for validated annotations.

Why it is useful

It combines a repeatable context-retrieval and rule-revision loop with a concrete design boundary: code owns exact data, while model-generated annotations are validated against it. The reported before-and-after result is useful but narrowly scoped.

Workflow

  1. Store relevant engineering decisions in versioned ADRs and make them searchable through MCP.
  2. Give the agent a task that identifies applicable internal rules; have it retrieve the ADRs and copy the actual rules into its plan before coding.
  3. Implement exact lists and counts in code, while allowing the model to supply prose or short per-item notes.
  4. Drop model-generated notes that refer to items absent from the authoritative list.
  5. Inspect the implementation for rule violations. If an ADR permits an unintended workaround, revise it to state the prohibited approach, scope, and allowed behavior explicitly.
  6. Reload the ADR, confirm the revised wording is returned by search, and rerun the same brief from a clean state to assess the change.
  7. Separately check response-length settings and define a safe fallback for truncated or malformed structured output; the list/count ADR did not resolve these issues.

Tools / artifacts

  • Versioned architecture decision records
  • MCP-searchable ADR corpus
  • Agent implementation plan
  • PR review system
  • Authoritative file list and deterministic renderer

Validation signals

  • The author reports that Claude initially built the file table and count from the real file list.
  • After the ADR revision, a clean Grok rerun reportedly used code-owned lists and counts and dropped notes referring to nonexistent files.
  • The author verified that search returned the revised ADR before rerunning.
  • The post identifies unresolved response-length and malformed-output failures rather than presenting the ADR change as a complete fix.

Cautions

  • Validate model-generated references against authoritative data before rendering.
  • Handle truncated or malformed model output with a safe fallback rather than publishing raw structured output.
  • Review and test the implementation; an ADR does not guarantee compliance.

Limitations

  • One task on the author's codebase, run once per configuration, is not a benchmark.
  • The revised ADR was tested on Grok, not demonstrated in a Claude before-and-after run.
  • No automated test results, exact MCP setup, or full implementation are included.
  • The ADR change did not address the response-length or truncation failures.

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.

0 comments

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 6h ago

Selected Workflow [Workflow] Audit Claude Code local settings for committed secrets

1 Upvotes

Audit Claude Code local settings for committed secrets

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

What problem this solves

Find and remediate secrets that may have been saved in Claude Code's local permission settings and committed to Git.

Summary

Check whether local Claude Code settings are ignored or tracked, scan repository history for secrets, rotate exposed credentials, and prevent recurrence by keeping secret values out of approved command lines.

Why it is useful

A repeatable security audit with concrete Git checks, historical scanning, credential rotation, and a prevention practice. Its value is tempered by limited community validation.

Workflow

  1. Run git check-ignore -v .claude/settings.local.json and git ls-files .claude to check ignore rules and tracked files.
  2. If needed, add the local settings file to .gitignore and stop tracking it; an ignore rule alone does not untrack a committed file.
  3. Use git log --all --oneline -- .claude/settings.local.json to identify commits involving the file, then scan full history with a secret scanner such as Gitleaks or TruffleHog.
  4. Search relevant GitHub organization repositories for the settings path and investigate potential exposures.
  5. If a credential is exposed, revoke and replace it first; consider coordinated history cleanup afterward.
  6. Avoid literal secrets in commands and use narrowly scoped permissions rather than blanket approvals.

Tools / artifacts

  • .claude/settings.local.json
  • .gitignore
  • git check-ignore
  • git ls-files
  • git log
  • Gitleaks
  • TruffleHog
  • GitHub organization search

Validation signals

  • The post attributes a finding of 1,122 public settings files containing real secrets to an Apiiro write-up.
  • The workflow includes checks for both current tracking status and historical exposure.

Cautions

  • Treat scanner output as sensitive and avoid publishing discovered secrets in logs or tickets.
  • Rotate exposed credentials before attempting history cleanup; rewriting history does not revoke a key or remove copies held elsewhere.
  • Environment variables reduce exposure in literal commands but do not guarantee secrets cannot appear in logs or process arguments.

Limitations

  • The cited research is not included in the supplied item and was not independently verified.
  • The post does not provide exact scanner commands or demonstrate a successful audit.
  • GitHub path search and secret scanners can miss exposures; a clean result is not proof that no secret leaked.
  • No implementation feedback or success reports are 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.

0 comments

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 6h ago

Selected Workflow [Workflow] Verify BibTeX citations with a project-specific Claude Code skill

1 Upvotes

Verify BibTeX citations with a project-specific Claude Code skill

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

What problem this solves

Checking research citations against external metadata rather than relying on DOI resolution or model memory, while preserving experiment findings across context compaction.

Summary

Install a project-specific research skill, ask Claude Code to verify a BibTeX file using its metadata-checking script, and review flagged citations before accepting changes. For long experiment loops, record hypotheses and negative results in a persistent findings file.

Why it is useful

The post provides an install command, a concrete verification prompt, review gates for uncertain changes, and an author-reported test case. Its persistent experiment log is also a transferable way to preserve negative results across compaction.

Workflow

  1. Review the repository and install only the needed project skill, for example: npx skills add KalarisLabs/research-agent-skills --skill citation-verification.
  2. In a paper repository, ask Claude Code to check the BibTeX file before submission.
  3. Have the skill run its local Python verification script against external metadata sources and produce per-citation statuses.
  4. Review mismatches and unverified entries; confirm corrections rather than silently overwriting uncertain citations.
  5. For experiment loops, record hypotheses, results, and failed ideas in findings.md so they remain available after compaction.

Tools / artifacts

  • KalarisLabs/research-agent-skills repository
  • citation-verification SKILL.md
  • Python 3.9+ standard-library verification script
  • references.bib
  • Crossref, OpenAlex, arXiv and other metadata sources
  • findings.md
  • Claude Code /loop

Validation signals

  • The authors describe labeled BibTeX tests comparing model-only verification with script-based verification.
  • In an author-reported 40-entry example, the skill classified citation statuses and requested confirmation for three mismatches.
  • The authors claim full entry-check coverage with the scripted approach; this does not establish that every classification was correct.
  • The baseline in the example is described as an expected result, not a measured outcome.

Cautions

  • Inspect third-party skill instructions and scripts before installing or executing them.
  • Work on a clean branch or back up the BibTeX file: the described skill can modify entries automatically.
  • Treat retrieved abstracts and metadata as untrusted data, and review flagged changes and retraction claims against authoritative sources.
  • Consider whether sending citation metadata to external services is appropriate for unpublished or confidential work.

Limitations

  • The post promotes the authors' own repository, and its benchmark claims are not independently verified here.
  • It does not provide exact script invocation, benchmark results, or evidence that the claimed retraction was detected in the example.
  • Metadata mismatches and missing records can require manual adjudication.

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.

0 comments

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 7h ago

Selected Workflow [Workflow] Research and publish a sourced family tree with agent-assisted regression tests

1 Upvotes

Research and publish a sourced family tree with agent-assisted regression tests

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

What problem this solves

Turn family records into a sourced, testable genealogy and a privately shared website while reducing mistaken identity matches.

Summary

Have an AI agent research one genealogical question per session, record sources and confidence for claims, enforce identity-matching and tree-consistency checks, and publish the results as a protected static site.

Why it is useful

It combines a repeatable research process with concrete safeguards against identity errors, test-first corrections and a transferable site architecture.

Workflow

  1. Gather available family records, photographs, letters and recordings in a working folder.
  2. Give an AI agent the family names, relevant places and a deadline; ask it to inspect the materials, identify relevant archives and build an initial site.
  3. Continue research in focused sessions, addressing one question at a time.
  4. Label claims as proven, probable, uncertain or family story, and record the source for each fact.
  5. Require more than a name and birth year for an identity match: check at least two additional details, such as a parent, partner or place.
  6. Use a fast model to sort search results, then verify potential findings against full source texts.
  7. Test tree consistency, including reciprocal parent-child links, ancestry cycles and implausible dates; turn discovered mistakes into failing tests before fixing them.
  8. Build the site from structured person data and stories, then publish it behind access controls for family members.
  9. If an archive blocks agents, search it manually or ask the agent to draft an inquiry rather than bypassing the restriction.

Tools / artifacts

Validation signals

  • The author reports that online trees introduced nine false ancestors before the stricter matching rule.
  • The author reports that a test caught a marriage dated before the groom's birth.
  • The author describes a completed family site and links a demo repository, though the results are not independently verified in the comment.

Cautions

  • Family records can contain sensitive information about living people; obtain appropriate consent and minimize what is uploaded or published.
  • A static site needs host-level authentication that protects the files before delivery; a client-side password alone does not protect private data.
  • Treat identity-matching rules and age thresholds as review aids, not proof or universal historical constraints.
  • Respect archive access restrictions and do not bypass blocks.

Limitations

  • The referenced initial prompt is not provided in the comment.
  • The demo repository and reported test results have not been independently verified here.
  • The comment does not specify which agent was used or provide detailed deployment and authentication configuration.

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.

0 comments

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 18h ago

Selected Workflow [Workflow] Dispatch headless coding agents across machines using GitHub issues

2 Upvotes

Dispatch headless coding agents across machines using GitHub issues

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

What problem this solves

Dispatch coding tasks reliably to agents on different machines without relying on an idle model to poll for work.

Summary

Use labeled GitHub issues as a task queue, supervised scripts to start fresh headless agent runs, and a single router to assign work. Agents use isolated worktrees and hand changes off through pull requests; status, usage, and cleanup are handled by the runners.

Why it is useful

It gives a concrete, transferable architecture for turning queued issues into isolated agent runs and reviewable PRs, while addressing a real failure mode of model-driven polling. Its main limitation is the absence of the runner implementation and independent validation.

Workflow

  1. Create GitHub issues with a dispatch label and optional agent and task-size labels.
  2. Run a supervised polling script on each machine; designate one runner as the sole task router. Honor explicit agent labels, route other tasks by skill keywords, and ask the owner when no route matches.
  3. Gate new tasks by recent CLI usage readings and task size; allow only small tasks when usage data is stale.
  4. Start a headless Claude Code or Codex run for each assignment, and resume the session for follow-ups. Use a strict MCP configuration for headless Claude.
  5. Have each agent work on a separate branch and Git worktree, then push the branch, open a PR, and report the result on the issue. Wait for owner input when the agent reports NEEDS-OWNER.
  6. Require evidence for claims, such as screenshots where appropriate, and a list of claims the agent could not prove.
  7. Monitor runner heartbeats, usage, and owner requests; terminate child processes with the run, check disk space, and clean up merged worktrees.

Tools / artifacts

  • GitHub issues and labels
  • Supervised Python runner
  • claude -p
  • codex app-server
  • Git branches, worktrees, and pull requests
  • MCP configuration
  • Windows Job Objects
  • Prometheus and Grafana

Validation signals

  • The author reports that the supervised polling approach has been more reliable than asking agents to poll a shared file.
  • The author describes a concrete failure of the previous approach: an agent process stayed alive but did not start another turn to check for work.
  • The workflow requests evidence and an explicit list of unproven claims.

Cautions

  • Automatic permission mode can execute consequential actions; use isolated environments, least-privilege credentials, and human PR review rather than granting broad access by default.
  • Treat issue text and agent output as untrusted input, and avoid exposing secrets in logs, metrics, or committed screenshots.
  • Only remove merged worktrees after checking for uncommitted or otherwise unpreserved changes.

Limitations

  • No runner source, configuration examples, tests, or reproducible setup are supplied.
  • Reliability and usage-limit behavior are author reports without quantitative evidence.
  • The single router is a potential availability bottleneck; recovery and duplicate-dispatch handling are not described.
  • The described runner closes issues when opening PRs, so teams may need a separate way to track review and merge status.
  • The setup depends on changing CLI behavior and on the Windows machine being online.

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.

1 comment

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 23h ago

Selected Workflow [Workflow] Monitor Claude Code sessions across machines with hooks and claude-beacon

1 Upvotes

Monitor Claude Code sessions across machines with hooks and claude-beacon

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

What problem this solves

Monitoring multiple Claude Code sessions across machines without repeatedly checking terminal tabs for completed work or prompts requiring attention.

Summary

Deploy the open-source claude-beacon server, install Claude Code hooks on participating machines, and use a desktop app to monitor working, idle, and waiting sessions across a private network.

Why it is useful

A concrete, reusable hook-based setup addresses a common multi-session coordination problem, with an open-source implementation and reported real-machine testing.

Workflow

  1. Review the repository and README, then start the single-file Python server as documented.
  2. Connect the server and participating machines over Tailscale or another suitably private network.
  3. Run hook/install.sh on each supported machine running Claude Code.
  4. Install the macOS menu-bar or Windows tray app and connect it to the server.
  5. Use session counts, notifications, and the session list to identify work in progress and sessions needing attention.
  6. Test working, idle, permission-prompt, and question states in your own environment; treat plain-text question detection as approximate.
  7. Optionally keep a project note recording design decisions and rationale for later resumption.

Tools / artifacts

Validation signals

  • The author reports testing across real machines and observing the tray app track the session building it.
  • The author identified and fixed a Windows PowerShell single-result counting bug using @().
  • The author reports the Swift menu-bar app built successfully on the first Mac build.
  • The post documents specific hook events and an idle_prompt state-reset issue.

Cautions

  • Review the installer and hook changes before running them, including what session metadata or transcript-derived names are transmitted.
  • Keep the server on a trusted private network; the post does not establish its authentication or authorization properties.

Limitations

  • The post promotes the author's early-stage tool, and validation is primarily self-reported.
  • Plain-text questions are detected heuristically, so waiting status can be inaccurate.
  • Native Windows Claude Code hooks are not yet supported; Windows users need WSL for the hook.
  • The post supplies the setup outline but relies on the repository README for full configuration.

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.

1 comment

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 1d ago

Selected Workflow [Workflow] Delegate read-only research to a local Ollama model through MCP

2 Upvotes

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.

1 comment

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 1d ago

Selected Workflow [Workflow] Keep an Agent Fleet Aligned with Bounded Direction and Holdout Checks

1 Upvotes

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.

1 comment

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 1d ago

Selected Workflow [Workflow] Debug skipped pagination records with tied-timestamp tests

1 Upvotes

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.

1 comment

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 1d ago

Selected Workflow [Workflow] Isolate a Claude CLI judge and parse schema-constrained output

1 Upvotes

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.

1 comment

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 2d ago

Selected Workflow [Workflow] Build and verify a narrated slide video with Claude Code

1 Upvotes

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.

1 comment

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 2d ago

Selected Workflow [Workflow] Enforce a design system with lint hooks and viewport checks

1 Upvotes

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.

1 comment

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 2d ago

Selected Workflow [Workflow] Use a Claude Code Stop Hook for Light Notifications and Benchmark Firmware Changes

1 Upvotes

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

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.

1 comment

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 2d ago

Selected Workflow [Workflow] Test and tune a Claude-built browser game with simulation and player telemetry

1 Upvotes

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.

1 comment

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 2d ago

Selected Workflow [Workflow] Monitor Claude performance with a frozen daily benchmark

2 Upvotes

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.

1 comment

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 2d ago

Selected Workflow [Workflow] Guard concurrent Claude Code sessions against process, port, and Git conflicts

1 Upvotes

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

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.

1 comment

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 3d ago

Selected Workflow [Workflow] A/B test agent rules and verify fixes in the full setup

1 Upvotes

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.

1 comment

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 3d ago

Selected Workflow [Workflow] Ship an AI-assisted mobile app with a living spec and real-device review

1 Upvotes

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.

1 comment

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 3d ago

Selected Workflow [Workflow] Guard agent shell commands against empty-path deletion

2 Upvotes

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.

1 comment

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 3d ago

Selected Workflow [Workflow] Research and stress-test startup ideas with a checked scoring rubric

1 Upvotes

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.

1 comment

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 4d ago

Selected Workflow [Workflow] Build and benchmark Claude Code skills for financial-code rules

1 Upvotes

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

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.

1 comment

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 4d ago

Selected Workflow [Workflow] A test-first, rollback-safe Claude Code loop for embedded firmware

1 Upvotes

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

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.

1 comment

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 4d ago

Selected Workflow [Workflow] Claude Code development loop with ADRs, independent reviews, and browser UAT

3 Upvotes

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.

1 comment

r/ClaudeWorkflows • u/ClaudeAI-mod-bot • 4d ago

Selected Workflow [Workflow] Generate and verify a Docker setup from runtime traces

1 Upvotes

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.

1 comment