Menu
Write engineering RCA record after bug is fixed.
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
Iterative multi-round codebase audit with diminishing-returns detection. Run 5-20+ rounds, each focusing on one specific area. Built from 19 rounds of dogfooding pi-crew on itself.
Pi TUI crew widget data sources, display priority, and rendering performance.
Multi-phase orchestration for planners and executors.
Spawn 3 adversarial subagents (Skeptic, Pragmatist, Critic) to evaluate a decision, architecture choice, or plan. Anti-anchoring: each role receives ONLY the question, not conversation history. Aggregates votes into consensus recommendation with dissent tracking. Use when facing critical decisions, architecture choices, security tradeoffs, or plan reviews where single-perspective analysis is insufficient.
Background worker, heartbeat, stale-run, crash-recovery, and deadletter workflow. Use when debugging stuck/dead workers or changing async run reliability.
Child Pi worker spawning, lifecycle callbacks, and failure modes.
| name | post-mortem |
| description | Write engineering RCA record after bug is fixed. |
| origin | pi-crew |
| triggers | ["post-mortem","root cause","RCA","document this fix","close out bug"] |
The canonical engineering record of a bug fix. Written after debugging lands a real fix.
If any missing → list what's missing and stop. Do not draft.
What broke (user terms), what fixed it (one sentence). JIRA key, PR, owner. A reader who stops here should have the right answer.
Concrete: test output, error message, log line. No paraphrase. What was actually observed.
The actual bug mechanism. Code identifiers welcome — function names, file paths, branch conditions. Walk the cause chain end-to-end.
Walk the chain so reader connects symptom to cause. Often non-obvious — bug is in X but visible failure is in Y.
What changed and why this addresses root cause. Link to PR/commit. If a previous fix attempt papered over the symptom, name it and explain what was wrong.
Short. The debugging path:
CI gap? Latent code? Workload gap? Incomplete prior fix? Review miss? Be specific.
If honest answer is "no good reason" — say so. Blameless — describe the gap, not the person.
How we know the fix works:
If only one config validated, say so explicitly.
What + owner + tracking artifact:
If none needed: "None — fix is sufficient and no class-of-bug follow-up warranted."
This is engineer-to-engineer:
