arch-doctor
Diagnoses the setup on this machine: hooks, boundary rules, the build wrapper, java, which .claude/ the project came from, and whether the compose stack runs.
arch-doctor, section by section
The sections of the skill's own SKILL.md, excerpted. Hover or click one to see which project rules, templates and references/ files it cites. The sections are also chips: click one to jump to it.
## Diagnosis
!java "${CLAUDE_PROJECT_DIR:-.}/.claude/hooks/ArchHook.java" doctor 2>&1
## AI files
!find "${CLAUDE_PROJECT_DIR:-.}/.claude" -maxdepth 2 -type f | sort
Interpret the result above and tell the user, in two or three sentences, whether the setup is operational. If something is marked with ❌, give the concrete command that fixes it — don't describe the problem in general terms.
The Provenance line is the one exception to "give the command": when it lists files edited locally, say which ones and that an update would overwrite them. Don't offer to run the update — losing a hand-edited norm is the user's call, not a fix to apply.
Don't fix anything without the user asking.
## Why this is a manually-invoked skill
Form 2: the whole body is two shell injections plus how to read them, so it is a procedure (axis 5) fired by a person who wants a verdict (axis 2 — /arch-doctor). Form 1 was rejected because a diagnostic the model reaches on its own runs a JVM and a find on every session that mentions a hook; Form 3 was rejected because there is nothing to isolate — the output is the report, and it is what the user asked to see.
Runs on sonnet with effort: high: the report is computed, but naming the cause and the command that fixes it is judgment (@.claude/decisions/0080-procedural-skills-on-sonnet.md).
The name is not doctor: /doctor is a native command, and a skill folder with that name shadows it silently — @CLAUDE.md § Known pitfalls.
What it reads, writes and refuses
The skill's own contract, from SKILL.md, in the original wording.
Class
observer — the territory is skill_classes.observer in @.claude/schemas/extensions.json, and it is empty: this skill writes no file. It reports, and the fix is the user's call. ArchHook.java guard enforces it.
Reads
the output of ArchHook.java doctor (which folds in compose) and the listing of .claude/, both injected above. Nothing else: an injection that lied about the setup would be worse than no report.
Writes
nothing, ever. Leaves no audit report either — its class, observer in skill_classes of @.claude/schemas/extensions.json, declares audited: false, because an observer that records its own observation makes the trail mostly about reading it.
Source: SKILL.md § Contract, at nerviz e4cae27.
What the guard does with it
observer is the skill's class, and the list on the left is its territory. The phase opens when the skill runs on a prompt of its own, and ArchHook judges every write against that list. The text on the right is the hook's own.
write_allow of arch-doctor
any file: the territory is empty
A refusal exits with code 2 and the message goes back to the model.
> /arch-doctor … UserPromptSubmit guard prompt exit 0 # phase opened: arch-doctor (class observer) # write_allow: [] — this class writes no file
PreToolUse Write(pom.xml) guard write exit 2 ❌ `arch-doctor` is class `observer` — pom.xml is outside its territory. write_allow: (nothing — this class writes no file) Put the content in the spec as a code block, or finish the run and invoke the skill that owns this path. If the path is legitimately this skill's, widen skill_classes.observer in .claude/schemas/extensions.json — retrying will not help.
Who calls it
It is not a step of a chain. It starts from a prompt of its own, /arch-doctor, and the guard treats it like any other skill: the phase opens, and the territory of its class applies.