spec-driven-brainstorm

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

You are helping the user turn an early-stage idea into a spec-driven change proposal.

你将协助用户把一个初步想法转化为基于规范的变更提议。

Prerequisites

前提条件

The

.spec-driven/

directory must exist at the project root. Before proceeding, verify:

ls .spec-driven/

If this fails, the project is not initialized. Run

/spec-driven-init

first.

.spec-driven/

目录必须存在于项目根目录下。在开始前，请验证：

ls .spec-driven/

如果验证失败，说明项目尚未初始化，请先运行

/spec-driven-init

。

Steps

步骤

Start from the idea, not the artifact list — ask the user what they want to achieve, what problem they are trying to solve, and any known constraints or preferences. Do not require a change name up front.
Read project context and existing specs early — before narrowing scope, read:
- ```
.spec-driven/config.yaml
```
  — use
```
context
```
  as project background and treat
```
rules
```
  as binding constraints
- ```
.spec-driven/specs/INDEX.md
```
  — identify existing spec areas that may already cover the requested behavior
- Every relevant main spec file referenced by
```
INDEX.md
```
  that appears related to the idea being discussed
Brainstorm until the change is decision-ready — use the discussion to converge on:
- the desired outcome and user-visible behavior
- what is in scope and explicitly out of scope
- important tradeoffs, constraints, risks, and unchanged behavior
- which existing spec files will likely be modified, or whether a new spec area is needed
- any questions that still need a human answer before implementation
Suggest the change name — once the idea is coherent enough, propose a short kebab-case change name. If the user already provided a valid name, keep it. If not, suggest one that reflects the agreed change scope.
Present a proposal checkpoint — before creating any files, summarize:
- the proposed change name
- the goal and scope
- the main spec areas expected to change
- key decisions or tradeoffs already settled
- any unresolved questions that would go into
```
questions.md
```
Then ask for explicit confirmation. If the user wants revisions, continue the brainstorm and re-summarize until confirmed.

Scaffold the change after confirmation — run:

node {{SKILL_DIR}}/scripts/spec-driven.js propose <name>

This creates

.spec-driven/changes/<name>/

with the seeded templates.

Fill the five proposal artifacts — after scaffolding, complete the same proposal workflow used by
```
/spec-driven-propose
```
:
- write
```
proposal.md
```
  with What, Why, Scope, and Unchanged Behavior
- write
```
design.md
```
  with Approach, Key Decisions, and Alternatives Considered
- populate
```
changes/<name>/specs/
```
  with delta spec files aligned by path with the main
```
.spec-driven/specs/
```
  structure
- write
```
tasks.md
```
  with atomic checklist items under
```
## Implementation
```
  ,
```
## Testing
```
  , and
```
## Verification
```
- write
```
questions.md
```
  , recording every unresolved point under
```
## Open
```
  , or leave
```

```
  if nothing is unclear
Validate before presenting the proposal — run:
```
node {{SKILL_DIR}}/scripts/spec-driven.js verify <name>
```
- Fix any safe artifact-format issues immediately and rerun
```
verify
```
- If only open questions remain, treat that as expected at proposal time and surface those questions clearly
- If any non-question error remains, stop and report it instead of presenting the proposal as ready
Hand off like propose — show the user the generated artifacts, summarize the final proposed scope, and list any open questions that must be answered before
```
/spec-driven-apply
```
.
Offer auto hand-off — after the hand-off, ask the user whether to enter
```
/spec-driven-auto
```
to execute the proposal end-to-end, or continue modifying the proposal with
```
/spec-driven-modify
```
. Do not auto-enter auto without the user's explicit choice.

从想法入手，而非工件列表 —— 询问用户想要实现的目标、试图解决的问题，以及任何已知的约束条件或偏好。不要求用户提前提供变更名称。
尽早了解项目上下文和现有规范 —— 在缩小范围之前，阅读以下内容：
- ```
.spec-driven/config.yaml
```
  —— 将
```
context
```
  作为项目背景，将
```
rules
```
  视为必须遵守的约束条件
- ```
.spec-driven/specs/INDEX.md
```
  —— 识别可能已涵盖所需行为的现有规范领域
- ```
INDEX.md
```
  中引用的所有与当前讨论想法相关的主要规范文件
头脑风暴直至变更方案可决策 —— 通过讨论达成以下共识：
- 期望的结果和用户可见的行为
- 变更的范围和明确排除在外的内容
- 重要的权衡、约束、风险以及未变更的行为
- 可能需要修改哪些现有规范文件，或者是否需要新增一个规范领域
- 在实施前仍需要人工解答的问题
提议变更名称 —— 当想法足够清晰后，提议一个简短的kebab-case格式的变更名称。如果用户已提供有效的名称，则沿用该名称；若未提供，则建议一个能反映已达成共识的变更范围的名称。
展示提议检查点 —— 在创建任何文件之前，总结以下内容：
- 提议的变更名称
- 目标和范围
- 预计会发生变更的主要规范领域
- 已确定的关键决策或权衡
- 任何将纳入
```
questions.md
```
  的未解决问题
然后请求用户明确确认。如果用户需要修改，则继续头脑风暴并重新总结，直至得到确认。
确认后搭建变更框架 —— 运行：
```
node {{SKILL_DIR}}/scripts/spec-driven.js propose <name>
```
此命令会创建
```
.spec-driven/changes/<name>/
```
目录并生成初始化模板。
填充五个提议工件 —— 搭建框架后，遵循与
```
/spec-driven-propose
```
相同的提议工作流：
- 编写
```
proposal.md
```
  ，包含What（内容）、Why（原因）、**Scope（范围）和Unchanged Behavior（未变更行为）**部分
- 编写
```
design.md
```
  ，包含Approach（实现方案）、**Key Decisions（关键决策）和Alternatives Considered（备选方案）**部分
- 在
```
changes/<name>/specs/
```
  目录中填充增量规范文件，路径与主
```
.spec-driven/specs/
```
  结构保持一致
- 编写
```
tasks.md
```
  ，在
```
## Implementation（实施）
```
  、
```
## Testing（测试）
```
  和
```
## Verification（验证）
```
  下列出原子化的检查项
- 编写
```
questions.md
```
  ，在
```
## Open（未解决）
```
  下记录所有未明确的问题；若没有疑问，则保留
```

```
提交提议前进行验证 —— 运行：
```
node {{SKILL_DIR}}/scripts/spec-driven.js verify <name>
```
- 立即修复所有可安全解决的工件格式问题，然后重新运行
```
verify
```
- 如果仅存在未解决的问题，这属于提议阶段的正常情况，需清晰地列出这些问题
- 如果存在非问题类的错误，请停止操作并报告该错误，不要将提议标记为已就绪
像propose那样交接 —— 向用户展示生成的工件，总结最终提议的范围，并列出在运行
```
/spec-driven-apply
```
之前必须解答的所有未解决问题。
提供自动交接选项 —— 交接完成后，询问用户是否要进入
```
/spec-driven-auto
```
以端到端执行提议，或者继续使用
```
/spec-driven-modify
```
修改提议。未经用户明确选择，请勿自动进入auto模式。

Rules

规则

Do not implement code — this skill is planning only
Do not scaffold proposal artifacts until the user explicitly confirms the brainstorm summary and change name
Read
```
.spec-driven/config.yaml
```
,
```
INDEX.md
```
, and relevant main specs before locking scope or writing delta specs
Suggest a kebab-case change name when the user starts with only a rough idea
Record unresolved ambiguity in
```
questions.md
```
; do not guess silently
After confirmation, follow the same artifact-writing and validation standard as
```
/spec-driven-propose
```

不要编写代码 —— 此Skill仅用于规划
在用户明确确认头脑风暴总结和变更名称之前，不要搭建提议工件的框架
在锁定范围或编写增量规范之前，务必阅读
```
.spec-driven/config.yaml
```
、
```
INDEX.md
```
和相关的主要规范文件
当用户仅提出初步想法时，建议使用kebab-case格式的变更名称
将未解决的歧义记录在
```
questions.md
```
中；不要默默猜测
确认后，遵循与
```
/spec-driven-propose
```
相同的工件编写和验证标准