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 KtKID/x-dev-pipeline --skill x-verify-specgit clone --depth 1 https://github.com/KtKID/x-dev-pipelineWrote 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/ktkid/x-dev-pipeline/x-verify-spec)<a href="https://agentmods.dev/skills/ktkid/x-dev-pipeline/x-verify-spec"><img src="https://agentmods.dev/badge/skills/ktkid/x-dev-pipeline/x-verify-spec/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/ktkid/x-dev-pipeline/x-verify-spec"><img src="https://agentmods.dev/badge/skills/ktkid/x-dev-pipeline/x-verify-spec.svg" alt="Reviewed on agentmods" width="80" 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.00110 | $0.02278 |
| Opus 5.5 | $0.00044 | $0.00911 |
| Sonnet 5.5 | $0.00022 | $0.00456 |
| Haiku 4.5 | $0.00011 | $0.00228 |
Grade A, and why
x-verify-spec 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 13d 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 — 75 lines — stays where its author put it; the contents beside it link to each section on GitHub.
x-verify-spec · Gate ① 交付对账
定位与边界
只核对单个 task 的交付记录是否闭合。spec 提供功能预期及用户已确认的关键业务约束，req 分配记录确定责任范围，开发记录提供执行结果。回指有效、测试全绿、对账通过都不等同独立行为验收。
不重跑测试、不审核断言充分性或实现架构、不改交付文档，不扫描或编排同级 task，不重新评审需求质量。
输入与来源
读取完整 dev-checklist.md、dev-report.md 及 checklist 指向的 spec.md；承接 C/用例时按设计指针读取 tech-design 的用例主定义与映射，仅用于交付对账。核对 spec 指针、task 目录、dev-report 的 task 指针是否对应同一交付；只检查对账所需结构，不假定 spec 已确认。
接受已有可定位记录，不要求新增固定字段或重写上游模板：
- 承接范围：req 交付中的 task→feat 分配、用户明确范围，或可读取的 req 分配基线。
- 内容基线与确认：已有用户确认依据、req 拆解及开发验证使用的版本/内容记录和可读取的历史内容。
- 执行证据：dev-report、已有测试报告、执行记录或人工记录中的验证位置、结果及来源回指。
记录采用的来源。当前任务行不能同时充当预期全集和实际集合；创建日期不能代替内容基线，开发者声明不能代替用户确认。缺资料先报告给来源负责方补取已有记录，继续检查不受影响的项目，不补造预期或批准。
旧项目无 C 定义时核对现有已确认场景/约束及既有编号或章节定位，不以缺 C 章节单独判失败、不强造 C。未确认提议只列待澄清，不作为既定验收标准；影响本轮范围时阻止整体通过。本 task 引用的设计/用例主定义缺失时，相应覆盖与证据映射标未核实，不因其他测试全绿豁免。
对账项
一次核查全部适用项，再汇总问题、待澄清项与待补资料。
-
结构与唯一定位：checklist、report、spec 可读取，spec 有标题、概述、feat 与场景结构；被引用场景有 GIVEN/WHEN/THEN。目标编号重复、结构残缺或指针矛盾时明确报告，不能含糊定位。
-
spec 内容基线：核对拆解、开发验证与当前相关 spec 的行为和编号。有差异时比较本 task 的场景、GIVEN/WHEN/THEN 与分配范围；同时比较相关 C 的原意、范围、可观察判据与确认来源，以及用例主定义的基线；纯措辞且行为、回指未变时记录依据，行为或编号变化须有重新对齐记录。编号仍存在不代表旧证据适用；缺确认来源、基线或可读旧内容时标“基线未核实”。
-
完整场景回指：按
(feat编号, 场景编号)建立索引；既有 Scenario ID 则按原 ID 建索引，不强制迁移编号。完整解析整格，支持中英文逗号、多项及闭区间。feat01 场景1, 场景2的后项继承本格最近明确的 feat；feat01 场景1-3, feat02 场景2展开后逐项检查。首项不能省 feat，不跨行继承；倒序范围、缺成员、歧义或未解析残余不得通过。同场景可被多行引用，覆盖统计去重。 -
本 task 覆盖：从可核查的 req 分配建立应覆盖集合，取分配给本 task 的 feat 的全部场景；用户另有明确范围时依其记录，不自行缩小或扩大。与任务行实际回指对照，列出遗漏；范围外引用单列用途与依据，不据此要求本 task 交付他人的 feat。从已确认 spec 和设计主定义核对本 task 适用 C 及其全部用例与 req 分配，跨 task 的共享约束以明确分配核对；一个 C 可有多个测试，不能以一条绿灯代替全部用例或需求覆盖。缺承接记录时只报告已有回指有效性，标“范围与完整覆盖未核实”，不得反推全集后宣称全覆盖。
-
None 与 D 回指：场景列 None 须有可辨认的纯技术支撑理由及相应检查结果，不计入功能覆盖，也不豁免应覆盖场景。功能任务写 None 或理由不清时报告给 req 负责方，不以数量多单独判失败。任务含 D 编号时按已有设计指针或 spec 同目录设计核对存在性；没有 D 不强行补，仅核对引用，不做架构验收。
-
每个预期结果的证据：所有应覆盖场景与 C 约束/分配用例须有真实、可定位执行记录对应前提/触发及全部预期/禁止结果；一份记录可覆盖多项，但需明确对应关系。总绿灯、测试名称或文件存在不能替代映射。接受现有记录，不规定新格式；缺记录标“证据映射未核实”，明确少哪个结果，不审断言证明能力或代验 D 机制。记录已说明关键机制被替换、关键用例跳过、零测试或仅构建成功时，不可算作该约束的有效证据；机制是否实际落实交 x-verify-tech。核对有效红灯原因或如实记录的既有满足/人工等理由，不要求伪造 TDD。发现验收标准变化须追溯权威来源与重新确认/对齐记录，不能靠改报告取得通过。
What ships with it
2 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.
- 13d ago First seen · 75 lines · 110 tokens per session scan A 6ffa47b55999
x-verify-spec is a skill published in the GitHub repository KtKID/x-dev-pipeline (12 stars, last pushed 13d ago), licensed MIT. It adds 110 tokens to every session and 2,278 once invoked, about $0.0004 per session on Opus 5.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-10-13.
Other skills, from other repositories
backlog
Seed a backlog from the project's documents: the Product Owner reads docs/ (plus the constitution and ROADMAP.md), proposes an ordered list of feature-sized items each traced to a source section, the user edits the list, and on explicit confirmation each item is filed as a GitHub issue that /story-time can import. Use…
plan-to-tasks
Transform a plancreation planv{N}.md into a structured tasks.yaml + per-WP workpackages/.yaml using parallel Sonnet sub-agents. Use after plan-creation finishes when you need execution-friendly task structure.
auto-build-loop
Autonomous build driver after SDD spec approval: phase-scoped headless build sessions, driver-owned commits, cross-provider review gates, milestone pauses, and fail-closed escalation — under explicit opt-in autonomy profiles.
pocket-closing
Close a reviewed Pocket phase or plan when the user explicitly requests closeout, including as part of an end-to-end request. Reconcile verdicts with log.json, advance only a passing phase, append a readable per-phase closeout, and finalize the plan when all phases are done. A passing verdict alone does not authorize…
engagement-scoping
Resolve the documentation engagement scope from the settings cascade — project identity, source roots, output root, delivery mode, action ceiling, confidentiality default, and the exact file set this run may touch — and freeze it to /00-control/.scope.json. Use when any /dossier: command starts, when the delivery mode…
finding-reconciliation
Merge the independent A/B/C findings tables into one adjudicated ledger in 07-verification/documentation-verification-report.md — normalizing to the finding schema, deduplicating by location and claim, recording per-finding corroboration without downgrading single-pass findings, promoting cross-pass disagreement to…