Repository Context Documentation
Own the information architecture and current-state content under an adopted docs/context/ system.
Workflow
- Confirm requested topics, audience, repository adoption of
docs/context/, dirty-worktree preservation, and authority for moves or removals.
- Read all existing context files and the minimum repository evidence needed to verify their claims.
- Classify units by entrypoints, runtime roles, deployment, consumers, state, and contracts rather than directory names.
- Create or update only justified topic files before updating the terse context index.
- Remove stale claims and duplicate facts; merge or remove files only when authorized.
- Verify every edited claim against current implementation.
- Use
text-improve on edited prose without weakening architectural precision or established terminology.
Write only under docs/context/. Use docs-drift-review for incidental change-caused drift, docs-review for general documentation, and critical-journey-document for actor-goal journeys. Link to canonical plans, specifications, runbooks, guides, and API references instead of duplicating them.
Record implemented responsibilities, ownership, runtime roles, contracts, state, invariants, dependency direction, and concise system flows. Exclude history, progress, raw file inventories, speculative design, TODO lists, duplicated instructions, and sensitive values.
Do not impose docs/context/ on a repository that has not adopted it without an explicit request.
Finish with the context files created, updated, consolidated, or removed and the evidence used.
1---2name: repo-context-document3description: Create, update, or consolidate adopted current-state documentation under docs/context/. Use for durable implemented architecture, ownership, runtime, domain, flow, terminology, or engineering-practice context.4---56# Repository Context Documentation78Own the information architecture and current-state content under an adopted `docs/context/` system.910## Workflow11121. Confirm requested topics, audience, repository adoption of `docs/context/`, dirty-worktree preservation, and authority for moves or removals.132. Read all existing context files and the minimum repository evidence needed to verify their claims.143. Classify units by entrypoints, runtime roles, deployment, consumers, state, and contracts rather than directory names.154. Create or update only justified topic files before updating the terse context index.165. Remove stale claims and duplicate facts; merge or remove files only when authorized.176. Verify every edited claim against current implementation.187. Use `text-improve` on edited prose without weakening architectural precision or established terminology.1920Write only under `docs/context/`. Use `docs-drift-review` for incidental change-caused drift, `docs-review` for general documentation, and `critical-journey-document` for actor-goal journeys. Link to canonical plans, specifications, runbooks, guides, and API references instead of duplicating them.2122Record implemented responsibilities, ownership, runtime roles, contracts, state, invariants, dependency direction, and concise system flows. Exclude history, progress, raw file inventories, speculative design, TODO lists, duplicated instructions, and sensitive values.2324Do not impose `docs/context/` on a repository that has not adopted it without an explicit request.2526Finish with the context files created, updated, consolidated, or removed and the evidence used.
yarlson