// Evaluates whether documentation sections have substantive content. Use when checking whether planned sections are complete, thin, placeholders, or missing.
| name | completeness-evaluation |
| description | Evaluates whether documentation sections have substantive content. Use when checking whether planned sections are complete, thin, placeholders, or missing. |
Hard technique for evaluating whether documentation sections have substantive content. Refer to @.claude/dockit/references/sections.md for the full list of sections and their requirements.
<evaluation_steps>
Read .planning/docs/{doc-name}/structure.md to know what sections the user chose. Only evaluate the sections in .planning/docs/{doc-name}/structure.md, not a theoretical maximum.
For each planned section, find it in the actual docs/{doc-name}.md file. Check:
For each section present in the document, evaluate the substance according to the following levels.
</evaluation_steps>
<status_levels>
structure.md but has no corresponding heading in the doc</status_levels>
These are guidelines, not rules. Context matters.
<minimum_thresholds>
| Section type | Minimum expectation |
|---|---|
| Metadata | The name, documentation type, and tier are stated clearly |
| Description | A clear, concise description that someone unfamiliar with the concept could understand |
| Anatomy | A numbered list of parts, each with a name and description, and a link to an annotated screenshot |
| Usage | Provides an understanding of how the construct should be used |
| Interactions | Lists the most important interactions that this construct has |
| Examples | A few scenarios showing how the construct is applied, including an image and description for each scenario |
| Properties | A list of the most important properties of this construct |
| Section type | Minimum expectation |
|---|---|
| Metadata | The name, documentation type, and tier are stated clearly |
| Description | A clear, concise description that someone unfamiliar with the concept could understand |
| Content | Provides the minimum amount of content that a reader would need to understand the core of this concept |
</minimum_thresholds>
<cross_references>
Sections should reference each other where appropriate:
Flag when these cross-references are missing ā it usually indicates incomplete thinking.
</cross_references>
<output_format>
āāā Completeness Review āāā
Section Status:
[done] Name ā Complete
[done] Description ā Complete
[warning] When to Use ā Thin: only 1 scenario listed, recommend 2-3
[done] When Not to Use ā Complete
[done] Anatomy ā Complete
[warning] Variants ā Thin: variants listed but missing use-case rationale
[skip] States ā Placeholder: contains "TBD"
[done] Props / API ā Complete
[warning] Accessibility ā Thin: missing screen reader behaviour
[done] Content Guidelines ā Complete
[done] Code Examples ā Complete
[skip] Do's and Don'ts ā Missing: no section found in document
Cross-Reference Issues:
- Do's and Don'ts should reference the 3 variants described in Variants section
- Code Examples do not demonstrate the "compact" variant
Consistency Issues:
- Props section calls it "isDisabled" but Code Examples use "disabled"
Summary:
Complete: 7/12
Thin: 3/12
Placeholder: 1/12
Missing: 1/12
Cross-reference issues: 2
Consistency issues: 1
</output_format>
Evaluates documentation against the team's brand guidelines. Use when reviewing docs for tone, terminology, sentence structure, and phrasing consistency.
Evaluates whether documentation sections have substantive content. Use when checking whether planned sections are complete, thin, placeholders, or missing.
Evaluates grammar, spelling, and formatting in design systems' documentation. Use when checking mechanics like spelling, punctuation, heading hierarchy, and list formatting.
Scores and evaluates documentation readability using Flesch-Kincaid metrics and qualitative analysis. Use when reviewing docs for sentence length, passive voice, jargon, and reading level.
Evaluates documentation against the team's brand guidelines. Use when reviewing docs for tone, terminology, sentence structure, and phrasing consistency.
Evaluates grammar, spelling, and formatting in design systems' documentation. Use when checking mechanics like spelling, punctuation, heading hierarchy, and list formatting.