---
name: soloforge-requirement-analysis
description: 把用户目标、角色、业务规则、边界和可验证验收标准整理为需求分析文档。
when: 需求分析 / requirement_analysis / 架构设计之前
---

# 需求分析

## 适用性

用于把“为什么做、给谁用、做到什么算成功”变成可验证契约。若目标、关键角色或高影响边界尚未得到用户确认，先研讨，不得用假设补齐。

## 事实输入

- 用户原始目标、现状痛点、使用场景和成功标准。
- 已知业务规则、合规约束、外部系统和历史兼容要求。
- 当前任务的 scope 与系统形态。
- `template.md` 的结构和 `examples.md` 的正反例；示例值只用于理解质量，不得复制。

## 关键决策

- 根本目标必须用用户结果表述，不能写成预选技术方案。
- 有前端时，系统形态与每个端的职责、技术栈和本期交付范围由用户确认。
- 冲突需求、未知规则和范围外事项必须显式记录，不得静默选择。

## 产出方法

1. 先复述目标、角色、主场景和不做什么，消除歧义。
2. 为每条需求分配稳定编号，并写出正常、异常和边界验收条件。
3. 把非功能要求写成可测指标；无法量化时记录验证方法和责任人。
4. 根据模板完成术语、权限、外部依赖、未确认项和端清单。
5. 默认路径是 `docs/context/需求分析.md`；brownfield 项目若有 project map override，以解析后的权威路径为准。

## 禁止项

- 不得保留示例编号、占位词、空表或“其余同上”。
- 不得把“使用某框架/建某服务”写成根本目标。
- 不得替用户确认价值取舍、端划分、合规接受或范围削减。
- 不得把不可验证的“体验好、性能高、功能正常”当验收标准。

## 交付自检

- 每条需求都能回答用户、场景、输入、结果和失败行为。
- 根本目标与确认来源真实可追溯。
- 角色权限、外部依赖、数据边界和非目标无矛盾。
- 所有 `N/A` 都说明不适用原因；未知项保留为待决策，不伪装已完成。

## 权威验证

编辑后先处理 quick 反馈，再调用 `sf_verify action="full" task_id="当前任务ID" artifact="requirement_analysis"`。只有 full 记录通过且保持新鲜，才能作为推进证据。


## 交付前对抗审查

`sf_verify` 通过只证明结构/编译/测试层；语义质量（承接正确性、异常/并发/权限/边界是否可靠、是否含空话或无法证伪的承诺）须经独立对抗审查。advance/deliver 前用 `sf_review action="start" task_id="当前任务ID" artifact="<本产物 kind>"` 发起 per_artifact 审查，用**独立 session/subagent**（非产出本产物的同一会话）执行返回的 prompt、submit findings，按 next_step 完成 K 次独立采样与闭环。deliver 会阻断未完成/未闭环的审查；活跃豁免与被驳回 error 会被注入审查 focus 供独立复核。