documentation-criteria — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited documentation-criteria (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
| Structural Scale | Required Documents | Creation Order |
|---|---|---|
| Small | None | Direct task execution |
| Medium | Design Doc → Work Plan | Start with Design Doc |
| Large | PRD → Design Doc → Work Plan | Continue after PRD approval |
Insert an ADR immediately before the Design Doc only when a current-scope decision passes both ADR filters below. A qualifying ADR decision sets the scale floor to Medium.
Classify the decision burden, not repository layout. File count is supporting evidence only.
| Scale | Structural condition |
|---|---|
| Small | One coherent outcome follows existing patterns within one responsibility boundary |
| Medium | One coherent outcome coordinates across a boundary or requires a durable design decision |
| Large | Multiple independently valuable outcomes require separate design decisions |
Multiple files or layers that serve one coherent outcome remain Medium. Large applies only when separate outcomes require separate design decisions.
Check accepted ADRs that govern the changed responsibility, then apply both filters to each technical topic in the confirmed scope:
Create one ADR for each topic that passes both filters. Keep a topic in the Design Doc when one repository-supported implementation is evident or the choice remains cheaply reversible.
Qualifying durable choices can include:
Counts of files, consumers, nesting levels, states, or processing steps do not independently require an ADR.
Create an artifact only when its downstream consumer would otherwise need to infer the named decision.
| Document | Decision it fixes | Consumer effect when missing |
|---|---|---|
| PRD | Product outcome, current requirements, acceptance criteria, and exclusions | Design would have to infer product scope |
| ADR | One qualifying durable technical choice and the alternatives it resolves | Design and future changes could not distinguish an accepted decision from a local choice |
| Design Doc | Repository-grounded implementation approach, contracts, change surface, and verification strategy | Planning and implementation would make design decisions locally |
| Work Plan | Implementation order, real dependencies, and executable verification | Execution would choose sequencing and proof boundaries locally |
Include product outcome, current requirements, success criteria, user-visible scope, exclusions, and unresolved product decisions. Keep technical implementation choices in the Design Doc or ADR.
Include the durable choice, materially distinct options, trade-offs, decision, consequences, and reversal conditions. Evaluate the number of options established by evidence; do not manufacture alternatives to satisfy a fixed count.
Include only information that constrains implementation or verification:
Add a change-impact map, field-propagation map, API matrix, or diagram when the relationship would otherwise be difficult for the next consumer to reconstruct.
Include the fewest implementation units needed to preserve real dependencies and observable proof. Each task names its source, intended result, scope, dependencies, and verification.
| Document | Path | Naming Convention |
|---|---|---|
| PRD | docs/prd/ | [feature-name]-prd.md |
| ADR | docs/adr/ | ADR-[4-digits]-[title].md |
| Design Doc | docs/design/ | [feature-name]-design.md |
| Work Plan | docs/plans/ | YYYYMMDD-{type}-{description}.md |
Work Plans are transient execution state and remain excluded by .gitignore unless the repository explicitly chooses to version them.
Proposed → Accepted → Deprecated / Superseded / Rejected
When a new ADR supersedes an accepted ADR, retain the old ADR, mark it Superseded with a reference to the new ADR, and add a reference to the old ADR in the new ADR.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.