codument: Skill for Claude Code

Work Step

Use this when the user says to continue, work the next step, or implement the approved plan.

Compatibility and project checks

At the first delivery action in a session, inspect codument --help from the executable you will actually use: it must list work and verify. A version string alone does not establish capability. If either is absent, repair the installation before executing this workflow: rebuild a linked Codument checkout with npm run build, or install the matching package and run codument update. Do not substitute older commands or invent manual approval/review checkpoints. Reuse this check for the session unless the executable changes.

Run the project's existing relevant tests, lint and type checks. Codument's named-test reproduction is a separate review check, not a requirement to install its own test runner. When reproduction is needed, declare the project's file-targeted runner once with testCommand in .codument-meta.json (including {file}); use a TAP reporter so failures are distinguishable from toolchain errors.

Workflow

1. Read codument work status --json and the selected plan under docs/features, docs/concepts, or docs/plans. Reconcile saved work with Git; hand its pending review or commit to the owning skill before starting another step. Explicitly resume interrupted work only when its resume condition is satisfied and the user has authorized continuation.
2. Confirm current bound approval with codument steps --plan <path> --json. Record approval with work approve only after actual human approval. For outcome-v1, compare work with the approved outcome, milestone, constraints, acceptance evidence and verification; implementation routing discoveries alone do not require an amendment. Legacy file-bound plans retain their scope gate, and existing approvals cannot adopt outcome permission without renewed human approval. Approval does not mean paused work is running.
3. Start new selected work with codument work start --plan <path>. Switching plans requires --reason and preserves the old plan; use work supersede only for an explicit replacement decision. Pick the first unchecked step only after any saved delivery has passed its pending gate.
4. Surface the checklist in the live view (see Plan Checklist Mirror below): mirror the plan's steps into your host's native to-do panel with the step you are about to implement marked in progress, and run codument steps --plan <active-plan> --emit so codument watch shows the active step. Post that checklist inline in the chat as well — the step just completed, the step now starting, and what remains — because the native to-do panel and the watch tape are not the chat transcript, and a run that does not wait between steps otherwise advances with no in-chat marker.
5. Reuse the grounded planning context and read its owning docs, invariants and tests. If it is missing or stale, query the affected paths together with codument context --paths <paths...>, or use --plan <active-plan> / --feature <slug> for the selected working set. Refresh after routing discoveries as needed; no ownership query is owed before and after every file. Read the whole registry when editing the map or when the CLI is unavailable. A context budget is soft: selected contracts may exceed it and must not be silently discarded.
6. Implement only that step toward its observable milestone. An infrastructure slice names the milestone it unblocks; do not claim that milestone complete without its promised evidence.
7. Use tdd or the strongest practical verification loop. Diagnose routine test, mapping and documentation failures, correct their cause within the approved contract, and rerun the affected checks. A failed check prevents delivery while red; it does not by itself require human intervention. Use the repair boundary below.
8. Batch new source registration with codument map materialize <files...> (see Feature Map Materialization), then update the mapped docs + registry as part of the same step.
9. Mark the step complete — in the plan doc, and in the mirrored native to-do list — only after implementation verification passes. Before final-step compaction, save the approved plan with a pending-review checkpoint at .codument/pending-plans/<repo-relative-plan-path>; keep this recovery copy outside the staged step. Then compact the ## Delivery Plan block per plan-with-docs (Compaction on ship): lift surviving decisions into ## Decisions/ADRs and any newly-true constraint into ## Invariants & boundaries, then delete the delivery scaffolding so the durable doc is left in the standard's layers.
10. Stage only the files belonging to this step. For the compacted final step, run codument work finish --prepare-final, then stage docs/.approvals.json; this binds the retained approved contract to the final staged delivery. Repeat preparation after any boundary correction. The ignored recovery copy is context, never the only approval evidence. Record the pending gate with codument work resume --gate review before handing off.
11. Proceed directly to review-work for this step without waiting. It selects focused self-review or independent adversarial review from the generated minimum effort and the change's semantics. Never start the next delivery-plan step from here — review and commit come first, in either mode.
12. In gated mode, stop instead and present the user with end-of-step options:
    • Run review-work now (recommended)
    • Make a specific correction to this step
    • Pause here