acceptance-tester

name	acceptance-tester
description	Agents should invoke this skill as the final gate before release, handoff, or claiming completion for substantial changes. Runs acceptance/readiness checks, determines pass/fail, and gives a go/no-go recommendation.

Acceptance Tester

Final quality gate — determines whether a project is ready to proceed.

Acceptance Criteria Source

The definition of done comes from the combined plan (section 8), which typically includes:

• All modules implemented
• All tests passing
• Linting clean
• Application starts and core flows work
• Documentation updated
• Security constraints verified

Acceptance Checklist

Run through this checklist systematically:

1. Build Verification

• Project builds without errors
• No compiler/linter warnings (or all are documented exceptions)
• All dependencies resolve correctly

2. Test Suite

• Full test suite passes (cargo test / npm test / pytest)
• Coverage meets target from combined plan (default: 80%)
• No skipped or ignored tests without documented reason

3. Core Flow Verification

For each core user flow defined in the spec:

• Happy path works end-to-end
• Primary error paths handled gracefully
• Data persists correctly across operations

4. Spec Completeness

• All P0 spec requirements verified (from spec-vs-impl checker)
• No Blocker or Critical bugs outstanding
• All Major bugs either fixed or explicitly deferred with user approval

5. Security Constraints

For each constraint from Zero's review:

• Constraint is implemented
• Constraint is tested
• No obvious bypasses found during functional testing

6. Integration Points

• Cross-module integrations work correctly
• Error propagation across module boundaries is handled
• Data format consistency across interfaces

Verdict Determination

PASS — Ready for Next Phase

All of these must be true:

• Build succeeds
• All tests pass
• Coverage target met
• Zero Blocker bugs
• Zero Critical bugs
• All P0 spec requirements verified
• All security constraints verified

CONDITIONAL PASS

• Minor or some Major bugs remain but none are blockers
• User has approved deferring specific issues to v2
• Core flows work, edge cases may have issues

FAIL — Return to Forge

Any of these triggers a fail:

• Build fails
• Tests fail
• Blocker bugs found
• Critical bugs found
• P0 spec requirement missing or broken
• Security constraint not met

Output Format

# Acceptance Test Report — <Project Name>

**Date:** YYYY-MM-DD
**Verdict:** PASS / CONDITIONAL PASS / FAIL
**QA Engineer:** Watchdog

## Checklist Results

| Category | Status | Details |
|---|---|---|
| Build | PASS/FAIL | [details] |
| Test Suite | PASS/FAIL | X/Y tests passing, Z% coverage |
| Core Flows | PASS/FAIL | X/Y flows verified |
| Spec Completeness | PASS/FAIL | X% requirements verified |
| Security | PASS/FAIL | X/Y constraints verified |
| Integration | PASS/FAIL | [details] |

## Outstanding Issues

| Bug | Severity | Status | Decision |
|---|---|---|---|
| BUG-003 | Minor | OPEN | Deferred to v2 |

## Recommendation

[PASS]: Project is ready for documentation (Ink) and release.
[CONDITIONAL PASS]: Project can proceed with noted caveats.
[FAIL]: Return to Forge. Fix items: [list].

Handoff

• On PASS: Control returns to Clawpick, who invokes Ink for documentation.
• On CONDITIONAL PASS: Clawpick presents conditions to user for approval. If approved, proceeds to Ink.
• On FAIL: Clawpick routes bug reports to Forge. After fixes, Watchdog re-tests failed items only (not full re-test unless regression is suspected).

---

Watchdog skill — Acceptance testing and release readiness assessment