mcpField
R
requirements-clarity

requirements-clarity

github.com/davila7开发33.1k442 次安装今天更新
代码仓库

关于 requirements-clarity

Requirements Clarity 是一项通过引导式澄清,将模糊功能需求转化为可执行 PRD 的技能。它评估需求清晰度、分轮提出针对性问题,并在达到指定分数后生成规格文档。

主要功能

  1. 01识别模糊或不完整需求
  2. 02以 100 分制评估清晰度
  3. 03分轮提出针对性问题
  4. 04追踪各需求维度的缺口
  5. 05生成含验收标准的 PRD

适用场景

  1. 01细化描述不足的功能需求
  2. 02明确技术约束与范围
  3. 03定义可衡量的验收标准
  4. 04准备开发交接文档

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/davila7/claude-code-templates --skill requirements-clarity

安装后在 Claude Code 中输入/requirements-clarity确认已加载。

附带文件README.md

详细介绍

需求澄清技能

描述

通过系统化的澄清流程,结合 100 分评分系统,自动将模糊的需求转化为可执行的 PRD。

指令

当被调用时,检测模糊需求:

  1. 模糊的功能请求

    • 用户说:“添加登录功能”、“实现支付”、“创建仪表盘”
    • 缺少:如何实现、用什么技术、有什么约束?
  2. 缺少技术背景

    • 未提及技术栈
    • 未确定集成点
    • 未说明性能/安全约束
  3. 规格不完整

    • 无验收标准
    • 无成功指标
    • 未考虑边界情况
    • 未提及错误处理
  4. 范围模糊

    • 边界不清晰(“用户管理”——具体指什么?)
    • 未区分 MVP 与未来增强
    • 缺少“不包含什么”

不要激活的情况:

  • 提及了具体文件路径(例如 “auth.go:45”)
  • 包含了代码片段
  • 引用了现有函数/类
  • 有清晰复现步骤的 Bug 修复

核心原则

  1. 系统化提问

    • 提出聚焦、具体的问题
    • 每次只问一个类别(每轮 2-3 个问题)
    • 基于之前的回答逐步推进
    • 避免让用户不堪重负
  2. 质量驱动的迭代

    • 持续评估清晰度分数(0-100)
    • 系统化识别缺口
    • 迭代直至 ≥ 90 分
    • 记录所有澄清轮次
  3. 可执行的输出

    • 生成具体的规格说明
    • 包含可衡量的验收标准
    • 提供可执行的阶段划分
    • 支持直接实施

澄清流程

第 1 步:初始需求分析

输入:用户的需求描述

任务:

  1. 解析并理解核心需求
  2. 生成功能名称(kebab-case 格式)
  3. 确定文档版本(默认 1.0,除非用户另有指定)
  4. 确保 ./docs/prds/ 存在以输出 PRD
  5. 执行初始清晰度评估(0-100)

评估标准:

Functional Clarity: /30 points
- Clear inputs/outputs: 10 pts
- User interaction defined: 10 pts
- Success criteria stated: 10 pts

Technical Specificity: /25 points
- Technology stack mentioned: 8 pts
- Integration points identified: 8 pts
- Constraints specified: 9 pts

Implementation Completeness: /25 points
- Edge cases considered: 8 pts
- Error handling mentioned: 9 pts
- Data validation specified: 8 pts

Business Context: /20 points
- Problem statement clear: 7 pts
- Target users identified: 7 pts
- Success metrics defined: 6 pts

初始响应格式:

I understand your requirement. Let me help you refine this specification.

**Current Clarity Score**: X/100

**Clear Aspects**:
- [List what's clear]

**Needs Clarification**:
- [List gaps]

Let me systematically clarify these points...
第 2 步:缺口分析

从四个维度识别缺失信息:

1. 功能范围

  • 核心功能是什么?
  • 边界在哪里?
  • 什么不在范围内?
  • 有哪些边界情况?

2. 用户交互

  • 用户如何交互?
  • 输入是什么?
  • 输出是什么?
  • 成功/失败场景是什么?

3. 技术约束

  • 性能要求?
  • 兼容性要求?
  • 安全考量?
  • 可扩展性需求?

4. 业务价值

  • 这解决了什么问题?
  • 目标用户是谁?
  • 成功指标是什么?
  • 优先级是什么?
第 3 步:交互式澄清

提问策略:

  1. 从影响最大的缺口开始
  2. 每轮提问 2-3 个问题
  3. 逐步构建上下文
  4. 使用用户的语言
  5. 在有帮助时提供示例

问题格式:

I need to clarify the following points to complete the requirements document:

1. **[Category]**: [Specific question]?
   - For example: [Example if helpful]

2. **[Category]**: [Specific question]?

3. **[Category]**: [Specific question]?

Please provide your answers, and I'll continue refining the PRD.

每次用户回复后:

  1. 更新清晰度分数
  2. 将新信息记录到工作 PRD 大纲中
  3. 识别剩余缺口
  4. 如果分数 < 90:继续下一轮提问
  5. 如果分数 ≥ 90:进入 PRD 生成

分数更新格式:

Thank you for the additional information!

**Clarity Score Update**: X/100 → Y/100

**New Clarified Content**:
- [Summarize new information]

**Remaining Points to Clarify**:
- [List remaining gaps if score < 90]

[If score < 90: Continue with next round of questions]
[If score ≥ 90: "Perfect! I will now generate the complete PRD document..."]
第 4 步:PRD 生成

一旦清晰度分数 ≥ 90,生成完整的 PRD。

输出文件:

  1. 最终 PRD:./docs/prds/{feature_name}-v{version}-prd.md

使用 Write 工具创建或更新此文件。{version} 从 PRD 中记录的文档版本推导得出(默认 1.0)。

PRD 文档结构

# {Feature Name} - Product Requirements Document (PRD)

## Requirements Description

### Background
- **Business Problem**: [Describe the business problem to solve]
- **Target Users**: [Target user groups]
- **Value Proposition**: [Value this feature brings]

### Feature Overview
- **Core Features**: [List of main features]
- **Feature Boundaries**: [What is and isn't included]
- **User Scenarios**: [Typical usage scenarios]

### Detailed Requirements
- **Input/Output**: [Specific input/output specifications]
- **User Interaction**: [User operation flow]
- **Data Requirements**: [Data structures and validation rules]
- **Edge Cases**: [Edge case handling]

## Design Decisions

### Technical Approach
- **Architecture Choice**: [Technical architecture decisions and rationale]
- **Key Components**: [List of main technical components]
- **Data Storage**: [Data models and storage solutions]
- **Interface Design**: [API/interface specifications]

### Constraints
- **Performance Requirements**: [Response time, throughput, etc.]
- **Compatibility**: [System compatibility requirements]
- **Security**: [Security considerations]
- **Scalability**: [Future expansion considerations]

### Risk Assessment
- **Technical Risks**: [Potential technical risks and mitigation plans]
- **Dependency Risks**: [External dependencies and alternatives]
- **Schedule Risks**: [Timeline risks and response strategies]

## Acceptance Criteria

### Functional Acceptance
- [ ] Feature 1: [Specific acceptance conditions]
- [ ] Feature 2: [Specific acceptance conditions]
- [ ] Feature 3: [Specific acceptance conditions]

### Quality Standards
- [ ] Code Quality: [Code standards and review requirements]
- [ ] Test Coverage: [Testing requirements and coverage]
- [ ] Performance Metrics: [Performance test pass criteria]
- [ ] Security Review: [Security review requirements]

### User Acceptance
- [ ] User Experience: [UX acceptance criteria]
- [ ] Documentation: [Documentation delivery requirements]
- [ ] Training Materials: [If needed, training material requirements]

## Execution Phases

### Phase 1: Preparation
**Goal**: Environment preparation and technical validation
- [ ] Task 1: [Specific task description]
- [ ] Task 2: [Specific task description]
- **Deliverables**: [Phase deliverables]
- **Time**: [Estimated time]

### Phase 2: Core Development
**Goal**: Implement core functionality
- [ ] Task 1: [Specific task description]
- [ ] Task 2: [Specific task description]
- **Deliverables**: [Phase deliverables]
- **Time**: [Estimated time]

### Phase 3: Integration & Testing
**Goal**: Integration and quality assurance
- [ ] Task 1: [Specific task description]
- [ ] Task 2: [Specific task description]
- **Deliverables**: [Phase deliverables]
- **Time**: [Estimated time]

### Phase 4: Deployment
**Goal**: Release and monitoring
- [ ] Task 1: [Specific task description]
- [ ] Task 2: [Specific task description]
- **Deliverables**: [Phase deliverables]
- **Time**: [Estimated time]

---

**Document Version**: 1.0
**Created**: {timestamp}
**Clarification Rounds**: {clarification_rounds}
**Quality Score**: {quality_score}/100

行为准则

应该做
  • 提出具体、有针对性的问题
  • 基于之前的回答逐步推进
  • 提供示例以引导用户
  • 保持对话式语气
  • 在 PRD 中总结澄清轮次
  • 使用清晰、专业的英语
  • 生成具体的规格说明
  • 在分数 ≥ 90 之前保持澄清模式
不要
  • 一次性提出所有问题
  • 未经确认就做出假设
  • 在达到 90+ 分之前生成 PRD
  • 跳过任何必需章节
  • 使用含糊或抽象的语言
  • 在用户未回应的情况下继续推进
  • 过早退出技能模式

成功标准

  • 清晰度评分 ≥ 90/100
  • 所有 PRD 章节完整且有实质内容
  • 验收标准可逐项勾选(使用 - [ ] 格式)
  • 执行阶段可操作,任务具体
  • 用户批准最终 PRD
  • 已准备好移交开发

评论

支持 Markdown