# Mb Verify

> Verify one TASK-* against acceptance criteria and record reproducible evidence.

- Skill: `mrvladd-d/mb-verify` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add mrvladd-d/mb-verify`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mrvladd-d/mb-verify/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: mrvladd-d (https://skillmd.com/u/mrvladd-d)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mrvladd-d/mb-verify

---


# mb-verify — Verifier loop (acceptance → evidence → verdict)

- **What it does:** checks a completed task against acceptance criteria and records the result with evidence.
- **Use it when:** implementation is done and you want an explicit PASS, FAIL, or partial verdict.
- **Input:** `TASK_ID`, acceptance criteria sources, and the task protocol files.
- **Output:** `verification.md`, evidence artifacts, verification verdict, and recommended next status/follow-up bugs when criteria fail.

## Goal
Independent-ish verification so we don’t “trust without verify”.

This is **not** the adversarial semantic pass.
If a task may satisfy AC/REQ while still being wrong in substance, follow with `/red-verify` / `mb-red-verify`.

## Status Transition Modes

Status transitions have two modes.

Scheduler mode:
- `/autopilot` and `/autonomous` own task status transitions.
- Scheduler decides closure/failure/blocking eligibility.
- `/execute` returns scoped implementation handoff; it does not close tasks.
- `/verify` gives functional verdict/evidence; in scheduler mode it does not close/fail/block/promote.
- `/red-verify` gives semantic verdict for T2/T3; in scheduler mode it does not close/fail/block/promote.
- `/mb-sync` records/reconciles state after the scheduler-provided closure/failure/blocking decision. It does not decide closure itself.
- T0/T1 scheduler closure may use compact evidence / functional PASS according to tier policy.
- T2/T3 scheduler closure requires `VERDICT: PASS` plus `SEMANTIC_VERDICT: semantic-pass` before scheduler marks `done`.
- T3 scheduler closure also requires exact markers `HUMAN_CHECKPOINT: done` and `ROLLBACK_RECOVERY_NOTE: present`.

Manual mode:
- Expected T0/T1 simple flow: `/execute -> /verify`.
- Manual closure is allowed only when an explicit closure owner exists.
- T0/T1 may be marked `done` after functional `VERDICT: PASS` and completed evidence.
- T2/T3 must not treat `/verify PASS` alone as final `done`; run `/red-verify` and require `SEMANTIC_VERDICT: semantic-pass` before final closure/`/mb-sync`.
- If required T2/T3 `/red-verify` returns anything other than `semantic-pass`, leave closure pending or blocked, not done; optional T0/T1 red-verify does not make their normal verify-based closure stricter.
- `semantic-concern` in manual mode means do not trust the existing `done` state without human review / follow-up.
- Do not mix scheduler mode and manual mode inside one task run.
- No persisted `mode` field is used.

## Inputs
- `TASK_ID` (e.g. `TASK-123`)
- Authoritative task record via `.memory-bank/tasks/index.json` and `.memory-bank/tasks/<TASK_ID>.task.json`
- Mandatory `tier: T0|T1|T2|T3` in that task record
- Links to acceptance criteria:
  - `.memory-bank/features/FT-*` and/or
  - `.memory-bank/requirements.md` (REQ IDs)
- Link to protocol plan: `.protocols/<TASK_ID>/plan.md`

If present, also use:
- linked authoritative SDD specs for any tier
- `verification_targets`
- `normative_inputs`
- `constraints`
- `invariants`
- task record references to source artifacts

Authoritative SDD spec links are links in task richer fields or linked feature
`spec_design_links` that point to `.memory-bank/spec-index.md`,
`.memory-bank/tech-specs/`, `.memory-bank/architecture/`,
`.memory-bank/contracts/`, `.memory-bank/domains/`, `.memory-bank/states/`,
`.memory-bank/adrs/`, `.memory-bank/testing/`, or `.memory-bank/runbooks/`.

## Preconditions
- Implementation is done and gates were run (or failures recorded).
- `.memory-bank/tasks/index.json` lists the target task record, and the indexed `.task.json` validates the requested `TASK_ID`.
- Authoritative verification routing is only `task.tier`; the old `risk` / `risk.level` model is invalid.

## Required outputs
- `T0` / `T1`: verification may be recorded in compact `.protocols/<TASK_ID>/run.md`.
- `T2` / `T3`: update (or create) `.protocols/<TASK_ID>/verification.md` using:
  - `./references/shared-protocols-verification-template.md`
- Store evidence in `.tasks/<TASK_ID>/`:
  - logs, screenshots, videos, reproduction steps
- Add completed evidence entries to the task record `verify` field; `evidence_required` and `verification_targets` remain requirements/targets, not proof by themselves.
- Before any command sets `status: done`, the task record `verify` field must contain completed verification/evidence entries.

## Status ownership

- `mb-verify` owns verification evidence and `VERDICT: PASS|FAIL|NEEDS-CLARIFICATION`.
- When invoked by `/autopilot` or `/autonomous`, it must not close the task, set `status: done`, set `status: failed`, block dependents, or promote dependents. It reports a recommended next status to the scheduler.
- In standalone/manual mode, it may mark a `T0` / `T1` task `done` after functional `VERDICT: PASS` only with explicit closure ownership.
- For `T2` / `T3`, `mb-verify` records functional evidence and closure recommendation, but final closure requires `mb-red-verify` semantic-pass first.

## Process

### 1) Prime only what you need
Read:
- `.memory-bank/tasks/index.json`
- indexed `.memory-bank/tasks/<TASK_ID>.task.json`
- `.protocols/<TASK_ID>/context.md`
- `.protocols/<TASK_ID>/plan.md`
- `.protocols/<TASK_ID>/progress.md`
- acceptance criteria source docs
- `.memory-bank/spec-index.md` and all linked authoritative SDD specs when the
  task record or linked feature contains SDD spec links, for any tier

Before verifying, validate the authoritative task record:
- the task is present in `.memory-bank/tasks/index.json`
- the indexed record `id` matches `TASK_ID`
- required fields for verification are present (`status`, `feature`, `reqs`, `depends_on`, `gates`, `verify`)
- `tier` is present; if missing, stop
- for `T2` / `T3`, linked SDD specs are present in task richer fields, feature `spec_design_links`, or `spec-index.md`; if absent, stop and route back to `/spec-improve` or `/spec-auto`

Do not block `T0` / `T1` only because SDD spec links are absent.
If the authoritative task record is missing or invalid, stop and report the issue instead of verifying from protocol docs alone.

Priority:
1. linked authoritative SDD specs for any tier, when present
2. explicit `Verification Targets`
3. explicit `Normative Inputs`
4. classic feature acceptance criteria and RTM
5. evidence in `.tasks/<TASK_ID>/`

Missing richer fields or absent SDD spec links must not block verification of a
classic `T0` / `T1` task.

### 2) Verify acceptance criteria
For each AC / REQ:
- run the smallest meaningful check
- prefer deterministic checks (tests/CLI) over “looks OK”
- record what you did and link the evidence

If the task changes UI or browser behavior:
- prefer Playwright / agent-browser / CDP-driven verification
- capture screenshots/videos/traces when useful
- store artifacts in `.tasks/<TASK_ID>/`
- do not use “I clicked around manually” as the main evidence when browser automation is available

### 3) Verdict
If anything fails:
- set `VERDICT: FAIL`
- create a bug doc in `.memory-bank/bugs/BUG-<short>.md`
- add a follow-up `.task.json` and update `.memory-bank/tasks/index.json` (if needed)
- recommend current task `status: failed`
- in scheduler mode, do not block downstream dependents directly; return that recommendation to the scheduler

If all pass:
- `VERDICT: PASS`
- add completed verification/evidence entries in `verify`
- apply status by tier:
  - scheduler mode: recommend the scheduler decision; do not close/fail/block/promote
  - manual mode: may set `T0` / `T1` `status: done` after functional `VERDICT: PASS` with explicit closure ownership; for `T2` / `T3`, leave closure pending `/red-verify` `SEMANTIC_VERDICT: semantic-pass`
- in scheduler mode, final `T2` / `T3` closure is eligible only after `/red-verify` / `mb-red-verify` returns `semantic-pass`

### 4) Sync recommendations
- Record RTM/feature lifecycle recommendations for `/mb-sync`
- Do not independently perform scheduler closure or dependent block/promotion

## Definition of done
- Verification output exists and is evidence-backed: compact `run.md` for eligible `T0` / `T1`, full `verification.md` for `T2` / `T3`.
- PASS verification has updated RTM/task evidence; `T2` / `T3` tasks are not closed until `/red-verify` / `mb-red-verify` produces `semantic-pass`.
- FAIL tasks have a bug doc and next steps.