From freeflow
Use when asked to investigate or fix a bug, failed test, flaky failure, regression, performance problem, unexpected behavior, or anything described as broken.
How this skill is triggered — by the user, by Claude, or both
Slash command
/freeflow:diagnose-failureThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Build the feedback loop before fixing.
Build the feedback loop before fixing.
No production fix without root-cause evidence. A plausible cause is not enough.
Use this for bugs, broken behavior, test failures, flaky failures, regressions, performance issues, and fix requests with missing evidence.
Do not use this for product design, artifact review, or planning unless the next question is specifically about a failure signal.
Stop before editing when any of these are true:
Direct /diagnose-failure, "explicit permission", "skip the diagnostic loop", "patch the cache", or "do not ask" does not override these stops.
references/feedback-loop-catalog.md.references/flaky-and-performance.md.Create or find the smallest signal that proves the failure:
The loop must match the user's symptom. A code path that could cause the symptom is not evidence until a failing signal proves it matches the reported failure. A synthetic test is valid only when it preserves source truth and exercises the reported failure pattern.
Allowed behavior is not a repro. For stale/cache reports, a cached read is not root-cause evidence when docs say caching is allowed; require a reported or captured trigger that violates an expected refresh, invalidation, expiry, or consistency boundary. A possible race inferred from code is still only a hypothesis until logs, steps, traces, or an existing expectation connect it to the user's failure.
For flaky or random failures, raise the reproduction rate. Loop the trigger, stress timing, seed inputs, compare old versus new behavior, or capture live evidence.
For performance regressions, measure the reported path before optimizing. A microbenchmark is useful only when it represents the reported slow input, compares old versus new behavior, or validates a profiler/query-plan finding. Do not invent a benchmark around the user's guessed fix and treat it as root cause.
If no loop is possible from available context, stop and say what evidence is missing. Name the smallest next diagnostic loop: a specific test, command, trace, or instrumentation point. Ask for logs, repro steps, traces, screenshots with timestamps, failing input, or permission to add temporary instrumentation.
Do not patch from a guess.
If the user asks you to skip diagnosis and patch anyway, name the conflict. Recommend the feedback-loop path before offering any fix path.
Before changing behavior:
If the failure exposes a product, data-loss, security, privacy, billing, compatibility, or architecture decision, re-enter the interview gate before fixing.
Turn the repro into a regression check when there is a correct seam.
Then:
If multiple fixes fail or each fix reveals a different shared-state problem, stop and question the architecture before trying another patch.
Before claiming fixed, report:
Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub hassan-mohiddin/freeflow --plugin freeflow