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-techgit 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-tech)<a href="https://agentmods.dev/skills/ktkid/x-dev-pipeline/x-verify-tech"><img src="https://agentmods.dev/badge/skills/ktkid/x-dev-pipeline/x-verify-tech/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-tech"><img src="https://agentmods.dev/badge/skills/ktkid/x-dev-pipeline/x-verify-tech.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.00124 | $0.02600 |
| Opus 5.5 | $0.00050 | $0.01040 |
| Sonnet 5.5 | $0.00025 | $0.00520 |
| Haiku 4.5 | $0.00012 | $0.00260 |
Grade A, and why
x-verify-tech 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 4d 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 — 80 lines — stays where its author put it; the contents beside it link to each section on GitHub.
x-verify-tech
回答“本次实现是否遵守已确认的技术设计与适用规范”。结论只覆盖明确范围、代码基线和已取得的证据；测试通过不等于全面正确证明，也不能保证没有漏洞。
输入与权限
- 项目根目录：明确可访问路径；项目文件路径相对此根目录。
- tech-design 路径、内容基线与确认依据：已有用户确认结论、来源及覆盖条目；文件存在、父 agent 接收或开发者声明不等于确认，已有确认无需重复征询。
- 本次范围：task/feat、设计条目或明确 diff 基线/文件范围及承接来源；包括受影响的共享约束，不自行扩成全仓验收。
- 适用规范：项目
AGENTS.md、相关.agents/skills、开发规范的路径与已知约束；无附加规范也注明。按需提供 spec 路径及基线以澄清行为依据。 - 授权边界与报告位置：是否允许新增验收测试、可用隔离环境/数据和外部副作用限制；未指定报告文件时直接输出回执。
缺输入先列具体缺项和影响；确认缺失、来源冲突或需求/设计歧义的受影响项记为未验证，向用户列出需确认的问题，其余项继续。不从实现猜预期，不修改已确认设计或自动启动其他技能。
缺 tech-design 或本轮适用机制/用例的确认依据时，相关项为未验证，不能仅靠 spec 场景或测试绿灯宣称技术符合性通过。C/D/用例编号按各自权威来源定位；旧设计没有 C 映射时沿用其已有 D、场景/约束 ID 或章节定位，不强制补编号，发现真实机制或测试覆盖缺口才报告。
只在授权项目测试范围内新增验收测试或隔离测试文件，并输出报告。不改业务实现、已有断言、排除项、阈值、设计/spec、任务状态或门禁记录来获取绿灯；发现问题仅报告，不自动修复。安装依赖、搭平台及外部副作用另需授权。持久化测试使用隔离临时数据并清理，不操作生产或真实私人数据。
1. 先列设计约束，再找实现
先读 tech-design 和适用规范，尚不据实现建立预期。复用 x-tech-design 开发规范，不另抄一份规则。该链接相对本技能目录解析；设计及规范中的项目路径相对项目根目录，其他文档的相对引用按其声明的基准解析。记录解析后的可访问路径；共用资源缺失时查找可访问的 x-tech-design 安装/仓库位置，不凭记忆补规范，仍不可读的项标未验证并列最小补法。
从本次范围提取约束清单：保留 D01 等已有编号；无编号用章节/行号定位，不回写设计。每项写来源、适用原因、预期/不变量和拟用方法。逐条核对共用规范 R1–R7 及项目附加规则；相关规则不能因设计漏写而跳过，无法确定落实方案时列设计缺口。小改动引用沿用基线，只检查差异及受影响约束。
按需读取 spec 的具体 feat/场景及已确认 C 约束来确定行为、边界或数据含义；沿用 tech-design 的 C→D→用例映射，核对保障约束的技术机制（如幂等、结果核对和并发控制），不复制功能验收全集，不代替功能验收。无法确定预期时列具体回指、分歧与影响，请用户确认，不用技术假设补需求。
2. 对照代码并复用检查
约束清单确定后，再定位真实入口、模块、schema、状态读写、配置和现有测试。读取项目已安装工具、测试配置与已有检查命令，先检查现有断言是否覆盖该约束，再运行相关检查/测试；开发报告和旧绿灯仅作线索，不能冒充本轮执行结果。
| 核对对象 | 可操作方法（判定标准来自设计与共用规范） |
|---|---|
| 模块边界与依赖（R1） | 对照公开入口、允许依赖和实际 import/调用；优先运行现成循环/内部访问检查，无工具则明确做代码审查，列出依赖链、内部访问位置及覆盖局限。局部搜索无命中不能证明全范围无循环 |
| 协议与校验（R2–R3） | 从权威 schema 追生产者、消费者、边界校验和错误传播；核对 TS Zod 的运行时校验与类型推导、Python Pydantic 的实际校验入口，跨语言查生成/同步及漂移证据。仅声明模型/类型不能证明入口校验生效；已有不同方案依确认设计核对差距，不自动替换 |
| 数据、概念与状态（R4–R5、R7） | 追数据所有者、值的权威存储和全部相关读写；对照派生值及缓存/索引/快照的更新、失效、重建与提交顺序。说明名称映射的语义依据，区分协议定义源和值来源；不靠字符串搜索判断唯一来源 |
| 具名配置（R6） | 定位权威配置、单位/默认值、覆盖方式及实际使用点；对照边界行为与重复字面值，不把普通索引当业务阈值 |
可机验的相关项实际运行；语义项给出文件/符号、调用或读写链及判断理由，明确标为代码审查，不能伪称自动验证。静态检查全绿不能代替协议权威性、数据归属等语义审查。
What ships with it
1 file 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.
- 4d ago First seen · 80 lines · 124 tokens per session scan A 4521f2b9facf
x-verify-tech is a skill published in the GitHub repository KtKID/x-dev-pipeline (12 stars, last pushed 4d ago), licensed MIT. It adds 124 tokens to every session and 2,600 once invoked, about $0.0005 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
test-audit
Audit test suites for T1-T4 violations using AST analysis, mock detection, and multi-stage synthesis. Invoke when user asks to audit tests, check test quality, find mock violations, review test effectiveness, or inspect test suites for over-mocking. Triggers automatic rewrites when quality gates fail.
pocket-planning
Converts a pocket-grinding spec into a TDD-structured execution plan of full Pocket Packets. Use when pocket-grinding handoff arrives (spec path + acceptance criteria). Trigger on "create plan", "build plan", "pocket-planning", or when pocket-grinding skill invokes this. Outputs tasks ready to dispatch via…
holdout-validation
Cross-reference agent self-review claims and evidence-bundle entries against actual file state using hidden holdout scenarios, producing P1/P2/P3 findings mapped to visible acceptance criteria only. Checks that every expected value in the tests has the source the bundle claims and that every risk-map row has a…
validate-plan
Validate implementation plans against DRY, YAGNI, TDD principles and best practices. Use when reviewing plans from pocket-planning or another planning workflow to identify gaps, anti-patterns, and improvement opportunities before execution.
review
Holistic review of all changes — correctness, consistency, style, test coverage. Runs tests, checks console, verifies integration. Returns pass/fail report.
coding-standards
Quality gates, prohibited patterns, verification discipline, and self-audit rules for all code generation and review sessions.