メニュー
Verify an implementation against its spec's acceptance criteria, marking each AC Verified, Failed, or Unknown with concrete evidence. Use after /implement or /test-and-fix, before /pr-ready, or when the user asks whether the spec is actually satisfied.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Run ProjectTwelve Unity batch validation and EditMode/PlayMode test suites via Unity 6000.5.1f1. Use when the user or ticket asks to run Unity tests, EditMode fixtures, batchmode validation, or verify test results from TestResults/*.xml.
Log agent sessions, consolidate project memory (dream), promote reviewed memory, and load context for new chats. Use when ending a session, improving cross-session recall, or when the user mentions agent memory, dream, log-session, or memory.md.
Wiki tickets under docs/wiki/tickets/ are the canonical task queue, each linked to a GitHub issue. Use when picking work, claiming an issue, or preparing PR references.
Recommend the next open wiki ticket to work on, ranked by phase then priority, without claiming or mutating anything. Use when the user asks "what's next", to pick the next task, or to start work without a specific ticket in hand.
Sync project-twelve with the Assets/_Licensed submodule via fetch_remotes.py, git hooks, and /fetch-remotes. Use at session start, before picking backlog work, or when the user asks to sync repos or get latest.
Use when the user asks to commit and push, publish, ship, or prepare a release commit. Guides staging only intended changes, writing a Conventional Commit, committing, and pushing to origin after verifying status and diff.
| name | validate-implementation |
| description | Verify an implementation against its spec's acceptance criteria, marking each AC Verified, Failed, or Unknown with concrete evidence. Use after /implement or /test-and-fix, before /pr-ready, or when the user asks whether the spec is actually satisfied. |
Answers one question: does the implementation satisfy the spec's acceptance criteria?
This is not merge readiness — CI status, review hygiene, and issue linkage belong to /pr-ready
(definition of done). Keep the two checks separate.
AC-n acceptance criteria (from /spec). If no spec exists, reconstruct
the criteria from the issue/user request and confirm them with the user first.For each acceptance criterion, assign exactly one verdict:
| Verdict | Meaning | Required evidence |
|---|---|---|
| Verified | Observed behavior matches the criterion | A test run, command output, or reproducible manual check — cite the command and result |
| Failed | Observed behavior contradicts the criterion | The failing output or observed divergence |
| Unknown | Could not be checked in this environment | Why it could not be checked and what would be needed |
Rules:
Prefer the narrowest gate from AGENTS.md:
cd tools/tile-viz && npm test when resolver/visual logic changedcd tools/world-viz && npm testpython3 scripts/check_markdown_links.py, OKF lint when docs/ changedpython scripts/sync_assistant_trees.py --check, validate_cli_skills.py## Validation report — <spec/feature name>
| AC | Criterion (short) | Verdict | Evidence |
|----|-------------------|---------|----------|
| AC-1 | … | Verified | `pytest tests/test_x.py::test_y` passed |
| AC-2 | … | Unknown | needs Unity Editor in PATH |
Overall: N verified / N failed / N unknown. <Blockers or next steps.>
Only claim the spec is satisfied when every AC is Verified.