メニュー
Use when a nontrivial change needs end-to-end verification before committing or shipping
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/hashgraph-online/awesome-codex-plugins --skill skill-verifyコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Coordinate agents via the AMQ CLI for file-based inter-agent messaging. Use this skill whenever you need to send messages to another agent (codex, claude, or any named handle), check your inbox, drain queued messages, set up co-op mode between agents, join a swarm team, route messages across projects, or diagnose delivery issues. Also use it when you receive a message and need to know how to reply, inspect receipts, or handle priority. Covers any multi-agent coordination task where agents need to talk to each other — review requests, questions, status updates, decision threads, wake notifications, and orchestrator integration (Symphony, Kanban). For collaborative spec/design workflows specifically, prefer the /amq-spec skill which provides structured phase-by-phase guidance. Not intended for distributed systems design (RabbitMQ, Kafka), CI/CD pipelines, or single-agent tasks with no partner.
Parallel-research-then-converge design workflow between two agents. Use this skill when the user wants two agents to independently think through a design problem before aligning on a solution — "spec X with codex", "design X together", "both agents think through X", "brainstorm architecture together", "parallel research then joint proposal", "think through separately then align", "careful thought from both sides before coding", or any variation where the user wants collaborative design rather than just splitting implementation work. Also use this when you receive a message labeled workflow:spec and need to know the correct receiver-side protocol. Not for sending simple messages or reviews (use /amq-cli), implementing completed designs, or creating document templates.
Use when defining new features, product behavior, UI/component design, architecture choices, contract changes, or ambiguous medium/high-complexity work before implementation, or when the user asks to grill or pressure-test a plan or design.
SKILL.md を表示中
| name | skill-verify |
| description | Use when a nontrivial change needs end-to-end verification before committing or shipping |
Host: Codex CLI — This skill was designed for Claude Code and adapted for Codex. Cross-reference commands use installed skill names in Codex rather than
/octo:*slash commands. Use the active Codex shell and subagent tools. Do not claim a provider, model, or host subagent is available until the current session exposes it. For host tool equivalents, seeskills/blocks/codex-host-adapter.md.
NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
If you haven't run the verification command in this turn, you cannot claim it passes.
Before claiming any success or expressing satisfaction:
Skip any step = the claim is unverified.
| Claim | Requires | NOT Sufficient |
|---|---|---|
| Tests pass | Test command output showing 0 failures | Previous run, "should pass" |
| Build succeeds | Build command exit 0 | Linter passing |
| Bug fixed | Reproduce original symptom: now passes | "Code changed, should work" |
| Regression test works | Red (fail without fix) → Green (pass with fix) | Test passes once |
| Subagent completed task | git diff shows expected changes | Subagent says "done" |
| Requirements met | Line-by-line checklist against spec | Tests passing |
| Provider dispatch worked | Output contains expected content | No error ≠ success |
If you catch yourself thinking any of these, STOP:
| Thought | What to do instead |
|---|---|
| "Should work now" | Run the verification |
| "I'm confident" | Confidence ≠ evidence |
| "Just this once" | No exceptions |
| "The linter passed" | Linter ≠ tests ≠ build |
| "The agent said it worked" | Verify independently |
| "It's a small change" | Small changes cause big bugs |
In Claude Octopus workflows, verification is especially critical because:
After any multi-provider workflow:
# Verify synthesis file exists and is recent
ls -la ~/.claude-octopus/results/*-synthesis-*.md | tail -1
# Verify it has content (not just headers)
wc -l ~/.claude-octopus/results/*-synthesis-*.md | tail -1
ALWAYS before:
In orchestrate.sh workflows:
probe (discover) — verify synthesis file existsgrasp (define) — verify consensus score meets thresholdtangle (develop) — verify tests pass, not just that code was writtenink (deliver) — verify review actually ran, not just that it was dispatched$ npm test
✓ user.create() saves to database (45ms)
✓ user.create() validates email (12ms)
Tests: 2 passed, 2 total
All 2 tests pass. ← Claim backed by output.
I've implemented the feature. It should work now. The tests should pass.
← No test was run. "Should" is not evidence.
1. Write test → run → FAIL (expected, proves test detects the bug)
2. Implement fix → run → PASS (proves fix works)
3. Revert fix → run → FAIL (proves test isn't false-positive)
4. Restore fix → run → PASS (final confirmation)
This skill is referenced by:
flow-develop.md — verification gate after implementationflow-deliver.md — verification gate before deliveryskill-code-review.md — verify review findings before reportingskill-tdd.md — red-green cycle requires evidence at each stepskill-factory.md — autonomous pipeline must verify at every phase