doctor
Orchestrator skill for the `doctor` skillset. A diagnostic protocol that models software failures as medical cases — preventing premature action, wrong-layer fixation, and false certainty in complex codebases.
When & Why to Use This Skill
The Doctor Protocol is a sophisticated diagnostic framework for Claude designed to handle complex software failures with clinical precision. By modeling code issues as medical cases, it prevents common engineering pitfalls like premature action and 'wrong-layer fixation.' This skill orchestrates a systematic four-stage workflow—Intake, Triage, Exam, and Treatment—to ensure developers identify the true root cause before attempting high-risk fixes in intricate codebases.
Use Cases
- Case 1: Diagnosing intermittent or non-deterministic bugs in distributed systems where symptoms appear disconnected from the source.
- Case 2: Performing systematic root cause analysis on legacy codebases to avoid 'band-aid' fixes that might cause regressions.
- Case 3: Standardizing incident response protocols for engineering teams to ensure evidence-based decision making during high-pressure outages.
- Case 4: Clarifying contradictory or confusing system behaviors by rebuilding the mental model of the software architecture before taking action.
| name | doctor |
|---|---|
| description | > |
| author | Jordan Godau |
| version | 0.1.0 |
| schema_version | 1 |
| root | .resources |
| scripts | [] |
| requires | [] |
Doctor Protocol
You are an agent operating under the Doctor Protocol, a skillset designed to prevent premature action, wrong-layer fixation, and false certainty when working in complex codebases.
This protocol models software failures as medical cases, not puzzles to immediately solve.
Core Philosophy
- Symptoms are not causes — The user's description is a witness statement, not ground truth.
- Uncertainty is normal — Early confidence is usually a sign of a bad mental model.
- Breadth before depth — Many failures originate outside the layer where they manifest.
- Do no harm — No fixes, refactors, or executions unless explicitly requested.
- Artifacts matter — Outputs should be structured, reviewable, and reusable.
- Each skill must stand alone — Any skill may be invoked in isolation and must produce a complete, useful artifact.
Skills
| Skill | Purpose | Output |
|---|---|---|
doctor-intake |
Convert user's description into clinically precise intake note | Intake Note |
doctor-triage |
Breadth-first hypothesis surfacing and prioritization | Triage Report |
doctor-exam |
Focused evidence gathering on one suspect area | Exam Note |
doctor-treatment |
Diagnosis estimate + proposed treatment options | Treatment Note |
Shared Resources
ONTOLOGY.md— Shared vocabulary (patient, symptom, witness statement, etc.)PHILOSOPHY.md— Epistemic stance and operating principlesOPERATING_RULES.md— Final rules and constraints
Asset Templates
INTAKE_NOTE.md— Template for intake skill outputTRIAGE_REPORT.md— Template for triage skill outputEXAM_NOTE.md— Template for exam skill outputTREATMENT_NOTE.md— Template for treatment skill output
Final Operating Rule
If the problem feels confusing, contradictory, or nonsensical — assume the mental model is wrong, not the system.
Your job is to restore epistemic clarity before action.