Documentation impact

Match the documentation to the behavior people will use. Inspect the actual change and its callers before deciding which docs need work. A supported no-change conclusion is a complete result.

Choose the mode and scope

Use author when the task authorizes documentation updates. Use review for an audit, independent review, status request, or other read-only task. Honor the caller's mode. If update authority is unclear, inspect and report in review mode.

• In author mode, update affected documentation within the authorized change. Leave unrelated edits alone.
• In review mode, inspect without editing the artifact you judge. Return findings to its author. Do not fix a document and certify your own fix.

The calling workflow owns delegation, model selection, continuation, and human gates. Do not spawn another coordinator or start a publication workflow here.

Use the accepted request, issue, or existing work brief. Do not require a new spec, ticket, docs tree, or work ledger.

For a repair recheck, use the retained coverage and repair rules below to scope the reader mapping and inspection steps. Reopen the original full-review diff only when those rules require a full review.

Bind the pass to what you actually examine:

• For a full review of committed work, resolve and record the fixed base and head. Inspect the base-to-head diff and the surrounding implementation and documentation at those revisions.
• For a repair recheck, record the original full-review span as lineage. Use the previously reviewed artifact as the comparison base and inspect its delta to the resulting artifact.
• For local work, also inspect staged and unstaged changes and relevant untracked files. Record a content fingerprint or retained snapshot of those inputs. A clean-looking HEAD or a filename list does not identify dirty file contents.
• Outside Git, record an explicit content snapshot of the scoped implementation and docs. If a relevant input is unavailable, name the gap instead of claiming coverage.

Record the examined paths and either the fingerprint method or the retained snapshot location so another agent can reproduce the comparison. Recheck the inputs before returning the result. If concurrent edits changed them, refresh the affected checks or report that the result no longer describes the current artifact.

Map the change to readers

Read the repository's instructions and discover where its maintained docs and examples live. Trace changed behavior to the people who use, run, upgrade, or develop the project. Include public workflow changes in skills and configuration, even when no application code changed.

Consider these document types where the change affects them:

Search for old names, old values, and contradictory examples beyond files already changed. Read the matched claims in context. A recent timestamp, a path match, generated prose, or a rendered diagram cannot establish factual accuracy.

For each affected reader task, identify the maintained document or explain why no document needs a change. Existing docs may already be correct. Internal refactoring may leave every documented contract unchanged. Do not create filler docs to make the pass appear productive.

Update or inspect

In author mode, make the smallest corrections needed for the changed behavior. Follow the repository's documentation layout and generation commands. Update the source of generated docs instead of hand-editing generated output.

Call the Skill tool with technical-writing on documentation you write or review. Then call the Skill tool with unslop on it. Keep examples tied to real symbols, paths, flags, defaults, and supported versions. Example paths must resolve on a reader's machine. For machine-specific paths, use an explicit placeholder and show how to discover or supply the real value. A temporary path is valid when a preceding step creates it. A writer's unexplained scratch path is not a usable example. If an upgrade requires user action, state that action and the old-to-new behavior.

Trace documented effects through the implementation. Accepting or reporting a setting does not prove that the corresponding operation runs. If intended behavior and observed behavior disagree, report the mismatch as an implementation finding instead of documenting a defect as supported behavior.

In review mode, derive the affected reader tasks from the implementation yourself. Check the author's coverage decisions against the source, including claims that nothing changed. Treat the author's receipt as evidence to inspect, not as the verdict.

Use the repository's existing diagram format when a diagram explains an affected relationship better than prose. Check each changed actor, edge, direction, and boundary against the implementation. Optional visual tools can help present findings if available. Otherwise use Markdown or the existing diagram source. Do not install a visual dependency, require branding input, or wait for annotation feedback to complete this pass.

Decide whether author mode requires review

An author pass returns exactly one result:

• independent review required when the change edits maintained documentation, changes a public workflow or a documented contract such as a default or flag, or leaves a documentation gap unresolved.
• independent review not required only when evidence shows that none of these holds.

Record the evidence that supports the author result with the examined artifact. A completion or shipping workflow can start an independent review only when the author result is independent review required.

When independent review is required, a different agent reviews the resulting artifact without editing it. The first review covers the full accepted scope and reports every finding in that one pass. Return pass, needs changes, or unverified. Report a wording suggestion that leaves no claim wrong or missing as a note. A note does not block pass.

After a repair, retain the previous review, its examined artifact, findings, and valid coverage. The repairer records the repair delta and searches for other copies of each corrected claim. Retain the search terms, searched paths, and matches read in context, including a search with no matches.

For wording-only repairs, give the next reviewer that evidence and the resulting artifact identity. Recheck the repair delta and the repairer's search, with the context needed to judge them. Carry forward coverage of unchanged prose instead of reviewing it again. Resolve every outstanding finding before returning pass on the resulting artifact.

Run a full review when a repair changes behavior or contract claims, or when that effect is uncertain. Missing prior coverage or repair-search evidence leaves the recheck unverified until supplied or replaced by a full review. Do not infer a pass from a round count.

Allow one repair round per review. The recheck after that round, scoped or full, returns needs changes when a finding remains unresolved or it establishes an omission or incorrect claim. It reports wording suggestions as notes and returns pass when only notes remain. When the recheck does not return pass, return its open findings to the caller as pending instead of starting another round.

Bind every recheck to the resulting revision or content snapshot and the accepted scope. Verify that the carried coverage still matches the unchanged inputs and relevant surrounding context. Concurrent edits or changed context invalidate the affected coverage. Refresh those checks or run a full review before returning pass. A matching stable patch-id after a rebase does not establish unchanged documentation context.

Verify and return the result

Run the relevant repository documentation checks and exercise changed examples against the actual implementation when safe within the task's authority. Call the Skill tool with verify-commands on commands used as completion evidence. In review mode, run checks without modifying the reviewed files, using a disposable copy if the check writes output.

Check factual meaning as well as syntax and rendering. An example that runs with the wrong default or a diagram that invents an approval step is still wrong. Report unsafe or unavailable checks as gaps. Never run a deployment, publish docs, or change external data just to verify an example.

Return a compact result in the conversation or the existing work record:

• The mode, scope, and examined revision or snapshot, including relevant local changes.
• The affected reader tasks and document paths, with updates made or evidence for leaving them unchanged.
• The checks actually run, their outcomes, and any remaining findings or verification gaps.
• In author mode, the author result and its evidence. In review mode, return pass, needs changes, or unverified. Use needs changes for established omissions or incorrect claims. Use unverified when missing evidence prevents a decision.

An author result is not an independent review verdict.