completeness

name: completeness description: 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. user-invocable: false disable-model-invocation: true

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.