design-readiness-check

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Design Readiness Check

设计就绪检查

Overview

概述

This skill is the quality gate between design work and implementation planning.

Its job is to answer one question clearly: is the current design complete enough to move into

writing-plans

It is not a replacement for

design-decision-audit

. That skill audits standalone design or plan documents. This skill checks the readiness of an in-progress design workflow before planning.

此skill是设计工作与实施规划之间的质量关卡。

它的职责是清晰回答一个问题：当前设计是否足够完备，可以进入

writing-plans

阶段？

它不能替代

design-decision-audit

。该skill用于审核独立的设计或规划文档，而本skill则是在规划前检查进行中设计工作流的就绪状态。

When to Use

使用场景

Use this skill when:

the design looks mostly complete
the next possible step is
```
writing-plans
```
the user asks whether the design is ready to implement
the remaining concern is completeness, not discovery

Do not use this skill when:

the design tree is still missing
major branches remain vague
core decisions are still unresolved
the user is asking for a general audit of an external design document
```
design_target_type
```
is missing from the design state

在以下场景中使用本skill：

设计看起来基本完成
下一步可能是
```
writing-plans
```
用户询问设计是否已准备好实施
剩余关注点是完备性，而非探索

在以下场景中请勿使用本skill：

设计树仍缺失
主要分支仍模糊不清
核心决策仍未解决
用户要求对外部设计文档进行通用审核
设计状态中缺少
```
design_target_type
```

Workflow

工作流程

Phase A: Context Preparation

A阶段：上下文准备

Goal: Load design state and assemble context for parallel checks.

Load the current
```
design_state
```
from the conversation context.
Read the design tree content and all related context (open branches, decision nodes, risks, validation state).
If
```
design_state
```
does not exist or the design tree is empty, return NOT READY immediately with a handoff to
```
design-structure
```
.
If
```
design_target_type
```
is missing, return NOT READY immediately with a blocking issue for missing required state.
Assemble a context package containing: design tree text, open branches, decision nodes, existing risks, validation entries, and
```
design_target_type
```
.
Perform a lightweight structural integrity check using the shared rules in
```
../design-tree-core/REFERENCE.md
```
:
- mixed responsibilities inside one tree
- parent/child ownership confusion
- duplicated parent/child logic on the same branch
- branches that likely should have been derived but were kept inline

目标：加载设计状态并组装上下文以进行并行检查。

从对话上下文中加载当前的
```
design_state
```
。
读取设计树内容及所有相关上下文（未闭合分支、决策节点、风险、验证状态）。
如果
```
design_state
```
不存在或设计树为空，立即返回NOT READY，并转交至
```
design-structure
```
。
如果缺少
```
design_target_type
```
，立即返回NOT READY，并标记缺失必要状态的阻塞问题。
组装上下文包，包含：设计树文本、未闭合分支、决策节点、已存在的风险、验证条目以及
```
design_target_type
```
。
使用
```
../design-tree-core/REFERENCE.md
```
中的共享规则执行轻量级结构完整性检查：
- 单个树中混合了不同职责
- 父/子所有权混淆
- 同一分支上存在重复的父/子逻辑
- 本应派生但仍内联保留的分支

Phase B: Parallel Readiness Checks

B阶段：并行就绪检查

Goal: Run four independent checks in parallel using specialized subagents.

Launch four parallel Sonnet subagents, each using one of the checker agent templates:

branch-checker: reads

skills/design-readiness-check/agents/branch-checker.md

. Fill

{{DESIGN_TREE}}

and

{{CONTEXT}}

assumption-checker: reads

skills/design-readiness-check/agents/assumption-checker.md

. Fill

{{DESIGN_TREE}}

and

{{CONTEXT}}

failure-checker: reads

skills/design-readiness-check/agents/failure-checker.md

. Fill

{{DESIGN_TREE}}

and

{{CONTEXT}}

risk-checker: reads

skills/design-readiness-check/agents/risk-checker.md

. Fill

{{DESIGN_TREE}}

and

{{CONTEXT}}

Collect results from all four subagents.

Fallback: If any subagent fails or times out, the main agent performs that check inline using the same rubric from the agent template.

目标：使用专用子agent并行运行四项独立检查。

启动四个并行的Sonnet子agent，每个子agent使用一个检查器agent模板：

branch-checker：读取

skills/design-readiness-check/agents/branch-checker.md

，填充

{{DESIGN_TREE}}

和

{{CONTEXT}}

。

assumption-checker：读取

skills/design-readiness-check/agents/assumption-checker.md

，填充

{{DESIGN_TREE}}

和

{{CONTEXT}}

。

failure-checker：读取

skills/design-readiness-check/agents/failure-checker.md

，填充

{{DESIGN_TREE}}

和

{{CONTEXT}}

。

risk-checker：读取

skills/design-readiness-check/agents/risk-checker.md

，填充

{{DESIGN_TREE}}

和

{{CONTEXT}}

。

收集所有四个子agent的结果。

回退方案：如果任何子agent失败或超时，主agent将使用agent模板中的相同标准内联执行该检查。

Phase C: Verdict Synthesis

C阶段：结论综合

Goal: Combine check results into a clear readiness judgment.

Map each subagent's
```
status
```
to a pass/fail entry in the readiness checklist:
- required-state check → "Design target type present"
- branch-checker → "Design tree present" and "Key branches refined"
- assumption-checker → "Decisions resolved" (if assumptions are unresolved)
- failure-checker → "Failure paths documented" and "Validation strategy defined"
- risk-checker → "Blocking risks mitigated"
- structural integrity check → "Structural integrity preserved"
Build the ✓/✗ checklist diagram following Diagram Conventions.
Determine verdict:

READY: required state is present, all four checks return
```
pass
```
, and no structural integrity issue is blocking
NOT READY: required state is missing, any check returns
```
fail
```
, or structural integrity issues are blocking

If NOT READY, determine the handoff target based on which check failed:
- required-state fails → hand off to
```
design-structure
```
- branch-checker fails → hand off to
```
design-structure
```
  (branches missing) or
```
design-refinement
```
  (branches weak)
- assumption-checker fails → hand off to
```
design-refinement
```
  (assumptions need expansion)
- failure-checker fails → hand off to
```
design-refinement
```
  (failure paths need adding)
- risk-checker fails → hand off to
```
decision-evaluation
```
  (unresolved risk decision) or
```
design-refinement
```
  (risk documentation weak)
- structural integrity fails → hand off to
```
design-orchestrator
```
  (re-route ownership),
```
design-structure
```
  (derive a child tree), or
```
design-refinement
```
  (shrink duplicated inline logic)
Update
```
design_state
```
with:
- ```
status.ready_for_planning
```
  : true or false
- ```
status.blocking_issues
```
  : list from failed checks
- Updated
```
open_branches
```
  ,
```
risks
```
  ,
```
validation
```
  if new information emerged
- If a persisted design artifact exists, keep its document status aligned with the verdict:
```
draft
```
  for NOT READY,
```
ready-for-planning
```
  for READY
Return the explicit verdict with checklist diagram. Never give a "probably ready" answer.

目标：将检查结果合并为清晰的就绪判断。

将每个子agent的
```
status
```
映射到就绪检查清单中的通过/未通过条目：
- 必要状态检查 → "设计目标类型已存在"
- branch-checker → "设计树已存在"和"关键分支已细化"
- assumption-checker → "决策已解决"（若假设未解决）
- failure-checker → "故障路径已记录"和"验证策略已定义"
- risk-checker → "阻塞风险已缓解"
- 结构完整性检查 → "结构完整性已保持"
遵循图表规范构建✓/✗检查清单图表。
确定结论：
- READY：必要状态已存在，四项检查均返回
```
pass
```
  ，且无阻塞性结构完整性问题
- NOT READY：必要状态缺失，任何一项检查返回
```
fail
```
  ，或存在阻塞性结构完整性问题
如果为NOT READY，根据哪项检查失败确定转交目标：
- 必要状态检查失败 → 转交至
```
design-structure
```
- branch-checker失败 → 转交至
```
design-structure
```
  （分支缺失）或
```
design-refinement
```
  （分支薄弱）
- assumption-checker失败 → 转交至
```
design-refinement
```
  （假设需要扩展）
- failure-checker失败 → 转交至
```
design-refinement
```
  （需要添加故障路径）
- risk-checker失败 → 转交至
```
decision-evaluation
```
  （未解决的风险决策）或
```
design-refinement
```
  （风险文档薄弱）
- 结构完整性检查失败 → 转交至
```
design-orchestrator
```
  （重新分配所有权）、
```
design-structure
```
  （派生子树）或
```
design-refinement
```
  （缩减重复的内联逻辑）
更新
```
design_state
```
，包含：
- ```
status.ready_for_planning
```
  ：true或false
- ```
status.blocking_issues
```
  ：来自失败检查的问题列表
- 若出现新信息，更新
```
open_branches
```
  、
```
risks
```
  、
```
validation
```
- 若存在持久化设计工件，使其文档状态与结论保持一致：NOT READY时为
```
draft
```
  ，READY时为
```
ready-for-planning
```
返回明确结论及检查清单图表。绝不能给出“可能就绪”的答案。

Readiness Standard

就绪标准

A design is ready for planning only when:

```
design_target_type
```
is present
the main design tree is present
key branches are refined enough to guide implementation for the current target type
major decision nodes are resolved or explicitly deferred with acceptable rationale
failure paths and validation strategy are not missing
blocking risks are either mitigated or clearly acknowledged
tree responsibilities are not mixed in a way that breaks routing clarity

设计只有满足以下条件时才具备规划就绪状态：

存在
```
design_target_type
```
主设计树已存在
关键分支已细化到足以指导当前目标类型的实施
主要决策节点已解决，或有可接受的理由明确推迟
故障路径和验证策略无缺失
阻塞风险已缓解或已明确确认
树的职责未混合到破坏路由清晰度的程度

Expected Outputs

预期输出

Produce or update a

design_state

that includes:

```
design_target_type
```
```
open_branches
```
```
risks
```
```
validation
```
```
status.ready_for_planning
```
```
status.blocking_issues
```

Always return an explicit result:

ready for planning
not ready for planning

If a persisted design file is part of the workflow, its document status should also be explicit:

```
draft
```
while the design is not ready
```
ready-for-planning
```
after the readiness gate passes

生成或更新包含以下内容的

design_state

：

```
design_target_type
```
```
open_branches
```
```
risks
```
```
validation
```
```
status.ready_for_planning
```
```
status.blocking_issues
```

始终返回明确结果：

已准备好进入规划阶段
未准备好进入规划阶段

如果工作流中包含持久化设计文件，其文档状态也应明确：

设计未就绪时为
```
draft
```
通过就绪关卡后为
```
ready-for-planning
```

Diagram Conventions

图表规范

Present the readiness verdict as a status checklist inside a code block (no language tag):

Readiness Check
├── Design target type present   ✓
├── Design tree present          ✓
├── Key branches refined         ✓
├── Decisions resolved           ✗ (storage choice pending)
├── Failure paths documented     ✓
├── Validation strategy defined  ✓
├── Blocking risks mitigated     ✗ (migration cutover risk)
└── Structural integrity preserved ✓

Verdict: NOT READY — 2 blocking issues

Rules:

Use
```
✓
```
(pass) and
```
✗
```
(fail) markers with inline reason for failures
Max width: 78 characters
Always include this checklist in the readiness verdict

在代码块中（无语言标签）以状态检查清单的形式呈现就绪结论：

Readiness Check
├── Design target type present   ✓
├── Design tree present          ✓
├── Key branches refined         ✓
├── Decisions resolved           ✗ (storage choice pending)
├── Failure paths documented     ✓
├── Validation strategy defined  ✓
├── Blocking risks mitigated     ✗ (migration cutover risk)
└── Structural integrity preserved ✓

Verdict: NOT READY — 2 blocking issues

规则：

使用
```
✓
```
（通过）和
```
✗
```
（未通过）标记，并为未通过项添加内联原因
最大宽度：78字符
就绪结论中必须包含此检查清单

Entry and Exit Criteria

进入与退出标准

Enter when:

the design is near completion
the next meaningful step may be implementation planning

Exit when:

you have issued a clear readiness decision
you have identified the next route if the design is not ready

进入条件：

设计接近完成
下一步可能是实施规划

退出条件：

已发布明确的就绪决策
已确定设计未就绪时的下一步路径

Handoff Rules

转交规则

Hand off to
```
writing-plans
```
only when the design is clearly ready.
Hand off to
```
design-structure
```
when foundational branches are still missing.
Hand off to
```
design-refinement
```
when important branches exist but are still weak.
Hand off to
```
decision-evaluation
```
when the real blocker is an unresolved decision node.
Hand off to
```
design-orchestrator
```
when the real blocker is tree ownership or routing drift rather than branch weakness.
Treat missing
```
design_target_type
```
as an immediate blocker, not as a soft warning.
Never give a "probably ready" answer. The result must be explicit.

仅当设计明确就绪时，才转交至
```
writing-plans
```
。
当基础分支仍缺失时，转交至
```
design-structure
```
。
当重要分支存在但仍薄弱时，转交至
```
design-refinement
```
。
当真正的阻塞因素是未解决的决策节点时，转交至
```
decision-evaluation
```
。
当真正的阻塞因素是树所有权或路由偏移而非分支薄弱时，转交至
```
design-orchestrator
```
。
将缺失
```
design_target_type
```
视为立即阻塞因素，而非软警告。
绝不能给出“可能就绪”的答案。结果必须明确。

Journal Integration

日志集成

When operating on a task tracked under

.agents/tasks/<task-id>/

, append a journal entry at this skill's milestone.

Trigger: after readiness verdict is produced
Reserved key(s):
```
readiness
```
(value must be
```
ready
```
or
```
not-ready
```
)

Entry shape:

## <ISO8601-timestamp> — design-readiness-check
readiness: ready
[optional ≤ 15-line body; longer content goes to artifacts/]

Resolve the task id from the explicit caller argument or

.agents/tasks/.current

. If neither resolves, skip the append; do not guess.

See

task-journal

for the full convention.

当在

.agents/tasks/<task-id>/

下跟踪的任务上操作时，在此skill的里程碑处追加日志条目。

触发时机： 就绪结论生成后
保留键：
```
readiness
```
（值必须为
```
ready
```
或
```
not-ready
```
）

条目格式：

## <ISO8601-timestamp> — design-readiness-check
readiness: ready
[可选≤15行正文；更长内容放入artifacts/]

从显式调用者参数或

.agents/tasks/.current

解析任务ID。如果两者都无法解析，则跳过追加操作；请勿猜测。

有关完整规范，请参见

task-journal

。