naswerks

Deep-audit one or more living docs (features, infrastructure, or patterns) against the actual code — write an audit report per doc and correct the doc. Use right after touching an area, when a doc is suspected stale, or run docs-audit-feature <doc-path...> (a single doc, a list, or a whole folder).

Master health check across all docs — staleness/age scan, convention spot-checks, research that looks resolved — producing a prioritized re-verify plan. Use monthly, after an extended absence, or run docs-audit-full.

Capture an idea, improvement, or future-state design as a research doc in docs/research/. Use when the user has thoughts/ideas to park for later, wants to capture research, or runs docs-backlog.

Patch the living docs from a session doc's "Living Docs to Update" checklist, verified against code. Use at the start of a session, when the user points at a working/archived session doc and asks to update the living docs, or run docs-process.

Read-only orientation at session start — what's recently archived, what's in progress in working/, and what ideas are waiting in research/. Use at session start or when the user asks for docs status, or runs docs-status.

Finalize the working doc at the end of an implementation session and leave it in docs/working/ as the queue for docs-process to patch + file. Use at the end of a coding session, when the user says to write up the work, document the session, book-end it, or run docs-write.

Make a repository able to run the loop — create the docs/ shape, the two method docs, a scanned first draft of every doc the loop's skills read, the doc-index menu with the repo's own slots, the Start-here stanza and the plugin pin; then say what is still missing. Run init in a repository that has none of this; run init doctor to check one that does; run init refresh to bring a repository's copies of the method docs up to a newer pack (it writes only their repository-owned sections and the stamp). A second init writes nothing and prints the doctor report.

Assume the COORDINATOR seat for a spec-pipeline effort — quarterback the build seats (one per spec) via prompts, TLDR reviews, verification, and commit calls. Use immediately after spec-pipeline in the same session (the author is already context-loaded), or in a fresh session with the topic name to resume/take a prepped effort. Run spec-parent {topic}.

Graduate a plan into a numbered spec pipeline in docs/research/{topic}/ — an umbrella plus one self-contained spec per planned seat. Use when a research idea is "really getting into it" and a plan has come through (a plan-approval mode, if your harness has one) and you want to commit it as specs instead of executing it directly, or run spec-pipeline.

The COORDINATOR's close-out retrospective for a finished spec pipeline — a substrate-VERIFIED grade of the run, the ceremony audit (did the acts the seat believes it performed actually write rows?), the ledger reconciliation, the true economics, the blindnesses, and the ranked fixit backlog. Run at the close, after the last session's commit. Run spec-retro {topic}.

Become the REVIEW SEAT for a spec pipeline that has finished building — the outside look, before the retro and before the PR. Reviews the shipped code against the repo's patterns, the composition across session seams, and the loop's own comms; classifies which findings earn a fixit; files sessions/code-review.md. Its value is having NONE of the pipeline's context. Use as the review seat of a pipeline, or run spec-review {topic}.

The CONTRACT for any seat a pipeline coordinator arms — the blackboard, the question lane, the parked-call discriminator, the verdict vocabulary, the BELIEFS sha, git shapes, the six-section FINAL TLDR, and the close-out order. Invoked FIRST, then the job skill (spec-child | spec-review | docs-process). Not a seat of its own; the shared half of every seat's procedure.

Become the WITNESS seat for a running or finished spec pipeline — a read-only verifier with substrate access (the control plane's read lanes, transcripts, endpoints, source) and no in-band blindness. Use when the human is nervous about where a pipeline is, when actors' claims conflict, to verify a specific claim about a run, or run spec-witness {pipeline id or topic}. The seats act, the human judges, the witness testifies. ZERO writes, ZERO terminal input, ZERO rulings.