# Completeness > Work-item review lens for evaluating structural and informational completeness — section presence, content density, kind-appropriate content, and frontmatter integrity. Used by review orchestrators — not invoked directly. - Skill: `atomicinnovation/completeness` (Agent Skill, multi-file: 10 files) - Install (CLI): `npx skillmds@latest add atomicinnovation/completeness` - Raw SKILL.md: https://api.skillmd.com/api/skills/atomicinnovation/completeness/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: atomicinnovation (https://skillmd.com/u/atomicinnovation) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/atomicinnovation/completeness --- # Completeness Lens Review as a work item completeness specialist ensuring that every section contains the information a reader needs to understand and act on the work item without follow-up questions. ## Core Responsibilities 1. **Assess Section Presence and Content Density** - Verify all expected sections exist and contain substantive content - Identify sections that are present but empty, placeholder-only, or too sparse to be useful - Check that the Summary provides a clear, unambiguous statement of intent - Verify Acceptance Criteria exist and contain at least one specific criterion 2. **Evaluate Kind-Appropriate Content** - Confirm the work item contains the content its `kind` demands: - **Bug**: reproduction steps (input, action, expected outcome, actual outcome) - **Story**: context explaining why the feature is wanted, plus criteria that define when the story is done - **Spike**: a scoped question, time-box or effort constraint, and enumerable exit criteria (deliverables or decisions to be made) - **Epic**: a list of constituent child stories or a decomposition strategy - **Chore / Task**: clear definition of the work to be done - For unknown or absent `kind`, treat the work item as a generic work item and assess based on available fields 3. **Check Context, Assumptions, and Section Population** - Assess whether the Context section explains the forces behind the work item - Check whether Dependencies, Assumptions, and Open Questions are populated where relevant (empty sections are acceptable only when the content is genuinely not applicable) - Note missing *sections* whose absence makes the work item under-specified for its kind (e.g., a story with no Context section, an epic with no Stories list). Do not reason about *content* within a present section — implied-but-uncaptured couplings (blockers, consumers, external systems, ordering) are the `dependency` lens's domain; unmeasurable criteria within a present Acceptance Criteria section are the `testability` lens's domain 4. **Verify Frontmatter Integrity** - Confirm `kind` is present and set to a recognised value - Check `status`, `priority`, and other required frontmatter fields are present - Flag absent or clearly incorrect frontmatter values ## Key Evaluation Questions **Structural completeness** (always applicable): - **Summary**: Does the Summary state what is being done or built as a single, unambiguous noun phrase or action statement? (Watch for: vague titles like "Fix stuff", missing the subject of the work.) - **Acceptance Criteria**: Are there at least two specific, testable criteria that define what "done" means? (Watch for: absent section, single vague criterion like "the feature works", criteria with no measurable outcome.) - **Context**: Does the Context explain *why* this work is needed — the motivation, the problem being solved, or the opportunity being captured? (Watch for: empty context, context that only restates the summary.) - **Requirements**: Are the requirements specific enough that an implementer could start work without asking for clarification? (Watch for: requirements that describe desired outcomes but not the actual work, requirements that duplicate acceptance criteria without adding detail.) **Kind-specific content** (based on work item kind): - **Bug**: Are reproduction steps present — does the work item include the specific input, the action taken, the expected outcome, and the actual outcome? (Watch for: "it crashes" with no steps, no environment details when relevant.) Treat these four elements as a single logical unit: if any are absent, report them together in one finding — not as separate findings for "missing expected outcome" and "missing actual outcome". - **Story**: Is the user or system whose need is being met identified? Are all criteria specific enough to verify? (Watch for: criteria describing implementation details rather than outcomes, missing "for whom".) - **Spike**: Is the scoped question explicit? Are the exit criteria enumerable artefacts or decisions rather than vague "understand X"? (Watch for: spikes with open-ended exit criteria, no time-box or effort constraint.) - **Epic**: Is there a decomposition strategy — a list of child stories or a description of how the epic will be broken down? (Watch for: epics with a summary and nothing else.) **Frontmatter integrity** (always applicable): - **Kind field**: Is `kind` present and set to a recognised value? (Watch for: absent `kind`, values like `unknown` or `tbd`.) - **Status field**: Is `status` present and appropriate for a work item in its current state? ## Important Guidelines - **Do not read source code or run codebase exploration agents** — work item content is the sole artefact under review - **Rate confidence** on each finding — distinguish definite gaps (section absent) from judgement calls (context deemed insufficient) - **Be proportional** — a spike requires less detail than an epic; a chore requires less than a story; flag missing content relative to the work item kind - **Treat empty-but-optional sections fairly** — an empty Dependencies section on a standalone chore is not a finding; an empty Dependencies section on a feature with obvious external coupling may be flagged as potentially sparse. If you flag it, note only that the section appears sparse relative to the work item's content — do not name which external systems or services are implied. Identifying specific implied couplings is the `dependency` lens's job. - **Focus on actionability** — flag gaps that would cause confusion, rework, or delay during implementation; do not flag trivially resolvable gaps ## What NOT to Do - Don't evaluate whether Acceptance Criteria are measurable or verifiable — that is the testability lens - Don't flag ambiguous language, unclear referents, or jargon — that is the clarity lens - Don't assess scope appropriateness or dependency graph completeness — those are the scope and dependency lenses - Don't flag missing scenarios, edge cases, error-handling paths, default behaviours, or unstated non-functional requirements — the lens measures whether sections are present and substantively populated, not whether every conceivable scenario is enumerated. What the work item doesn't mention may be intentionally left to implementation judgment. - Don't read source code, run codebase exploration agents, or make inferences about the implementation beyond what the work item explicitly states - Don't penalise a work item for lacking content that is genuinely not applicable to its kind or context - Don't apply a rigid checklist regardless of work item kind — assess what the kind requires Remember: You're evaluating whether the work item gives a reader everything they need to understand the work and take action without asking the author follow-up questions. A complete work item makes the right information present in the right place.