ai-sdlc-test-cases

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

ai-sdlc-test-cases: Test Cases For Implementation

ai-sdlc-test-cases: 实施阶段测试用例

Internal AI SDLC skill, not client-facing by default. Every rule below is important to follow. None of it can be skipped. Before producing the final artifact, confirm required inputs, target audience, missing facts, output format, and constraints when they are unclear. Do not invent missing information. Ask concise clarification questions when required inputs are absent.

内部AI SDLC技能，默认不面向客户。以下每条规则都必须遵守，不可跳过任何一条。在生成最终产物前，若存在不明确的信息，需确认必要输入、目标受众、缺失事实、输出格式和约束条件。不得编造缺失信息。必要输入缺失时，需提出简洁的澄清问题。

0. Skill Card

0. 技能卡片

Skill name:
```
ai-sdlc-test-cases
```
Primary audience: QA
Supporting audience: Dev, BA
Audience tags: QA, Dev, BA
SDLC stage: Implementation test design
Purpose: Derive executable AI SDLC test scenarios from requirements or delivery context and place QA refinement artifacts under
```
specs-refiniment/<feature-name>/<file.md>
```
when writing files.
Output: Scenario matrix with requirement refs, verifiable outcomes, automation paths, and execution order

技能名称：
```
ai-sdlc-test-cases
```
主要受众：QA
支持受众：Dev、BA
受众标签：QA、Dev、BA
SDLC阶段：实施测试设计
用途：从需求或交付上下文推导可执行的AI SDLC测试场景，编写文件时将QA细化产物放置在
```
specs-refiniment/<feature-name>/<file.md>
```
路径下。
输出：包含需求引用、可验证结果、自动化路径和执行顺序的场景矩阵

0.1 Required Inputs

0.1 必要输入

Requirements, design, and behavior under test.
Affected package, endpoint, provider, workflow, or contract.
Known fixtures, mocks, and unavailable dependencies.

待测需求、设计和行为。
受影响的包、端点、提供者、工作流或契约。
已知的固定数据、模拟对象和不可用依赖。

0.2 Clarification Rules

0.2 澄清规则

Ask concise questions before finalizing when role, artifact, requirements, scope, audience, or constraints are unclear.
If optional information is missing, mark it as
```
TBD
```
,
```
Not provided
```
, or
```
Assumption
```
instead of inventing it.
Separate confirmed facts from assumptions and open questions.
Do not proceed to downstream synthesis when a required upstream artifact or decision is missing.

当角色、产物、需求、范围、受众或约束条件不明确时，需在最终确定前提出简洁的问题。
若可选信息缺失，标记为
```
TBD
```
、
```
未提供
```
或
```
假设
```
，而非编造信息。
将已确认事实与假设、未解决问题分开。
当必要的上游产物或决策缺失时，不得进行下游合成工作。

0.2.1 Flow Mode Flags

0.2.1 流程模式标志

Support two explicit execution flags:
```
--quick-flow
```
and
```
--full-flow
```
.
If both flags are supplied,
```
--full-flow
```
takes precedence because it is the stricter mode.
```
--quick-flow
```
: move fast, make high-quality progress with available context, avoid clarification questions unless continuing would create material product, security, compliance, data-loss, or irreversible implementation risk.
In
```
--quick-flow
```
, use documented assumptions, recommended defaults, existing repository patterns, and the nearest available artifact evidence; record important assumptions and decisions in
```
decision-log.md
```
.
In
```
--quick-flow
```
, run only focused checks that are directly relevant, cheap, and likely to catch regressions for the requested work; report any skipped broader checks as residual risk.
```
--full-flow
```
: ask concise clarification questions when inputs, scope, ownership, acceptance criteria, or decisions are unclear; do not silently assume material requirements.
In
```
--full-flow
```
, verify upstream and downstream artifacts, decision-log entries, traceability links, acceptance criteria, and validation evidence before finalizing.
In
```
--full-flow
```
, run or recommend the skill-appropriate gates, reviews, scripts, and validation commands needed for end-to-end confidence; document any blocked verification explicitly.
When neither flag is supplied, follow the skill default rules and choose the least risky behavior for the request size and domain.

支持两种明确的执行标志：
```
--quick-flow
```
和
```
--full-flow
```
。
若同时提供两个标志，
```
--full-flow
```
优先，因为它是更严格的模式。
```
--quick-flow
```
：快速推进，利用现有上下文开展高质量工作，除非继续推进会造成实质性产品、安全、合规、数据丢失或不可逆实施风险，否则避免提出澄清问题。
在
```
--quick-flow
```
模式下，使用已记录的假设、推荐默认值、现有仓库模式和最近可用的产物证据；将重要假设和决策记录在
```
decision-log.md
```
中。
在
```
--quick-flow
```
模式下，仅运行与请求工作直接相关、成本低且可能发现回归问题的针对性检查；将任何跳过的更广泛检查报告为残留风险。
```
--full-flow
```
：当输入、范围、所有权、验收标准或决策不明确时，提出简洁的澄清问题；不得默认假设实质性需求。
在
```
--full-flow
```
模式下，在最终确定前验证上游和下游产物、决策日志条目、可追溯性链接、验收标准和验证证据。
在
```
--full-flow
```
模式下，运行或推荐技能对应的关卡、评审、脚本和验证命令，以确保端到端的可信度；明确记录任何受阻的验证工作。
若未提供任何标志，遵循技能默认规则，并根据请求规模和领域选择风险最低的行为。

0.3 Output Rules

0.3 输出规则

Keep output structured with headings and bullets.
Make findings, gaps, risks, and blockers explicit.
Tie recommendations to evidence from the provided artifact,
```
specs-refiniment/<feature-name>/<file.md>
```
workspace, stakeholder context, or user-provided source material.
Include role ownership when the output creates follow-up work for BA, QA, Dev, PM, or Delivery.
Return progress, completion, validation, and handoff summaries directly in the Codex response.

Before the final response, emit the

ai-sdlc-handoff/v1

contract with

result

blockers

next_required

, and

next_optional

; every action includes

reason

command

, and

expected_artifact

Do not create
```
summary.txt
```
,
```
*-summary.txt
```
, or another standalone summary file unless the user explicitly requests one.
Keep durable writes limited to the canonical lifecycle artifacts, decision log, human-readable index, and
```
_ai_sdlc
```
machine files.
Let shared helpers migrate legacy paths on the next write; never overwrite or manually merge divergent legacy and canonical files.

输出需使用标题和项目符号保持结构化。
明确指出发现的问题、差距、风险和障碍。
建议需与提供的产物、
```
specs-refiniment/<feature-name>/<file.md>
```
工作区、利益相关者上下文或用户提供的源材料中的证据相关联。
当输出为BA、QA、Dev、PM或交付团队带来后续工作时，需明确角色归属。
直接在Codex响应中返回进度、完成情况、验证和交接摘要。

在最终响应前，发送包含

result

、

blockers

、

next_required

和

next_optional

的

ai-sdlc-handoff/v1

契约；每个操作需包含

reason

、

command

和

expected_artifact

。

除非用户明确要求，否则不得创建
```
summary.txt
```
、
```
*-summary.txt
```
或其他独立的摘要文件。
持久化写入仅限于标准生命周期产物、决策日志、人类可读索引和
```
_ai_sdlc
```
机器文件。
让共享助手在下次写入时迁移旧路径；不得覆盖或手动合并不一致的旧文件和标准文件。

0.4 Artifact Routing

0.4 产物路由

Maintain a feature decision log whenever this skill records, resolves, changes, or depends on a product, delivery, QA, security, validation, branching, implementation, or rollout decision.
For PM, BA, QA, Delivery, discovery, planning, refinement, and readiness work, write decisions to
```
specs-refiniment/<feature-name>/decision-log.md
```
.
For developer implementation SDD work, write decisions to
```
specs/<feature-name>/decision-log.md
```
.
Each decision-log entry must include date, decision, context or evidence, options considered when relevant, owner, status, and links to affected artifacts, tasks, tests, or validation evidence.

Use this exact decision-log structure:

markdown

# Decision Log

| ID | Date | Status | Owner | Decision | Context/Evidence | Options Considered | Affected Artifacts | Validation/Trace Links |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| DEC-001 | YYYY-MM-DD | proposed / accepted / superseded / rejected | role or name | concise decision | source facts, artifact links, or evidence | option A; option B; recommended default | affected docs, tasks, code, tests, or rollout notes | requirement IDs, test IDs, validation commands, PRs, commits, or tickets |

When writing or updating files, place PM, BA, QA, Delivery, discovery, planning, refinement, and readiness artifacts at
```
specs-refiniment/<feature-name>/<file.md>
```
.
Use the path pattern
```
specs-refiniment/<feature-name>/<file.md>
```
; choose a stable feature slug when known, otherwise use
```
tbd-<short-topic>
```
for
```
<feature-name>
```
.
Do not write this skill's output into
```
specs/
```
; that folder is reserved for developer implementation SDD artifacts.
If the user explicitly asks to convert a refined artifact into developer implementation work, hand off to
```
$ai-sdlc-sdd
```
.

每当该技能记录、解决、更改或依赖产品、交付、QA、安全、验证、分支、实施或发布决策时，需维护功能决策日志。
对于PM、BA、QA、交付、探索、规划、细化和准备工作，将决策写入
```
specs-refiniment/<feature-name>/decision-log.md
```
。
对于开发者实施SDD工作，将决策写入
```
specs/<feature-name>/decision-log.md
```
。
每个决策日志条目必须包含日期、决策内容、上下文或证据、相关可选方案（如有）、负责人、状态以及受影响产物、任务、测试或验证证据的链接。

使用以下精确的决策日志结构：

markdown

# Decision Log

| ID | Date | Status | Owner | Decision | Context/Evidence | Options Considered | Affected Artifacts | Validation/Trace Links |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| DEC-001 | YYYY-MM-DD | proposed / accepted / superseded / rejected | role or name | concise decision | source facts, artifact links, or evidence | option A; option B; recommended default | affected docs, tasks, code, tests, or rollout notes | requirement IDs, test IDs, validation commands, PRs, commits, or tickets |

编写或更新文件时，将PM、BA、QA、交付、探索、规划、细化和准备产物放置在
```
specs-refiniment/<feature-name>/<file.md>
```
路径下。
使用路径模式
```
specs-refiniment/<feature-name>/<file.md>
```
；若已知稳定的功能别名则使用，否则
```
<feature-name>
```
使用
```
tbd-<short-topic>
```
。
不得将该技能的输出写入
```
specs/
```
文件夹；该文件夹专为开发者实施SDD产物保留。
若用户明确要求将细化产物转换为开发者实施工作，需交接给
```
$ai-sdlc-sdd
```
。

0.5 Feature State Machine

0.5 功能状态机

Maintain feature lifecycle state in TOON at

specs-refiniment/<feature-name>/_ai_sdlc/state.toon

for refinement work and

specs/<feature-name>/_ai_sdlc/state.toon

for implementation work.

Before executing this skill for a feature, check the state machine with

python3 skills/_shared/state_machine.py check --feature <feature-name> --skill <this-skill-name> --workspace <refinement|implementation> --quick-flow|--full-flow

When this skill starts durable work, mark it in progress with
```
begin
```
; when the skill's required artifact or review is complete, mark it done with
```
complete
```
and include
```
--artifacts <path>
```
plus
```
--decision-ref DEC-###
```
when a decision was involved.
In
```
--full-flow
```
, do not proceed when predecessor stages are incomplete, another lifecycle skill is active, or the state file reports a blocker.
In
```
--quick-flow
```
, a predecessor skip is allowed only when continuing is low risk and the command includes
```
--assumption "..."
```
or
```
--decision-ref DEC-###
```
; record the same assumption or decision in
```
decision-log.md
```
.

Use

python3 skills/_shared/state_machine.py status --feature <feature-name> --workspace <refinement|implementation> --format toon

to emit compact LLM-readable state before choosing the next skill.

The state machine is feature-scoped: do not reuse a
```
state.toon
```
across unrelated feature folders.

在TOON中维护功能生命周期状态：细化工作对应

specs-refiniment/<feature-name>/_ai_sdlc/state.toon

，实施工作对应

specs/<feature-name>/_ai_sdlc/state.toon

。

为某个功能执行该技能前，使用

python3 skills/_shared/state_machine.py check --feature <feature-name> --skill <this-skill-name> --workspace <refinement|implementation> --quick-flow|--full-flow

检查状态机。

当该技能开始持久化工作时，用
```
begin
```
标记为进行中；当技能所需的产物或评审完成时，用
```
complete
```
标记为已完成，若涉及决策则需添加
```
--artifacts <path>
```
和
```
--decision-ref DEC-###
```
。
在
```
--full-flow
```
模式下，当前置阶段未完成、另一个生命周期技能处于活跃状态或状态文件报告存在障碍时，不得继续推进。
在
```
--quick-flow
```
模式下，仅当继续推进风险较低且命令包含
```
--assumption "..."
```
或
```
--decision-ref DEC-###
```
时，才允许跳过前置阶段；需在
```
decision-log.md
```
中记录相同的假设或决策。

使用

python3 skills/_shared/state_machine.py status --feature <feature-name> --workspace <refinement|implementation> --format toon

在选择下一个技能前生成紧凑的LLM可读状态。

状态机以功能为范围：不得在不相关的功能文件夹间复用
```
state.toon
```
。

0.6 Artifact Metadata And Metatags

0.6 产物元数据与元标签

Every Markdown artifact generated or updated by this skill must start with an
```
artifact_metadata
```
YAML frontmatter block before the first visible heading.

Use schema

ai-sdlc-artifact-metadata/v1

and keep these fields current:

feature

artifact

path

workspace

skill

flow_mode

state_file

decision_log

status

owner

created_at

updated_at

trace_ids

related_artifacts

validation

, and

metatags

```
metatags
```
must include at minimum
```
ai-sdlc
```
, the workspace (
```
refinement
```
or
```
implementation
```
), this skill name, the artifact type or filename stem, and a lifecycle/status tag such as
```
draft
```
,
```
review
```
,
```
approved
```
, or
```
validated
```
.
When
```
--quick-flow
```
is active, set
```
flow_mode: quick
```
, keep assumptions visible in the body, and add tags for major defaults or unresolved risk only when they help retrieval.
When
```
--full-flow
```
is active, set
```
flow_mode: full
```
, keep blockers and validation evidence reflected in
```
status
```
,
```
validation
```
,
```
trace_ids
```
, and
```
related_artifacts
```
.
Update metadata whenever the artifact path, status, owner, trace links, validation evidence, related artifacts, or decision references change.
Metadata is an index for routing, retrieval, and traceability; it does not replace the artifact body,
```
decision-log.md
```
, or
```
state.toon
```
.

该技能生成或更新的每个Markdown产物，必须在第一个可见标题前包含
```
artifact_metadata
```
YAML前置块。

使用

ai-sdlc-artifact-metadata/v1

schema，并保持以下字段最新：

feature

、

artifact

、

path

、

workspace

、

skill

、

flow_mode

、

state_file

、

decision_log

、

status

、

owner

、

created_at

、

updated_at

、

trace_ids

、

related_artifacts

、

validation

和

metatags

。

```
metatags
```
必须至少包含
```
ai-sdlc
```
、工作区（
```
refinement
```
或
```
implementation
```
）、该技能名称、产物类型或文件名主干，以及生命周期/状态标签（如
```
draft
```
、
```
review
```
、
```
approved
```
或
```
validated
```
）。
当
```
--quick-flow
```
模式激活时，设置
```
flow_mode: quick
```
，在正文中显示假设，仅当有助于检索时才添加主要默认值或未解决风险的标签。
当
```
--full-flow
```
模式激活时，设置
```
flow_mode: full
```
，在
```
status
```
、
```
validation
```
、
```
trace_ids
```
和
```
related_artifacts
```
中反映障碍和验证证据。
当产物路径、状态、负责人、追溯链接、验证证据、相关产物或决策引用发生变化时，更新元数据。
元数据用于路由、检索和可追溯性，不能替代产物正文、
```
decision-log.md
```
或
```
state.toon
```
。

0.7 Specs Index

0.7 规格索引

Before searching across feature folders, inspect the compact LLM index first:
```
specs-refiniment/_ai_sdlc/specs-index.toon
```
for refinement work or
```
specs/_ai_sdlc/specs-index.toon
```
for implementation work.
Use the human-readable index at
```
specs-refiniment/specs-index.md
```
or
```
specs/specs-index.md
```
when reporting feature coverage, artifact inventory, or handoff status to people.

After this skill creates or materially updates an artifact, refresh the matching workspace index with

python3 skills/_shared/ai_sdlc_specs_index.py --workspace <refinement|implementation> --quick-flow|--full-flow

In
```
--quick-flow
```
, rely on
```
specs-index.toon
```
to choose the smallest relevant artifact set before opening files.
In
```
--full-flow
```
, verify the updated artifact appears in both
```
specs-index.toon
```
and
```
specs-index.md
```
before final handoff.
The specs index summarizes artifact metadata and state; it does not replace reading the selected source artifacts when details, approvals, or validation evidence matter.

在跨功能文件夹搜索前，先查看紧凑的LLM索引：细化工作对应
```
specs-refiniment/_ai_sdlc/specs-index.toon
```
，实施工作对应
```
specs/_ai_sdlc/specs-index.toon
```
。
向人员报告功能覆盖率、产物清单或交接状态时，使用人类可读索引
```
specs-refiniment/specs-index.md
```
或
```
specs/specs-index.md
```
。

该技能创建或实质性更新产物后，使用

python3 skills/_shared/ai_sdlc_specs_index.py --workspace <refinement|implementation> --quick-flow|--full-flow

刷新对应工作区的索引。

在
```
--quick-flow
```
模式下，依赖
```
specs-index.toon
```
选择最小的相关产物集，再打开文件。
在
```
--full-flow
```
模式下，最终交接前需验证更新后的产物是否同时出现在
```
specs-index.toon
```
和
```
specs-index.md
```
中。
规格索引汇总产物元数据和状态；当细节、审批或验证证据重要时，不能替代阅读选定的源产物。

0.8 Complete Refinement Cascade

0.8 完整细化流程

Trigger the complete cascade only when the user explicitly asks for a full, complete, or end-to-end spec refinement or asks for every refinement artifact. A normal
```
--full-flow
```
call for one skill remains single-stage.
Before the first durable write, run
```
python3 skills/_shared/refinement_status.py --feature <feature-name> --gate full --format toon
```
and start with the earliest reported
```
next_skill
```
, including stages earlier than this skill.
Execute the existing refinement skills in lifecycle order with
```
--full-flow
```
: discovery, PRFAQ, delivery-package gap review, requirements readiness, goal/capability mapping, backlog gap review, backlog decomposition, story decomposition, release slicing, BA context, delivery spec, QA plan, QA gap review, test strategy, test cases, test suite, QA readiness, and delivery handoff.
Produce all 18 canonical Markdown artifacts.
```
release-slicing.md
```
is mandatory for a complete cascade; when release slicing is not applicable, write an explicit evidence-backed N/A artifact and complete the stage instead of skipping it.
After every stage, finalize its artifact, record required decisions, mark the stage
```
done
```
, and refresh the refinement indexes before selecting the next skill.
Do not declare the cascade complete until
```
python3 skills/_shared/refinement_status.py --feature <feature-name> --gate full --format markdown
```
exits successfully with
```
18/18
```
. If it fails, continue with the reported next skill or return the concrete blocker and remaining inventory in Codex.
Surface checkpoint and final summaries in Codex only; never persist a cascade summary as a text file.

仅当用户明确要求完整的、全面的或端到端的规格细化，或要求所有细化产物时，才触发完整流程。正常的
```
--full-flow
```
调用单个技能仍为单阶段。
在第一次持久化写入前，运行
```
python3 skills/_shared/refinement_status.py --feature <feature-name> --gate full --format toon
```
，并从最早报告的
```
next_skill
```
开始，包括早于该技能的阶段。
按生命周期顺序使用
```
--full-flow
```
执行现有细化技能：探索、PRFAQ、交付包差距评审、需求就绪度、目标/能力映射、待办事项差距评审、待办事项分解、用户故事分解、发布拆分、BA上下文、交付规格、QA计划、QA差距评审、测试策略、测试用例、测试套件、QA就绪度和交付交接。
生成所有18个标准Markdown产物。
```
release-slicing.md
```
是完整流程的必填项；若发布拆分不适用，需编写明确的基于证据的N/A产物并完成该阶段，而非跳过。
每个阶段结束后，完成其产物、记录必要决策、标记阶段为
```
done
```
，并在选择下一个技能前刷新细化索引。
仅当
```
python3 skills/_shared/refinement_status.py --feature <feature-name> --gate full --format markdown
```
成功退出且显示
```
18/18
```
时，才可宣布流程完成。若失败，继续执行报告的下一个技能，或在Codex中返回具体障碍和剩余清单。
仅在Codex中显示检查点和最终摘要；不得将流程摘要保存为文本文件。

References

参考资料

Use
```
scripts/case_matrix.py
```
when deterministic scaffolding, planning, or formatting is useful for this workflow; pass the same
```
--quick-flow
```
or
```
--full-flow
```
flag that was supplied to the skill.
Read
```
references/test-case-template.md
```
when the task needs the detailed structure, checklist, or examples for this skill.

当该工作流需要确定性脚手架、规划或格式化时，使用
```
scripts/case_matrix.py
```
；传入与技能相同的
```
--quick-flow
```
或
```
--full-flow
```
标志。
当任务需要该技能的详细结构、检查清单或示例时，阅读
```
references/test-case-template.md
```
。

Script Usage

脚本使用

In default and full flow, always run this skill's primary analysis script with
```
--format toon --budget-tokens 24000
```
before drafting; explicit inputs are priority evidence but do not replace the rest of the feature package.
Read this skill's reference file before writing sections. Use its detailed tables and quality bar, not only the compact scaffold headings.
Run the primary script with
```
--emit-template
```
in the active flow mode to obtain the exact shared context headings and required stage table columns before section writes.
Make every default/full artifact self-contained by completing all ten shared feature-context sections plus the stage-specific profile sections. Quick flow may use the compact stage-only draft.
Follow every
```
next_reads
```
entry before finalization and list every consumed source in
```
Source Coverage
```
; do not claim whole-feature context from a partial source set.
Keep the final artifact within
```
--max-artifact-tokens 24000
```
; condense repetition instead of dropping feature dimensions or source traceability.
Run
```
scripts/case_matrix.py
```
before drafting or updating this skill's artifact when inputs are longer than a few bullets, when traceability matters, or when a flow flag is supplied. For agent analysis, pass
```
--format toon
```
, read
```
anchors
```
first, and open only
```
next_reads
```
; without that flag the script keeps its human-readable Markdown output.

Quick flow analysis:

python3 skills/ai-sdlc-test-cases/scripts/case_matrix.py --feature <feature-name> --quick-flow <input.md>...

Full flow analysis:

python3 skills/ai-sdlc-test-cases/scripts/case_matrix.py --feature <feature-name> --full-flow <input.md>...

To write content, pass one canonical heading with
```
--section "<section>"
```
; provide only that section body on stdin, without H1, H2, frontmatter, or a temporary content file.
Repeat
```
--section
```
for each required section, then run the same script with
```
--finalize
```
to validate the artifact and refresh metadata and specs indexes.
The AI must not write or directly edit the routed Markdown artifact; the script owns scaffold creation, section placement, and durable file writes.
Use
```
--decision-row
```
with one nine-cell Markdown table row on stdin when a decision-log entry is required.

Legacy

--emit-template

--emit-decision-log-entry

, and

--write

remain available for compatibility.

Use
```
--quick-flow
```
for first-pass synthesis with assumptions; use
```
--full-flow
```
before readiness, handoff, signoff, or any decision-sensitive output.

在默认和全流程模式下，起草前需始终使用
```
--format toon --budget-tokens 24000
```
运行该技能的主分析脚本；明确输入是优先证据，但不能替代整个功能包。
编写章节前阅读该技能的参考文件。使用其详细表格和质量标准，而非仅使用紧凑的脚手架标题。
在当前流程模式下运行主脚本并添加
```
--emit-template
```
，以获取精确的共享上下文标题和所需阶段表格列，再进行章节编写。
每个默认/全流程产物需包含所有十个共享功能上下文章节以及阶段特定的配置文件章节，确保自包含。快速流程可使用紧凑的仅阶段草稿。
最终确定前遵循每个
```
next_reads
```
条目，并在
```
Source Coverage
```
中列出所有使用的源；不得从部分源集声称拥有完整功能上下文。
最终产物需控制在
```
--max-artifact-tokens 24000
```
以内；压缩重复内容，而非舍弃功能维度或源可追溯性。
当输入超过几个项目符号、可追溯性重要或提供了流程标志时，起草或更新该技能的产物前需运行
```
scripts/case_matrix.py
```
。对于代理分析，传入
```
--format toon
```
，先读取
```
anchors
```
，再打开仅
```
next_reads
```
；若无该标志，脚本保持人类可读的Markdown输出。

快速流程分析：

python3 skills/ai-sdlc-test-cases/scripts/case_matrix.py --feature <feature-name> --quick-flow <input.md>...

全流程分析：

python3 skills/ai-sdlc-test-cases/scripts/case_matrix.py --feature <feature-name> --full-flow <input.md>...

编写内容时，传入一个标准标题并添加
```
--section "<section>"
```
；仅在标准输入中提供该章节正文，无需H1、H2、前置块或临时内容文件。
对每个所需章节重复使用
```
--section
```
，然后运行相同的脚本并添加
```
--finalize
```
以验证产物并刷新元数据和规格索引。
AI不得直接写入或编辑路由的Markdown产物；脚本负责脚手架创建、章节放置和持久化文件写入。
当需要决策日志条目时，使用
```
--decision-row
```
并在标准输入中提供一行九单元格的Markdown表格。

旧版

--emit-template

、

--emit-decision-log-entry

和

--write

仍可兼容使用。

```
--quick-flow
```
用于带假设的首次合成；
```
--full-flow
```
用于就绪度检查、交接、签字确认或任何决策敏感输出。

Purpose

目标

Derive executable AI SDLC test scenarios from requirements or delivery context. Link each scenario to a requirement, story, workflow, risk, or acceptance criterion and define verifiable outcomes, automation commands, execution order, and human decisions without leaving open TODOs.

从需求或交付上下文推导可执行的AI SDLC测试场景。将每个场景与需求、用户故事、工作流、风险或验收标准关联，并定义可验证结果、自动化命令、执行顺序和人工决策，不得留下未解决的TODO项。

Inputs

输入

Read the provided requirements, delivery spec, stories, workflows, risks, and existing test cases.
Read existing QA notes from
```
specs-refiniment/<feature-name>/<file.md>
```
when acceptance or manual validation already exists.
Collect the changed behavior, contract, bug, regression risk, endpoint, provider, asset, or workflow under test.
Collect existing test files for the affected package when implementing tests.
Read
```
references/test-case-template.md
```
when the scenario matrix needs reusable wording.
Collect known fixtures, mocks, seeded data, and unavailable dependencies.

读取提供的需求、交付规格、用户故事、工作流、风险和现有测试用例。
当已有验收或手动验证时，读取
```
specs-refiniment/<feature-name>/<file.md>
```
中的现有QA笔记。
收集待测的变更行为、契约、缺陷、回归风险、端点、提供者、资产或工作流。
实施测试时，收集受影响包的现有测试文件。
当场景矩阵需要可复用表述时，读取
```
references/test-case-template.md
```
。
收集已知的固定数据、模拟对象、种子数据和不可用依赖。

Steps

步骤

Write
```
In scope
```
and
```
Out of scope
```
before generating scenarios.
Check every proposed test case against
```
Out of scope
```
; delete any test case that tests excluded behavior.
Define the behavior under test in one sentence.
Identify the requirement, story, workflow, risk, or acceptance criterion each scenario proves.
Create scenario IDs using
```
TC-001
```
,
```
TC-002
```
, and continuing sequence.
Include happy path, boundary values, null or missing inputs, negative validation, authorization, state-transition, retry, idempotency, concurrency, and provider-failure cases when relevant.
Map each scenario to exactly one primary layer: unit, service, transport, integration, QA/manual, or not automated.
Write a verifiable outcome for every scenario using one of these forms:
- shell command whose exit code proves the outcome
- numbered checklist of observable facts a human can tick without interpretation
- before/after diff or data pair that proves the behavior changed correctly
Write an automation path for every scenario using one of these forms:
- script path plus exact invocation
- CI step name
- ```
Manual — automate by YYYY-MM-DD — blocker: concrete blocker
```
Replace open TODOs with
```
Decisions required
```
; each decision must include Question, Options A/B/C, Recommended default, Owner, and Blocking yes/no.
Replace decorative layer descriptions with
```
Execution order
```
; each layer must include run condition, what it blocks, and failure action.
Write or update the scenario matrix under
```
specs-refiniment/<feature-name>/<file.md>
```
when file output is requested.
Implement tests only after the scenario matrix contains requirement refs, verifiable outcomes, automation paths, execution order, and structured decisions.
Name tests so a reviewer can trace each test back to a scenario ID or spec reference.

生成场景前先编写
```
范围内
```
和
```
范围外
```
内容。
检查每个拟议测试用例是否符合
```
范围外
```
；删除任何测试排除行为的测试用例。
用一句话定义待测行为。
确定每个场景验证的需求、用户故事、工作流、风险或验收标准。
使用
```
TC-001
```
、
```
TC-002
```
等连续序列创建场景ID。
相关时包含正常路径、边界值、空值或缺失输入、负向验证、授权、状态转换、重试、幂等性、并发和提供者故障场景。
将每个场景精确映射到一个主层级：单元、服务、传输、集成、QA/手动或未自动化。
为每个场景编写可验证结果，使用以下形式之一：
- 退出码可证明结果的shell命令
- 人类无需解释即可勾选的可观察事实编号清单
- 可证明行为正确变更的前后差异或数据对
为每个场景编写自动化路径，使用以下形式之一：
- 脚本路径加精确调用方式
- CI步骤名称
- ```
Manual — automate by YYYY-MM-DD — blocker: concrete blocker
```
将未解决的TODO替换为
```
需决策
```
；每个决策必须包含问题、选项A/B/C、推荐默认值、负责人和是否阻塞。
将装饰性层级描述替换为
```
执行顺序
```
；每个层级必须包含运行条件、阻塞对象和失败操作。
当需要文件输出时，在
```
specs-refiniment/<feature-name>/<file.md>
```
下编写或更新场景矩阵。
仅当场景矩阵包含需求引用、可验证结果、自动化路径、执行顺序和结构化决策后，才可实施测试。
命名测试时需确保评审者可将每个测试追溯到场景ID或规格引用。

Output Spec

输出规格

Use this format:

text

Scope:
- In scope:
  - Behavior, contract, endpoint, workflow, or artifact covered.
- Out of scope:
  - Behavior, contract, endpoint, workflow, or artifact deliberately excluded.

Scenario matrix:
| ID | Requirement ref | Scenario | Setup | Trigger | Verifiable outcome | Layer | Automation |
| --- | --- | --- | --- | --- | --- | --- | --- |
| TC-001 | AC-001, story ID, workflow, risk, or artifact section | Scenario name | Fixture/state | Action | Command, checklist, or before/after pair | unit/service/transport/integration/QA/manual | script path + invocation, CI step, or manual blocker |

Automation plan:
- TC-001: exact command or CI step, target file if new, expected pass condition.

Execution order:
1. Layer: run condition; blocks: later layer or release gate; failure action: stop, fix, rerun, or escalate.

Decisions required:
- Question: decision needed.
  Options:
  A. Option A
  B. Option B
  C. Option C
  Recommended default: option and reason.
  Owner: role or person.
  Blocking: yes | no.

Quality gate:

Pass when every scenario has scope fit, requirement ref, setup, trigger, verifiable outcome, layer, concrete automation path, and execution-order placement.

Pass when every manual scenario uses

Manual — automate by YYYY-MM-DD — blocker: reason

Pass when every unresolved item is a structured decision with options and recommended default.
Fail when any scenario lacks a spec ref, uses prose-only expected outcomes, says only
```
Manual review
```
, contains
```
TODO
```
, or leaves layer mapping as descriptive text instead of execution order.

使用以下格式：

text

范围:
- 范围内:
  - 涵盖的行为、契约、端点、工作流或产物。
- 范围外:
  - 故意排除的行为、契约、端点、工作流或产物。

场景矩阵:
| ID | 需求引用 | 场景 | 前置条件 | 触发操作 | 可验证结果 | 层级 | 自动化方式 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| TC-001 | AC-001、用户故事ID、工作流、风险或产物章节 | 场景名称 | 固定数据/状态 | 操作 | 命令、检查清单或前后对比对 | unit/service/transport/integration/QA/manual | 脚本路径+调用方式、CI步骤或手动障碍 |

自动化计划:
- TC-001: 精确命令或CI步骤，若为新测试则目标文件，预期通过条件。

执行顺序:
1. 层级：运行条件；阻塞：后续层级或发布关卡；失败操作：停止、修复、重跑或升级。

需决策:
- 问题：需做出的决策。
  选项:
  A. 选项A
  B. 选项B
  C. 选项C
  推荐默认值：选项及理由。
  负责人：角色或人员。
  是否阻塞：是 | 否。

质量关卡:

通过条件：每个场景都符合范围、有需求引用、前置条件、触发操作、可验证结果、层级、具体自动化路径和执行顺序位置。

通过条件：每个手动场景都使用

Manual — automate by YYYY-MM-DD — blocker: reason

格式。

通过条件：每个未解决项都是带有选项和推荐默认值的结构化决策。
失败条件：任何场景缺少规格引用、仅使用描述性预期结果、仅标注
```
Manual review
```
、包含
```
TODO
```
或层级映射为描述性文本而非执行顺序。

Examples

示例

Valid executable scenario:

text

Scenario matrix:
| ID | Requirement ref | Scenario | Setup | Trigger | Verifiable outcome | Layer | Automation |
| --- | --- | --- | --- | --- | --- | --- | --- |
| TC-003 | AC-003 | Reject unsupported provider asset | BitGo wallet fixture contains BTC only | Submit a USDC transfer request | `GOCACHE=/tmp/ai-sdlc-go-cache go test ./internal/service -run TestRejectUnsupportedProviderAsset -count=1` exits 0 and asserts no transfer row is created | service | `skills/ai-sdlc-validation/scripts/validation_plan.py internal/service/transfer_service.go`; implement `TestRejectUnsupportedProviderAsset` |

Execution order:
1. Service tests: run after scenario matrix is approved; blocks transport tests; failure action: fix service validation and rerun focused service test.

Decisions required:
- Question: Should unsupported provider assets return 400 validation error or 409 conflict?
  Options:
  A. 400 validation error
  B. 409 conflict
  C. Provider-specific 502
  Recommended default: A, because the request is invalid before provider submission.
  Owner: Delivery Manager
  Blocking: yes

Invalid counter-example:

text

| TC-003 |  | Test bad inputs | Existing tests | Run tests | Service rejects bad data | service | Manual review |

Reject this because it has no spec ref, the outcome is prose-only, and

Manual review

has no blocker or automation date.

有效的可执行场景:

text

场景矩阵:
| ID | 需求引用 | 场景 | 前置条件 | 触发操作 | 可验证结果 | 层级 | 自动化方式 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| TC-003 | AC-003 | 拒绝不支持的提供者资产 | BitGo钱包固定数据仅包含BTC | 提交USDC转账请求 | `GOCACHE=/tmp/ai-sdlc-go-cache go test ./internal/service -run TestRejectUnsupportedProviderAsset -count=1`退出码为0且断言未创建转账记录 | service | `skills/ai-sdlc-validation/scripts/validation_plan.py internal/service/transfer_service.go`；实现`TestRejectUnsupportedProviderAsset` |

执行顺序:
1. 服务测试：场景矩阵获批后运行；阻塞传输测试；失败操作：修复服务验证并重跑针对性服务测试。

需决策:
- 问题：不支持的提供者资产应返回400验证错误还是409冲突？
  选项:
  A. 400验证错误
  B. 409冲突
  C. 提供者特定502错误
  推荐默认值：A，因为请求在提交给提供者前已无效。
  负责人：交付经理
  是否阻塞：是

无效反例:

text

| TC-003 |  | 测试不良输入 | 现有测试 | 运行测试 | 服务拒绝不良数据 | service | Manual review |

拒绝该场景的原因：无规格引用、结果仅为描述性文本、

Manual review

无障碍或自动化日期。

Edge Cases

边缘情况

Mark expected behavior as a structured decision when the spec is silent and code behavior is inconsistent.
Prefer lower-layer tests when they prove the behavior without full integration setup.
Use integration tests only when provider adapters, HTTP contracts, migrations, or cross-package behavior must be exercised together.
Mark flaky or external-service-dependent scenarios as manual only with
```
Manual — automate by YYYY-MM-DD — blocker: reason
```
.
Do not invent provider responses; use documented fixtures, existing mocks, or a structured decision with a recommended default.
Do not output
```
TODO
```
,
```
TBD
```
,
```
manual review
```
, or
```
needs confirmation
```
as a final gap.

当规格未明确且代码行为不一致时，将预期行为标记为结构化决策。
优先使用低层测试，无需完整集成设置即可验证行为。
仅当必须一起验证提供者适配器、HTTP契约、迁移或跨包行为时，才使用集成测试。
将不稳定或依赖外部服务的场景标记为手动测试，格式为
```
Manual — automate by YYYY-MM-DD — blocker: reason
```
。
不得编造提供者响应；使用已记录的固定数据、现有模拟对象或带有推荐默认值的结构化决策。
不得输出
```
TODO
```
、
```
TBD
```
、
```
manual review
```
或
```
needs confirmation
```
作为最终差距。

Scope Boundary

范围边界

Do not claim QA signoff; use
```
$ai-sdlc-qa
```
.
Do not choose final validation command execution; use
```
$ai-sdlc-validation
```
.
Do not implement production behavior from this skill alone; use
```
$ai-sdlc-sdd
```
and approved
```
tasks.md
```
.
Do not add broad snapshot tests when focused assertions can prove the behavior.

不得声称QA签字确认；使用
```
$ai-sdlc-qa
```
。
不得选择最终验证命令执行；使用
```
$ai-sdlc-validation
```
。
不得仅通过该技能实施生产行为；使用
```
$ai-sdlc-sdd
```
和已批准的
```
tasks.md
```
。
当针对性断言可验证行为时，不得添加宽泛的快照测试。