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 BlueprintOS/analysis-to-delivery --skill test-case-designgit clone --depth 1 https://github.com/BlueprintOS/analysis-to-deliveryWrote 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/blueprintos/analysis-to-delivery/test-case-design)<a href="https://agentmods.dev/skills/blueprintos/analysis-to-delivery/test-case-design"><img src="https://agentmods.dev/badge/skills/blueprintos/analysis-to-delivery/test-case-design/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/blueprintos/analysis-to-delivery/test-case-design"><img src="https://agentmods.dev/badge/skills/blueprintos/analysis-to-delivery/test-case-design.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.00064 | $0.01003 |
| Opus 5.5 | $0.00026 | $0.00401 |
| Sonnet 5.5 | $0.00013 | $0.00201 |
| Haiku 4.5 | $0.00006 | $0.00100 |
Grade A, and why
test-case-design 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 1mo 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.
What it actually says
Test-Case-Design — 测试用例设计
Contract
- 输入: 已签字的 BRD,可选
04-合规评审.md,业务规则与验收标准 - 输出:
07-测试用例设计.md - 门控: BRD 功能已覆盖;正常/边界/异常/合规 4 大类齐;用户签字
- Required rules:
stage-gate,no-field-guessing,doc-numbering,goal-boundary - Required paths:
knowledge-path,doc-naming-path - 下一步:
/to-prd
适用场景
- BRD 通过,需要明确"什么算成功"
- 开发前需要验收标准
- 测试团队需要用例输入
流程步骤
1. 加载模板
templates/TEST_CASE_DESIGN.md
2. 覆盖范围
按以下 5 大类逐项设计:
| 类别 | 内容 | 占比建议 |
|---|---|---|
| 正常路径 | 主流程 happy path | 30% |
| 边界条件 | 极值、空值、最大/最小 | 20% |
| 异常路径 | 错误输入、超时、外部依赖失败 | 30% |
| 合规校验 | 数据授权、审计、效期锁定 | 10% |
| 性能/安全 | 并发、SQL 注入、XSS | 10% |
3. 用例结构
每条用例至少包含:
| 字段 | 说明 |
|---|---|
| 用例编号 | TC-{模块}-{序号} |
| 关联需求 | BRD §{章节} |
| 前置条件 | 初始数据/状态 |
| 输入 | 测试数据 |
| 操作步骤 | 步骤化 |
| 预期结果 | 精确、可验证 |
| 实际结果 | 测试执行时填 |
| 通过条件 | PASS/FAIL 判定标准 |
4. 业务规则回测(从 BRD §四 提取)
对每条业务规则设计至少 1 个用例:
- 正向:触发条件满足 → 期望行为
- 反向:触发条件不满足 → 期望拦截
- 边界:临界值
输出
07-测试用例设计.md
调用的 rule
rules/stage-gate— 阶段 5 门控
结束条件
- 用例覆盖 BRD §四 全部功能点
- 异常路径 100%(每条主流程至少 1 个异常用例)
- 业务规则正向 + 反向 + 边界 三类齐
- 合规校验用例关联到合规评审条款
- 用户签字进入
/to-prd
反模式
- ❌ 5 大类缺一(正常路径/边界条件/异常路径/合规校验/性能安全) —
testcase-coverage-check.py --strict直接 fail - ❌ TC 编号不规范(TC-001 写成 Test001) — 必须
TC-N-xxx/TC-B-xxx/TC-E-xxx/TC-C-xxx/TC-P-xxx前缀 - ❌ 合规校验用例未关联到合规条款 — 每条 TC-C-* 必须标
GSP-XXX/GDPR-Art-X等条款号 - ❌ 只写正常路径不写异常 — 主流程:异常用例比例 ≥ 1:1,异常路径 ≥ 90% 覆盖
- ❌ 性能测试写"应该很快" — 必须量化(P95 < Xs / 并发 Y 单/秒)
- ❌ 用例步骤空泛("操作直到成功") — 必须分 1/2/3/4 步,每步可复现
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.
- 1mo ago First seen · 91 lines · 64 tokens per session scan A 8c8cac13b5c3
test-case-design is a skill published in the GitHub repository BlueprintOS/analysis-to-delivery (26 stars, last pushed 4mo ago), licensed MIT. It adds 64 tokens to every session and 1,003 once invoked, about $0.0003 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-08-30.
Other skills, from other repositories
qa-testing
Run QA testing on a page, feature, or full site at one of three depth tiers (smoke, standard, full). Use this skill whenever the user asks to QA a page or site, run a smoke test after a deploy, verify a page before launch, or run a regression sweep. Triggers on QA, QA sweep, smoke test, regression test, post-deploy…
visual-qa
Runs rigorous visual QA across web, terminal, and paginated surfaces: an Apple HIG-based checklist, paired light/dark captures at phone and desktop widths, screenshot evidence, and a per-item PASS/FAIL verdict. Use for any UI build or change, or when asked whether a page, component, or TUI looks right or follows the…
remove-ai-slops
Removes AI-generated code smells from branch changes or an explicit file list behind regression tests. Use when the user asks to clean up, deslop, or remove AI-slop patterns from recent changes.
senpi-qa
QA the omo Senpi adapter (packages/omo-senpi, packages/senpi-task) against the REAL senpi binary in strict isolation, and write every artifact to the one canonical evidence path .omo/evidence/omo-senpi-adapter/ /. The live drivers under packages/omo-senpi/scripts/qa/ create their own isolated SENPICODINGAGENTDIR and…
test-coverage-improver
Analyze test coverage gaps and generate tests to improve coverage. Use when improving test coverage, finding untested code, or writing missing tests.
browser-test-loop
Use to actually verify a web change in a real browser instead of assuming it works — click through a flow, catch console errors, check a form submits, confirm a fix on the page. Trigger when a UI change needs proof, a bug only reproduces in the browser, or the user asks to test, check, or screenshot the running app.