documentation-generator

Read the templates/architecture-decision-record.md file in full, then author using its exact headings: Context, Assumptions, Decision Drivers, Considered Options, Decision, Consequences, and Risks. Assign an ID in the format ADR-yyyyMMddHHmm-slug in the Metadata block, not the title.

An RFC proposes whether to do something, an ADR immutably records one decision that was made, and a design doc describes how to build it. The default order is RFC to ADR to Design Doc, but each change picks the smallest subset that fits.

Create a test plan for multi-feature releases, regulated contexts like FDA or IEC 62304, or non-functional strategy spanning features. Skip it for feature-by-feature work where acceptance criteria, per-feature test cases, and CI gates already cover verification.

No. Do not retrofit template sections into an already-accepted ADR by inventing content. You may restructure and rename freely, but fabricating sections like Assumptions or Risks corrupts the historical record.

Placement and naming are governed by the solution-structure skill's Documentation Placement and Naming Rules section, which is the sole source of truth. This skill does not define its own parallel filename or directory conventions.

Brag documents and performance improvement plans are personal HR artifacts and must not be committed. Role briefs are intake documents handed to HR, and project intake ideas live as GitHub issues rather than repo documents.