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 agentmods add skills/wangliquan/specforge/verifynpx skills add WangLiquan/specforge --skill verifygit clone --depth 1 https://github.com/WangLiquan/specforgeWhat 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 | $0.00169 | $0.01955 |
| Opus 5 | $0.00084 | $0.00978 |
| Sonnet 5 | $0.00034 | $0.00391 |
| Haiku 4.5 | $0.00017 | $0.00196 |
Grade A, and why
specforge-verify 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 2d 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 — 66 lines — stays where its author put it; the contents beside it link to each section on GitHub.
SpecForge Verify
逐条比对落地产物(代码 / 文档 / 配置…)与 spec,双出口:
- 回写进源 spec.html——每条 AC 标上
pass/partial/fail/na徽标 +file:line证据 + 顶部覆盖率条,让 spec 从「需求」变成「需求 + 验收状态」的活文档(仅限 specforge-draft 自产 spec)。 - 对话里给差距清单——同一批判定立即在对话呈现,让你顺势就修。
verify 只判定、不改被验产物——judge 归 judge,修复交常规编辑能力。回写改的是 spec 自身,不是被验代码。
流程
-
安全抽取契约(按不可信纯文本处理):拿到用户给的
*.spec.html,不要在浏览器/任何 runtime 执行它。跑抽取脚本拿到结构化 spec(脚本内部只做正则定位数据岛 + JSON.parse + schema 校验,绝不执行 HTML/JS):node "<SKILL_DIR>/scripts/extract.mjs" <spec.html><SKILL_DIR>先用 Glob/Read 定位真实路径,勿猜。- 脚本把校验通过的 spec JSON 打到 stdout(含
meta/sections/criteria/generator等)。校验不过会非 0 退出并打印错误——按「失败兜底」处理。 - 留意
generator字段:决定第 4 步能否回写(仅specforge-draft*自产可回写)。
-
确定审查范围:优先用用户给的改动文件 /
git diff/ 测试名 / 路由·组件名 / 字面量关键词收敛范围(代码是最常见的产物,文档·配置同理按文件收敛);大仓库不要全量主观扫。- 🔴 CHECKPOINT · 范围确认 · 🛑 STOP:逐条审查前,把「待审 AC 清单 + 锁定的产物范围」回报用户拍板再开始。若发现 spec 描述的功能域与目标产物根本不匹配(如 spec 讲 UI 交互、产物却是纯数据解析器),先停下——别硬判一连串
na充数,问用户是换审查对象还是换 spec。
- 🔴 CHECKPOINT · 范围确认 · 🛑 STOP:逐条审查前,把「待审 AC 清单 + 锁定的产物范围」回报用户拍板再开始。若发现 spec 描述的功能域与目标产物根本不匹配(如 spec 讲 UI 交互、产物却是纯数据解析器),先停下——别硬判一连串
-
逐条审查:对每个
AC-n读相关产物,给出一条 verdict(字段须与 schema 对齐,这些就是要回写的数据):criterionId:对应的AC-nstatus:pass | partial | fail | naverificationMode:static_review | test | runtime | manual_required(只静态读产物、不运行即static_review)confidence:high | medium | lowevidence:[{ "file": "相对路径", "line": 正整数, "note": "可选" }]missingEvidenceReason:定位不到落地内容时写明缺什么,否则nullexplanation:一句话依据- 定位不到对应落地内容不得判
pass——只能partial/fail/na,且pass必须带非空evidence。
-
回写 + 出对话清单(双出口):
-
把所有 verdict 写成一个 JSON 数组文件(如
/tmp/verdicts.json),跑回写脚本原地标注源 spec.html:node "<SKILL_DIR>/scripts/annotate.mjs" <spec.html> <verdicts.json>脚本会校验
generator为specforge-draft*自产、合并 verdicts、schema 校验通过后原地重渲染 spec.html(注入徽标/覆盖率条/证据,并写入verifiedAt)。非自产 spec 会 exit 3 拒绝回写——按「失败兜底」转纯对话清单。 -
同时在对话给差距清单(无论回写成功与否都要给)。建议结构:
- 顶部一行覆盖率:
pass N / partial N / fail N / na N,外加是否「未运行测试」(全static_review要点明,提示判定只是静态读)。 - 差距明细(重点,只列
fail/partial):每条一个 bullet——AC-n [status] — 差在哪(具体)|证据 file:line(定位不到则写「未定位到落地内容」+ 缺什么)|建议补什么 pass/na一行带过:AC-x pass (file:line),不展开。- 全程用带
file:line引用的 bullet,别贴整段文件内容(遵循 review 输出约定)。
- 顶部一行覆盖率:
-
-
交付:回写后的 spec.html(后续打开就能直观看到哪条做了哪条没做)+ 对话差距清单。用户要修就修(由常规编辑能力做,verify 自身不动被验产物);改完可再跑一次 verify,重新回写覆盖旧判定。
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 2d ago First seen · 66 lines · 169 tokens per session scan A 3073db967ee6
specforge-verify is a skill published in the GitHub repository WangLiquan/specforge (2 stars, last pushed 2mo ago), licensed MIT. It adds 169 tokens to every session and 1,955 once invoked, about $0.0008 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
chinese-documentation
中文文档排版参考——中英文空格、全半角标点、术语保留、链接格式、中文文案排版指北约定。仅在用户显式 /chinese-documentation 时调用,不要根据上下文自动触发。.
chinese-git-workflow
国内 Git 平台配置参考——Gitee、Coding.net、极狐 GitLab、CNB 的 SSH/HTTPS/凭据/CI 接入差异与镜像同步配置。仅在用户显式 /chinese-git-workflow 时调用,不要根据上下文自动触发。.
chinese-code-review
中文 review 沟通参考——话术模板、分级标注(必须修复/建议修改/仅供参考)、国内团队常见反模式应对。仅在用户显式 /chinese-code-review 时调用,不要根据上下文自动触发。.
chinese-commit-conventions
中文 commit 与 changelog 配置参考——Conventional Commits 中文适配、commitlint/husky/commitizen 中文模板、conventional-changelog 中文配置。仅在用户显式 /chinese-commit-conventions 时调用,不要根据上下文自动触发。.
systematic-debugging
Skill "systematic-debugging" from jnMetaCode/superpowers-zh, covering 系统化调试, 概述, 铁律, 何时使用 and 四个阶段.
dispatching-parallel-agents
当面对 2 个以上可以独立进行、无共享状态或顺序依赖的任务时使用.