--- name: document-clarify description: Clarify project documentation using resolved dotdotgod memory-area guidance and direct, concise prose. Use when asked to improve README indexes, specs, tests, architecture docs, plans, archives, or project-specific docs while preserving established meaning and traceability. --- # Document Clarify ## Memory-Area Context Before evaluating the target document, run `dotdotgod config --json` (or the source-checkout CLI equivalent) and include the resolved `config.areas` in the active working context. Match the target path against the ordered areas and use the first match. ## Goal Make project documentation easier to understand and act on while preserving established behavior, decisions, task state, historical meaning, and traceability. ## Workflow 1. Confirm the target document and requested outcome. Use its matched memory-area metadata when available: `clarify` guidance first, then `description`, `label`, and `role`. 2. Read only the context needed to preserve meaning: the nearest README, directly linked documents, relevant query results, and targeted history when a past decision matters. 3. Clarify purpose, next actions, terms, ownership, headings, links, and runnable examples. Keep exact commands, paths, package names, API names, requirements, and behavior claims unless verified evidence supports a change. 4. Prefer direct affirmative statements. Use “X is not Y; it is Z” only when that contrast resolves a likely ambiguity. Remove repeated framing, indirect wording, mixed responsibilities, and background that obscures the document's job. 5. Follow repository-local generated markers and canonical-source instructions. For dotdotgod traceability, edit the fenced `json dotdotgod` block as the canonical mapping and use `dotdotgod traceability links --write` to refresh generated links. 6. Ask for a decision when the requested clarification would change established meaning or when current sources conflict. 7. Run verification that matches the changed surface. Use documentation and traceability checks for ordinary docs; add generation checks, focused package tests, dry-runs, or workspace verification when shared resources or product behavior are affected. When CLI-backed routing is unavailable, continue from the target document, nearest README, direct links, and repository conventions.