diff --git a/SKILL.md b/SKILL.md
index c09baa4..901a9ae 100644
--- a/SKILL.md
+++ b/SKILL.md
@@ -30,7 +30,7 @@ whenToUse: 在 one_divine_lot 仓库中从事任何开发、规划、讨论、
 | `02-计划/` | 目标分解后的执行方案，支持不同粒度 | 必须从终极目标派生；计划条目必须有明确范围与验收；计划未覆盖的事不做 |
 | `03-设计约束/` | 设计与技术的强制规范，下分三个文档模块（产品功能 / 技术方案 / UI交互） | 后续迭代必须以本目录为依据；规范变更需讨论并记录理由；不得与终极目标冲突 |
 | `04-迭代记录/` | 执行过程的事实档案，每次迭代一个子目录（迭代目标 / 技术实现方案 / 验收标准） | 只记录事实（做了什么、结果如何），不写感想；追加式，不改写历史 |
-| `05-需求池/` | 所有待办需求的入口 | 统一格式登记；有优先级与状态流转（池 → 计划 → 完成）；讨论中的想法先入池；**只有确定的需求才可进入计划/迭代范围，未确定的需求停留在池中** |
+| `05-需求池/` | 所有待办需求的入口 | 统一格式登记；每条需求维护状态（起草/讨论中/已定稿）与更新日期；讨论中的想法先入池；**只有已定稿的需求才可进入计划/迭代范围，未定稿的需求停留在池中** |
 
 > **设计约束的文档模块**：`03-设计约束/` 下三个文档模块，各自以**列表**记录约束条目，每条含「编号 / 约束说明 / 添加日期 / 生效状态 / 失效日期 / 最后一次变更描述」：
 > - `产品功能约束.md`：产品功能层面的约束（功能边界、行为定义、不可违背的产品规则）
@@ -45,6 +45,11 @@ whenToUse: 在 one_divine_lot 仓库中从事任何开发、规划、讨论、
 > - `验收标准.md`：本次迭代的验收标准线（验收标准在哪里）、验收方法、验收目标 —— 明确如何判定本次迭代是否达成
 > - **与需求池联动**：迭代目标若引用需求池中的需求，需求池索引记录需补充「实现该需求的迭代」与「需求实现状态」两要素，双向可追溯。
 
+> **需求状态管理**：`05-需求池/` 的每条需求在索引中维护两个状态字段：
+> - **状态**：`起草`（刚入池，想法未成形）→ `讨论中`（正在讨论、未确定）→ `已定稿`（讨论确定、可进入计划/迭代）。状态按此单向推进，回退需讨论说明。
+> - **更新日期**：最近一次状态变更或内容更新的日期，随每次变更刷新。
+> - **与入范围门槛的对应**：只有状态为「已定稿」的需求才可进入计划范围或迭代工作范围；起草 / 讨论中的需求停留在需求池。
+
 > **关于粒度**：计划不是单一粒度。一个计划可以是"概念范围大一些的阶段航点"，也可以是"可直接执行的小任务"。两者本质相同 —— 都是对目标的分解 —— 只是范围大小不同，统一归入 `02-计划/`，通过粒度标记区分。
 
 ### 文档之间的流转关系
@@ -61,7 +66,7 @@ whenToUse: 在 one_divine_lot 仓库中从事任何开发、规划、讨论、
                            01-终极目标 ──(验证)──▶ 持续迭代
 ```
 
-> **入范围门槛**：`05-需求池 → 02-计划` 之间有一道门槛 —— **只有讨论确定的需求才允许跨过**。讨论中、未确定的需求停留在需求池，不得进入计划范围，也不得进入迭代工作范围。
+> **入范围门槛**：`05-需求池 → 02-计划` 之间有一道门槛 —— **只有状态为「已定稿」的需求才允许跨过**。起草 / 讨论中的需求停留在需求池，不得进入计划范围，也不得进入迭代工作范围。
 
 > 注：序号反映**阅读与裁决的层级顺序**（01 最高），实际推进节奏按 `05 → 02 → 04 → 01` 的流转闭环走，且每次进入计划/执行都必须先对照 `03-设计约束`，两者不冲突。
 
@@ -74,7 +79,8 @@ whenToUse: 在 one_divine_lot 仓库中从事任何开发、规划、讨论、
 1. 建立 `docs/` 五大强约束目录：`01-终极目标/`、`02-计划/`、`03-设计约束/`、`04-迭代记录/`、`05-需求池/`。
 2. 每个目录写入 `说明.md` 骨架：角色 / 强约束（初始定义）/ 待讨论细节，内容与本节框架一致。
 3. `03-设计约束/` 下建立三个文档模块：`产品功能约束.md`、`技术方案约束.md`、`UI交互约束.md`，各含六列列表骨架（编号 / 约束说明 / 添加日期 / 生效状态 / 失效日期 / 最后一次变更描述）。
-4. 检查 `.agents/skills/divine-lot-dev/` 是否存在（skill 本身），不存在则提示先安装 skill。
+4. `05-需求池/` 下建立需求索引骨架：每条需求含「编号 / 标题 / 描述 / 优先级 / 状态（起草 / 讨论中 / 已定稿）/ 更新日期 / 实现迭代 / 实现状态」等字段。
+5. 检查 `.agents/skills/divine-lot-dev/` 是否存在（skill 本身），不存在则提示先安装 skill。
 
 **初始化原则**：
 
@@ -84,8 +90,8 @@ whenToUse: 在 one_divine_lot 仓库中从事任何开发、规划、讨论、
 ## 4. 开发流程（框架层）
 
 1. **新想法 → 需求池**：任何新需求、新想法先登记入池，不直接进代码。
-2. **需求 → 讨论 → 确定**：对池内需求进行讨论，确定优先级与范围。**未确定的需求停留在需求池**，不进入计划与迭代。
-3. **确定的需求 → 计划**：只有讨论确定的需求，才从终极目标派生计划（含大粒度阶段航点与小粒度任务，按需拆分）。
+2. **需求 → 讨论 → 定稿**：对池内需求进行讨论，需求状态随讨论推进（起草 → 讨论中 → 已定稿）。**未定稿（起草 / 讨论中）的需求停留在需求池**，不进入计划与迭代。
+3. **已定稿的需求 → 计划**：只有状态为「已定稿」的需求，才从终极目标派生计划（含大粒度阶段航点与小粒度任务，按需拆分）。
 4. **计划 → 对照设计约束 → 执行**：进入计划与执行前，先对照 `03-设计约束/` 中的设计/技术/产品设计规范，确保实现有规范依据。
 5. **计划 → 执行 → 迭代记录**：按计划执行，每次迭代的事实写入迭代记录。
 6. **迭代 → 复盘 → 计划/需求池**：对照计划检查进度，更新计划状态与需求池流转。
@@ -94,7 +100,7 @@ whenToUse: 在 one_divine_lot 仓库中从事任何开发、规划、讨论、
 ## 5. 质量门禁（框架层）
 
 - **文档先行**：代码改动必须有对应文档条目（计划/需求池）支撑。
-- **入范围门槛**：只有确定的需求才可进入计划范围或迭代工作范围；未确定的需求不得进入，只停留在需求池。
+- **入范围门槛**：只有状态为「已定稿」的需求才可进入计划范围或迭代工作范围；起草 / 讨论中的需求不得进入，只停留在需求池。
 - **规范约束**：实现必须符合 `03-设计约束/` 的规范；无规范依据的实现需要先补规范或讨论豁免。
 - **记录诚实**：迭代记录只写事实，成功失败都记录，失败是复盘的原料。
 - **约束优先**：文档强约束 > 临时便利；违反约束的改动需要讨论并修订文档。
@@ -116,6 +122,6 @@ whenToUse: 在 one_divine_lot 仓库中从事任何开发、规划、讨论、
 - [x] 迭代记录：组织结构（每次迭代一个子目录，含迭代目标 / 技术实现方案 / 验收标准；与需求池索引联动）
 - [ ] 迭代记录：验收标准的写法（标准线如何划定、验收方法、验收目标）
 - [ ] 迭代记录：记录粒度、编号规则、复盘模板
-- [ ] 需求池：登记格式（含"实现迭代 / 实现状态"联动字段）、优先级规则、状态流转的具体定义
+- [x] 需求池：登记格式（含状态字段：起草/讨论中/已定稿 + 更新日期，以及"实现迭代 / 实现状态"联动字段）、优先级规则、状态流转的具体定义
 - [x] 入范围门槛：只有确定的需求才可进入计划/迭代范围，未确定的需求停留在需求池
 - [ ] 讨论本身的规范：讨论如何发起、如何收敛、如何判定"讨论完成"（含"需求确定"的判定标准）