acceptance-criteria-verification — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited acceptance-criteria-verification (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Systematically verify each acceptance criterion and post structured reports.
Core principle: Every criterion verified. Every verification documented.
Announce at start: "I'm using acceptance-criteria-verification to verify the implementation."
Read the issue and extract all acceptance criteria:
# Get issue body
gh issue view [ISSUE_NUMBER] --json body -q '.body'Parse out criteria (look for - [ ] or - [x] patterns in acceptance criteria section).
For each criterion, determine:
| Criterion | Test Type | How to Verify |
|---|---|---|
| [Criterion 1] | Unit test | Run specific test |
| [Criterion 2] | Integration | API call + response check |
| [Criterion 3] | E2E | Browser automation |
| [Criterion 4] | Manual | Visual inspection |
For each criterion, run the appropriate verification:
#### Unit/Integration Tests
# Run specific tests
pnpm test --grep "[test pattern]"
# Or run test file
pnpm test path/to/specific.test.ts#### E2E Tests
# If using Playwright
npx playwright test [test file]
# If using browser automation MCP
# Use mcp__playwright or mcp__puppeteer#### Manual Verification
For criteria requiring visual or interactive verification:
For each criterion, record:
Criterion: [Text from issue]
Status: PASS | FAIL | PARTIAL | SKIP
Evidence: [Test output, screenshot, observation]
Notes: [Any relevant details]Post a structured comment to the issue:
gh issue comment [ISSUE_NUMBER] --body "## Verification Report
**Run**: $(date -u +%Y-%m-%dT%H:%M:%SZ)
**By**: agent
**Commit**: $(git rev-parse --short HEAD)
**Branch**: $(git branch --show-current)
### Results
| # | Criterion | Status | Notes |
|---|-----------|--------|-------|
| 1 | [Criterion text] | PASS | [Notes] |
| 2 | [Criterion text] | FAIL | [What failed] |
| 3 | [Criterion text] | PARTIAL | [What works, what doesn't] |
### Summary
| Status | Count |
|--------|-------|
| PASS | X |
| FAIL | X |
| PARTIAL | X |
| SKIP | X |
| **Total** | **X** |
### Test Output
<details>
<summary>Test Results</summary>
\`\`\`
[test output here]
\`\`\`
</details>
### Next Steps
- [ ] [Action items for failures/partials]
"For each passing criterion, check it off in the issue body:
# Get current body
BODY=$(gh issue view [ISSUE_NUMBER] --json body -q '.body')
# Update checkboxes for passing criteria
# (Implementation depends on body format)
# Update issue
gh issue edit [ISSUE_NUMBER] --body "$NEW_BODY"# Update project fields using project-status-sync skill
# Verification status
# - All PASS → Passing
# - Any FAIL → Failing
# - Mix of PASS/PARTIAL → Partial
# Criteria Met count
# - Count of PASS criteria
# Last Verified
# - Current date
# Verified By
# - "agent"| Status | Meaning | Action |
|---|---|---|
| PASS | Criterion fully met, verified working | Check off in issue |
| FAIL | Criterion not met, requires fix | Document what failed, return to development |
| PARTIAL | Works with issues, needs improvement | Document issues, may need fix |
| SKIP | Could not verify (blocked, N/A, etc.) | Document reason |
When using browser automation:
// Example verification flow (pseudo-code)
await page.goto(appUrl);
await page.click('[data-testid="new-chat"]');
await page.waitForSelector('[data-testid="chat-input"]');
await page.screenshot({ path: 'new-chat-verification.png' });
// Verify expected state
const title = await page.title();
expect(title).toContain('New Chat');When criteria fail:
Do NOT:
Before completing verification:
Based on results:
| Overall Result | Next Action |
|---|---|
| All PASS | Proceed to code review |
| Any FAIL | Return to development, fix, re-verify |
| Partial only | Discuss with user - acceptable or needs fix? |
This skill is called by:
issue-driven-development - Step 8This skill calls:
project-status-sync - Update verification fieldsissue-lifecycle - Post comments~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.