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/buildrai/buildr/project-testingnpx skills add BuildrAI/Buildr --skill project-testinggit clone --depth 1 https://github.com/BuildrAI/BuildrWhat 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.00081 | $0.01771 |
| Opus 5 | $0.00041 | $0.00886 |
| Sonnet 5 | $0.00016 | $0.00354 |
| Haiku 4.5 | $0.00008 | $0.00177 |
Grade A, and why
project-testing 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 3d 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 — 85 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Project Testing Skill
本 Skill 指导 Agent 理解 Project / Service 的测试框架，并在当前任务授权内设计或开发测试。它没有 Result、Receipt、Application、provider contract 或自身持久状态；长期事实只进入项目已有测试、脚本、CI、registry 或文档。
开始行动时必须读取 references/testing-model-v1.md。项目已有约定优先；reference 只提供判断框架，不要求固定目录、命令名或测试库。
1. 先读取真实项目
核对当前变更、待证明事实和风险，再读取相关 Project / Service 的：
- 技术栈、源码边界和可独立交付物；
- 已有测试目录、fixture、package/POM scripts、CI 与测试文档；
- 各入口真实调用、环境、副作用、近期耗时和失败定位能力；
- Project / Service owner，以及已有
verification.yml公开了哪些稳定能力。
不要按文件名、fast、unit 或技术栈惯例猜执行成本和覆盖。没有现成框架时，只在当前实现任务确实需要且授权允许时建立最小测试入口，不借机建设通用平台。
2. 分开判断测试边界与编排
测试本身分别判断：
- 主要意图：Development、Acceptance、Static Conformance、Delivery / Release；
- 执行边界：Static、Unit、Component、Integration、System。
编排另外回答三个独立问题：
- 成本约束：是否进入可高频运行的 Quick；
- 选择范围：本次是显式 focus、按影响面选择 affected，还是完整选择 full；
- 验证目标：运行在开发中的目标、冻结 Candidate，还是 Release artifact。
Quick、affected/full、Candidate/Release 不是同一层级的测试类型或互斥场景。冻结 Candidate 可以执行 affected，也可以在明确需要时执行 full。System 不等于 Acceptance；只有从提案、需求或设计验收标准派生的业务证据才是 Acceptance。Static 是独立执行形式。focus 只用于失败诊断和定向选择，不表示交付完整性。
Service 负责自身代码、公开技术契约和独立交付物可判定的事实；Project 负责跨 Service 行为、治理资产、用户旅程及组合 Candidate / Release。辅助证据可以重叠，但每项关键事实只保留一个 primaryEvidenceOwner。
3. 为任务设计和开发测试
先为每项关键待证明事实建立最小质量闭环：
- 写出事实 owner 对外可观察的正确结果，不用内部调用或覆盖率数字代替行为；
- 按当前变更风险选择能区分正确与错误实现的正常、失败、边界和必要状态转换案例，不机械穷举不适用类别；
- 再选择能够证明这些结果的最低充分执行边界，并让每个测试的失败含义可独立定位；
- 实现后检查测试是否能在目标错误存在时失败，无法取得可信反例时明确报告替代证据和 gap。
功能实现后，按最低充分边界补充 Development Tests：
- 纯逻辑优先 Unit，并让完整 Unit suite 保持可被任何变更高频运行；
- 单一有界组装或轻量上下文优先 Component，外部系统使用替身或内存实现；
- 真实进程、Git、数据库、HTTP、消息或文件系统协议使用 Integration；
- 只有完整交付物、公共入口或跨组件生命周期才使用 System。
先复用项目已有工具和 fixture；新增测试应断言返回值、状态变化、输出协议和公开副作用等公共行为，并由最接近实现的 owner 维护。mock、fake 或内存实现只隔离外部协作者或不属于当前主要事实 owner 的边界，不复制被测算法后验证自身；只有交互协议本身属于待证明契约时才断言调用参数、顺序或次数。不要为了目录整齐迁移无关测试，也不要用一个重型 System 测试替代本可低成本证明的 Unit / Component 事实。
Bug 回归测试说明它捕获的旧错误，并在安全、低成本且可复现时证明测试会在修复前、受控错误实现或移除修复后失败。旧行为无法安全执行时，使用当前失败复现、受控替代实现或精确人工推导作为替代证据并报告 gap；不得为取得红灯证据执行越权或破坏性操作，也不得伪造失败历史。
修改被多个action、状态或公共入口复用的validation/helper时，先枚举真实调用面并核对各入口既有错误类型、诊断顺序与公共结果；再结合已有tests和Project plan-only/dry-run changed-plan reasons，选择至少一个能区分主要兼容回归、成本最低的既有canary。一个canary不能覆盖已识别的独立公共边界时，按最低充分原则扩大focused regression；不得为固定低耗时遗漏已知路径。该反馈属于Development，不能把plan preview或canary结果冒充Task Verification Result，也不替代最终affected Formal Verification。
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.
- 3d ago First seen · 85 lines · 81 tokens per session scan A de99aebad3ed
project-testing is a skill published in the GitHub repository BuildrAI/Buildr (24 stars, last pushed 3d ago), licensed MIT. It adds 81 tokens to every session and 1,771 once invoked, about $0.0004 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-30.
Other skills, from other repositories
run-helix-tests
Submit and monitor .NET MAUI unit tests on Helix infrastructure. Supports running XAML, Resizetizer, Core, Essentials, and other unit test projects on distributed Helix queues.
write-tests
Write failing tests from requirements. Invoke for each todo before /implement.
dart-add-unit-test
Write and organize unit tests for functions, methods, and classes using package:test. Use when creating new logic or fixing bugs to ensure code remains correct and regression-free.
go-testing
Trigger: Go tests, go test coverage, Bubbletea teatest, golden files. Apply focused Go testing patterns.
dart-test
DART Test: unit tests, integration tests, CI validation, and debugging.
myco:runtime-bootstrap-and-test-isolation
Activate this skill when adding a new manager, adding a new tool category, writing or debugging tool unit tests, diagnosing tool-visibility failures, investigating startup performance, or extending/maintaining/debugging the two-tier tool discovery system (toolindex) — even if the user doesn't explicitly ask about the…