story-readiness

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Story Readiness

故事就绪性检查

This skill validates that a story file contains everything a developer needs to begin implementation — no mid-sprint design interruptions, no guessing, no ambiguous acceptance criteria. Run it before assigning a story.

This skill is read-only. It never edits story files. It reports findings and asks whether the user wants help filling gaps.

Output: Verdict per story (READY / NEEDS WORK / BLOCKED) with a specific gap list for each non-ready story.

本技能用于验证故事文件是否包含开发者开始实现所需的全部内容——避免 sprint 中期的设计中断、猜测工作内容或模糊的验收标准。在分配故事前运行此技能。

本技能为只读模式。 它绝不会编辑故事文件，仅会报告检查结果，并询问用户是否需要帮助填补缺失内容。

输出结果： 每个故事的判定结果（READY / NEEDS WORK / BLOCKED），以及每个未就绪故事的具体问题清单。

Phase 0: Resolve Review Mode

阶段0：确定评审模式

Resolve the review mode once at startup (store for all gate spawns this run):

If skill was called with
```
--review [full|lean|solo]
```
→ use that value
Else read
```
production/review-mode.txt
```
→ use that value
Else → default to
```
lean
```

See

.claude/docs/director-gates.md

for the full check pattern and mode definitions.

在启动时一次性确定评审模式（本次运行的所有 gate 实例均使用该模式）：

如果调用技能时携带参数
```
--review [full|lean|solo]
```
→ 使用该参数值
否则读取
```
production/review-mode.txt
```
文件 → 使用文件中的值
若以上都不满足 → 默认使用
```
lean
```
模式

查看

.claude/docs/director-gates.md

获取完整检查模式及模式定义。

1. Parse Arguments

1. 解析参数

Scope:

$ARGUMENTS[0]

(blank = ask user via AskUserQuestion)

Specific path (e.g.,

/story-readiness production/epics/combat/story-001-basic-attack.md

): validate that single story file.

sprint
: read the current sprint plan from
```
production/sprints/
```
(most recent file), extract every story path it references, validate each one.
all
: glob
```
production/epics/**/*.md
```
, exclude
```
EPIC.md
```
index files, validate every story file found.
No argument: ask the user which scope to validate.

If no argument is given, use

AskUserQuestion

"What would you like to validate?"
- Options: "A specific story file", "All stories in the current sprint", "All stories in production/epics/", "Stories for a specific epic"

Report the scope before proceeding: "Validating [N] story files."

范围：

$ARGUMENTS[0]

（为空时通过 AskUserQuestion 询问用户）

指定路径（例如：

/story-readiness production/epics/combat/story-001-basic-attack.md

）：验证单个故事文件。

sprint
：从
```
production/sprints/
```
读取当前 sprint 计划（最新文件），提取其中引用的所有故事路径并逐一验证。
all
：匹配
```
production/epics/**/*.md
```
文件，排除
```
EPIC.md
```
索引文件，验证所有找到的故事文件。
无参数：询问用户要验证的范围。

若未提供参数，使用

AskUserQuestion

：

"您想要验证什么内容？"
- 选项："单个指定故事文件"、"当前 sprint 中的所有故事"、"production/epics/ 下的所有故事"、"指定 epic 下的故事"

在开始检查前报告范围："正在验证 [N] 个故事文件。"

2. Load Supporting Context

2. 加载支持上下文

Before checking any stories, load reference documents once (not per-story):

```
design/gdd/systems-index.md
```
— to know which systems have approved GDDs
```
docs/architecture/control-manifest.md
```
— to know which manifest rules exist (if the file does not exist, note it as missing once; do not re-flag per story) Also extract the
```
Manifest Version:
```
date from the header block if the file exists.
```
docs/architecture/tr-registry.yaml
```
— index all entries by
```
id
```
. Used to validate TR-IDs in stories. If the file does not exist, note it once; TR-ID checks will auto-pass for all stories (registry predates stories, so missing registry means stories are from before TR tracking was introduced).
All ADR status fields — for each unique ADR referenced across the stories being checked, read the ADR file and note its
```
Status:
```
field. Cache these so you don't re-read the same ADR for every story.
The current sprint file (if scope is
```
sprint
```
) — to identify Must Have / Should Have priority for escalation decisions

在检查任何故事之前，一次性加载参考文档（无需每个故事重复加载）：

```
design/gdd/systems-index.md
```
—— 了解哪些系统已获得批准的 GDD
```
docs/architecture/control-manifest.md
```
—— 了解存在哪些 manifest 规则（若文件不存在，仅记录一次缺失，无需每个故事重复标记）若文件存在，从头部区块提取
```
Manifest Version:
```
日期。
```
docs/architecture/tr-registry.yaml
```
—— 按
```
id
```
索引所有条目，用于验证故事中的 TR-ID。若文件不存在，仅记录一次；所有故事的 TR-ID 检查将自动通过（注册表早于故事存在，缺失注册表意味着故事是在 TR 跟踪机制引入前创建的）。
所有 ADR 的状态字段 —— 对于本次检查的故事中引用的每个唯一 ADR，读取 ADR 文件并记录其
```
Status:
```
字段。缓存这些状态，避免每个故事重复读取同一 ADR。
当前 sprint 文件（若范围为
```
sprint
```
）—— 识别 Must Have / Should Have 优先级，用于决策是否升级问题。

3. Story Readiness Checklist

3. 故事就绪性检查清单

For each story file, evaluate every item below. A story is READY only if all items pass or are explicitly marked N/A with a stated reason.

对于每个故事文件，评估以下所有项。只有当所有项通过或被明确标记为 N/A 并说明理由时，故事才会被判定为 READY。

Design Completeness

设计完整性

GDD requirement referenced: The story includes a
```
design/gdd/
```
path and quotes or links a specific requirement, acceptance criterion, or rule from that GDD — not just the GDD filename. A link to the document without tracing to a specific requirement does not pass.
Requirement is self-contained: The acceptance criteria in the story are understandable without opening the GDD. A developer should not need to read a separate document to understand what DONE means.
Acceptance criteria are testable: Each criterion is a specific, observable condition — not "implement X" or "the system works correctly". Bad example: "Implement the jump mechanic." Good example: "Jump reaches max height of 5 units within 0.3 seconds when jump is held."
No acceptance criteria require judgment calls (auto-pass for
Type: Visual/Feel
): Criteria like "feels responsive" or "looks good" are not testable without a defined benchmark. For Logic, Integration, UI, and Config/Data stories, these must be replaced with specific observable conditions. For Visual/Feel stories, subjective criteria are expected and this check auto-passes — instead verify that each subjective criterion has a paired playtest protocol or evidence requirement (e.g., "evidence doc required at
```
production/qa/evidence/[slug]-evidence.md
```
"). PASS if the acceptance criterion ends with or is accompanied by an explicit reference to a file path such as
```
production/qa/evidence/[slug]-evidence.md
```
. NEEDS WORK if the criterion is purely subjective with no evidence file path specified.

引用GDD需求：故事包含
```
design/gdd/
```
路径，并引用该 GDD 中的特定需求、验收标准或规则——而不仅仅是 GDD 文件名。仅链接文档但未指向具体需求不视为通过。
需求自包含：故事中的验收标准无需打开 GDD 即可理解。开发者无需阅读单独文档即可明确“完成”的定义。
验收标准可测试：每个标准都是具体、可观察的条件——而非“实现X”或“系统正常工作”。反例：“实现跳跃机制。” 正例：“按住跳跃键时，角色在0.3秒内达到5单位的最大跳跃高度。”
验收标准无需主观判断（
```
Type: Visual/Feel
```
类型自动通过）：诸如“感觉响应迅速”或“看起来不错”的标准在没有定义基准的情况下无法测试。对于 Logic、Integration、UI 和 Config/Data 类型的故事，这些标准必须替换为具体可观察的条件。对于 Visual/Feel 类型的故事，允许主观标准，但需验证每个主观标准都配有对应的 playtest 协议或证据要求（例如：“需在
```
production/qa/evidence/[slug]-evidence.md
```
提供证据文档”）。若验收标准末尾或附带明确的文件路径引用（如
```
production/qa/evidence/[slug]-evidence.md
```
）则通过；若标准纯主观且未指定证据文件路径则标记为 NEEDS WORK。

Architecture Completeness

架构完整性

ADR referenced or N/A stated: The story references at least one ADR, OR explicitly states "No ADR applies" with a brief reason. A story with no ADR reference and no explicit N/A note fails this check.
ADR is Accepted (not Proposed): For each referenced ADR, check its
```
Status:
```
field using the cached ADR statuses loaded in Section 2.
- If
```
Status: Accepted
```
  → pass.
- If
```
Status: Proposed
```
  → BLOCKED: the ADR may change before it is accepted, and the story's implementation guidance could be wrong. Fix:
```
BLOCKED: ADR-NNNN is Proposed — wait for acceptance before implementing.
```
- If the ADR file does not exist → BLOCKED: referenced ADR is missing.
- Auto-pass if story has an explicit "No ADR applies" N/A note.
TR-ID is valid and active: If the story contains a
```
TR-[system]-NNN
```
reference, look it up in the TR registry loaded in Section 2.
- If the ID exists and
```
status: active
```
  → pass.
- If the ID exists and
```
status: deprecated
```
  or
```
status: superseded-by: ...
```
  → NEEDS WORK: the requirement was removed or replaced. Fix: update the story to reference the current requirement ID or remove if no longer applicable.
- If the ID does not exist in the registry → NEEDS WORK: ID was not registered (story may predate registry, or registry needs an
```
/architecture-review
```
  run).
- Auto-pass if the story has no TR-ID reference OR if the registry does not exist.
Manifest version is current: If the story has a
```
Manifest Version:
```
date in its header AND
```
docs/architecture/control-manifest.md
```
exists:
- If story version matches current manifest
```
Manifest Version:
```
  → pass.
- If story version is older than current manifest → NEEDS WORK: new rules may apply. Fix: review changed manifest rules, update story if any forbidden/required entries changed, then update the story's
```
Manifest Version:
```
  to current.
- Auto-pass if either the story has no
```
Manifest Version:
```
  field OR the manifest does not exist.
Engine notes present: For any post-cutoff engine API this story is likely to touch, implementation notes or a verification requirement are included. If the story clearly does not touch engine APIs (e.g., it is a pure data/config change), "N/A — no engine API involved" is acceptable.
Control manifest rules noted: Relevant layer rules from the control manifest are referenced, OR "N/A — manifest not yet created" is stated. This item auto-passes if
```
docs/architecture/control-manifest.md
```
does not exist yet (do not penalize stories written before the manifest was created).

引用ADR或声明N/A：故事至少引用一个 ADR，或明确声明“无适用ADR”并给出简要理由。未引用ADR且未明确标记N/A的故事将不通过此检查。
ADR已被接受（非提议状态）：使用阶段2加载的缓存ADR状态，检查每个引用ADR的
```
Status:
```
字段。
- 若
```
Status: Accepted
```
  → 通过。
- 若
```
Status: Proposed
```
  → BLOCKED：ADR在被接受前可能会变更，故事的实现指导可能不准确。修复方案：
```
BLOCKED: ADR-NNNN 处于提议状态 —— 需等待接受后再开始实现。
```
- 若ADR文件不存在 → BLOCKED：引用的ADR缺失。
- 若故事明确声明“无适用ADR”则自动通过。
TR-ID有效且活跃：若故事包含
```
TR-[system]-NNN
```
引用，在阶段2加载的TR注册表中查找该ID。
- 若ID存在且
```
status: active
```
  → 通过。
- 若ID存在且
```
status: deprecated
```
  或
```
status: superseded-by: ...
```
  → NEEDS WORK：该需求已被移除或替换。修复方案：更新故事以引用当前需求ID，或在不再适用时移除引用。
- 若ID未在注册表中找到 → NEEDS WORK：ID未注册（故事可能早于注册表创建，或需要运行
```
/architecture-review
```
  更新注册表）。
- 若故事无TR-ID引用或注册表不存在则自动通过。
Manifest版本为当前版本：若故事头部包含
```
Manifest Version:
```
日期且
```
docs/architecture/control-manifest.md
```
存在：
- 若故事版本与当前manifest的
```
Manifest Version:
```
  匹配 → 通过。
- 若故事版本早于当前manifest → NEEDS WORK：可能已应用新规则。修复方案：审查manifest变更的规则，若有禁止/必填条目变更则更新故事，然后将故事的
```
Manifest Version:
```
  更新为当前版本。
- 若故事无
```
Manifest Version:
```
  字段或manifest不存在则自动通过。
包含引擎说明：对于故事可能涉及的任何 cutoff 后引擎API，需包含实现说明或验证要求。若故事明确不涉及引擎API（例如纯数据/配置变更），声明“N/A — 不涉及引擎API”即可。
记录控制manifest规则：引用控制manifest中的相关层规则，或声明“N/A — manifest尚未创建”。若
```
docs/architecture/control-manifest.md
```
尚未创建，此项自动通过（不因manifest创建前编写的故事而扣分）。

Scope Clarity

范围清晰度

Estimate present: The story includes a size estimate (hours, points, or a t-shirt size). A story with no estimate cannot be planned.
In-scope / Out-of-scope boundary stated: The story states what it does NOT include, either in an explicit Out of Scope section or in language that makes the boundary unambiguous. Without this, scope creep during implementation is likely.
Story dependencies listed: If this story depends on other stories being DONE first, those story IDs are listed. If there are no dependencies, "None" is explicitly stated (not just omitted).

包含估算：故事包含规模估算（小时、点数或T恤尺码）。无估算的故事无法进行规划。
明确界定范围边界：故事说明其不包含的内容，可通过显式的“Out of Scope”部分或明确的表述来界定。若无此项，实现过程中可能出现范围蔓延。
列出故事依赖：若本故事依赖其他故事完成，需列出这些故事的ID。若无依赖，需明确声明“无”（不能仅省略）。

Open Questions

未解决问题

No unresolved design questions: The story does not contain text flagged as "UNRESOLVED", "TBD", "TODO", "?", or equivalent markers in any acceptance criterion, implementation note, or rule statement.
Dependency stories are not in DRAFT: For each story listed as a dependency, check if the file exists and does not have a DRAFT status. A story that depends on a DRAFT or missing story is BLOCKED, not just NEEDS WORK.

无未解决设计问题：故事的验收标准、实现说明或规则声明中不存在标记为“UNRESOLVED”、“TBD”、“TODO”、“?”或类似含义的文本。
依赖故事非草稿状态：对于每个列出的依赖故事，检查文件是否存在且未处于DRAFT状态。依赖于草稿或缺失故事的故事将被标记为BLOCKED，而非仅NEEDS WORK。

Asset References Check

资产引用检查

Referenced assets exist: Scan the story text for asset path patterns (paths containing
```
assets/
```
, or file extensions
```
.png
```
,
```
.jpg
```
,
```
.svg
```
,
```
.wav
```
,
```
.ogg
```
,
```
.mp3
```
,
```
.glb
```
,
```
.gltf
```
,
```
.tres
```
,
```
.tscn
```
,
```
.res
```
).
- For each asset path found: use Glob to check whether the file exists.
- If any referenced asset does not exist: NEEDS WORK — note the missing path(s). (The story references assets that have not been created yet. Either remove the reference, create a placeholder, or mark it as an explicit dependency on an asset creation story.)
- If all referenced assets exist: note "Referenced assets verified: [count] found."
- If no asset paths are referenced in the story: note "No asset references found in story — skipping asset check." This item auto-passes.
- This is an existence-only check. Do not validate file format or content.

引用的资产存在：扫描故事文本中的资产路径模式（包含
```
assets/
```
的路径，或文件扩展名
```
.png
```
,
```
.jpg
```
,
```
.svg
```
,
```
.wav
```
,
```
.ogg
```
,
```
.mp3
```
,
```
.glb
```
,
```
.gltf
```
,
```
.tres
```
,
```
.tscn
```
,
```
.res
```
）。
- 对于每个找到的资产路径：使用Glob检查文件是否存在。
- 若任何引用的资产不存在：NEEDS WORK —— 记录缺失的路径。（故事引用了尚未创建的资产。需移除引用、创建占位符，或明确标记为依赖于资产创建故事。）
- 若所有引用资产均存在：记录“已验证引用资产：共找到[count]个。”
- 若故事中无资产路径引用：记录“故事中未找到资产引用 —— 跳过资产检查。”此项自动通过。
- 此检查仅验证存在性，不验证文件格式或内容。

Definition of Done

完成定义

Minimum testable acceptance criteria by story type:
- Logic / Integration stories: at least 3
- Visual/Feel and UI stories: at least 2
- Config/Data stories: at least 1 Apply the threshold matching the story's
```
Type:
```
  field. If the story has fewer than the minimum, mark as NEEDS WORK.
Performance budget noted if applicable: If this story touches any part of the gameplay loop, rendering, or physics, a performance budget or a "no performance impact expected — [reason]" note is present.
Story Type declared: The story includes a
```
Type:
```
field in its header identifying the test category (Logic / Integration / Visual/Feel / UI / Config/Data). Without this, test evidence requirements cannot be enforced at story close. Fix: Add
```
Type: [Logic|Integration|Visual/Feel|UI|Config/Data]
```
to the story header.
Test evidence requirement is clear: If the Story Type is set, the story includes a
```
## Test Evidence
```
section stating where evidence will be stored (test file path for Logic/Integration, or evidence doc path for Visual/Feel/UI). Fix: Add
```
## Test Evidence
```
with the expected evidence location for the story's type.

按故事类型满足最低可测试验收标准数量：
- Logic / Integration 故事：至少3条
- Visual/Feel 和 UI 故事：至少2条
- Config/Data 故事：至少1条根据故事的
```
Type:
```
  字段应用对应阈值。若故事数量低于最小值，标记为NEEDS WORK。
适用时记录性能预算：若故事涉及游戏循环、渲染或物理部分，需包含性能预算或“预期无性能影响 —— [理由]”说明。
声明故事类型：故事头部包含
```
Type:
```
字段，标识测试类别（Logic / Integration / Visual/Feel / UI / Config/Data）。若无此项，故事收尾时无法强制执行测试证据要求。修复方案：在故事头部添加
```
Type: [Logic|Integration|Visual/Feel|UI|Config/Data]
```
。
测试证据要求明确：若已设置故事类型，故事需包含
```
## Test Evidence
```
部分，说明证据存储位置（Logic/Integration类型为测试文件路径，Visual/Feel/UI类型为证据文档路径）。修复方案：添加
```
## Test Evidence
```
部分，并根据故事类型指定预期的证据位置。

4. Verdict Assignment

4. 判定结果分配

Assign one of three verdicts per story:

READY — All checklist items pass or have explicit N/A justifications. The story can be assigned immediately.

NEEDS WORK — One or more checklist items fail, but all dependency stories exist and are not DRAFT. The story can be fixed before assignment.

BLOCKED — One or more dependency stories are missing or in DRAFT state, OR a critical design question (flagged UNRESOLVED in a criterion or rule) has no owner. The story cannot be assigned until the blocker is resolved. Note: a story that is BLOCKED may also have NEEDS WORK items — list both.

为每个故事分配以下三种判定结果之一：

READY —— 所有检查项通过或有明确的N/A理由。故事可立即分配。

NEEDS WORK —— 一个或多个检查项未通过，但所有依赖故事均存在且非草稿状态。故事可在修复后分配。

BLOCKED —— 一个或多个依赖故事缺失或处于草稿状态，或存在无负责人的关键设计问题（标准或规则中标记为UNRESOLVED）。在阻塞问题解决前，故事无法分配。注意：被标记为BLOCKED的故事可能同时存在NEEDS WORK项——需同时列出两者。

5. Output Format

5. 输出格式

Single story output

单个故事输出

undefined

undefined

Story Readiness: [story title]

故事就绪性：[故事标题]

File: [path] Verdict: [READY / NEEDS WORK / BLOCKED]

文件：[路径] 判定结果：[READY / NEEDS WORK / BLOCKED]

Passing Checks (N/[total])

通过的检查项 (N/[总数])

[list passing items briefly]

[简要列出通过项]

Gaps

问题点

[Checklist item]: [exact description of what is missing or wrong] Fix: [specific text needed to resolve this gap]

修复方案: [解决此问题所需的具体文本]

Blockers (if BLOCKED)

阻塞原因（若为BLOCKED）

[What is blocking]: [story ID or design question that must resolve first]

undefined

undefined

Multiple story aggregate output

多个故事汇总输出

undefined

undefined

Story Readiness Summary — [scope] — [date]

故事就绪性总结 —— [范围] —— [日期]

Ready: [N] stories Needs Work: [N] stories Blocked: [N] stories

就绪: [N] 个故事需完善: [N] 个故事阻塞: [N] 个故事

Ready Stories

就绪故事

[story title] ([path])

[故事标题] ([路径])

Needs Work

需完善故事

[story title]: [primary gap — one line]
[story title]: [primary gap — one line]

[故事标题]: [主要问题点 —— 一行描述]
[故事标题]: [主要问题点 —— 一行描述]

Blocked Stories

阻塞故事

[story title]: Blocked by [story ID / design question]

[Full detail for each non-ready story follows, using the single-story format]

undefined

[故事标题]: 被 [故事ID / 设计问题] 阻塞

[以下为每个未就绪故事的详细内容，采用单个故事输出格式]

undefined

Sprint escalation

Sprint 问题升级

If the scope is

sprint

and any Must Have stories are NEEDS WORK or BLOCKED, add a prominent warning at the top of the output:

WARNING: [N] Must Have stories are not implementation-ready.
[List them with their primary gap or blocker.]
Resolve these before the sprint begins or replan with `/sprint-plan update`.

若范围为

sprint

且存在任何Must Have故事处于NEEDS WORK或BLOCKED状态，在输出顶部添加醒目的警告：

警告: [N] 个Must Have故事未准备好开发实现。
[列出这些故事及其主要问题点或阻塞原因。]
请在sprint开始前解决这些问题，或通过 `/sprint-plan update` 重新规划。

6. Collaborative Protocol

6. 协作协议

This skill is read-only. It never proposes edits or asks to write files.

After reporting findings, offer:

"Would you like help filling in the gaps for any of these stories? I can draft the missing sections for your approval."

If the user says yes for a specific story, draft only the missing sections in conversation. Do not use Write or Edit tools — the user (or

/create-stories

) handles writing.

Redirect rules:

If a story file does not exist at all: "This story file is missing entirely. Run
```
/create-epics [layer]
```
then
```
/create-stories [epic-slug]
```
to generate stories from the GDD and ADR."
If a story has no GDD reference and the work appears small: "This story has no GDD reference. If the change is small (under ~4 hours), run
```
/quick-design [description]
```
to create a Quick Design Spec, then reference that spec in the story."
If a story's scope has grown beyond its original sizing: "This story appears to have expanded in scope. Consider splitting it or escalating to the producer before implementation begins."

本技能为只读模式，绝不会提议编辑或请求写入文件。

报告检查结果后，提供以下选项：

“您需要帮助填补这些故事的问题点吗？我可以为您草拟缺失的内容，供您审批。”

若用户同意为特定故事提供帮助，仅在对话中草拟缺失部分。请勿使用Write或Edit工具——由用户（或

/create-stories

）负责写入。

重定向规则：

若故事文件完全不存在：“此故事文件缺失。请运行
```
/create-epics [layer]
```
然后
```
/create-stories [epic-slug]
```
，从GDD和ADR生成故事。”
若故事无GDD引用且工作量较小：“此故事无GDD引用。若变更工作量较小（约4小时以内），请运行
```
/quick-design [描述]
```
创建快速设计规范，然后在故事中引用该规范。”
若故事范围超出原始估算：“此故事的范围似乎已扩大。在开始实现前，考虑拆分故事或向负责人升级问题。”

7. Next-Story Handoff

7. 后续故事交接

After completing a single-story readiness check (not

all

sprint

scope):

Read the current sprint file from
```
production/sprints/
```
(most recent).
Find stories that are:
- Status: READY or NOT STARTED
- Not the story just checked
- Not blocked by incomplete dependencies
- In the Must Have or Should Have tier

If any are found, surface up to 3:

undefined

完成单个故事就绪性检查后（非

all

或

sprint

范围）：

从
```
production/sprints/
```
读取当前sprint文件（最新版本）。
查找符合以下条件的故事：
- 状态：READY或NOT STARTED
- 不是刚刚检查的故事
- 未被未完成的依赖阻塞
- 属于Must Have或Should Have层级

若找到符合条件的故事，最多展示3个：

undefined

本Sprint中的其他就绪故事

[Story name] — [1-line description] — Est: [X hrs]
[Story name] — [1-line description] — Est: [X hrs]

Run

/story-readiness [path]

to validate before starting.


If no sprint file exists or no other ready stories are found, skip this section silently.

---

[故事名称] —— [一行描述] —— 估算: [X 小时]
[故事名称] —— [一行描述] —— 估算: [X 小时]

运行

/story-readiness [路径]

在开始前进行验证。


若sprint文件不存在或未找到其他就绪故事，静默跳过此部分。

---

Phase 8: Director Gate — Story Readiness Review

阶段8：负责人关卡 —— 故事就绪性评审

Apply the review mode resolved in Phase 0 before spawning QL-STORY-READY:

```
solo
```
→ skip. Note: "QL-STORY-READY skipped — Solo mode." Proceed to close.
```
lean
```
→ skip. Note: "QL-STORY-READY skipped — Lean mode." Proceed to close.
```
full
```
→ spawn as normal.

Spawn

qa-lead

via Task using gate QL-STORY-READY (

.claude/docs/director-gates.md

Pass the following context:

Story title
Acceptance criteria list (all items from the story's acceptance criteria section)
Dependency status (all dependencies listed and their current state: exist / DRAFT / missing)
Overall verdict (READY / NEEDS WORK / BLOCKED) from Phase 4

Handle the verdict per standard rules in

director-gates.md

ADEQUATE → story is cleared. Proceed to close.

GAPS [list] → surface the specific gaps to the user via

AskUserQuestion

: options:

Update story with suggested gaps

Accept and proceed anyway

Discuss further

INADEQUATE → surface the specific gaps; ask user whether to update the story or proceed anyway.

在生成QL-STORY-READY前，应用阶段0确定的评审模式：

```
solo
```
→ 跳过。记录：“QL-STORY-READY已跳过 —— 单人模式。” 继续关闭流程。
```
lean
```
→ 跳过。记录：“QL-STORY-READY已跳过 —— 精简模式。” 继续关闭流程。
```
full
```
→ 正常生成。

通过Task生成

qa-lead

，使用关卡QL-STORY-READY（

.claude/docs/director-gates.md

）。

传递以下上下文：

故事标题
验收标准列表（故事验收标准部分的所有项）
依赖状态（列出的所有依赖及其当前状态：存在/草稿/缺失）
阶段4得出的整体判定结果（READY / NEEDS WORK / BLOCKED）

根据

director-gates.md

中的标准规则处理判定结果：

ADEQUATE → 故事已通过审核。继续关闭流程。

GAPS [清单] → 通过

AskUserQuestion

向用户展示具体问题点：选项：

使用建议的问题点更新故事

接受现状并继续

进一步讨论

。

INADEQUATE → 展示具体问题点；询问用户是更新故事还是继续推进。