requirements-builder

用途

Requirements Builder 是一个智能需求收集系统，用于在开始开发某个功能或需求之前，通过自动化的代码库发现和结构化的“是/否”提问，逐步收集需求，并最终生成一份完整的需求规格文档。它基于 claude-code-requirements-builder。

主要能力

自动分析代码库结构，理解高层架构、主要组件与服务、技术栈以及既有模式与约定。
通过两轮各 5 个“是/否”问题收集需求：第一轮为上下文发现提问，第二轮为专家级需求提问。
在提问之间自主进行针对性上下文收集，深入阅读相关代码、分析相似功能与实现细节，并可借助 WebSearch 和/或 context7 查询最佳实践或库文档。
生成包含问题陈述、功能需求、技术需求、实现提示、验收标准以及未回答问题假设的完整需求规格。
提供多个子命令管理需求收集会话。

使用方式

调用时传入参数 $ARGUMENTS，用于描述要收集的功能或需求，例如“add user profile photo upload”。

初始设置需确保项目根目录存在 requirements/ 目录：

mkdir -p requirements
touch requirements/.current-requirement

工作流程分为五个阶段：

阶段 1：初始设置与代码库分析 — 创建带时间戳的文件夹 requirements/YYYY-MM-DD-HHMM-[slug]，从 $ARGUMENTS 提取 slug（例如“add user profile” → “user-profile”），创建 00-initial-request.md 和 metadata.json，更新 requirements/.current-requirement，并分析代码库整体结构。
阶段 2：上下文发现提问 — 生成 5 个最重要的“是/否”问题，了解问题空间、用户交互与工作流、用户当前使用的相似功能、涉及的数据/内容、外部集成或第三方服务、性能或规模预期。所有问题先写入 01-discovery-questions.md 并附智能默认值，然后一次只问一个问题。只有在所有问题都问完后，才将答案记录到 02-discovery-answers.md 并更新 metadata.json。
阶段 3：针对性上下文收集（自主进行） — 根据发现答案搜索特定文件、批量阅读相关代码、深入分析相似功能与模式、分析具体实现细节，并可使用 WebSearch 和/或 context7。发现记录写入 03-context-findings.md，包括需要修改的具体文件、应遵循的确切模式、详细分析的相似功能、技术约束与考量、已识别的集成点。
阶段 4：专家级需求提问 — 像熟悉代码库的资深开发者一样提问，将 5 个最紧迫的未回答详细“是/否”问题写入 04-detail-questions.md，问题面向不了解代码的产品经理，用于在深入理解代码后澄清预期系统行为，并包含基于代码库模式的智能默认值。一次只问一个问题，全部问完后才将答案记录到 05-detail-answers.md。
阶段 5：需求文档生成 — 在 06-requirements-spec.md 中生成完整需求规格，包含问题陈述与解决方案概述、基于所有答案的功能需求、带具体文件路径的技术需求、实现提示与应遵循的模式、验收标准、未回答问题所采用的假设。

重要规则

只使用带智能默认值的“是/否”问题。
一次只问一个问题。
在提问任何问题之前，先将所有问题写入文件。
保持聚焦于需求（不涉及实现）。
在细节阶段使用实际文件路径和组件名称。
记录每个默认值为何合理。

阶段过渡

每个阶段结束后宣布：“Phase complete. Starting [next phase]...”，并在进入下一阶段前保存所有工作。

子命令

/requirements-status：显示当前需求收集进度，并从最后一个未回答的问题继续。读取 requirements/.current-requirement；若无活动需求，建议启动一个；若有活动需求，显示格式化状态、加载问题文件、从最后一个未回答问题继续。
/requirements-current：显示活动需求的详细信息（只读，不继续收集）。展示初始请求、代码库概览、所有问题/答案、上下文发现、当前阶段、下一步。
/requirements-list：显示所有需求及其状态和摘要，排序为活动优先，其次完成，再次未完成。
/requirements-end：结束当前需求收集会话。选项包括：用当前信息生成规格（未回答项使用默认值）、标记为未完成以便稍后继续、取消并删除。
/requirements-remind：当偏离需求收集规则时快速纠正。自动检测：提出开放式问题 → 改写为“是/否”；一次提出多个问题 → 改为一次一个；开始实现 → 重定向回需求；未提供默认值 → 添加默认值。

文件结构

每个需求会创建如下文件夹结构：

requirements/
  .current-requirement          # Active requirement folder name
  YYYY-MM-DD-HHMM-[slug]/
    00-initial-request.md       # Original user request
    01-discovery-questions.md   # Context discovery questions
    02-discovery-answers.md     # User's answers
    03-context-findings.md      # AI's codebase analysis
    04-detail-questions.md      # Expert requirements questions
    05-detail-answers.md        # User's detailed answers
    06-requirements-spec.md     # Final requirements document
    metadata.json               # Status tracking

元数据结构

{
  "id": "feature-slug",
  "started": "ISO-8601-timestamp",
  "lastUpdated": "ISO-8601-timestamp",
  "status": "active",
  "phase": "discovery|context|detail|complete",
  "progress": {
    "discovery": { "answered": 0, "total": 5 },
    "detail": { "answered": 0, "total": 0 }
  },
  "contextFiles": ["paths/of/files/analyzed"],
  "relatedFeatures": ["similar features found"]
}

最终规格格式

# Requirements Specification: [Name]

Generated: [timestamp]
Status: [Complete with X assumptions / Partial]

## Overview
[Problem statement and solution summary]

## Detailed Requirements

### Functional Requirements
[Based on answered questions]

### Technical Requirements
- Affected files: [list with paths]
- New components: [if any]
- Database changes: [if any]

### Assumptions
[List any defaults used for unanswered questions]

### Implementation Notes
[Specific guidance for implementation]

### Acceptance Criteria
[Testable criteria for completion]

适用场景

适用于在开始开发某个功能或需求之前，需要系统化梳理问题空间、技术约束和验收标准的场景。尤其适合希望借助代码库上下文进行结构化需求收集、并生成可追溯需求文档的开发团队或个人。

限制

资料未提供关于收费、价格、平台支持范围、具体效果或性能的说明。