Doc

Write or update the documentation the caller needs, grounded in the current repository and its accepted intent. A small explanation needs no interview, coverage ledger or separate report. Select only the mode relevant to the task.

Modes

Need	Scope and reference
Explain an API, command, code-map or architecture	Inspect its consumers and source; use code/API guidance or architecture guidance when useful.
Create or improve a README	Lead with the user's problem and a working first-use path; preserve useful depth. See README craft.
Check an advertised install, upgrade or first-success path	Follow the selected package and current instructions in an authorized disposable environment. See developer journey.
Audit or scaffold OSS documentation	Compare existing docs with the requested pack. Create missing files; revise existing files only within the authorized request. See OSS pack.
Initialize missing entry documents	Create only explicitly requested missing files; report existing paths as skipped. See setup examples.
Bring docs current after a change, describe a change for reviewers, or write release notes for a range	Start from the exact diff and its public surface; fix what it proves wrong and ask about judgment calls. See change-driven docs.
Preserve a session for another context, or resume from one	Fill the handoff template and deliver it as described there; resume by checking it against current state.
Get facts or decisions only another person holds	Write one questionnaire they can answer alone; the caller sends it.

These are optional task shapes, not successive phases. Detailed references supply techniques and formats; they do not add interviews, approval checkpoints, reports or files beyond the accepted request. Existing authorization to revise specified documents is sufficient.

Grounded writing

1. Identify the audience, question and existing document owner. Reuse accepted intent; ask only for missing content that materially changes the document. Name the reader's need: learning from scratch, doing one task, looking up a fact, or understanding why. A reference list does not show how to do the task it exists for. For a reader who learns from it, explain each idea before a section relies on it (ordering).
2. Read the relevant declarations and verify them against code, configuration, command help or executable behavior. Use the caller's domain terminology. Take steps in another vendor's interface (menus, settings, where a value appears) from its current docs or the caller, or mark them unverified; never guess. For a larger surface, retain enough source references to disclose what was inspected and what remains unknown; do not imply whole-repository coverage.
3. Make the smallest useful edit. Explain non-obvious rules, ordering and tradeoffs when they help the reader; a reference page need not manufacture a lesson. Preserve operator policy and history outside the authorized scope. Edit an existing document in its own shape, from a fresh read if a person may have changed it (their edits win): extend the passage that already says it, under any heading, rather than add a duplicate section, and do not reorder or restyle it into a template unless asked for a rewrite. When rewriting existing prose, keep every fact, number, name, citation and identifier, and keep each claim's certainty: "may" does not become "does". When condensing (a summary, handoff or release notes), keep every failure, caveat, open question and request, and sound no more finished, positive or certain than the source; say where it is vague or contradicts itself. Leave code blocks, quotes and link targets untouched unless they are the thing to fix.
4. Check links, cited commits and paths, leftover drafting scaffold, examples and the repository's documentation build or validator (techniques). Remove empty claims and redundant prose; prose guidance can help when the requested output is substantial. A link handed to a reader (in a document, report, handoff or change description) must open the exact item it names for that reader. Build repository URLs from Git rather than by hand, and point them at a ref that already contains the pushed content: a main-branch link to a file that exists only on a feature branch is dead. Link the item itself (the pull request, the file and line), not its parent page. When no direct link can be verified, say where to find the item instead of giving a guessed link.
5. Return changed paths and check results, plus unresolved factual gaps. Write a separate report only when the caller requests one or an existing consumer requires it.

Missing-document setup

Create only the requested missing documents, such as PRODUCT.md, GOALS.md or AGENTS.md; a collision is skipped, not overwritten by setup. Verify the created paths and report created, skipped and failed writes. Setup does not install tools, run ao session bootstrap, initialize Git or trackers, start a runtime, add hooks, or infer a repository workflow. AgentOps verdict storage is created only on explicit request; see AgentOps internals.

Session handoff

A requested handoff records end-state facts another context can verify. Fill every field. Write unknown with the reason for any fact you did not observe; record a caller's unobserved claim as "stated, unverified", never as fact.

# Handoff: <goal, one line>
- Goal and acceptance: <accepted goal>; acceptance <met | not met | unknown>
- Done: <change or artifact> (<exact path, commit or command>) -> <observed result>
- In progress: <piece> (<path or ref>) -> <what remains inside it> | none
- Failed or withdrawn: <attempt> -> <observed failure or reason> | none
- Decisions and constraints: <choice or limit> (<caller's | writer's>, <source>); rejected: <alternative> -> <reason> | none
- Open: <unmet acceptance, findings, causal gaps> | none known
- Stop state: <native state and where it was read> | unknown
- Remaining allowance: <measured time, cost or turns left; helper use for the current incident when it matters> | unknown
- Identities: <repository and commit; runtime, session or context IDs and resume links as observed> | unknown
- Selected skills: <skills the caller selected by name for this work> | none
- Continuation: <caller-supplied next step> | none supplied

• IDs: record only observed identities. A remembered, approximate or reconstructed ID is unknown; at most quote it as the caller's unverified claim.
• Stop state: a note or report saying HOLD, paused or done is only a note. Read the state from its native owner (tracker, runtime, goal controller) or write unknown.
• Allowance: compaction, a new session or a handoff resets no budget, allowance or helper incident. Carry the measured remainder or unknown.
• Failures: keep informative failures and withdrawn claims so the next context does not repeat them.
• Pointers: point at the plan, issue, commit or file rather than copying it, and say what matters there. Redact secrets and unrelated personal data.
• Local state: give repository files as repository-relative paths. Name work that exists only uncommitted, untracked or in one worktree, with its absolute path marked machine-local, and warn that cleanup or another host loses it.
• Sessions: do not assign a whole multi-work session to one task. Follow session associations for startup and resume links; end-state notes cannot replace missing startup evidence.

Destination. A new CDLC handoff, draft or proof goes only to the selected protected external non-Git destination; with none selected, report the missing routing and create no fallback file. For any other handoff a location the caller names wins: write there, read it back and return the exact path, and say