Skip to content
Back to skills

Criterion Verification Map

ASecurity

Transform acceptance criteria into plan-time runnable verification commands (behavioral, API, UI, error, performance, config, data, contract types) with expected evidence shapes and risk areas, then execute at verify time and assemble the evidence bundle with its mandatory completeness subsections, including test inputs/expected values taken from test source and risk-map coverage. Use when planning implementation against issue acceptance criteria or verifying completeness. This skill MUST be ...

  • 7 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added May 27, 2026
data-aigobashapiperformance

Works with

  • api

Security analysis

A100/100

Scanned September 24, 2026

npx -y skills add synaptiai/synapti-marketplace --skill criterion-verification-map --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Criterion Verification Map?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Criterion Verification Map
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/synaptiai-criterion-verification-map/badge)](https://www.skillsdirectory.com/skills/synaptiai-criterion-verification-map)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: criterion-verification-map
description: "Transform acceptance criteria into plan-time runnable verification commands (behavioral, API, UI, error, performance, config, data, contract types) with expected evidence shapes and risk areas, then execute at verify time and assemble the evidence bundle with its mandatory completeness subsections, including test inputs/expected values taken from test source and risk-map coverage. Use when planning implementation against issue acceptance criteria or verifying completeness. This skill MUST be consulted because deferring verification to later causes incomplete PRs, and suppressing evidence gaps prevents the verdict judge from reasoning about gaps."
allowed-tools: Bash, Read, Grep, Glob, TaskCreate, TaskList, TaskUpdate, TaskGet
context: fork
agent: general-purpose
---

# Criterion Verification Map

## Contract

Iron law: **every acceptance criterion is an eval source: at plan time it must produce a runnable verification command, or planning is blocked.** Invoked by `/flow:start` at the Spec Validation Gate and PLAN (Phases 1-2) to classify each criterion and emit the task's verification fields, and at VERIFY (Phase 4) to run them and assemble the evidence bundle shaped by [`references/evidence-bundle-format.md`](../../references/evidence-bundle-format.md). Returns task fields at plan time, the bundle at verify time. Permitted skips: none; an unmappable criterion is escalated through the Spec Validation Gate.

## Classification

| Type | Signal words | Method |
|---|---|---|
| behavioral | "when X then Y", "should return" | unit/integration test |
| api | "status code", "endpoint", "header" | curl/fetch |
| ui | "displays", "renders", "layout" | screenshot + analysis |
| error | "error message", "invalid", "fails gracefully" | invalid-input test |
| performance | "within N ms", "timeout" | benchmark/timing |
| config | "config", "setting" | build/load test |
| data | "transforms", "output matches" | run with test data |
| contract | "schema", "type", "signature" | validator / type-check |

## Plan-time task fields

Tasks are atomic (`commands/start.md` Phase 2). Emit per criterion:

```
Criterion: {full criterion text}
Verification type: {type from the table}
Verification command: {exact runnable command}
Expected evidence: {what successful output looks like}
Does NOT promise: {non-goals scoped to this criterion}
Risk areas: {risk-map rows whose area this criterion's logic touches, verbatim | none | (disabled by specFirst.riskMap)}
```

`Does NOT promise` comes from the journal's `### Non-goals`, `Risk areas` from `### Risk map` ([`references/specification-journal-format.md`](../../references/specification-journal-format.md)). `implementation-planner` adds one discriminating test per risk row (input, expected, source). Any unfillable field: escalate through the Spec Validation Gate.

## Evidence collection protocol (verify time)

For each atomic task:

1. `TaskUpdate(taskId, status: "in_progress")`
2. Run the verification command
3. Capture output verbatim
4. `TaskUpdate(taskId, status: "completed", result: "EVIDENCE_COLLECTED")`

Then assemble one `## Criterion {N}` section each. `### Type` and `### Does NOT promise` are the plan-time fields; `### What was NOT tested`, `### Known limitations of this evidence`, `### Negative/adversarial cases covered` are authored honestly now (`none — {reason}` is positive; blank is an auto-FAIL). `### Visual analysis` copies every `Viewport:` and `Step:` block from the `visual-verification` result, or its `Flows: none — {reason}` line when no flow ran, never re-derived; non-`ui` types write `none — criterion type {type} has no visual surface`.

Two subsections come from test source, never memory:

- **`### Test inputs and expected values`**: open every test file the command or its output cites. For each test that ran, record one `| Test | Input | Expected | Source of expected |` row from its source: literal input, literal asserted value, its origin (spec/criterion text, reference implementation, hand computation, existing fixture, external standard). Implementation-captured values are written `implementation output`; the judge FAILs them. `none — {reason}` only for `ui`/`config` types.
- **`### Risk map coverage`**: for each `Risk areas` row, find the test whose input is its discriminating check and write `<area> → <test file:line>`. A row with no such test is a gap: add it or escalate. `none — {reason}` only when no row maps here; `none — risk map disabled (specFirst.riskMap=false)` only when the journal subsection is the disabled marker.

Validate the bundle against the reference (every mandatory subsection present, `none` only where permitted) before `Agent(verdict-judge)`.

## Judge isolation

The verdict-judge has no file tools and receives ONLY acceptance criteria, evidence bundle, and holdout-validation output — never diff, journal, planning notes, self-review findings, test source, or screenshots.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.