Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add adamancyzhang/claude-orchestrator-server --skill task-verificationgit clone --depth 1 https://github.com/adamancyzhang/claude-orchestrator-serverWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/adamancyzhang/claude-orchestrator-server/task-verification)<a href="https://agentmods.dev/skills/adamancyzhang/claude-orchestrator-server/task-verification"><img src="https://agentmods.dev/badge/skills/adamancyzhang/claude-orchestrator-server/task-verification.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00108 | $0.01930 |
| Opus 5 | $0.00054 | $0.00965 |
| Sonnet 5 | $0.00022 | $0.00386 |
| Haiku 4.5 | $0.00011 | $0.00193 |
Grade A, and why
task-verification scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 195 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Task Verification
验证不是跑一遍测试就完了,是对照蓝图逐项核实 Builder 的产出与计划的一致性。本技能与 [[task-traceability]] 协作,确保每次验证独立、客观、可复现、可追溯——每个验证结果都可追溯到具体的验收标准。
何时触发
- Builder 标记任务完成,责任链流转到 Verify 阶段
- Worker 通过
claude-orchestrator claim-task认领了 verify 类型的任务 - 用户说"验证一下 XXX 的产出"、"检查一下有没有问题"
- 蓝图中有 verify 类型的任务需要开工
验证六步法
按顺序执行,每一步通过才进入下一步。任一步发现偏离 → 记录问题,最终报告中体现。
1. 认领 Verify 任务并读取蓝图
# 认领验证任务
claude-orchestrator claim-task
# 读取蓝图
claude-orchestrator get-context --key plan-<目标slug>
从蓝图中提取:
- 被验证的 Build 任务的验收标准
- 预期的产出物类型和路径
- 上下游依赖(谁依赖这个验证结果)
明确验证范围:只验证蓝图定义的范围内内容。不验证蓝图未定义的东西。
2. 收集 Builder 的产出物
定位 Builder 在 complete_task 中声明的产出物:
# 通过 orchestrator 或任务文档找到 Builder 的 commit hash
claude-orchestrator list-tasks --status completed | grep <task-id>
# 查看 Builder 的代码变更
git show <commit-hash> --stat
git diff <commit-hash>^..<commit-hash>
确认产出物是否存在且可访问:
- 代码 commit 是否存在且可检出?
- 测试报告/截图文件是否存在?
- Builder 声明的产出物是否都可以独立检查?
如果产出物不存在或不可访问 → 立即记录为 P1 问题,退还给 Builder。
3. 逐项对照验证
按照蓝图中的验收标准,逐项独立验证(不依赖 Builder 的自测报告):
# 运行蓝图指定的测试命令
npm test -- <test-pattern> 2>&1
# 检查蓝图要求的文件产出
ls -la <expected-output-path>
# 验证代码变更是否匹配任务描述
git show <commit-hash> --name-only
对每一项验收标准记录:
- 验收标准原文
- 验证方法和命令
- 实际结果
- 判定(通过 / 偏离 / 未覆盖)
如果某项验收标准无法独立复现(如依赖 Builder 的本地环境),标记为 ⏸ 无法验证,记录原因。
4. 检查边缘情况
蓝图定义了 happy path,Verifier 检查边缘情况:
- 异常输入的处理是否正确?
- 边界值是否行为正确?
- 空状态、加载中状态是否处理?
- 与现有功能的兼容性是否被破坏?(回归测试)
- 错误信息是否有意义?
# 运行全量测试确认无回归
npm test 2>&1 | tail -30
5. 判断偏离类型
对每个发现的问题进行分类:
| 类型 | 定义 | 处理 |
|---|---|---|
| 偏离 | 产出与蓝图不一致(少做了、做错了、多做了) | 退回 Builder 修复 |
| 遗漏 | 蓝图的验收标准未满足 | 退回 Builder 补齐 |
| 越界 | 做了蓝图范围外的事 | 标记给 Reviewer 判断是否需要回退 |
| 隐患 | 表面上满足验收标准但存在隐蔽问题 | 写入验证报告,提醒 Reviewer 关注 |
6. 产出验证报告
写入验证报告文件(如 docs/verify/<目标slug>-YYYY-MM-DD.md):
# 验证报告
> Verifier | YYYY-MM-DD | 验证范围:Builder <name> 对 <task> 的产出
## 验证结论
(一句话:通过 / 不通过)
## 验证范围
| Build 任务 | Builder | Commit | 产出物 |
|------------|---------|--------|--------|
| <任务名> | <name> | `hash` | <path> |
## 逐项验证
| # | 验收标准 | 验证方法 | 实际结果 | 判定 |
|---|---------|---------|---------|------|
| 1 | `npm test -- auth` 通过 | 执行 `npm test -- auth` | 5/5 passed | ✅ |
| 2 | 截图 `login-flow.png` 存在 | `ls -la screenshots/` | 文件存在,尺寸 1200x800 | ✅ |
| ... | ... | ... | ... | ... |
## 问题清单
| # | 类型 | 描述 | 影响 |
|---|------|------|------|
| 1 | 遗漏 | 未实现错误重试逻辑(蓝图要求 3 次重试) | 生产环境可能因瞬时故障失败 |
## 回归检查
| 检查项 | 结果 |
|--------|------|
| 全量测试 | 42/42 passed |
| lint | 0 errors, 0 warnings |
---
*Verifier — YYYY-MM-DD*
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 195 lines · 108 tokens per session scan A 9b4e6e39be9c
task-verification is a skill published in the GitHub repository adamancyzhang/claude-orchestrator-server (2 stars, last pushed 1mo ago), licensed MIT. It adds 108 tokens to every session and 1,930 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
adversarial-reviewer
Adversarial code review that assumes bugs exist and hunts for them. Use when asked to review code, find bugs, audit for correctness, stress-test a PR, or when someone says "tear this apart" or "what's wrong with this". Give no benefit of the doubt — every line is guilty until proven innocent.
go-testing
Trigger: Go tests, go test coverage, Bubbletea teatest, golden files. Apply focused Go testing patterns.
semgrep-rule-variant-creator
Creates language variants of existing Semgrep rules. Use when porting a Semgrep rule to specified target languages. Takes an existing rule and target languages as input, produces independent rule+test directories for each language.
include-test-files-that-assert-on-behavior-being-changed-in-decl
When delegating a task affected by this skill, include.
brooks-sweep
Full-sweep mode: runs a unified analysis across all quality dimensions — code decay, architecture, tech debt, and test quality — then applies fixes directly to the codebase. Safe changes are auto-applied; risky changes are confirmed before execution. Drawing on twelve classic engineering books. Triggers when: user…
plugin-review
Review plugin quality with tiered checks and dependency scoping. Use for PR and pre-release audits.