メニュー
Use when a PRD, feature spec, or acceptance criteria already exist and need to be turned into a concise test plan and traceable test cases with clear priorities, coverage, and execution focus.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | writing-test-cases |
| description | Use when a PRD, feature spec, or acceptance criteria already exist and need to be turned into a concise test plan and traceable test cases with clear priorities, coverage, and execution focus. |
writing-test-cases 是测试设计 lane。它的职责是：把 PRD、功能需求或验收标准，转成 测试计划 + 可执行测试用例，让 QA、研发或交付方知道应该验证什么、优先验证什么、以及如何证明完成。
它不负责重写需求，也不负责自动化脚本实现。它的重点是测试建模、覆盖追踪、优先级控制和可执行表达。
适用于：
FR / AC 变成覆盖清晰、优先级明确的测试计划和测试用例P0 / P1 / P2以下情况不要直接进入本 skill：
遇到这些情况时，优先转交：
skills/reviewing-product-requirements/SKILL.mdskills/develop-feature/SKILL.mdskills/fix-bug/SKILL.mdskills/architecture-review/SKILL.md输入来源 / 测试目标 / 测试范围 / 非目标 / 当前证据 / 关键待决问题。测试草案。FR 或 AC；无法追踪的 case 说明范围失控或输入不清。P0 只覆盖上线阻断风险；不得把所有 case 都标成最高优先级。Align
输入来源 / 测试目标 / 范围 / 非目标 / 关键待决问题完成态 PRD / feature spec / AC / issueAssess Input Quality
测试草案Model
主路径 / 失败态 / 边界值 / 角色权限 / 状态切换 / 回归影响 / 迁移兼容Plan
Specify
动作 -> 预期结果Report
测试状态 -> 输入缺口 / 覆盖追踪 -> 测试计划 -> 详细用例 -> 风险 -> NextOpen Questions，明确说明只能给出 测试草案默认只保留必要章节；不适用的章节直接省略。
测试状态
完成态测试集 或 测试草案输入缺口 / 待确认问题测试目标测试范围
In ScopeOut of Scope测试策略
优先级
P0P1P2环境与前置条件覆盖追踪
AC-1 -> TC-001, TC-002FR-3 -> TC-006详细测试用例至少检查这些点：
按需读取以下规则或相邻 skill：
rules/output-style.md
rules/deliverable-quality-gate.md
PASS / CONDITIONAL PASS / FAIL 门槛时读取skills/reviewing-product-requirements/SKILL.md
Open Questions 时读取skills/fix-bug/SKILL.md
skills/develop-feature/SKILL.md
不要把测试文档写成 PRD、自动化脚本或实现说明。
出现以下信号时，说明测试设计正在退化：
P0FR 或 AC对用户的交付至少应包含：
测试状态输入缺口 / 待确认问题测试目标、范围、优先级覆盖追踪详细测试用例 或最小可上线测试集Next若上游 PRD 仍有 Open Questions，Next 默认应说明：先回到 skills/reviewing-product-requirements/SKILL.md 补齐需求，再继续测试设计。
若当前路径没有更优替代方案，应明确写出：当前路径合理，暂无更优替代建议。
完成态测试集 与 测试草案P0 覆盖最小上线风险rules/output-style.mdUse when handling local Git CLI daily operations such as checking status or diff, staging files, creating conventional commits, restoring local changes, reverting commits, or resolving merge/rebase/cherry-pick conflicts.
Use when explaining code, answering technical questions, comparing approaches, or providing repository-grounded analysis without entering an implementation or remediation workflow.
Use when evaluating system architecture, platform design, or high-level technical structure to identify production risks, evidence gaps, and prioritized remediation without directly redesigning or implementing the system.
Use when improving internal code structure without intentionally changing externally observable behavior, such as module splits, simplification, dependency cleanup, or maintainability and performance-oriented restructuring.
Use when feature ideas, issues, stakeholder notes, or partial specs need to be reviewed and turned into a concise, testable PRD with clear scope, user stories, acceptance criteria, and explicit open decisions.
Use when reviewing pull requests, diffs, patches, or repository files to identify merge-blocking issues, important risks, and evidence gaps without directly fixing the reviewed artifact.