issue-diagnose
Skill1 starsChanged 14 days agoMITView on GitHub
Diagnose a bug's root cause in one RCA comment before planning. Use to diagnose a bug, find its root cause, or run an RCA on an issue.
In this repository15 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- backlog-refineSkill
- burndownSkill
- code-reviewSkill
- dev-cycleSkill
- issue-implementSkill
- issue-planSkill
- issue-raiseSkill
- issue-refineSkill
- paper-docSkill
- project-statusSkill
- qaSkill
- setupSkill
- weekly-reviewSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
No board reads, claims, or transitions.
- Distinctive: line 71
needs evidence: no actionable cause is reachable (cannot reproduce, needs production data).
- Distinctive: line 90
Use existing tests, § Build & Validation commands, history (git log, git blame), logs, or the issue's evidence.
- Distinctive: line 91
Follow the chain to an actionable cause or an open question.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Diagnose Issue
Architect-only: find a bug's Why in one living RCA comment before any plan. Never design the fix (issue-plan owns the How) or edit the body (issue-refine owns the What).
Project facts from AGENTS.md: § Repositories, § Branch Map (reproduction base), § Code Layout & Tech Stack, § Build & Validation, § Review Notes (critical flows). Missing section: name it and stop.
No board reads, claims, or transitions. Any open issue; closed: stop.
Criteria (shared)
Shared by issue-refine, issue-plan, and code-review. A bug has Type Bug, a bug label, or a body describing existing behavior that differs from what is expected. It needs an RCA when any criterion applies:
| Criterion | Applies when |
| Impact | Serious actual or potential harm: security, permissions, privacy, money, data loss or corruption (including saved bad data and near misses), or a § Review Notes critical flow |
| History | It outlived a fix or is worked around: happened before; earlier fix failed or was reverted; issue reopened; manual reruns, refreshes, or data patches |
| Distance | The cause is not visible where the failure shows: intermittent; depends on data, timing, order, or environment; silent (wrong result, no error); the first "why" leads into another component or only a guess answers it |
| Ownership | What should have prevented it did not, or nothing owns it: bypassed safeguard (validation, constraint, expected writer, test); two components each assume the other handles it; the same mistake likely exists elsewhere |
| Fix shape | The obvious or a proposed fix adds machinery around the symptom: retry, fallback, special case, suppressed error, new record, flag, or format |
| Request | The user asks |
Skip only when none applies: one "why" lands on a defect you can point to where the failure shows, and fixing it there adds nothing new. Doubt: diagnose.
The RCA Comment
One per issue, first line <!-- root-cause -->; edit in place, never post another. Once triggered, always post, even for a one-step chain, so the trigger can see diagnosis happened.
<!-- root-cause -->
## Root Cause
_Diagnosis for this issue: the Why. Edited in place on re-diagnosis; the fix lives in the plan ledger._
**Conclusion:** actionable cause | needs refinement | needs evidence
**Criteria:** <criteria that applied> | request
**Re-diagnosed:** <trigger; what changed, or "cause unchanged">
## Observed Failure
Reproduced on `<sha>` with <command or steps>; report in the issue body. Or: not reproduced, <what was tried>.
## Why Chain
1. <failure>, because <cause>. Evidence: <path:line, test output, log>.
2. <cause>, because <deeper cause>. Assumption: <basis>.
Stops at: <actionable cause>, or the open question below.
## Existing Responsibility
<component or contract that should already handle this; how it was bypassed or failed>, or "None: ownership gap".
## Proof
<reproduction that fails on base and must pass after the fix: test to add (location, assertion) or manual steps>
## Variants
<other places with the same mistake>
## Refinement Needed
<specific body change>
## Open Questions
1. <question>Omit Re-diagnosed on first diagnosis and empty Variants, Refinement Needed, Open Questions. Few evidence-backed lines; mark every step Evidence or Assumption; an open question beats an invented cause; no fix design.
- actionable cause: the chain reached a cause with evidence; open questions past it become plan risks.
- needs refinement: the body is wrong (intended behavior, a different failure, wider scope, saved bad data needing repair); name the change.
- needs evidence: no actionable cause is reachable (cannot reproduce, needs production data); name the evidence.
Workflow
Load the issue and all comments via paginated REST, retaining numeric ids:
gh issue view <number-or-url> --repo <repo-slug> --json number,title,body,labels,state,url gh api --paginate repos/<owner>/<repo>/issues/<number>/comments --jq '.[] | {id, html_url, body}'- Existing RCA: report it and stop, unless the user requests re-diagnosis or the current
dev-cycleauthorizes it (issue URL, RCA REST id, triggering blocker or review finding). Multiple RCAs: stop as ambiguous. Reproduce in a detached worktree at the § Branch Map base tip:
git fetch origin <base> git worktree add --detach .worktrees/diagnose-<number> origin/<base>Use existing tests, § Build & Validation commands, history (
git log,git blame), logs, or the issue's evidence; never edit tracked files. A reproduction needing a new test goes under Proof as specified, not run.- Follow the chain to an actionable cause or an open question; name the existing responsibility; search for variants.
Stage
.tmp-rca-<number>.mdwith a file-write tool. Create: re-fetch all REST comments, POST, then applyissue-plan§ Claim's numeric-id tie-break to RCA comments (a later duplicate deletes only itself and reports the earlier one). Re-diagnosis: re-fetch and PATCH the unique RCA by numeric id. Verify the stored body and uniqueness; remove the temp file even on failure.gh api -X POST repos/<owner>/<repo>/issues/<number>/comments -F body=@.tmp-rca-<number>.md --jq '{id, html_url}' gh api -X PATCH /repos/<owner>/<repo>/issues/comments/<comment-id> -F body=@.tmp-rca-<number>.mdFrom the original repo, remove only a clean worktree whose resolved path is inside
.worktrees/; otherwise stop/report:git worktree remove .worktrees/diagnose-<number> git worktree prune- Report RCA link and REST id, conclusion, criteria, and the refinement or evidence needed.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

