菜单
The evidence gate. Run the verification command via Bash, read the output, then make the claim. USE WHEN about to mark ANY prompt complete, before any "done" / "passed" claim, or the user asks to verify, confirm, or prove a result.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/Sheshiyer/skill-clusters --skill conducty-verify命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | conducty-verify |
| description | The evidence gate. Run the verification command via Bash, read the output, then make the claim. USE WHEN about to mark ANY prompt complete, before any "done" / "passed" claim, or the user asks to verify, confirm, or prove a result. |
| aliases | ["conducty-verify","verify"] |
| tags | ["conducty/skill","conducty/verify"] |
| cluster | conductor |
| version | 1.0.0 |
| origin | robertbarclayy/conducty (MIT) |
Run the command. Read the output. Then claim the result. Nothing else qualifies.
Before ANY completion claim, status update, or expression of satisfaction:
1. IDENTIFY — What command proves this claim? (from the prompt's Verification field)
2. RUN — Execute the command (Bash) fresh and complete
3. READ — Full output, exit code, failure count
4. JUDGE — Does the output confirm the claim?
YES → State the claim WITH the evidence
NO → State what actually happened WITH the evidence
5. RECORD — Log the result for checkpoint and improvement tracking
Skip any step and the claim is unsupported. "Should work" is not evidence. "The agent said it passed" is not evidence. Only output from a command you just ran via Bash is evidence.
The plan assigns a review level to each prompt. Verification scales accordingly:
Run the verification command. Read the output. If it passes, the prompt is done.
IDENTIFY: P3 verification is `npm test -- --grep "auth"`
RUN: npm test -- --grep "auth"
READ: 12/12 tests pass, exit 0
CLAIM: "P3 verified — 12/12 auth tests pass"
Run the verification command. If it passes, dispatch the spec compliance reviewer (see [[conducty-execute]]). Both must pass.
IDENTIFY: P5 verification is `cargo test session`
RUN: cargo test session
READ: 8/8 tests pass, exit 0
THEN: Dispatch spec reviewer → spec-pass
CLAIM: "P5 verified — tests pass, spec compliant"
Run the verification command. If it passes, dispatch spec reviewer. If spec passes, dispatch quality reviewer. All three must pass.
IDENTIFY: P7 verification is `make test && make lint`
RUN: make test && make lint
READ: all pass, exit 0
THEN: Spec reviewer → spec-pass → Quality reviewer → pass
CLAIM: "P7 verified — tests pass, spec compliant, quality approved"
When verifying an entire group (used by [[conducty-checkpoint]]):
For EACH prompt in the group:
IDENTIFY → RUN → READ → JUDGE
Record: pass with evidence / needs-fix with failure output
Report: "Group A: 3/4 passed. P2 needs-fix (2 test failures in auth module)"
Never say "Group passed" without individually verifying every prompt.
When verifying a fix prompt resolved the original issue:
1. Run the ORIGINAL verification command (the one that failed)
2. Run any ADDITIONAL check for the specific failure that triggered the fix
3. Both must pass
CLAIM: "Fix verified — original tests pass AND specific failure resolved"
For consistency and machine-readability in [[Metrics]] / [[Prompt Log]]:
**P{N} Verification** [{timestamp}]
- Command: `{command}`
- Exit code: {0/1/...}
- Result: {pass/fail}
- Detail: {summary of output — test count, error message, etc.}
- Review: {verify-only/spec-review/full-review} — {outcome}
This format feeds into [[conducty-checkpoint]] health metrics and [[conducty-improve]] learning.