vibe-acceptance-gate
npx machina-cli add skill ash1794/vibe-engineering/acceptance-gate --openclawvibe-acceptance-gate
Don't claim "done" until you've checked against the criteria that define "done."
When to Use This Skill
- After completing a task that has acceptance criteria
- Before marking an issue/ticket as resolved
- When the user asks "is this done?"
- After implementing a spec with defined requirements
When NOT to Use This Skill
- Exploratory work with no defined criteria
- Research tasks (use
vibe-reflect-and-compoundinstead) - When criteria haven't been defined yet (define them first)
Steps
-
Find the criteria — Look in:
- Issue/ticket description (MUST/SHOULD requirements)
- Spec document (acceptance criteria section)
- Task description (success conditions)
- User's original request (implicit criteria)
-
Validate each criterion — For each one:
- Run the relevant test, command, or check
- Record PASS (met), FAIL (not met), or PARTIAL (partially met)
- Capture evidence (test output, code reference)
-
Report results:
| # | Criterion | Status | Evidence |
|---|---|---|---|
| 1 | [criterion text] | PASS/FAIL/PARTIAL | [evidence] |
- Gate decision:
- All PASS → Task complete
- Any FAIL on MUST criteria → Task NOT complete, list remaining work
- PARTIAL only → Report what's missing, ask user if acceptable
Output Format
Acceptance Gate: [Task Name]
Result: PASS / FAIL / PARTIAL Criteria Met: X/Y (Z%)
| # | Criterion | Status | Evidence |
|---|---|---|---|
| 1 | ... | ✓/✗/◐ | ... |
Remaining Work (if FAIL)
- [What needs to be done]
Source
git clone https://github.com/ash1794/vibe-engineering/blob/master/skills/acceptance-gate/SKILL.mdView on GitHub Overview
The vibe-acceptance-gate ensures you do not declare work done until every defined acceptance criterion has been verified. It guides you to locate criteria in issues, specs or task descriptions, validate each item with the appropriate test or check, and document evidence. This process improves quality and reduces rework.
How This Skill Works
Find criteria in the issue or ticket description, the spec acceptance criteria section, the task description, or the user request. For every criterion, run the relevant test or check and record PASS, FAIL or PARTIAL with evidence. Generate an Acceptance Gate report and decide whether the task is complete based on the results: all PASS means complete; any FAIL on MUST criteria means not complete; PARTIAL means report the gaps and confirm with the user.
When to Use It
- After finishing a task with explicit acceptance criteria
- Before closing or marking an issue as resolved
- When a user asks is this done
- After implementing a specification with defined requirements
- When acceptance criteria exist in the ticket or spec and you need formal validation
Quick Start
- Step 1: Find the acceptance criteria in issue description, spec, task description, or user request
- Step 2: Validate each criterion, record PASS/FAIL/PARTIAL, and capture evidence
- Step 3: Review the gate decision and communicate the outcome
Best Practices
- Identify MUST and SHOULD criteria in the ticket, spec, or request
- Validate each criterion with the appropriate test or check
- Record outcomes as PASS, FAIL, or PARTIAL and attach evidence
- Treat MUST failures as blocking and do not declare done
- Communicate the gate results clearly and store evidence for audit
Example Use Cases
- Completing a feature with acceptance criteria defined in the issue
- Fixing a bug where criteria are specified in the ticket
- API endpoint validation against the response schema in the spec
- UI change implemented with explicit success criteria in the design doc
- Documentation update requiring acceptance criteria before closure
