/document

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](shared-capy-knowledge-protocol.md).
• **Read profile detection** at [shared-profile-detection.md](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 the shared protocols and all resolved profile content are in context. Bounded signal inspection for profile detection is the only content-read exception.

Read the shared protocols in Conventions before the steps below, even when the invocation ultimately needs no edits.

1. **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. 2. **Detect active profiles.** Run the `shared-profile-detection.md` procedure against the filename list from Step 1. 3. **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. 4. **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. 5. **Apply the doc guidelines below.** Write or update documentation applying the rubric's required topics where applicable. Explain the purpose and applicable current or planned behavior before reference detail, retaining evidence limits and unresolved decisions. 6. **Suggest optional clarification.** After creating or materially revising documentation, suggest a `/kk:clarify-docs` invocation naming those output paths. If no documents were created or materially revised, skip the suggestion. Clarification is a separate user-selected editing workflow; this skill neither loads its procedure nor runs it automatically. Drafting still owns clear explanations and every applicable profile-rubric topic, including explicit N/A reasons and inherited-source citations. The suggestion does not replace any project-prescribed review.

Guidelines

1. **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. 2. 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. 3. **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.