Update Docs

Trigger

• Keywords: update docs, sync docs, docs out of date, update-docs

When NOT to Use

• Document review (use /codex-review-doc)
• Creating new docs (use /tech-spec or /create-request)
• Document refactoring (use /doc-refactor)

Auto-Trigger

Auto-triggered after precommit Pass, only when the change maps to a feature under docs/features/ (see @rules/auto-loop.md § Tiers, gate sequence). Can also be invoked manually.

Task

Step 1: Locate Docs and Related Code (5-Level Cascade)

Key principle: can't find target → ## Gate: ⚠️ Need Human — don't guess or create new docs.

Use the shared feature context resolution algorithm (see @skills/create-request/references/feature-context-resolution.md):

scan_error gate. scan_error !== false ⇒ the source sets are unknown, not empty — report it and take the ⚠️ Need Human exit rather than syncing against a corpus you could not enumerate — an unreadable corpus and a feature with no documents both return empty, and the first one silently becomes "nothing to sync". Gate on !== false, not === true: a {} payload from a shell fallback carries no such field at all, and a non-null key is not evidence the sets are complete — scan_error rides alongside a resolved key.

Confidence	Action
high/medium	Proceed with detected feature
low	Proceed with warning
null (not found)	Output ## Gate: ⚠️ Need Human — do not guess

Step 1.5: Classify Each Target — Sync Authority, Freeze Records

This skill rewrites current-authority docs. It does not rewrite records.

resolveDocRole(path, source, taxonomy) in scripts/lib/doc-metadata.js answers which a file is, and owesCodeAlignment(path, source, taxonomy) is the same answer as a boolean — a doc owes code alignment exactly when its role is the fallback (current-authority) one.

Both take a repository path as the first argument — never a role label. Spelling it owesCodeAlignment() invites the call that has already been made here once: passing the string "Design record" where the path goes. That string matches no rule, so it falls through to FALLBACK_ROLE and the function returns true — a fail-closed default reads exactly like an affirmative answer, and the wrong reading was an instruction to rewrite a frozen record (docs/features/push-gate-optin/review-log-push-gate-optin.md, round 43).

The four roles below are BUILTIN_ROLE_CONFIG.closed_set in that file, and the Examples column states what its path_defaults patterns actually match — read it there, not from the phase number. docs-numbering.md numbers documents by lifecycle phase; doc-metadata.js assigns authority role. They are different axes, and reading the first as the second is what put 2-tech-spec.md in the Current-authority row of this table until 2026-08-21 — an instruction to rewrite a frozen design record, and the exact failure the paragraph below this table warns about.

Role	Matches (path_defaults)	What this skill does
Current authority — owes code alignment	4-implementation*; anything whose first segment is skills/rules/agents/commands; and the fallback, which is what README.md resolves through	Rewrite the sections the code changed
Design record — states a decision	Conventionally 0-feasibility-study*, 1-requirements*, 2-tech-spec*, 3-architecture* — but the pattern is ^[0-3]-(feasibility|requirements|tech-spec|architecture), a cross-product: any of those four prefixes with any of those four stems, sixteen names, not four (see below). Also intent-<feature>.md (the intent-records rule) — planner-written constraints the implementer checks work against	Do not rewrite. Append a dated > **Update(…)** note recording what later changed — except intent-*: touch it not at all, appends included. Amending intent is a human re-decision, never a sync; this skill only reports a tension between the code and an invariant or Non-goal, and the human edits the file or does not
Work record — states what was asked	anything under a requests/ segment	Do not rewrite — this skill does not touch it at all. /create-request --update may overwrite exactly four fields (Status, the Progress table, AC checkboxes, Progress.Note); everything else in the ticket is frozen, and a closed ticket is frozen entirely. That is the whole mutable set for an ordinary update. The single exception is a reported factual correction — a non-lifecycle recorded fact such as a path or a date, or an unfilled template placeholder that was never a statement about the ticket — which may also apply to a closed ticket, authorizes only that correction, and never unrelated trimming or cleanup; it must be stated in Progress.Note. It must never change Status, a Progress phase status, or AC checkbox state: those lifecycle fields stay governed by the freeze and the ordinary transition rules, or "the erroneous fact" becomes a label an agent can put on a lifecycle edit to walk past them. Both halves are defined once in skills/create-request/SKILL.md § Phase 4.5
History record	review-log-*, adr-*	Do not rewrite. Append only

owesCodeAlignment(path, source, taxonomy) is resolveDocRole(path, source, taxonomy) === FALLBACK_ROLE — the Current authority role and nothing else, so the three record rows are one decision, not three. Named by role, not by position: "the first row" was true only until somebody reordered or inserted one, and a reordered table would then have silently redirected this instruction at a record.

The four canonical pairings — 0-feasibility-study, 1-requirements, 2-tech-spec, 3-architecture — are a naming convention (@rules/docs-numbering.md), not what the classifier tests. Measured 2026-08-21: 1-tech-spec.md, 3-requirements.md, 0-architecture.md and 2-feasibility-study.md all resolve to Design record, because the prefix and the stem are matched independently. Listing only the four pairings invites the opposite reading — that an off-convention name is a gap the classifier cannot see — and it is the reverse: the classifier is wider than the convention, deliberately, so a mis-numbered spec is still protected from rewriting. Where it does stop is the prefix: 4-tech-spec.md falls past [0-3] into the fallback and resolves to Current authority, i.e. rewritable. A spec numbered outside the range loses the protection its name suggests, so fix the number rather than relying on the stem.

A record that disagrees with today's code is not stale — that disagreement is the record. Editing it to agree destroys the only copy of what was decided, and buys nothing: the reviewer reads records under the record-diff profile, which carries no code-alignment obligation (skills/doc-review/SKILL.md § Review Profiles).

Report a record you were pointed at rather than silently skipping it — "not in scope for rewriting" is a fact the caller needs, and silence reads as "synced".

Step 2: Research Current Code State

Key research items:

• Any new scripts / skills / commands added?
• Any modified logic in existing files?
• Any new configuration or rules added?
• Any API or interface changes?

Step 3: Compare Docs vs Code Differences

Item	Doc Description	Current Code	Status

Step 4: Update Docs

Update document content based on differences:

1. Architecture diagrams (Mermaid sequenceDiagram / flowchart)
2. Core service table
3. API description
4. Data model

Step 5: Verification

After update:

1. Re-read updated document sections
2. Verify all new modules are documented
3. Verify all removed modules are cleaned up

Safety Valve

After doc sync, compare code diff against pre-sync baseline. If new code changes exist (e.g., lint:fix modified code), return to review loop.

Output

## Doc Update Report

| Document | Sections Updated | Status |
|----------|-----------------|--------|

## Changes Made
- <summary of each update>

## Verification
- [ ] New modules documented
- [ ] Removed modules cleaned
- [ ] Diagrams updated