diagnosing-bugs
Diagnosing Bugs
Turn the reported symptom into a fast pass/fail signal, then use falsifiable experiments to isolate the cause. Evidence precedes explanation.
Set the authorization boundary
Classify the request before editing:
- Diagnose only: reproduce, isolate, and explain the cause. Do not implement the production fix.
- Diagnose and fix: diagnosis plus regression protection, the smallest fix, verification, and cleanup is authorized.
If the request is ambiguous, default to diagnose only. Under diagnose-only authorization, keep temporary harnesses and probes outside the repository unless the user separately authorizes repository edits. Any probe must be reversible and disclosed, and existing user changes must never be overwritten or cleaned up.
Do not write issue-backed repository files until the authoritative work-github-issue lifecycle holds a valid implementation lease. This inner skill never claims or releases an issue, changes tracker state, commits, pushes, or publishes evidence.
Keep the diagnosis in the response by default. When the user or repository requires a durable diagnosis, use documenting-work to resolve whether the issue comment or one diagnosis repository document is authoritative. This skill may recommend the destination, but tracker publication remains owned by the outer workflow.