Documentation Criteria
Determines which of PRD, ADR, UI Spec, Design Doc, and Work Plan a change requires, and...
Install
npx skills add shinpr/claude-code-workflows --skill documentation-criteria -g -a claude-code -y- Repository
- shinpr/claude-code-workflows708
- Category
- Design
- Updated
- 7d ago
- License
- MIT
- Context cost
- Mediumabout 1,992 tokens
- Runs scripts
- No, instructions only
What it does
Determines which of PRD, ADR, UI Spec, Design Doc, and Work Plan a change requires, and where each is stored. Use when deciding documentation scope, or when creating or reviewing a technical document.
Documentation Creation Criteria
This file holds the routing decision: which documents a change requires and where they live. What to write inside one is defined by its template, linked from Storage Locations.
What Each Document Fixes
Each document fixes one class of decision that the repository alone cannot supply. An unfilled section becomes a guess made later by the consumer named below, with no record of what was assumed.
-
PRD, Fixes the business outcome and the acceptance criteria later work traces to. Its AC IDs are the traceability keys that the Design Doc, UI Spec, and test selection reuse; without them each consumer re-derives requirements from prose and the link between a test and the value it protects is lost. Implementation details belong to the Design Doc, selection rationale to an ADR, phases and task breakdown to 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 options it beat, so later work can tell a deliberate decision from an accident. Without it a future change either re-runs the same comparison or silently reverses it.
Acceptedrecords the currently selected means, not an obligation to retain it: when later evidence supports a smaller sufficient choice, update or supersede the decision while the confirmed outcome, desired-future requirements, and non-goals remain true. End-to-end implementation design belongs to the Design Doc, schedule and repository tasks to the Work Plan.


