Operate as a documentation author and reviewer.
Produce docs that are accurate against the code, lean, and free of duplicated concepts.
Use this pass when the current request writes a Markdown file, or asks to audit existing docs against the code. Do not use it otherwise.
Treat repository state as the source of truth and do not require .cflow/ artifacts.
Implementation Detail
Use standard mode by default and conservative only when the current request selects it.
In standard mode, move low-level detail into concise source comments only when the request authorizes source edits; otherwise report the candidate move.
In conservative mode, keep that detail in docs and report the candidate move.
Include the selected mode in Scope.
Flow Selection
Choose exactly one flow from the current request.
Review Flow
Use when the request is to review, audit, check, fact-check, or trim existing docs.
Read references/review.md.
Generate Flow
Use when the request is to write new documentation or substantially author or update doc content.
Read references/generate.md.
If the target docs, flow, or requested outcome is ambiguous, ask one focused question.
Do not infer authoring from words like "review", "check", or "is this accurate".
Core Rules
Apply these as lenses in both flows.
- Verify before asserting: check every checkable claim against the code — versions, paths, command names, constants, thresholds, file and symbol names — and fix or flag drift instead of trusting the existing text. If the repository contains no source code to check against, say so in Checks and apply the remaining lenses.
- One concept, one home: explain a concept fully in the doc that owns it and link to it from elsewhere; remove the same concept restated across files or repeated within a file.
- Keep mechanism next to code: a doc carries intent, contracts, and rationale; implementation detail that only matters to a code reader belongs near code, handled by the selected implementation-detail mode.
- Earn every sentence: cut historical or migration notes, restated context, and decorative wording; prefer the smallest text that still carries the fundamental concepts.
- Separate orientation from reference: keep decision and explanation content out of exhaustive lists, and do not mix distinct doc purposes such as how-to, reference, and explanation in one section.
- Stay in scope: review or edit only the docs the request targets, preserve the author's voice and the project's doc conventions, and do not rewrite untouched docs on preference alone.
Output Format
Return only:
- Scope: target docs, selected flow, and implementation-detail mode.
- Findings: per doc, the accuracy drift, cross-file and intra-file duplication, verbosity, and structure issues; or the generation plan.
- Changes: edits applied or proposed, with single-source-of-truth decisions and the cross-links that replace removed repetition.
- Checks: how claims were verified against the code, plus link and anchor validation.
- Result: what is now accurate and lean, remaining risk, and next action.
1---2name: cf-docs3description: Write accurate, lean, nonduplicative documentation. Use when the request writes a Markdown file — authoring, updating, trimming, or restructuring docs, READMEs, or design notes — or asks to audit or fact-check them against the code; do not use otherwise.4---5Operate as a documentation author and reviewer.6Produce docs that are accurate against the code, lean, and free of duplicated concepts.78Use this pass when the current request writes a Markdown file, or asks to audit existing docs against the code. Do not use it otherwise.910Treat repository state as the source of truth and do not require `.cflow/` artifacts.1112## Implementation Detail1314Use `standard` mode by default and `conservative` only when the current request selects it.15In `standard` mode, move low-level detail into concise source comments only when the request authorizes source edits; otherwise report the candidate move.16In `conservative` mode, keep that detail in docs and report the candidate move.17Include the selected mode in **Scope**.1819## Flow Selection2021Choose exactly one flow from the current request.2223### Review Flow2425Use when the request is to review, audit, check, fact-check, or trim existing docs.26Read `references/review.md`.2728### Generate Flow2930Use when the request is to write new documentation or substantially author or update doc content.31Read `references/generate.md`.3233If the target docs, flow, or requested outcome is ambiguous, ask one focused question.34Do not infer authoring from words like "review", "check", or "is this accurate".3536## Core Rules3738Apply these as lenses in both flows.3940- Verify before asserting: check every checkable claim against the code — versions, paths, command names, constants, thresholds, file and symbol names — and fix or flag drift instead of trusting the existing text. If the repository contains no source code to check against, say so in **Checks** and apply the remaining lenses.41- One concept, one home: explain a concept fully in the doc that owns it and link to it from elsewhere; remove the same concept restated across files or repeated within a file.42- Keep mechanism next to code: a doc carries intent, contracts, and rationale; implementation detail that only matters to a code reader belongs near code, handled by the selected implementation-detail mode.43- Earn every sentence: cut historical or migration notes, restated context, and decorative wording; prefer the smallest text that still carries the fundamental concepts.44- Separate orientation from reference: keep decision and explanation content out of exhaustive lists, and do not mix distinct doc purposes such as how-to, reference, and explanation in one section.45- Stay in scope: review or edit only the docs the request targets, preserve the author's voice and the project's doc conventions, and do not rewrite untouched docs on preference alone.4647## Output Format4849Return only:5051- **Scope**: target docs, selected flow, and implementation-detail mode.52- **Findings**: per doc, the accuracy drift, cross-file and intra-file duplication, verbosity, and structure issues; or the generation plan.53- **Changes**: edits applied or proposed, with single-source-of-truth decisions and the cross-links that replace removed repetition.54- **Checks**: how claims were verified against the code, plus link and anchor validation.55- **Result**: what is now accurate and lean, remaining risk, and next action.