foomakers/verify-done

/verify-done — Definition of Done Checker

Validate a work item against Definition of Done criteria. Two sources of truth:

• definition-of-done.md — universal DoD checklist (18 criteria covering requirements, code standards, testing, security, performance, accessibility, deployment, documentation).
• Adoption files (../../../.pair/adoption/tech/) — project-specific criteria derived from adopted architecture, tech-stack, and way-of-working decisions.

Only check criteria that are not already passing.

Arguments

| Argument | Required | Description | | -------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | $scope | No | Limit checking to specific areas: requirements, code-quality, testing, security, performance, accessibility, deployment, documentation, all (default: all) | | $story | No | Story ID to load acceptance criteria from PM tool. If omitted, checks universal DoD only. |

Algorithm

Execute each criterion group in order. For every criterion, follow the check → skip → act → verify pattern.

Step 1: Load DoD Criteria

1. Check: Read definition-of-done.md and extract the DoD checklist.
2. Skip: If $scope is set, filter to only the matching criterion group.
3. Act: Build the working checklist. If $story is provided, prepend story-specific acceptance criteria from the PM tool.
4. Verify: Checklist loaded. If definition-of-done.md is not found, warn and proceed with adoption-only criteria.

Step 2: Requirements & Acceptance Criteria

1. Check: Are all story acceptance criteria met? (Requires $story to be set.)
2. Skip: If no $story provided, or all AC already verified — mark PASS and move to Step 3.
3. Act: For each AC, evaluate whether the current code/PR satisfies it. Report unmet criteria.
4. Verify: All AC met, or unmet criteria reported.

Step 3: Code Standards

1. Check: Does the code follow adopted code design guidelines and technical standards?
2. Skip: If already verified (e.g., by a prior /verify-quality run in the same session) — mark PASS.
3. Act: Check code against code-design guidelines and technical standards. Report non-conformities.
4. Verify: Standards met or non-conformities reported.

Step 4: Architecture & ADR Compliance

1. Check: Does the solution align with adopted architecture? Are relevant ADRs followed?
2. Skip: If no architectural changes in the PR — mark PASS.
3. Act: Cross-reference changes against architecture adoption and existing ADRs in adoption/tech/adr/. Report gaps.
4. Verify: Compliant or gaps reported. Missing ADR is a HALT condition for the composing skill.

Step 5: Testing

1. Check: Are tests written per testing strategy? Do all tests pass?
2. Skip: If already verified by /verify-quality in the same session — mark PASS.
3. Act: Verify test existence for new/modified modules (1:1 mapping). Check test quality (behavior-based, not implementation-based). Report gaps.
4. Verify: Testing criteria met or gaps reported.

Step 6: Security

1. Check: Are security considerations identified and practices followed?
2. Skip: If no security-relevant changes in the PR — mark PASS.
3. Act: Check against security guidelines. Look for: hardcoded secrets, injection vulnerabilities, improper data handling, missing input validation.
4. Verify: Secure or issues reported.

Step 7: Performance

1. Check: Do performance benchmarks meet standards?
2. Skip: If no performance-relevant changes — mark PASS.
3. Act: Check for obvious performance issues: N+1 queries, unbounded loops, missing pagination, large bundle imports.
4. Verify: Performance criteria met or issues reported.

Step 8: Documentation

1. Check: Is documentation updated for changed functionality?
2. Skip: If no public API or behavior changes — mark PASS.
3. Act: Check for: updated READMEs, inline documentation for complex logic, updated adoption files if decisions changed.
4. Verify: Documentation current or gaps reported.

Step 9: Manual Test Validation (Optional)

1. Check: Does the project have a manual test suite (look for qa/ directory with CP*.md files at project root)?
2. Skip: If no manual test suite exists — mark SKIPPED. If $scope excludes manual-testing — mark SKIPPED.
3. Act: Check if a manual test report exists for the current version in .tmp/manual-test-reports/ with overall result PASS. Do NOT execute tests — only check for an existing report.
4. Verify: Report exists and PASS → mark PASS. Report exists and FAIL → mark FAIL with summary of failures. No report → mark SKIPPED with note: "No manual test report found for this version. Run /execute-manual-tests to generate one."

Output Format

Present results as:

DEFINITION OF DONE REPORT:
├── Requirements:  [PASS | FAIL — N unmet AC | SKIPPED — no $story]
├── Code Standards: [PASS | FAIL — N issues | SKIPPED]
├── Architecture:  [PASS | FAIL — N gaps | HALT — missing ADR | SKIPPED]
├── Testing:       [PASS | FAIL — N gaps | SKIPPED]
├── Security:      [PASS | FAIL — N issues | SKIPPED]
├── Performance:      [PASS | FAIL — N issues | SKIPPED]
├── Documentation:    [PASS | FAIL — N gaps | SKIPPED]
└── Manual Testing:   [PASS | FAIL — N failures | SKIPPED — no suite or no report]

RESULT: [ALL CRITERIA MET | N criteria failing | HALT — reason]

Composition Interface

When composed by /review:

• Input: /review invokes /verify-done during the completeness phase (Phase 4).
• Output: Returns the DoD report. /review incorporates findings into the review output.
  • HALT conditions (missing ADR) propagate to /review.
  • FAIL criteria become review findings.
  • SKIPPED criteria are noted but do not block.

When invoked independently:

• Run all criteria groups (or scoped groups if $scope is provided).
• Report results. This skill only reads and reports — it does not modify code.

Graceful Degradation

• If definition-of-done.md is not found, warn and check only adoption-derived criteria.
• If adoption files are missing, warn and check only universal DoD criteria.
• If $story is not provided, skip requirements/AC check and evaluate only universal criteria.
• If specific guideline files are not found (e.g., security guidelines), skip that criterion group and report: "[Area]: SKIPPED — guidelines not found."
• If /verify-quality already ran in the same session, reuse its results for code standards and testing criteria (avoid duplicate work).
• If no manual test suite exists (qa/ directory not found), Step 9 is SKIPPED — this is expected for projects without a manual test suite.
• If a manual test report exists but is for a different version, mark SKIPPED with note about version mismatch.

Notes

• This skill is read-only — it inspects code and configuration but never modifies files.
• Criteria evaluation is contextual: only changes in the PR/work item are assessed, not the entire codebase.
• SKIPPED criteria (no relevant changes) are distinct from PASS (verified and conformant).
• HALT on missing ADR: if architectural changes lack an ADR, this is escalated to the composing skill. /verify-done itself does not create ADRs — that is /record-decision's responsibility.