<aside>

按软件工程生命周期推进，而不是按零散场景选流程。

任何工作都从“当前最早仍不确定的阶段”进入；已经确认的阶段可以跳过，但不能在关键问题未解决时直接编码。

</aside>

需求与可行性分析
→ 需求规格化
→ 架构与详细设计
→ 计划与任务拆分
→ 编码与持续重构
→ 测试与代码评审
→ 发布、运维与持续演进

生命周期导航

全生命周期速查

新需求或较大改动
/grill-with-docs
→ domain-modeling / research / prototype（按需）
→ /to-spec
→ /codebase-design（按需）
→ /to-tickets（多切片时）
→ /implement
→ /code-review
→ 发布与观察

单一明确的小改动
/tdd
→ checks
→ /code-review
→ commit

超大型、高不确定性工作
/wayfinder
→ research / prototype / grilling
→ /to-spec
→ /codebase-design
→ /to-tickets
→ 分批 /implement

生产缺陷
/diagnosing-bugs
→ 回归测试
→ 最小修复
→ /code-review
→ 发布与指标验证

架构治理
/improve-codebase-architecture
→ /to-spec
→ /codebase-design
→ /to-tickets
→ /implement

1. 需求与可行性分析

目标：回答为什么做、为谁做、解决什么问题、边界在哪里，以及方案是否可行。此阶段不写生产代码。

主流程：

/grill-with-docs
→ 按需调用 domain-modeling / research / prototype
→ 超大型工作改用 /wayfinder 管理未知问题
→ 决策稳定后进入 /to-spec

1.1 澄清需求与边界

新功能、较大改动或描述模糊时，先调用：

/grill-with-docs <要解决的问题>

1.2 建立统一领域语言

术语混乱、代码命名与业务语言不一致时，使用 domain-modeling：

/domain-modeling
请识别实体、值对象、状态、动作、约束和关系，用边界案例检验术语，并更新 CONTEXT.md、术语表和必要 ADR。

1.3 消除关键未知

外部事实未知：API、协议、框架行为、安全规范或第三方能力无法从代码库确认时，使用：