メニュー
Define or run live verify discipline for a feature — one live-verify artifact per product area, no overlap with unit tests. Use when finishing a slice, adding live-verify tests, or when asked what command proves the feature on a running stack.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
After the dev team has written their spec slice from the PRD, review it against the current codebase — baseline, gaps, impact, test harness, architecture governance (ADR + MDC), risks, and 4-lane triage. Use when the dev has drafted the spec and wants to check buildability before technical review and planning. Runs while the spec PR is open.
Before implementing one wave slice, produce a pre-flight checklist: verify the prior wave's human gate is satisfied, confirm contracts consumed from prior Ground Reports match what was actually built, then read specs/ADRs/rules. Use when starting implementation, opening a branch, or asked what to read before coding.
After feasibility (and technical review when applicable), produce a wave-level implementation plan with REQ/TASK/FILE/TEST tables and a WorkManifest YAML seed section (§9). Runs while the spec PR is open, before spec merge. Board seeding (gh issue create) happens after spec PR merge — not before.
After feasibility, produce a principal-engineer design document: resolve all engineering decisions (ADRs, interface contracts, test policy, module boundaries), draft any required ADRs, and route only true product questions back to PM on the meta PRD PR. Use before /spec-implementation-plan when the feasibility report contains NEW-ADR findings, Critical/Should-fix engineering items, or unclear module boundaries. TDD commits on the spec PR branch; PE gives GitHub Approve on the same spec PR.
Translate the PRD into a spec slice for this repo. Reads the PRD from the meta PRD PR branch or merged develop, extracts capabilities relevant to this repo, and drafts docs/specification/product/INIT-*.md. Use after engineering opens the spec PR and before /initiative-feasibility.
Map a PRD to affected repos using the service catalog. Reads the PRD and config/service-catalog.yaml from <client>-meta, matches PRD capabilities to service descriptions, and posts an impact map as a PR comment on the meta PRD PR for tech lead confirmation. Run in <client>-meta Cursor session after PRD is validated and before engineering opens spec PRs in app repos.
| name | verify |
| description | Define or run live verify discipline for a feature — one live-verify artifact per product area, no overlap with unit tests. Use when finishing a slice, adding live-verify tests, or when asked what command proves the feature on a running stack. |
| disable-model-invocation | true |
| paths | AGENTS.md, tests/**, docs/specification/as-built/** |
Clarify live verify vs unit for one feature, or run verify when asked.
Read AGENTS.md, tests_readme, and rules_glob (include testing-verify rule when present). Policy: references/verify-policy.md. Paths: .harness/profile.yaml or references/layout-defaults.md.
Resolve unit_tests_dir, live_verify_dir, debug_tests_dir from profile.
| Layer | Location (profile key) | Proves |
|---|---|---|
| Unit | unit_tests_dir | Logic, branches, edge cases |
| Verify | live_verify_dir | Product feature on running stack |
| Debug | debug_tests_dir | Exploration — not gating |
No overlap: do not assert the same behavior in unit and verify for the same feature.
Commands come from tests_readme and profile toolchain — do not hardcode stack-specific commands in the skill.
Do not skip prerequisites (running server, config files, bootstrap scripts) documented in tests_readme.
## Verify plan — FEATURE
### Unit scope
- What to test in {unit_tests_dir} (no live stack)
### Verify script
- Path: {live_verify_dir}/...
- Prerequisites: (from tests_readme)
- Command: ...
- Pass criteria: exit 0, expected shape / behavior
### As-built row
- Update implementation-status.md: unit-tested / live-verified
### Overlap check
- Confirm no duplicate assertions vs unit
If the user asks to run verify: state the exact command from tests_readme and tracker Verify command; run it when the environment is available; report pass/fail.