| name | document |
| description | After implementing a new feature or fixing a bug, make sure to document the changes.
Use when writing documentation, after finishing the implementation phase for a feature or a bug-fix.
|
Documentation Process
Conventions
- Read capy knowledge base conventions at shared-capy-knowledge-protocol.md.
- Read profile detection at shared-profile-detection.md. When an active profile contributes a
document/ subdirectory (e.g., ${TOOLBOX_PLUGIN_ROOT}/profiles/k8s/document/), its index.md lists a doc rubric — required topics the documentation for that artifact type must cover. See the Workflow below for the load order.
Workflow
Mandatory order — instructions before action. The flow below is strictly sequential. Do not read feature-tree content, write, or edit documentation files until profile detection has completed and all resolved profile content is in context.
- Minimal-scope listing. List the feature directory (filenames and metadata only — no file-content reads). This is the input profile detection needs, and nothing more; content-level reading happens after profile content is loaded.
- Detect active profiles. Run the
shared-profile-detection.md procedure against the filename list from Step 1.
- Load profile content. For each active profile that contributes a
document/ subdirectory, load ${TOOLBOX_PLUGIN_ROOT}/profiles/<name>/document/index.md and read its always-load + any matching conditional content. The rubric named there specifies topics the documentation must cover for that profile's artifacts.
- Read the feature-tree content the documentation will cover. This is the first step that touches subject-matter content; the profile rubric is now loaded and frames what to look for.
- Apply the doc guidelines below. Write or update documentation applying the rubric's required topics where applicable.
Guidelines
- Discover the project's documentation structure. List top-level doc directories and doc-related files at the repo root (e.g.,
docs/, README.md, ARCHITECTURE.md, CONTRIBUTING.md). Scan for architecture guides, testing guides, API docs, user guides, and contributing docs — common locations include docs/contributing/architecture.md, docs/contributing/testing.md, but every project organizes differently. Update whichever docs are relevant to the change — don't limit yourself to a fixed set of paths.
- If the code change included prior decision-making out of several alternatives, document an ADR at
/docs/adr for any non-trivial/non-obvious decisions that should be preserved.
- Profile-aware rubric. For each active profile, apply the doc rubric its
document/index.md specifies (loaded in Step 3 of the Workflow). Each required topic must be addressed in one of three ways: (a) write the topic if the feature touches it, (b) state N/A — <reason> in a single line if the feature does not touch the topic, or (c) cite the inherited source explicitly if the feature assumes the topic but inherits it from elsewhere (e.g., NetworkPolicy defined in a platform repo). Silent omission is the failure mode — an explicit N/A communicates consideration; an absent heading communicates nothing.
Capy search: Before writing docs, search kk:arch-decisions and kk:project-conventions for decisions that should be reflected in documentation — decisions not obvious from code alone.
