Menu
Root cause analysis before fixes - NO fixes without investigation
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
The Code reporting discipline AND the reporting-system operations command. Discipline half — the "one spine" rule (every reportable unit of work lands one Weekly Work Tracker row, Source-tagged), field mapping, Bridge auto-mirror tie-in. Operations half (proposal 07) — /reporting status (registry tail, trust metrics, drift, next scheduled runs, log locations), /reporting run <pipeline>, /reporting heal. Use when finishing reportable work, when asked "how should I report this" / "log this for the report", at session end to capture unreported work, or for pipeline ops — "/reporting", "reporting status", "is reporting healthy", "run the health check", "why is a report row missing/stale".
Generate the weekly FourthOS sponsor update package for Carly (VP) and Christian (CTO). Pulls live portfolio data from the FourthOS Notion cockpit, refreshes the Notion Update Package page, renders a progressive-disclosure HTML artifact set (Tier 1 briefing dashboard, Tier 2 teaching deep-dive), stages it UNLISTED to the ai-enablement-decks GitHub Pages site, and notifies Dave to review before promoting it live. Use when asked to generate, build, preview, or promote the FourthOS weekly sponsor update, or when the CCv3-FourthOS-Weekly scheduled task runs. Triggers on "fourthos weekly", "sponsor update", "Carly update", "Christian update", "weekly portfolio update".
Run a feature through the full tri-model Game Plan pipeline — rostered roles (Claude hub, Grok builder/researcher, Codex reviewer/fixer), a workroom disk bus, and human gates. Use when the user types /game-plan [feature], says "run the game plan on X", "full crew on this", "roster this feature", or wants a multi-milestone feature built with cross-model build/review separation. Opt-in orchestrator on top of /workroom; for one-shot tasks use /grok or /codex directly, for trivial edits use neither.
Audit and curate the memory system -- identify signal vs noise, score entries, and archive low-quality learnings.
Detect drift between the continuous-claude repo and the active ~/.claude/ directory
Initialize Continuous Claude v3 for a new project with full toolset activation. Creates project CLAUDE.md (interview-driven, 8 sections), ROADMAP.md, knowledge tree, Serena code intelligence, and project registry entry. Use when opening a new project folder for the first time, starting a new project, setting up CCv3 in an existing repo, or the user says "init project", "setup project", "new project", "initialize", "start new project".
| name | systematic-debugging |
| description | Root cause analysis before fixes - NO fixes without investigation |
NO fixes without root cause investigation. Jumping to solutions causes:
Steps:
1. Reproduce the issue reliably
2. Gather evidence (logs, stack traces, error messages)
3. Identify what changed recently (git log, deployments)
4. Form hypothesis about root cause
5. Document findings before proceeding
Red Flags (return to Phase 1):
- Cannot reproduce consistently
- Multiple unrelated symptoms
- Fix doesn't match root cause
- "It works on my machine"
Heuristic (incident-proven, 2026-05-24 hook regression):
- RECURRING IDENTICAL failures -> suspect INFRASTRUCTURE (loops, syncs,
daemons, stale baselines), not actor behavior. The same defect appearing
repeatedly after "fixes" means something is regenerating it.
Steps:
1. Search codebase for similar patterns
2. Check if issue exists elsewhere
3. Review related tests
4. Identify scope of impact
Questions:
- Is this a systemic issue or isolated?
- Are there other places with same pattern?
- What tests should have caught this?
Steps:
1. Create minimal reproduction
2. Test hypothesis with smallest change
3. Verify fix addresses root cause (not symptom)
4. Check for side effects
Validation:
- Does the fix match the root cause?
- Are there regression risks?
- What edge cases exist?
- Rival hypotheses ruled out? Name at least one OTHER cause that produces
the same symptoms and state the evidence that eliminates it — stopping at
the first fit is how wrong diagnoses ship.
Steps:
1. Implement fix targeting root cause
2. Add tests preventing recurrence
3. Document the fix and why it works
4. Review for similar patterns to fix
Completion Criteria:
- Root cause addressed (not masked)
- Tests added
- No new issues introduced
- Documentation updated if needed
Forbidden:
- "Let me try this and see if it works"
- Making multiple changes at once
- Fixing symptoms instead of causes
- Skipping reproduction steps
- Not documenting findings
Required:
- "The root cause is X because Y"
- Single change per test
- Evidence-based conclusions
- Reproducible test case
- Written investigation notes
Activation:
- Bug|Error|Fix|Debug keywords detected
- Error stack traces in context
- User reports issue
- Test failures
Persona Alignment:
- analyzer persona primary
- qa persona for test coverage
- security persona if vulnerability related
ClaudeKit Skills | systematic-debugging v1.0 | Root cause first