/s —— 需求 → SPEC.md

输入

需求的唯一来源是 Meegle 工作项。没有工作项时先运行 /pd，不要直接从聊天或会议纪要生成 SPEC。

• 装了飞书项目 CLI：直接读工作项（meegle 命令），拿标题、描述、验收标准、优先级、子任务。
• 没装：让用户贴工作项内容。
• 不许猜。 工作项里没写的，问；问不到的，写进 SPEC 的「待澄清」并停下来。
• 工作项应已经过 /bl 或等价的人类排期，具有明确优先级和迭代；缺失时报告计划缺口，不替产品补排期。

同时读仓库现状：AGENTS.md、README.md、相关模块代码、docs/intent/。 SPEC 是在现有系统上的增量，不是凭空设计。

产出

SPEC.md（仓库根，或 docs/SPEC.md），结构：

# SPEC: <标题>
> Meegle: [PROJ-1234](<工作项链接>)

## 目标
<一句话：为谁解决什么问题。做完什么样算成功。>

## 可验证行为
- <每条都能写出对应的测试。「系统应该好用」不是行为。>

## 边界与非目标
- <明确不做什么。这是 /b 阶段防止范围蔓延的唯一依据。>

## 影响面
| 维度 | 影响 |
|---|---|
| 模块 / 接口 | |
| 数据 / 存储 | |
| 上下游 | |

## 待澄清
- <问题 → 谁能回答。空着比编好。>

规则

1. 每条行为都要可测。 写不出测试的条目，要么细化，要么进「待澄清」。
2. 边界和非目标不能省。 它比目标更能防止后面跑偏。
3. 头部必须带工作项号和链接 —— 这是仓库与 Meegle 之间唯一的溯源锚点。
4. 需求变更先改 Meegle，再更新 SPEC.md。 反过来两边立刻漂移。
5. 这一步不写代码，也不改现有文件（除了新建 SPEC.md）。
6. 产品设计描述产品行为，SPEC 将其转成可验证行为；不要在 /s 重做产品需求或优先级判断。

何时进下一步

SPEC 里每条行为都可验证，边界写清楚了，「待澄清」为空或已确认可以带着风险开工。 然后跑 /p。

Red Flags

• 「待澄清」全空，但你其实是靠猜填满了 SPEC
• 验收标准是「性能良好」「体验流畅」这类没法验的话
• 影响面表格空着 —— 说明还没读代码就在写 SPEC
• SPEC 里出现实现细节（用哪个库、怎么分层）—— 那是 /p 的事