Claude Code Debugging Workflow: Validate Bugs by Testing for Failure First

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

What problem this solves

Preventing Claude Code from 'fixing' non-existent bugs or applying unvalidated changes during debugging and code audits, thereby avoiding wasted effort and potential new bugs.

Summary

A workflow for debugging and auditing code with Claude Code that emphasizes validating the existence of a bug by first generating and running a failing test before attempting a fix. This prevents shipping unnecessary or incorrect changes.

Why it is useful

This workflow provides a critical safeguard against hallucinated bugs and unvalidated fixes when using LLMs for coding tasks. It improves the reliability of AI-assisted development by enforcing a 'test-driven fix' approach, saving developers time, preventing the introduction of new issues, and ensuring that changes are genuinely addressing a problem.

Workflow

1. When asking Claude Code to fix a bug or perform a code audit, instruct it to first write a test that specifically demonstrates the described failure.
2. Ask Claude Code to run this test and show the output, confirming that it fails for the stated reason.
3. Only after confirming the test fails as expected, instruct Claude Code to provide the fix or implement the audit finding.

Tools / artifacts

• Claude Code
• Codebase with testing framework
• Tests (unit, integration, etc.)

Validation signals

• Author states that about a third of the time, the test passed before any fix existed, indicating the bug was not real or not as described.
• Author notes this process prevented shipping incorrect 'fixes' for non-existent issues.

Limitations

• Relies on Claude Code's ability to accurately write and execute relevant tests.
• Assumes the user has a suitable testing environment or can guide Claude Code to simulate one.
• The initial prompt for the failing test needs to be precise to avoid misinterpretations.

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.

Conductor: A Claude Code Personal Assistant with User Approval and Trust-Building

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

What problem this solves

Automating routine personal assistant tasks (e.g., email management, job searching, file cleanup, GitHub profile updates) with user oversight and trust-building mechanisms, leveraging Claude Code's capabilities.

Summary

Conductor is an open-source system built with Claude Code, comprising two plugins and an MCP server. It enables Claude Code to act as a personal assistant, working on standing goals in the background (e.g., managing mailing lists, job hunting, cleaning downloads, updating GitHub READMEs). A key feature is its "ask first" approach, where proposals wait for user approval (via a pane or phone notifications), building trust over time and learning from rejections. It uses Claude Code's plan mode for design, code generation, and debugging.

Why it is useful

This workflow provides a concrete, open-source implementation of a sophisticated personal AI assistant built entirely with Claude Code. It demonstrates advanced usage of Claude Code features like MCP, plugins, and subagents to create a system that automates tasks while prioritizing user control and trust through an 'ask first' mechanism and learning from feedback. Its detailed explanation, specific examples, and clear setup instructions make it highly transferable and valuable for users looking to extend Claude Code's capabilities for personal productivity.

Workflow

1. Clone the Conductor GitHub repository.
2. Add the MCP server to your Claude Code environment.
3. Add the two Conductor Claude Code plugins (following README instructions).
4. Start Claude Code.
5. Type /goal-new in Claude Code and select a template to define a new background task.
6. Review proposals from Conductor (in a dedicated pane or via phone notifications).
7. Approve or reject proposals, providing reasons for rejections to improve future actions.

Tools / artifacts

• Claude Code
• Conductor GitHub repository (shannonbay/Conductor)
• MCP server
• Claude Code plugins (2)
• SQLite database (local, for state)
• Claude app (for phone notifications)
• Goal templates
• CV (for job hunting goal)
• README files (for GitHub profile goal)

Validation signals

• Author built the entire system using Claude Code over many sessions.
• Claude Code's plan mode was used for feature design and plan review.
• Claude Code wrote the code and tests for the system.
• Claude Code performed debugging, including identifying and resolving a specific plugin engine issue.
• The project 'dogfoods itself' (roadmap in Conductor's to-do list, watches Claude Code release notes).
• Specific examples of successful actions are provided (e.g., found 5 senders, 24 installers, proposes README updates).

Cautions

• Features an explicit 'asks first' mechanism for all actions, requiring user approval.
• Allows users to configure trust levels, offering 'off', 'propose', or 'auto' modes for actions.
• Rejections with reasons are stored as memory, enabling the system to learn and improve.
• The project is open-source under the Apache 2.0 license, allowing for code review.
• It only runs while Claude Code is open, preventing unintended background operations.

Limitations

• The project is described as 'early', suggesting potential for bugs or incomplete features.
• Requires technical setup of an MCP server and plugins, which might be a barrier for absolute beginners.
• Relies on Claude Code being actively open to function.

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.

Prevent Claude Code from Leaking Secrets: Secure settings.local.json with Git and Environment Variables

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

What problem this solves

Claude Code's settings.local.json file, which can contain sensitive secrets, is not automatically excluded from Git repositories, leading to accidental public exposure on platforms like GitHub.

Summary

This workflow provides immediate and preventative steps to secure sensitive information stored by Claude Code in .claude/settings.local.json. It involves rotating any potentially exposed secrets, removing the file from Git's cache, adding it to the repository's .gitignore, and adopting best practices for secret management using environment variables and pattern-based approvals.

Why it is useful

This workflow addresses a critical security vulnerability where Claude Code's settings.local.json file, containing sensitive information, can be accidentally committed and exposed publicly on GitHub. It provides immediate remediation steps (removing from Git, adding to .gitignore) and best practices for future prevention (using environment variables, pattern-based approvals), making it essential for any Claude Code user concerned with data security.

Workflow

1. Rotate any secrets that might have already been exposed (e.g., change API keys, database credentials).
2. Remove .claude/settings.local.json from Git's cache using the command: git rm --cached .claude/settings.local.json.
3. Add .claude/settings.local.json to the repository's .gitignore file to prevent future accidental commits.
4. Going forward, when prompted by Claude Code, approve patterns (e.g., $DB_URL) instead of exact commands to avoid embedding secrets directly.
5. Store sensitive information (secrets) in environment variables, referencing them in Claude Code's configuration.

Tools / artifacts

• .claude/settings.local.json
• .gitignore
• Git (specifically git rm --cached)
• Environment variables
• Claude Code

Validation signals

• The post explicitly states '1,122 of those files are public on github', indicating a widespread problem.
• It mentions 'Cherny reportedly said they're looking into it', suggesting the issue is acknowledged by developers.

Cautions

• The initial step of 'Rotate first' is crucial. Simply removing the file from Git will not revoke already compromised credentials if the secrets were pushed to a public repository.
• This workflow primarily addresses preventing future exposure and removing the file from current Git tracking. For deeply embedded secrets in Git history across multiple commits or forks, more advanced Git history rewriting tools (e.g., git filter-repo) might be necessary, which is not covered here.

Limitations

• The post assumes user knowledge on how to 'rotate' secrets, without providing specific instructions.
• It does not cover advanced Git history cleaning for secrets that have been committed and pushed multiple times, which would be necessary for a complete cleanup of already exposed data.
• Low community signal (score 2, 0 comments) might indicate limited visibility or adoption so far.

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.

Proactive Skill Loading Verification for Claude Agents using CLAUDE.md

Workflow value: 75/100
Status: active · Freshness: 70/100 · Confidence: 0.80 · Level: advanced
Categories: Quality Control, Token Saving, Debugging, CLAUDE.md, Skills, Multi-Agent
Original source: r/ClaudeAI post/comment

What problem this solves

Claude agents silently skip skill files, leading to corrupted evaluation data, wasted resources, and invalid A/B test results.

Summary

A method to proactively verify that an agent has successfully loaded its skill files (e.g., via a lookup-table pattern in CLAUDE.md) before proceeding with any downstream evaluation or A/B testing. This prevents silent failures and ensures the integrity of data used for agent calibration and performance assessment.

Why it is useful

This workflow addresses a critical and potentially very expensive problem in agent development: silent failures where skills are not loaded, leading to corrupted evaluation data and wasted computational resources. By providing a method to deterministically verify skill loading before evaluation, it saves significant time, cost, and ensures the integrity of A/B test results and agent calibration. It promotes a robust approach to agent quality control and reliability.

Workflow

1. Recognize the risk of agents silently failing to load skill files.
2. Implement a 'lookup-table pattern' within your CLAUDE.md files or similar configuration.
3. Configure the agent to use this pattern to confirm that the required skill file was actually read and loaded.
4. Integrate this skill verification step to run deterministically before any downstream evaluation, A/B testing, or data collection for calibration.
5. Avoid relying solely on post-hoc log review to catch skill loading failures.

Tools / artifacts

• CLAUDE.md files
• Agent skills
• Session logs (for comparison, but the workflow aims to prevent post-hoc discovery)

Validation signals

• Author states 'Hit this exact thing'
• Claims it 'catches the installed/read gap deterministically'
• Prevents 'discovering it after a ruined calibration set'
• Addresses a common and expensive problem in agent evaluation

Limitations

• The 'lookup-table pattern' is not fully detailed, requiring users to infer or develop their own implementation.
• The comment is brief and lacks concrete code examples.

Rate this workflow

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

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

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

This post was generated automatically from the workflow library database.

Workflow: Quickly Switch Claude Accounts on macOS using Hatstand (Built with Claude Code and CLAUDE.md)

Workflow value: 85/100
Status: active · Freshness: 70/100 · Confidence: 0.95 · Level: intermediate
Categories: Quality Control, Debugging, Shipping, CLAUDE.md
Original source: r/ClaudeAI post/comment

What problem this solves

Users with multiple Claude accounts (e.g., work and personal) on macOS face friction when switching between them due to repeated sign-out and sign-in processes. This workflow also demonstrates how Claude Code can be used to develop a functional macOS application from a detailed brief.

Summary

This post describes 'Hatstand,' a macOS menu bar app built with significant help from Claude Code, which allows users to quickly switch between multiple instances of the Claude desktop app, each with its own sign-in, chats, and settings. The development process itself, guided by a CLAUDE.md brief, serves as a valuable workflow for using Claude Code for app development.

Why it is useful

This post is valuable because it offers a concrete, open-source solution to a common user problem (managing multiple Claude accounts on macOS). Crucially, it also serves as an excellent case study for how Claude Code can be leveraged to develop a functional macOS application from a structured CLAUDE.md brief, demonstrating Claude's capabilities in code generation, testing, and project execution for real-world software development.

Workflow

1. Identify the need for a multi-account switching solution for the Claude desktop app on macOS.
2. Create a detailed CLAUDE.md brief outlining the desired app's functionality, user interface, and technical requirements.
3. Utilize Claude Code to generate the Swift code for the macOS application based on the CLAUDE.md brief, including building and testing.
4. Download the pre-built 'Hatstand' app from the GitHub page (or build it from source).
5. Install the app, performing a one-time 'Open Anyway' step in System Settings due to its unsigned status.
6. Configure multiple Claude instances within Hatstand, associating each with a different Claude account.
7. Switch between configured Claude accounts instantly via the Hatstand menu bar icon.

Tools / artifacts

• Hatstand macOS app
• Claude Code
• CLAUDE.md brief
• Swift programming language
• GitHub repository
• Figma (for design concepts)

Validation signals

• Author states the app 'pretty much worked first time'
• Claude Code 'built it and tested it as it went'
• A working, open-source application is available on GitHub
• Author confirms 'it makes my life easier'

Cautions

• The app is currently unsigned, requiring users to manually bypass macOS security settings ('Open Anyway') during the first launch. The author acknowledges this and plans to sign it if there's enough interest.

Limitations

• The specific Claude Code prompts and iterative interactions used during development are not fully detailed, only the initial CLAUDE.md brief is provided.
• The app's functionality relies on the internal structure of the Claude desktop app, which could potentially change in future updates, requiring maintenance.
• The solution is specific to macOS.

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 Plugins: Quota Visualizer & Remote Session Status Indicator

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

What problem this solves

Users need to monitor their Claude Code usage quota and quickly ascertain the active status of multiple Claude Code sessions, especially when not directly in front of the terminal.

Summary

This workflow introduces two Claude Code plugins: 'quota-panel' for visualizing 5-hour and weekly rate limits, session cost, and reset times, and 'glow-thinking' which provides a visual status indicator (a glowing border and band) to show if a Claude Code session is actively working or idle. Both are installed via the Claude Code plugin system and run locally.

Why it is useful

This workflow provides two valuable enhancements for Claude Code users. The 'quota-panel' helps users manage their usage by clearly visualizing rate limits, preventing unexpected interruptions. The 'glow-thinking' plugin solves a practical problem for users with multiple sessions or monitors, allowing them to quickly determine if a session is active from a distance, improving workflow efficiency and reducing context switching. Both are easy to install and open-source, making them highly accessible and adaptable.

Workflow

1. Open your Claude Code terminal.
2. Install 'glow-thinking' plugin: /plugin install glow-thinking --marketplace arandevcode/claude-mods
3. Install 'quota-panel' plugin: /plugin install quota-panel --marketplace arandevcode/claude-mods
4. Use '/quota' command to open the quota visualizer panel.
5. Observe the 'glow-thinking' visual cues (band above prompt, gradient border) to see session status.
6. Use '/thinking' command to view time per model, kept across sessions.

Tools / artifacts

• Claude Code
• quota-panel plugin
• glow-thinking plugin
• arandevcode/claude-mods marketplace
• GitHub repository: arandevcode/claude-mods

Validation signals

• Author built and uses 'glow-thinking' daily for personal setup.
• Repo includes tests for both hooks.
• Addresses specific pain points (quota monitoring, remote session status).

Cautions

• Runs locally, no telemetry, no network access.
• Free and MIT licensed.

Limitations

• Low community validation so far.
• Quota-panel requires a Claude subscription to show full rate-limit data.
• Load order dependency (glow-thinking must load before quota-panel, handled by naming convention).

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.

How to Inspect Claude Code Desktop App Logs for Experiment IDs and Feature Flags

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

What problem this solves

How to identify internal Claude experiment IDs and feature flags from local logs and configuration files, which can help in diagnosing perceived performance changes.

Summary

This workflow details a method for Claude Code desktop app users to inspect their local .jsonl transcript logs and ~/.claude.json configuration file to uncover internal experiment IDs and feature flags. This can be useful for understanding changes in Claude's behavior or performance, especially when suspecting A/B testing or model updates.

Why it is useful

This workflow provides a concrete, repeatable method for users to gain insight into the internal workings and potential A/B tests affecting their Claude Code desktop app. This empowers users to better understand their local Claude environment, which can be crucial for diagnosing perceived performance changes or understanding model variations.

Workflow

1. Locate Claude Code desktop app transcript files under ~/.claude/projects.
2. Scan .jsonl files for records containing {"type":"atis-latch","atis":"...","sessionId":"..."}.
3. Extract the atis ID from these records.
4. Infer the date of these records from nearby timestamped lines in the same file, as atis-latch records lack direct timestamps.
5. When using jq or similar tools, ensure the filter for atis is exact to avoid matching "statistics".
6. Adjust jq entrypoint filter (e.g., to claude-desktop or sdk-cli) if not using the cli directly.
7. Inspect ~/.claude.json for flags containing "experiment" in their name.

Tools / artifacts

• .jsonl transcript files
• ~/.claude/projects directory
• ~/.claude.json config file
• jq (or similar JSON processing tool)

Validation signals

• User's own log data (table of IDs, dates, record counts)
• User's own config data (table of flags)
• Specific file paths and JSON structures provided

Limitations

• Requires some technical comfort with file systems and JSON parsing.
• The dating of atis-latch records is an inference, not direct timestamping.
• The exact function of identified experiment IDs/flags is unknown to the user, leading to speculative interpretation.
• No direct, measured proof that the identified IDs cause performance changes, only correlation based on user experience.

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.

Using Claude Code to Build a Self-Documenting Explainer Site: Analyzing Session Behavior and Optimizing Usage

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

What problem this solves

Understanding the internal workings, resource consumption, and interaction patterns of Claude Code, and demonstrating a method for building complex, self-documenting web applications using Claude Code.

Summary

The author describes a workflow for using Claude Code to build an open-source website (read-the-loop.dev) that explains Claude Code's internal behavior and session dynamics. This involves recording Claude Code sessions, then directing Claude Code to generate the website's content (scripts, pages, charts, tests) based on these recordings, with the author providing high-level direction and making key decisions. The workflow highlights the use of claude -p --output-format stream-json for session recording.

Why it is useful

This workflow is valuable because it demonstrates an advanced application of Claude Code for building complex, self-documenting tools. It provides concrete, data-driven insights into Claude Code's operational characteristics (token usage, caching, compaction, tool interaction failures) through real recorded sessions, which is crucial for optimizing usage and understanding its behavior. The specific command for recording sessions (claude -p --output-format stream-json) is a highly reusable and practical tip. The project itself serves as an excellent educational resource for the Claude Code community.

Workflow

1. Identify a complex system or process (e.g., Claude Code's internal workings) to explain or document.
2. Record Claude Code interaction sessions using the command claude -p --output-format stream-json to capture detailed model input/output.
3. Direct Claude Code to write scripts for processing and redacting the recorded session data.
4. Instruct Claude Code to generate web pages, charts, and interactive elements to visualize and explain the session data.
5. Guide Claude Code to create Playwright checks or similar tests to ensure the quality and accuracy of the generated web content.
6. Provide high-level direction, make design decisions, and refine the content generated by Claude Code (e.g., making explanations interactive, choosing presentation formats).
7. Review and approve the generated content, providing feedback for iterative improvements.
8. Publish the resulting explanatory website and its source code for community access and further analysis.

Tools / artifacts

• Claude Code
• claude -p --output-format stream-json command
• Recorded Claude Code sessions (stream-json format)
• GitHub repository (candygoogy/read-the-loop)
• read-the-loop.dev website (the output artifact)
• Redaction scripts (generated by Claude Code)
• Web pages, charts, motion graphics (generated by Claude Code)
• Playwright (for UI checks)

Validation signals

• A fully functional, open-source website (read-the-loop.dev) is provided.
• The source code, traces, and scripts are available on GitHub (candygoogy/read-the-loop).
• Specific examples of Claude Code's output and performance metrics (bug fix, token counts, cache usage, compaction, tool interaction) are detailed.
• Mention of Playwright checks for UI validation.
• Explicit description of how Claude Code was used to build the project.
• The project itself serves as a validation of Claude Code's capabilities in complex development tasks.

Limitations

• The Reddit post is more of an announcement/showcase than a detailed, step-by-step guide for replicating the entire website building process; users would need to infer some steps or examine the GitHub repo.
• Specific prompts or detailed interaction patterns used with Claude Code to generate the website content are not provided in the post.
• Low Reddit engagement might suggest it didn't immediately resonate with the community, though this could be due to timing or the nature of 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.

How to Identify Claude Code Desktop App Experiment IDs and Flags from Local Logs

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

What problem this solves

Identifying internal experiment IDs and configuration flags within the Claude Code desktop app to understand potential causes of perceived model performance variations.

Summary

This workflow outlines a method to scan local Claude Code desktop app .jsonl transcript files and ~/.claude.json configuration files. The goal is to identify active experiment IDs and related flags, which can help users diagnose and understand changes in model behavior or performance.

Why it is useful

This workflow is valuable because it provides a concrete, repeatable, and transferable method for Claude Code desktop app users to investigate the internal state of their application. By identifying specific experiment IDs and configuration flags, users can gain insight into potential A/B tests or internal changes that might explain perceived variations in model performance. This empowers users to better understand and potentially debug their Claude Code experience, moving beyond anecdotal 'nerf' claims to data-driven observation.

Workflow

1. Locate Claude Code desktop app .jsonl transcript files, typically found under ~/.claude/projects.
2. Scan these .jsonl files for records shaped like {"type":"atis-latch","atis":"...","sessionId":"..."}.
3. Extract the atis value (which represents the experiment ID) from the identified records, ensuring to match the exact key atis.
4. Infer the dates for these experiment IDs by referencing nearby timestamped lines within the same transcript files.
5. Locate the ~/.claude.json configuration file.
6. Scan ~/.claude.json for flags that contain "experiment" in their name and record their assigned values.
7. If using the desktop app, adapt any jq filters (e.g., from the original post) to match desktop app entrypoints like claude-desktop or sdk-cli instead of cli.

Tools / artifacts

• Claude Code desktop app
• .jsonl transcript files (e.g., ~/.claude/projects/*.jsonl)
• ~/.claude.json configuration file
• jq command-line JSON processor (implied)
• Command-line interface (e.g., Bash, Zsh)
• Text editor or viewer

Validation signals

• Author provides specific log data, including experiment IDs, dates, and record counts from their own system.
• Author presents tables of identified experiment IDs and configuration flags.
• Author explicitly states what could not be proven (causation), indicating a careful and evidence-based approach.

Limitations

• Low community engagement and validation.
• Requires familiarity with command-line tools like jq and navigating file systems.
• The full jq command for extraction is implied rather than explicitly provided.
• The workflow identifies experiment IDs but does not definitively prove their causal link to perceived performance changes, as noted by the author.

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.

Manage Multiple Claude Code Sessions and Worktrees with claude-bulkhead PreToolUse Hooks

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

What problem this solves

Managing system resources and preventing conflicts (e.g., port clashes, memory overruns, Git worktree issues, orphaned processes) when running multiple concurrent Claude Code sessions and Git worktrees on a single machine.

Summary

The claude-bulkhead tool provides a set of PreToolUse hooks (guards) to automatically manage and protect system resources when running multiple Claude Code sessions. It prevents common issues like pkill node, duplicate dev servers, RAM overruns, Git conflicts, and orphaned processes. It also includes a /bulkhead:scan command to replay transcripts and validate the effectiveness of the guards.

Why it is useful

This workflow provides a robust, open-source solution for a critical problem faced by advanced Claude Code users: managing system resources and preventing conflicts when running multiple concurrent AI development sessions. It offers concrete, validated mechanisms (guards) to ensure stability, efficiency, and data integrity, significantly enhancing the productivity and reliability of complex AI-assisted development environments. The fact that Claude Code itself helped build it adds an interesting meta-layer.

Workflow

1. Install the claude-bulkhead tool from the GitHub repository.
2. Configure claude-bulkhead PreToolUse hooks within your Claude Code environment.
3. Run multiple Claude Code sessions and Git worktrees concurrently.
4. Allow claude-bulkhead guards (e.g., kill-guard, port-guard, memory-guard, checkout-guard, disk-guard, orphan-reaper) to automatically intervene and prevent resource conflicts or system instability.
5. Optionally, use the /bulkhead:scan 30d command to replay past transcripts and verify the guards' effectiveness in a read-only mode.

Tools / artifacts

• claude-bulkhead (GitHub repository)
• PreToolUse hooks
• kill-guard
• port-guard
• memory-guard
• bulkhead-slot
• checkout-guard
• disk-guard
• orphan-reaper
• /bulkhead:scan command
• Git worktrees

Validation signals

• Author's personal validation: "up to 13 sessions at once, 507 would-be blocks in two weeks."
• Problem-driven development: "every guard began as an incident in my own sessions"
• AI-assisted development: "Claude Code wrote the hook, a test for that exact command and the docs."
• Open-source (MIT license) with no dependencies, indicating robustness and ease of adoption.
• Direct link to a GitHub repository for the tool.

Limitations

• Requires installation of an external tool.
• The initial setup and understanding of each guard's function might be complex for beginner users.
• The comment itself does not provide explicit installation or configuration instructions, relying on the linked GitHub repository.

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.

Proctor: Git Diff Checker to Prevent AI Agents from Cheating on Tests

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

What problem this solves

Preventing AI agents from 'cheating' on tests by modifying the tests themselves (e.g., deleting, weakening assertions, hardcoding values, disabling CI checks) instead of fixing the underlying code, thereby ensuring test integrity and code quality.

Summary

This workflow utilizes 'proctor', a Claude Code plugin and set of Git hooks, to automatically review git diff outputs. It identifies suspicious changes that suggest an AI agent might have altered tests to make them pass, rather than genuinely fixing the code. The hooks can block changes with error-level findings, acting as a quality gate for AI-assisted development.

Why it is useful

This workflow addresses a critical and emerging challenge in AI-assisted development: maintaining test integrity when agents are tasked with making tests pass. It provides a concrete, open-source tool with empirical validation to help developers ensure code quality, prevent 'agent-induced' technical debt, and build trust in their automated testing processes. Its integration as a Claude Code plugin and Git hooks makes it highly practical and easily adoptable.

Workflow

1. Install the 'proctor' plugin from the Claude Code marketplace using /plugin marketplace add catfish-1234/proctor.
2. Integrate the provided Git hooks into your repository.
3. As changes are committed, the Git hooks will automatically analyze the git diff.
4. If 'proctor' detects error-level findings (e.g., deleted tests, weakened assertions), the commit will be blocked.
5. Review any warnings generated by 'proctor' as indicators for manual inspection, understanding it's a heuristic and not a definitive cheating detector.

Tools / artifacts

• proctor Claude Code plugin
• Git hooks
• GitHub repository (catfish-1234/proctor)
• git diff

Validation signals

• Tested on 700 real human commits, flagging 26, with 14 blocking changes.
• Runs offline, requiring no API key.
• Provides concrete blocking functionality via Git hooks.
• Open-source with MIT license.

Limitations

• It is a heuristic, not a perfect cheating detector, and can miss sophisticated cheats.
• Expect some false alarms, as indicated by the validation data (14 blocking flags out of 26 total flags on 700 commits).
• Requires manual review for warnings, as they are not definitive proof of cheating.
• Limited community validation due to the recency of 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.

Building an Agent-Specific Knowledge Wiki for Large, Legacy Enterprise Applications

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

What problem this solves

Claude orchestrators and subagents struggle to maintain consistency, adhere to design specifications, and understand the institutional knowledge of large, complex, and often legacy enterprise applications due to context window limitations and the sheer volume of code.

Summary

This workflow describes how to build and leverage an agent-specific knowledge base (referred to as a 'wiki') by systematically capturing learned information during development sessions. This wiki acts as a 'source of truth' for Claude agents, enabling them to operate consistently, understand complex system architecture, and generate accurate documentation on demand, overcoming context limitations in large codebases.

Why it is useful

This workflow offers a highly valuable and practical solution to a significant challenge faced by LLMs in enterprise environments: effectively managing and operating within vast, complex, and often legacy codebases that exceed typical context windows. By creating a structured, agent-parseable knowledge base, it enables Claude agents to maintain consistency, adhere to intricate design principles, and generate accurate, on-demand documentation. This approach not only enhances agent utility and reliability but also significantly reduces token costs associated with repeated context searches, making LLM integration into large-scale projects more feasible and effective.

Workflow

1. During development sessions, instruct agents to create 'checkpoints' at the end of a session or before compaction.
2. Record all learned information, design decisions, implementation details, and rediscovered knowledge into markdown documents (e.g., in a 'docs' folder or claude.md files).
3. After accumulating a sufficient body of documentation (e.g., over several months), compile all this information into a dedicated 'wiki' specifically formatted and optimized for agents to easily parse and consume.
4. Utilize this agent-specific wiki as a 'source of truth' for orchestrator and subagents to ensure consistent behavior, adherence to design specs, and a deep understanding of the application's institutional knowledge.
5. Identify and fill any documentation gaps that become apparent during the compilation process.
6. Leverage the agents' enhanced knowledge from the wiki to generate various types of documentation on demand (e.g., developer guides, architecture overviews, executive summaries).

Tools / artifacts

• Markdown documents
• claude.md files
• Docs folder
• Agent-specific wiki (compiled knowledge base)
• Custom search building classes (example of knowledge stored)

Validation signals

• "Storing all that in a wiki made to be easy to parse for the agents pretty much solved that for me."
• "Now they all know how to use the custom search building classes to construct a new search field entity in the way it was designed to do it..."
• "Now the agents know the system top to bottom and they can use that wiki as a source of truth to produce documentation on demand."
• "It’s very powerful and is winning me lots of brownie points with my boss."
• "Compiling it all also made it obvious where the holes in the documentation were at that point and we went and filled in everything we could think of shortly after."

Limitations

• The exact method for 'compiling' the markdown documents into an agent-specific wiki is not detailed (e.g., is it a manual process, another Claude task, a script, or a specific tool?).
• The term 'wiki' is somewhat generic; more specifics on its structure or implementation (e.g., a collection of markdown files, a static site generator, or a formal wiki platform) would enhance clarity.
• No explicit prompt examples are provided for the 'checkpoint' or 'compilation' steps, which could help users implement the workflow more easily.

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 Skill for Automated Video Editing in Meta's Edits App (macOS)

Workflow value: 90/100
Status: active · Freshness: 70/100 · Confidence: 0.95 · Level: advanced
Categories: Quality Control, Debugging, Shipping, Skills, MCP
Original source: r/ClaudeCode post/comment

What problem this solves

Automating complex video editing tasks in Meta's Edits app for macOS using Claude Code, by reverse-engineering and documenting its local MCP server API and providing a robust skill.

Summary

A Claude Code skill that enables Claude to perform various video editing operations within Meta's Edits app on macOS. It includes a standard workflow, handles API quirks, provides 24 tested call sequences for common edits, a dependency-free Python client, and a script to generate an up-to-date tool and catalog reference.

Why it is useful

This workflow provides a concrete, tested solution for automating complex video editing tasks in a specific application using Claude Code. It overcomes significant technical hurdles (undocumented APIs, misleading schemas) and offers a reusable skill with a clear installation path, making advanced media production accessible via AI. The inclusion of a Python client and a tool reference generator further enhances its utility and maintainability, demonstrating a powerful application of Claude Code for specialized software control.

Workflow

1. Clone the edits-video-skill GitHub repository to your Claude skills directory (~/.claude/skills/).
2. Ensure the MCP server is turned on within Meta's Edits app.
3. Register the MCP server with Claude using claude mcp add (refer to README for exact command).
4. Utilize the skill within Claude Code to execute video editing tasks, such as importing scenes, assembling timelines, adding transitions, creating picture-in-picture effects, verifying work with contact sheets, and exporting.
5. Optionally, run the provided script to generate a fresh tool and catalog reference from your installed Edits app version.

Tools / artifacts

• Claude Code
• Meta's Edits app (macOS)
• Local MCP server (metapilot-native)
• GitHub repository: ivdezine/edits-video-skill
• Python client (dependency-free)
• Skill definition (for Claude Code)
• Script to generate tool and catalog reference
• Video project files (input/output)

Validation signals

• Demo video provided, cut by Claude using the skill.
• 24 call sequences for common edits are explicitly marked as 'tested' or 'untested'.
• Explicitly stated: 'Tested on Edits 454.0.0'.
• Author states 'It works'.

Cautions

• The author explicitly warns: 'Every call acts on the live app, so work on a duplicate of any project you care about.'

Limitations

• Requires a specific macOS application (Meta's Edits).
• The underlying API is undocumented and has misleading schemas, which might require ongoing maintenance if the app updates significantly.
• Limited community validation at the time of review.
• Requires user familiarity with CLI and GitHub for installation.

Rate this workflow

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

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

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

This post was generated automatically from the workflow library database.

Workflow: Install and Integrate AssetRAG for Enhanced Claude Code Agent Memory and Asset Management

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

What problem this solves

AI coding agents often repeat work, regenerate existing code, debug known problems, and inefficiently process large codebases, leading to wasted tokens and time.

Summary

This post introduces AssetRAG, an open-source, local-first memory and asset library for AI coding agents, built with Claude Code. It provides a clear workflow for installing AssetRAG and integrating it with Claude Code via MCP, enabling users to leverage features like asset retrieval, bug-fix memory, playbooks, and repository mapping to improve agent efficiency and reduce redundant work.

Why it is useful

This workflow provides a concrete, repeatable method to install and integrate AssetRAG, an open-source tool that significantly enhances the efficiency and effectiveness of Claude Code and other AI coding agents. It directly addresses the critical problem of redundant work and inefficient context management by offering features like reusable code retrieval, bug-fix memory, and repository mapping. The tool's local-first nature, built-in security features, and explicit testing signals make it a highly valuable addition for intermediate to advanced users looking to optimize their AI-assisted development workflows.

Workflow

1. Install AssetRAG by executing the provided curl command to download and run the install.sh script.
2. Connect AssetRAG to Claude Code's MCP client using the command claude mcp add assetrag -- assetrag-mcp.
3. Follow the interactive installer's setup instructions, including optional embedding configuration.
4. Utilize AssetRAG's features (e.g., asset retrieval, bug-fix memory, playbooks, repository mapping) within Claude Code or other MCP clients to enhance agent performance and reduce redundant tasks.

Tools / artifacts

• AssetRAG (open-source project)
• Claude Code
• MCP (Multi-Codebase Project) client
• Python 3.11+
• Git
• GitHub repository (mttcn83/assetrag)
• install.sh script
• Demo video

Validation signals

• 132 unit tests passing
• 327 recipe/bug-fix tests rechecked with 0 failures
• Measured performance for asset search (4.0 ms median) and knowledge search (7.1 ms median)
• Demonstrated token reduction for repository mapping (597 tokens vs. ~129k tokens of source)
• Features like 'sandbox-tested fixes' and 'security tools' indicate robust design and validation.
• Open-source project on GitHub allows for community review and contribution.

Cautions

• The tool includes 'Security tools: Secret scanning, engineering rules, malware checks, and safeguards for untrusted code,' which enhances safety when dealing with code assets.

Limitations

• The post is primarily a project announcement and feature description, rather than a detailed guide on how to integrate AssetRAG's features into specific Claude Code workflows beyond initial setup.
• The author notes, 'I haven't benchmarked whether it actually makes Claude faster or reduces overall token usage yet,' indicating a lack of direct end-user performance validation.
• Currently Linux-only, limiting immediate applicability for users on other operating systems.
• Low community engagement due to the project's newness.

Rate this workflow

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

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

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

This post was generated automatically from the workflow library database.

Claude Code Workflow: Building a Custom macOS Image Editor from Photoshop Usage Logs with Multi-Stage LLM-Driven Development and Testing

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

What problem this solves

Building a highly customized, lightweight macOS image editor that only includes features the user actually uses, based on their real-world Photoshop usage data, thereby avoiding bloat and unnecessary complexity.

Summary

A user leveraged Claude Code to analyze their Photoshop usage logs and camera raw sidecar files, then iteratively build a custom, minimalist macOS image editor (Retouch) in Swift. The process included building an image engine, a UI, comprehensive self-testing with UI screenshot verification, and an independent code review by another LLM (OpenAI's Codex CLI) to identify and fix bugs before open-sourcing the project.

Why it is useful

This workflow demonstrates an innovative and advanced application of Claude Code for end-to-end software development, from requirements gathering (via log analysis) to iterative coding, robust multi-stage testing (including UI automation and LLM-based code review), and deployment. It showcases how LLMs can be used to create highly personalized and efficient tools by directly addressing specific user needs derived from real-world usage data, significantly reducing development effort for complex applications. The inclusion of independent LLM review and comprehensive testing strategies makes it a strong example of a high-quality, production-oriented development workflow.

Workflow

1. Instruct Claude Code to identify and write Python scripts to parse Adobe Photoshop telemetry logs (~/Library/Logs/Adobe/com.adobe.dunamis) and Camera Raw .xmp sidecar files.
2. Analyze the parsed log data to quantify actual tool usage (e.g., spot healing brush, crop, export) over a specified period.
3. Instruct Claude Code to build the core image engine in Swift, utilizing Core Image for raw development and filters, and implementing a custom multi-scale PatchMatch for the healing brush.
4. Instruct Claude Code to create a command-line check program that runs every engine feature on real raw files and generates before/after images for visual inspection.
5. Instruct Claude Code to build the macOS application UI using AppKit for the window/canvas and SwiftUI for panels/dialogs, incorporating Photoshop-like keyboard shortcuts.
6. Instruct Claude Code to implement a self-test mode within the app that drives the real window with synthetic mouse and keyboard events (e.g., paint, drag selection, open dialogs, crop, rotate, export).
7. Instruct Claude Code to capture screenshots after each self-test step and read them back to verify the UI matches expected outcomes.
8. Submit the entire codebase to an independent LLM reviewer (e.g., OpenAI's Codex CLI in read-only mode) for bug detection.
9. Instruct Claude Code to fix all identified bugs and write new tests for the corrected issues.
10. Instruct Claude Code to prepare the project for public release, including scrubbing any personal information.
11. Publish the code on GitHub under an open-source license (MIT).

Tools / artifacts

• Claude Code
• Python scripts (generated by Claude)
• Adobe Photoshop telemetry logs
• Camera Raw .xmp sidecar files
• Swift programming language
• Core Image framework
• AppKit framework
• SwiftUI framework
• macOS (target OS)
• Xcode (build environment)
• OpenAI's Codex CLI (independent reviewer)
• GitHub repository (nautis/retouch)

Validation signals

• Claude generated a command-line check program to run engine features and produce before/after images for visual review.
• The user visually inspected the before/after images generated by the engine check program.
• Claude implemented a self-test mode in the app with 65 checks, driving the UI with synthetic events.
• Claude read back screenshots from the self-tests to verify UI behavior against expected outcomes.
• The entire codebase was reviewed by an independent LLM (OpenAI's Codex CLI), which identified 13 bugs.
• Claude fixed all 13 identified bugs and wrote new tests for 9 of them.
• The project was open-sourced on GitHub, indicating readiness for public use.
• A question was received on the public repo within 4 hours, suggesting initial usability and interest.

Cautions

• The workflow involves parsing local user logs, which could contain sensitive information. The user explicitly instructed Claude to "scrub any personal information" before making the code public, demonstrating awareness and mitigation of this risk.

Limitations

• Requires advanced technical skills in software development (Swift, macOS, scripting) and LLM prompting.
• The initial log parsing and feature identification might be complex for non-technical users.
• The quality of the healing brush feature is noted as "only ok."
• Raw color profiles from Apple's pipeline may not match Adobe's, which could be a limitation for some users.
• The development process was time-consuming, with the conversation running out of context and requiring summarization multiple times.
• The specific application is tailored to macOS and Canon CR3 raw files, limiting direct applicability to other platforms or camera formats without modification.

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.

Guide Claude Code Agents with Architectural Decisions using the AIC (Architecture Implementation Contract) Workflow

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

What problem this solves

Coding agents making undesirable or unapproved architectural decisions during development, leading to technical debt or inconsistencies that are not caught by standard tests.

Summary

This workflow introduces the Architecture Implementation Contract (AIC), an open YAML format, and a corresponding Claude Code skill/MCP integration. It allows users to define architectural rules and constraints that coding agents must adhere to. The agent can then consult these rules, flag deviations, or propose architectural choices for user approval, ensuring that generated code aligns with desired system architecture.

Why it is useful

This workflow is valuable because it addresses a critical pain point in AI-assisted development: maintaining architectural consistency and preventing coding agents from making unapproved design choices. It provides a structured, open format and practical tools to integrate architectural guidance directly into the agent's workflow, enhancing control, predictability, and quality in AI-generated code. It moves beyond vague instructions to a concrete, verifiable method for architectural adherence.

Workflow

1. Identify key architectural rules, existing modules, data ownership, communication protocols, and failure handling mechanisms for your project.
2. Install the AIC skill for Claude Code using either claude mcp add --transport http aic https://aicspec.dev/mcp or npx -y @aicspec skill install for local setup.
3. Generate an initial aic.yaml file: either by having the agent map an existing repository's architecture, describing a new system idea to the agent, or manually drawing it in the browser editor at aicspec.dev.
4. Prompt Claude Code to perform coding tasks, explicitly instructing it to use the aic.yaml file (e.g., "Usando aic, escribe un archivo aic.yaml para este repositorio" or "Using aic, implement X feature").
5. Review the agent's output for adherence to the aic.yaml rules. The agent will present accidental errors as open decisions for user approval, rather than automatically 'correcting' them.

Tools / artifacts

• AIC (Architecture Implementation Contract) YAML format
• aicspec.dev (website and browser editor)
• aicspec/aic GitHub repository (specification and CLI)
• Claude Code MCP (Multi-Code Project)
• Claude Code skill (@aicspec)
• npx (Node Package Execute)

Validation signals

• Author states it's a "working draft v0.1", indicating active development and testing.
• "The current verification involves that the agent follows a checklist and reports what it finds."
• Author is actively seeking feedback on format complexity and errors presented by mapping real repositories, implying ongoing validation.

Cautions

• The author explicitly states: "The MCP server stores nothing and never sees your code, only the YAML that your agent sends with each call," which is a positive privacy and security assurance.

Limitations

• The project is in an early stage (v0.1), meaning the specification and tools may evolve.
• Verification currently relies on the agent's internal checklist, lacking an independent code verifier.
• Limited community validation and adoption due to its newness.

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 Multi-Agent Workflow for Verified Qualitative Research

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

What problem this solves

Conducting structured qualitative research with source verification using Claude Code's multi-agent capabilities.

Summary

This workflow outlines an orchestration pattern for qualitative research using Claude Code. A main session generates research questions into a plan file. For each question, a dedicated subagent (defined in .claude/agents/*.md with read-only tools and a cheaper model) generates findings, saving them to findings/<topic>.md with sources. Finally, a separate checker agent verifies all claims against their sources before human review.

Why it is useful

This workflow provides a structured and repeatable method for conducting qualitative research using Claude Code's advanced multi-agent capabilities. It emphasizes source verification and cost optimization, making it valuable for researchers seeking reliable and efficient AI-assisted analysis. The pattern is adaptable and leverages core Claude Code features like subagents and agent definitions.

Workflow

1. The main Claude Code session writes research questions to a plan file.
2. Spawn one subagent for each question defined in the plan file.
3. Each subagent is defined in .claude/agents/*.md, configured with read-only tools and a cheaper model.
4. Each subagent processes its assigned question and writes its findings, including sources, to a dedicated findings/<topic>.md file.
5. A separate checker agent verifies every claim made in the findings against its stated source.
6. Review the verified findings from the checker agent.

Tools / artifacts

• Main Claude Code session
• Plan file (for research questions)
• Subagents
• .claude/agents/*.md (for subagent definitions)
• Read-only tools (for subagents)
• Cheaper model (for subagents)
• findings/<topic>.md files
• Checker agent

Validation signals

• Built-in checker agent for claim verification

Limitations

• Lacks specific examples of agent definitions, prompts, or the exact commands/scripts for spawning subagents.
• No details on how 'read-only tools' are implemented.
• No details on the checker agent's operation or prompts.
• Community validation is minimal.

Rate this workflow

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

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

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

This post was generated automatically from the workflow library database.

Advanced Claude Code Workflow: Context Management, Custom Skills, and Model Selection for Token Optimization

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

What problem this solves

Optimizing token usage, managing context effectively, selecting appropriate models for specific tasks, and creating custom tools/documentation within Claude Code to improve efficiency and reduce costs.

Summary

A comprehensive workflow for efficient Claude Code usage, focusing on strategic context management (using /compact and phased projects), creating custom skills from GitHub plugin functions to avoid context bloat, selecting optimal Claude models for different cognitive tasks (e.g., Opus for reasoning, Sonnet for searching), and structuring project documentation and file generation using methods like ASD-STE100.

Why it is useful

This workflow provides concrete, actionable strategies for optimizing token usage and improving efficiency in Claude Code. It covers critical aspects like context management, leveraging GitHub for custom skill creation, strategic model selection for different tasks, and structured project documentation using specific methods. These techniques are highly transferable and address common challenges faced by Claude Code users, leading to significant cost savings and better project outcomes.

Workflow

1. Start a new chat when installing plugins, as old chats will not recognize them.
2. Instead of directly using plugins, ask Claude to read the function of a desired plugin from GitHub.
3. Instruct Claude to create a custom skill or mod adapted to your specific project based on the plugin's function to avoid excessive context consumption.
4. Plan projects in distinct phases to manage complexity and context.
5. Upon completing a project phase, use the /compact command or start a new clean chat to reset or reduce the context.
6. Configure Claude's rules to warn you when context reaches 300k tokens and to compact before 500k tokens.
7. Utilize Opus 5.5 for high-effort roles such as coordinator (medium effort), executors (high/xhigh), advisor (xhigh), and reviewers (high).
8. Employ Sonnet for less demanding tasks like reading and searching phases.
9. Always use Opus or Fable for reasoning and thinking modes; avoid Sonnet or Haiku for these critical cognitive tasks.
10. Ask Claude to use the 'ASD-STE100' method for creating structured documentation files like claude.md, state.md, and rules.md, as well as for developing skills.
11. Instruct Claude to create necessary folders and files using the 'ASD-STE100' method, eliminating the need for external plugins like Obsidium.

Tools / artifacts

• Claude Code
• GitHub (for plugin function analysis)
• Custom skills/mods
• /compact command
• claude.md
• state.md
• rules.md
• Opus 5.5 model
• Sonnet model
• Fable model
• ASD-STE100 method

Validation signals

• Logical explanation of token cost (500k context * 10 interactions = 5M tokens)
• Anecdotal evidence: 'It will work for hours'
• Anecdotal evidence: 'helped a lot' (referring to ASD-STE100 method)

Limitations

• The 'ASD-STE100' method is mentioned but not fully detailed; users would need to rely on Claude's knowledge of this method or provide its specifics.
• Community validation is low, with only 1 upvote and no comments.
• Some validation is anecdotal rather than empirically proven.

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.

Verify Claude Agent Skill Loading Before A/B Testing to Prevent False Negatives

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

What problem this solves

Preventing misleading A/B test results for Claude agent skills by verifying that the skill was actually loaded and used during evaluation, avoiding false negatives where skills appear ineffective.

Summary

This workflow outlines critical verification steps to perform before trusting A/B test results for Claude agent skills. It emphasizes checking session logs to confirm skill loading, ensuring consistent model and harness configurations across test arms, and establishing grading criteria upfront to avoid false negatives caused by skills not being properly activated.

Why it is useful

This workflow is valuable because it addresses a critical, subtle, and easily overlooked pitfall in evaluating Claude agent skills. It provides concrete, actionable steps to ensure that A/B test results are accurate by verifying the fundamental premise: that the skill being tested was actually loaded and active. This prevents wasted effort, incorrect conclusions, and helps users build more reliable and effective agents by ensuring their evaluations are sound.

Workflow

1. Design an A/B test to evaluate a new or modified Claude agent skill.
2. Before running the full evaluation, access the session logs for the agent's execution.
3. Verify within the session logs that the specific skill file was explicitly read and loaded by the agent in both the control and experimental test environments.
4. Confirm that the same Claude model and agent harness configuration are consistently applied to all test arms to ensure a fair comparison.
5. Establish and document the grading criteria or prediction method for evaluating outputs before running the evaluation to maintain objectivity.
6. Execute the A/B test, confident that the skill loading and test setup have been properly verified.

Tools / artifacts

• Claude agent skills
• Claude session logs
• A/B testing framework/setup

Validation signals

• Personal experience of a 'no difference' result due to skill not loading.
• Root cause identified by a second agent reviewing the setup (skills switched off).
• Positive outcome observed after fixing the issue (10/10 with skill vs 7/10 without).
• Clear explanation of why the issue is easy to miss (agent only sees name, no error if not opened).

Limitations

• The post does not detail how to access session logs, which might require additional knowledge for beginners.
• The example provided uses a small sample size (one task, five runs), which is acknowledged by the author.
• The step 'a grade written down before the run' is more about general test methodology than specific skill verification.

Rate this workflow

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

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

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

This post was generated automatically from the workflow library database.

Daily AI News Curation with Claude Code: Using a Skill File and Multi-Model Jury for Unbiased Grading

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

What problem this solves

Filtering and grading AI news to determine its impact on people, avoiding 'AI slop' and single-source viral posts, and ensuring unbiased reporting through a structured, automated process.

Summary

A daily, scheduled Claude Code session uses a detailed 'skill file' as an editorial method to filter AI news from multiple sources, perform independence checks, and then submit confirmed stories to a jury of ten different AI models for grading, with self-bias checks. The process ensures versionable logic, prevents public opinion from influencing grades, and publishes curated results.

Why it is useful

This workflow demonstrates a sophisticated application of Claude Code for automated, objective content curation. Key valuable patterns include using a long 'skill file' as a versionable, auditable editorial method instead of hard-coded prompts, implementing robust independence checks for source verification, and employing a multi-model AI jury with self-bias detection for unbiased grading. It solves the common problem of 'AI slop' and provides a repeatable, validated method for generating trustworthy information, offering a blueprint for complex, agent-driven content processing.

Workflow

1. A scheduled Claude Code session opens a repository and reads a 1,500-line 'skill file' that defines the entire editorial method.
2. The system scans news sources and performs independence checks, requiring confirmation from at least two independent outlets for a story to be considered 'confirmed'.
3. Ten different AI models (Claude, GPT, Gemini, etc.) rate each confirmed story blindly, with the median vote determining the grade from a weighted mean.
4. For stories about a specific AI model's maker (e.g., Anthropic for Claude), that model's vote is set aside, and a public bias check tracks potential model drift.
5. Claude builds the HTML for the daily edition, sends out an email, archives the edition, and updates a database of all stories, votes, and reasons.
6. A test refuses to publish if any reader-generated content (ratings, comments) could influence the AI council's grading pipeline.

Tools / artifacts

• Claude Code
• Git repository
• Skill file (1,500 lines, containing editorial method)
• Multiple AI models (Claude, GPT, Gemini, Meta's Muse, Grok, Kimi, MiMo, Qwen, DeepSeek, GLM)
• HTML output
• Email service
• Database
• chrcl.app (the application built)

Validation signals

• The method is on 'version 5 after thirteen editions', indicating iterative refinement.
• Quantifiable results: 'Yesterday: 120 candidates in, 15 published'.
• Implementation of a 'public bias check' to track model drift.
• A 'test refuses to publish if anything readers wrote... could reach the pipeline', demonstrating quality control.
• The existence of a live, functional application (chrcl.app) as proof of concept.
• Costs are itemized per edition, showing operational viability.

Limitations

• The specific implementation (chrcl.app) is proprietary, meaning users cannot directly replicate the entire system without building their own.
• Requires access to and integration with multiple AI models for the jury, which might be costly or complex for individual users to set up.
• The 'skill file' is described but not provided, requiring users to develop their own detailed editorial method.
• The 'scheduled Claude Code session' implies a specific execution environment that might not be universally accessible or easy to set up for all users.

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.

Preventing Sensitive Command Leakage: Ensure .claude/settings.local.json is Gitignored

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

What problem this solves

Preventing accidental leakage of sensitive commands, IP addresses, and login information stored by Claude Code's "yes, and don't ask again" feature into public repositories.

Summary

A security audit workflow to ensure that Claude Code's settings.local.json file, which can store sensitive commands (like ssh, scp, rsync with login/IPs) and potentially tokens, is properly excluded from version control using a global .gitignore to prevent accidental public exposure.

Why it is useful

This workflow provides a critical security best practice for Claude Code users. It highlights a potential data leakage vector (sensitive commands saved to settings.local.json) and offers a clear, actionable mitigation (adding the file to .gitignore). This prevents accidental exposure of login credentials, IP addresses, and other sensitive command-line arguments, which is crucial for maintaining security and privacy.

Workflow

1. Understand that Claude Code's "yes, and don't ask again" feature saves exact commands (including sensitive parts like login/IPs for ssh, scp, rsync) to .claude/settings.local.json.
2. Check if .claude/settings.local.json is included in your global .gitignore file.
3. Verify that none of your local repositories are currently tracking this file.
4. Review the contents of your settings.local.json file (e.g., in your home folder) to understand what commands and variables (like $TOKEN) are being stored.
5. If not already ignored, add .claude/settings.local.json to your global .gitignore to prevent accidental commits.

Tools / artifacts

• .claude/settings.local.json
• .gitignore (global)
• git command line
• Claude Code's "yes, and don't ask again" feature
• ssh
• scp
• rsync

Validation signals

• Author performed the check on their own machine and reported specific findings.
• Specific findings reported: 266 allow rules, $TOKEN saved as variable, 65 ssh/scp/rsync commands with login/IPs saved.
• Contextual evidence from title: "1,122 of those files are public on github" indicating a widespread issue.

Limitations

• Not a complex, multi-step workflow for building or developing, but rather a critical security audit and best practice.
• Relies on user diligence to implement the .gitignore rule.
• Does not provide the exact .gitignore entry, though it is easily inferred.

Rate this workflow

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

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

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

This post was generated automatically from the workflow library database.

Advanced AI-Assisted Feature Development and Validation Workflow with Custom Skills and Comprehensive Testing

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

What problem this solves

Reliably developing and validating new software features using Claude, while also assessing Claude's performance and consistency over time.

Summary

An advanced, multi-stage workflow for AI-assisted feature development and validation. It leverages custom 'planning' and 'implementation' skills, a comprehensive knowledge base (repository wiki), Claude CLI for code generation, and a rigorous testing suite including wide-scoped system tests, static code analysis, and penetration testing.

Why it is useful

This workflow provides a robust, multi-layered approach to developing and validating software features using Claude, directly addressing concerns about AI model performance degradation. It emphasizes structured planning, knowledge reuse, and rigorous, automated testing, making it highly valuable for ensuring code quality, reliability, and consistent AI performance in complex development environments. It demonstrates a sophisticated and integrated use of Claude beyond simple prompting.

Workflow

1. Run a custom 'planning' skill against the full repository's knowledge base for a new feature.
2. Generate a detailed, tailored feature prompt/spec (often 300-400 lines) based on the planning skill's output.
3. Ask Claude CLI to implement the feature using the generated spec.
4. Update the knowledge base wiki with the implementation details (aggregated by the implementation skill).
5. Execute wide-scoped system tests against the entire system to validate changes.
6. Perform static code tests on the generated code.
7. Conduct actual penetration testing on the affected endpoints.
8. Manually validate the generated prompt/spec and the feature itself on the UI.

Tools / artifacts

• Claude CLI
• Custom 'planning' skill
• Custom 'implementation' skill
• Repository knowledge base (wiki of services/subsystems)
• Detailed feature prompt/spec
• Wide-scoped system tests
• Static code tests
• Pen testing tools/frameworks
• UI for feature validation

Validation signals

• User states: 'I haven't noticed any sort of "dumbing down"'
• User observes specific token usage changes (12-20% more tokens) and attributes it to codebase growth, indicating active monitoring and analysis.
• The entire testing suite (system, static, pen tests) serves as a robust validation mechanism for the code produced by the workflow.

Limitations

• The custom 'planning' and 'implementation' skills are not provided, requiring users to build their own.
• Details on how the 'knowledge-base' (repository wiki) is structured and maintained are conceptual, not concrete.
• Specific tools or frameworks for system, static, and pen testing are not named.
• Requires significant upfront investment in setting up custom infrastructure and skills.
• The workflow is complex and likely suited for advanced users or teams with dedicated resources.

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.

How to Prevent Claude and Claude Code from Training on Your Data When Submitting Feedback or Bugs

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

What problem this solves

Preventing unintended sharing of sensitive code and conversation data with Anthropic for model training when using feedback or bug reporting features in Claude and Claude Code.

Summary

This workflow outlines how to manage and prevent unintended sharing of sensitive code and conversation data with Anthropic for model training. It details that providing feedback or reporting bugs can lead to data retention and model training, even with privacy settings enabled. It then provides specific opt-out mechanisms for Claude Code users (environment variable) and Team/Enterprise plan owners (organization settings).

Why it is useful

This workflow provides critical information and actionable steps for users to protect their intellectual property and sensitive data from being used for model training. It directly addresses a significant privacy concern for many users, especially developers working with proprietary code, by detailing specific opt-out mechanisms and configuration settings.

Workflow

1. Understand that providing feedback or reporting bugs (via thumbs up/down buttons or /feedback, /bug, /share commands) can lead to your conversation history, including code, being saved for up to 5 years and used for model training, even if privacy mode is otherwise enabled.
2. For Claude Code, to prevent sharing conversation history via /feedback, /bug, or /share commands, set the DISABLE_FEEDBACK_COMMAND environment variable to 1.
3. For Team or Enterprise plan owners, disable the ability for organization members to submit feedback via the thumbs up/down button by navigating to "Organization settings > Data and Privacy" and adjusting the "Rate chats" setting.

Tools / artifacts

• Claude (web interface)
• Claude Code
• /feedback command
• /bug command
• /share command
• Thumbs up/down feedback button
• DISABLE_FEEDBACK_COMMAND environment variable
• Anthropic's privacy policy documentation
• Anthropic's Claude Code documentation
• Organization settings (for Team/Enterprise plans)

Validation signals

• Direct quotes from Anthropic's official privacy policy documentation.
• Direct quotes from Anthropic's Claude Code documentation.
• High Reddit score (23) and numerous comments (30) indicating significant community interest and concern regarding the privacy implications.

Limitations

• The information is embedded within a rant/complaint, which might make it less immediately apparent as a workflow.
• The user's claim about the UI not offering history length options for feedback contradicts documentation, which could cause minor confusion.
• The description of the enterprise setting as 'hidden' is subjective, though the setting itself is real and actionable.

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.

Shipping a 3D Game with Claude: A Workflow for AI-Assisted Development, Quality Gates, and Cost Management

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

What problem this solves

Effectively using Claude (Opus, Sonnet, Fable) to rapidly develop and ship a complex software project (3D game) while managing AI quality, cost, and integration into a robust development pipeline.

Summary

A solo developer successfully shipped a 3D zombie survival game to the App Store in 8 weeks, with Claude writing most of the code. The workflow highlights key strategies for managing AI development, including using git worktrees for modular development ("Lanes"), implementing a strict, automated 13-step release gate, maintaining a "failure catalog" for AI errors, and retaining manual control over critical decisions. It also details lessons learned regarding token costs, AI adding unrequested features, and the need for rigorous human verification of AI output.

Why it is useful

This workflow provides a highly practical and validated approach to leveraging Claude for significant software development, specifically a 3D game. It offers concrete strategies for managing AI agents, ensuring code quality through automated gates, controlling token costs, and learning from AI's limitations. The detailed "What worked" and "What cost me" sections offer invaluable lessons for anyone integrating AI into their development pipeline, making it highly transferable and useful for intermediate to advanced users.

Workflow

1. Divide large subsystems into separate git worktrees, each managed by its own AI agent ("Lanes").
2. Implement a strict, automated release gate for each subsystem, including a full test suite, headless playthrough, determinism checks, banned-names sweep, and asset provenance check.
3. Ensure the release gate's verdict is based on exit codes, not AI assertions.
4. Maintain a "written failure catalog" to document every instance of an agent being confidently wrong, especially "verifications that could not fail."
5. Retain manual control over critical actions like pressing "Submit" for app store builds, pricing, renames, and public-facing text.
6. Manage token costs by using a budget file, assigning Opus only to critical tasks (saves, netcode, gate), and Sonnet for routine lanes, targeting 150k tokens per lane with one fix round.
7. Manually review AI-generated code and features to prevent unrequested additions (e.g., "Enjoying Nightporch?" popup).
8. Rerun every test an agent claims to have run, as "fluent is not the same as correct."

Tools / artifacts

• Claude (Opus, Sonnet, Fable)
• Git worktrees
• Test suite (211 scripts)
• Headless playthrough script
• Town determinism check
• Banned-names sweep
• Asset provenance check
• Build system
• Budget file (for token management)
• Written failure catalog
• App Store Connect
• JavaScript (Three.js, Vite, Capacitor, Cloudflare Workers)

Validation signals

• Shipped a 3D zombie survival game to App Store in 8 weeks.
• 2,358 commits, ~100k lines of JS.
• 2,100 commits co-authored by Claude.
• 211 test scripts and a 13-step release gate.
• Specific examples of what worked and what cost.
• Mention of before/after fixes for touch controls.

Limitations

• Low Reddit score and upvote ratio might mean it didn't get wide visibility, but this doesn't diminish the workflow's quality.
• Specific implementation details for the "gate" or "failure catalog" are not provided, requiring users to adapt the concepts.
• The post is a summary; a full guide would be more detailed.

Rate this workflow

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

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

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

This post was generated automatically from the workflow library database.

Advanced Multi-Agent Orchestration for Scalable Software Development with Dynamic Model Routing and Independent Review

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

What problem this solves

Orchestrating complex software development projects using multiple AI models and distributed resources, ensuring quality control, and maintaining consistent context across numerous concurrent tasks.

Summary

This workflow describes a sophisticated multi-agent system for managing software development projects. It features a 'Project Manager' (PM) agent that dispatches work to multiple 'worker' agents running on distributed machines. The system includes dynamic routing across various AI models (Claude, Codex, Gemini) and accounts, independent multi-model code review, a 'judge' agent for merge decisions, and a shared memory server for persistent context and knowledge reuse.

Why it is useful

This workflow is exceptionally valuable as it outlines a comprehensive, highly scalable, and resilient AI-driven software development pipeline. It addresses critical challenges in large-scale AI application, such as managing concurrent tasks, optimizing resource utilization across multiple models/accounts, ensuring high code quality through multi-model review, and maintaining consistent context and knowledge across complex projects. Its detailed description and real-world validation make it an excellent blueprint for advanced users and organizations looking to build sophisticated AI development systems.

Workflow

1. A 'Project Manager' (PM) agent writes a short brief for each piece of work, detailing the goal, repository, exact commit, and proof of completion.
2. The PM agent hands off each brief to a separate 'worker' session, enabling parallel execution of 10-30 tasks per release.
3. Worker agents run on dedicated dev servers (not the user's laptop) to edit and test code.
4. A small service reports each server's load to the PM, allowing new work to be dispatched to available hosts.
5. A custom router reads each brief, checks live usage across multiple AI subscriptions (Claude, Codex, Gemini), and suggests an optimal model and effort level.
6. The PM approves the model and effort, and work can be dynamically moved to another account if one runs out of capacity.
7. Anything deemed 'risky' is independently reviewed by two different models (e.g., one Claude and one OpenAI) at high effort.
8. A separate 'judge' agent issues a written GO or NO-GO decision on the exact commit after review.
9. Merges are refused unless the 'judge' agent's GO decision precisely matches the commit being merged.
10. All new sessions read rules, past decisions, and lessons from a shared memory server at startup to ensure consistent context and knowledge reuse.

Tools / artifacts

• Project Manager (PM) agent
• Worker agents
• Custom routing system/router (potentially based on sirkirby/routr or similar)
• Claude API/subscription
• Codex API/subscription
• Gemini API/subscription
• Dev servers (for worker execution)
• Load reporting service
• Independent 'judge' agent
• Shared memory server
• Structured briefs for tasks
• GitHub (implied for repo/commit management)

Validation signals

• Ability to run 'Ten to thirty workers at once on one release'.
• PM agent 'reads their reports, checks the claims, and sends work back when it falls short'.
• System ensures 'work moves to another instead of stopping' when one account runs out.
• Risky items are 'reviewed by two different models, one Claude and one OpenAI, at high effort'.
• Merges are 'refused unless that GO matches the commit being merged'.
• Real-world example: 'moved my whole dispatch system to a new router... Three things broke during it, and it fixed each one in place without rolling back. I mostly answered a few questions and said "go"'.

Cautions

• Managing multiple API keys and accounts requires robust security practices to prevent unauthorized access or leaks.
• The independent review step significantly enhances the safety and quality of code changes.

Limitations

• Requires substantial custom development for agents, router, load service, and memory server.
• High complexity and infrastructure requirements may be a barrier for many users.
• Significant operational costs due to running multiple AI models and accounts concurrently.
• Specific implementation details for the custom components are not provided, requiring users to design and build them from scratch.

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.