Documentation Creation Criteria

This skill owns document routing: which durable decisions the change needs to record and where each document lives. Each template linked from Storage Locations owns the document's content and structural requirements.

What Each Document Fixes

• PRD — Fixes the business outcome, current requirements, exclusions, and acceptance criteria that later work traces to. Its AC IDs are stable traceability keys for design and verification. Implementation design belongs in the Design Doc, technical option selection in an ADR, and task order in the Work Plan. Later design, review, and test selection treat its content as governing, so a precondition held outside the repository change, such as release execution or organizational approval, appears in it only when the user's wording raises it
• ADR — Records one durable technical choice and the materially distinct options it beat, allowing later work to distinguish an accepted decision from an incidental implementation. Accepted records the currently selected means, not an obligation to retain it: when later evidence supports a smaller sufficient choice, update or supersede the ADR while the outcome, desired-future requirements, and non-goals remain true. Complete implementation design belongs in the Design Doc
• UI Spec — Records screen structure, transitions, component and state contracts, interactions, and visual acceptance before implementation. Create one only while those decisions remain open; reuse an approved UI Spec or proceed to the Design Doc when representative repository evidence already determines them
• Design Doc — Records the complete implementation design for the scope of the requirements: responsibilities, flows, contracts, change impact, and verification boundaries. Implementation treats it as the primary technical baseline, so implementation does not silently invent missing How. The same baseline turns anything written in it into planned and implemented work, so release execution, production operation, and other work outside the repository change stay out of it; a requirement that describes such work is met by designing the capability it uses. When repository evidence invalidates technical How while the outcome, desired-future requirements, and non-goals remain true, correct the implementation and the affected technical artifact through their owning workflow without reopening product requirements
• Work Plan — Fixes dependency order, task boundaries, executable verification, and the earliest useful proof point. It references design details instead of reproducing them. Each task is repository work the executor completes and verifies during implementation using repository artifacts and its own output
• Task File — Carries one executable Work Plan outcome, its governing sources, investigation starting points, write responsibility, and observable verification into implementation

Creation Decision Matrix