Speckit 需求分析

解决的问题

Analyze 位于 Specify 之前，负责把“用户的一段话”变成“可进入规格的结构化需求”。直接写 Specify 容易在概念未确认时就把 ID 定死，返工成本高。这个技能要处理三件事：

• 概念准入：区分“用户确认过的概念”和“助手建议 / 业务推导”，避免后者混入规范性需求
• 决策留痕：变更先记录 decision event，再定点更新正式产物，不重写无关历史章节
• 交接干净：Markdown 与 JSON 交接包只在批次完成或需要交付时物化

核心能力

1. 先定 Execution-Profile：Delta 用于已有稳定 Draft 的局部需求，只读新增需求及影响对象；Full 用于首次建产品或影响范围不明
2. 运行 resolve_workflow.py 定位状态：存在可写 Draft 时返回 DRAFT_EXISTS_USE_CLARIFY，不创建竞争性分析记录；只有 Frozen 或无 spec 才进入 Analyze
3. 原样保留用户需求概要，先生成完整 AI-* 分析清单，再开始提问
4. 为重要概念建 SRC-* 来源与准入台账，区分 origin 与 admission_status
5. 每轮只讨论一个最高优先级项，最多合并五个强相关问题；每次回答后先用中性语言复述规则，再把问题、回答、来源、影响对象原子写回 requirements-analysis.md 与 analysis-handoff.json
6. 助手建议、业务推导、基线发现和外部约束必须先询问“是否纳入本次需求”，人工明确确认后才生成 CAP/G/US/FR/BR/STATE/ACT 等正式 ID
7. 字段密集型需求额外输出 field_candidates 与 schema_sources，模板、字典、运行时字段标记快照要求

适用边界

• user-confirmed 只代表用户确认，不代表 Spec-admissible；ready_for_specify 只放行 target_artifact=spec 且 promotion_status=approved|not-required 的项
• 原型截图、演示数据默认标记为 prototype-presentation 或 prototype-fixture，不得生成正式 CAP/FR/BR/AC
• 用户描述若改变业务能力、数据来源、权限或验收标准，先输出 SPEC_CHANGE_CANDIDATE 确认是否提升到 Spec
• Analyze 不直接调用 Clarify、不生成 spec，下一步由路由器决定；退出码为 0 且 JSON 中 valid: true 才允许交付