Menu
Validate an RCA for correctness and evidence quality before presenting it to the engineering team. Use after analyze-bug produces an rca.json.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Produce a concrete implementation plan for a standalone Task or Epic takeover ticket. Use when a Jira Task/Epic is approved for Task Takeover planning and needs target files, implementation steps, tests, and repository scope.
Read-only qualitative review for Task Takeover implementations before PR creation. Use after task takeover execution completes.
Decompose a Technical Specification into implementable Epics with technical plans. Use when asked to break down features, create epics, or plan implementation.
Break down Epic implementation plans into concrete, actionable Tasks. Use when decomposing Epics into implementation units.
Implement code changes according to Task specifications. Use when executing implementation Tasks.
Produce a concrete implementation plan for a bug fix from an approved RCA and selected fix approach. Use when the team has selected a fix option and needs a detailed plan before implementation.
| name | reflect-rca |
| description | Validate an RCA for correctness and evidence quality before presenting it to the engineering team. Use after analyze-bug produces an rca.json. |
Validate the root cause analysis against seven criteria. You have access to the codebase — use it to verify claims.
Check each criterion. For any failure, write a specific, actionable finding that names the file, function, commit, or option that is wrong.
File and function exist — Verify the named file and function actually exist at the stated location using find and grep. If the code location is wrong, flag it.
Mechanism is plausible — Given the code, is the stated failure mechanism actually possible? Does the code do what the RCA claims?
Options are distinct — Are the fix options genuinely different approaches, or paraphrases of each other? Two options that differ only in wording are not distinct.
No unexplained gaps — Is there a complete, unbroken chain from the stated trigger to the observed symptom? Flag any missing links.
Multiple hypotheses were considered — The hypothesis_log should include at least one "rejected" candidate unless the bug is trivially isolated. If no candidates were rejected, verify the bug is genuinely trivial.
Git history was consulted — Does introduced_in contain a real commit hash? Verify using git show <commit> that it exists and is plausible. If the hash looks fabricated, flag it.
Confidence level is justified — If confidence is Low or Medium, the rationale must name specific missing evidence. Vague rationales are insufficient.
The output format is a forge protocol constraint — do not change it:
VALIDNo other text. Do not explain that you are outputting VALID.