feature-spec-reviewing

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Feature Spec Reviewing

功能规格说明书评审

Purpose

目的

Systematically review feature specifications to ensure they are complete, testable, and ready for implementation. Catches gaps in edge cases and error handling before engineering work begins.

系统地评审功能规格说明书，确保其完整、可测试且已准备好进入实施阶段。在工程工作开始前发现边缘场景和错误处理方面的漏洞。

When NOT to Use This Skill

不适用场景

Creating feature specs (use
```
feature-spec-writing
```
instead)
Reviewing PRDs (use
```
prd-reviewing
```
instead)
Reviewing technical specs (use
```
technical-spec-reviewing
```
instead)
Code review (different domain)
No spec exists yet (nothing to review)

创建功能规格说明书（请使用
```
feature-spec-writing
```
技能）
评审PRD（请使用
```
prd-reviewing
```
技能）
评审技术规格说明书（请使用
```
technical-spec-reviewing
```
技能）
代码评审（属于不同领域）
尚未生成规格说明书（无评审对象）

Review Workflow

评审流程

Step 1: Document Analysis

步骤1：文档分析

Read the entire feature spec and assess structure:

markdown

Initial Assessment:
- [ ] Feature definition is clear one-sentence
- [ ] Primary user story present
- [ ] Acceptance criteria exist
- [ ] Error states documented
- [ ] Definition of Done checklist exists

Red Flags:

Feature definition is vague or multi-sentence
Multiple unrelated user stories bundled
Only happy path documented
No error handling defined

通读完整的功能规格说明书并评估其结构：

markdown

初始评估：
- [ ] 功能定义为清晰的单句表述
- [ ] 包含核心用户故事
- [ ] 存在验收标准
- [ ] 已记录错误状态
- [ ] 存在完成定义检查清单

警示信号：

功能定义模糊或为多句表述
捆绑多个不相关的用户故事
仅记录了正常流程
未定义错误处理机制

Step 2: Feature Definition Review

步骤2：功能定义评审

Evaluate the feature definition:

markdown

Feature Definition Checklist:
1. Is it a single sentence?
2. Does it follow [Verb] [what] for [whom] to [outcome]?
3. Is the scope clear and bounded?
4. Is it too broad (actually multiple features)?
5. Does it align with parent PRD (if applicable)?

Severity Guide:

Issue	Severity
No feature definition	BLOCKER
Multi-feature bundling	BLOCKER
Vague definition	CRITICAL
Misaligned with PRD	MAJOR
Minor clarity issues	MINOR

评估功能定义的合理性：

markdown

功能定义检查清单：
1. 是否为单句表述？
2. 是否遵循「动作+内容+对象+目标」的结构？
3. 范围是否清晰且明确？
4. 是否过于宽泛（实际包含多个功能）？
5. 是否与上级PRD对齐（若适用）？

严重程度指南：

问题	严重程度
无功能定义	BLOCKER
多功能捆绑	BLOCKER
定义模糊	CRITICAL
与PRD不一致	MAJOR
轻微清晰度问题	MINOR

Step 3: User Story Quality

步骤3：用户故事质量评估

Evaluate user story against standard format:

markdown

User Story Checklist:
- [ ] Follows "As a... I want... So that..." format
- [ ] User type is specific (not just "user")
- [ ] Goal is concrete and achievable
- [ ] Benefit explains real value
- [ ] Story is right-sized (not an epic)
- [ ] Variants cover key user paths (if applicable)

Common Issues:

Issue	Example	Severity
Missing format	"Add quick view feature"	CRITICAL
Generic user	"As a user" instead of "As a shopper"	MAJOR
No benefit	Missing "so that" clause	MAJOR
Epic-sized	Entire workflow in one story	CRITICAL

对照标准格式评估用户故事：

markdown

用户故事检查清单：
- [ ] 遵循「作为...，我希望...，以便...」的格式
- [ ] 用户类型具体（而非笼统的「用户」）
- [ ] 目标具体且可实现
- [ ] 收益说明了实际价值
- [ ] 故事粒度合适（非史诗级需求）
- [ ] 变体覆盖了核心用户路径（若适用）

常见问题：

问题	示例	严重程度
不符合格式	"添加快速查看功能"	CRITICAL
用户类型笼统	使用「作为用户」而非「作为购物者」	MAJOR
无收益说明	缺少「以便...」部分	MAJOR
史诗级粒度	单个故事包含完整工作流	CRITICAL

Step 4: Acceptance Criteria Review

步骤4：验收标准评审

Evaluate acceptance criteria for completeness and testability:

markdown

Criteria Coverage Checklist:
- [ ] Happy path (primary success scenario)
- [ ] Input validation (valid and invalid)
- [ ] Edge cases (boundaries, empty, max)
- [ ] Error handling (network, server, timeout)
- [ ] Performance expectations
- [ ] Security requirements (if applicable)
- [ ] Accessibility (if UI feature)

Testability Test: For each criterion, ask: "Can QA write a test case from this?"

markdown

❌ Untestable: "Quick view should be fast"
✅ Testable: "Quick view modal appears within 300ms of hover"

❌ Untestable: "Handle errors gracefully"
✅ Testable: "On network failure, show 'Connection lost' and retry button"

❌ Untestable: "Work on mobile"
✅ Testable: "On screens < 768px, bottom sheet replaces modal"

评估验收标准的完整性和可测试性：

markdown

标准覆盖检查清单：
- [ ] 正常流程（核心成功场景）
- [ ] 输入验证（有效/无效输入）
- [ ] 边缘场景（边界值、空值、最大值）
- [ ] 错误处理（网络、服务器、超时）
- [ ] 性能预期
- [ ] 安全要求（若适用）
- [ ] 可访问性（若为UI功能）

可测试性验证： 针对每条标准，提问：「QA能否据此编写测试用例？」

markdown

❌ 不可测试："快速查看应足够快"
✅ 可测试："鼠标悬停后300ms内弹出快速查看模态框"

❌ 不可测试："优雅处理错误"
✅ 可测试："网络失败时，显示「连接中断」提示及重试按钮"

❌ 不可测试："支持移动端"
✅ 可测试："屏幕宽度<768px时，使用底部弹窗替代模态框"

Step 5: Edge Case Coverage

步骤5：边缘场景覆盖验证

Verify edge cases are comprehensive:

markdown

Edge Case Categories:
□ Empty state (no data, first use)
□ Minimum values (0, 1, empty string)
□ Maximum values (limits, overflow)
□ Null/undefined handling
□ Concurrent access (race conditions)
□ Timeout scenarios
□ Partial failure (some items succeed, some fail)
□ Network conditions (slow, offline, reconnect)

Coverage Scoring:

Coverage	Rating	Action
7-8 categories	Strong	Approve
5-6 categories	Adequate	Minor improvements
3-4 categories	Weak	Critical - add cases
< 3 categories	Missing	Blocker - major gaps

验证边缘场景的全面性：

markdown

边缘场景分类：
□ 空状态（无数据、首次使用）
□ 最小值（0、1、空字符串）
□ 最大值（限制值、溢出）
□ Null/未定义值处理
□ 并发访问（竞态条件）
□ 超时场景
□ 部分失败（部分项成功、部分项失败）
□ 网络状况（慢速、离线、重连）

覆盖度评分：

覆盖数量	评级	行动建议
7-8类	优秀	批准
5-6类	合格	小幅优化
3-4类	薄弱	关键问题 - 补充场景
<3类	缺失	阻塞问题 - 重大漏洞

Step 6: Error States Review

步骤6：错误状态评审

Evaluate error states matrix:

markdown

Error States Checklist:
- [ ] All API calls have failure handling
- [ ] User-facing messages are helpful
- [ ] System actions are appropriate
- [ ] Recovery paths are clear
- [ ] Logging/alerting defined

Error Categories to Verify:

Category	Example Errors
Input	Invalid format, missing required, too long
Network	Offline, timeout, partial response
Server	500, 503, rate limit
Business Logic	Conflict, not found, unauthorized
External	Third-party API down, invalid response

评估错误状态矩阵：

markdown

错误状态检查清单：
- [ ] 所有API调用均有失败处理机制
- [ ] 面向用户的提示信息有帮助性
- [ ] 系统操作合理
- [ ] 恢复路径清晰
- [ ] 已定义日志/告警机制

需验证的错误分类：

分类	示例错误
输入	格式无效、缺少必填项、过长
网络	离线、超时、部分响应
服务器	500、503、速率限制
业务逻辑	冲突、未找到、未授权
外部依赖	第三方API故障、响应无效

Step 7: Technical Feasibility

步骤7：技术可行性评估

Assess implementation readiness:

markdown

Feasibility Assessment:
- [ ] Dependencies identified and available
- [ ] Non-functional requirements realistic
- [ ] Data requirements clear
- [ ] No obvious technical blockers
- [ ] Performance targets achievable

评估实施就绪度：

markdown

可行性评估：
- [ ] 已识别依赖项且可获取
- [ ] 非功能性需求合理
- [ ] 数据需求清晰
- [ ] 无明显技术阻塞点
- [ ] 性能目标可实现

Step 8: Parent PRD Alignment

步骤8：与上级PRD对齐验证

If feature has parent PRD:

markdown

Alignment Check:
- [ ] Feature implements specific PRD user story
- [ ] Acceptance criteria align with PRD scope
- [ ] Out-of-scope items match PRD exclusions
- [ ] Success metrics support PRD goals

若功能存在上级PRD：

markdown

对齐检查：
- [ ] 功能实现了PRD中的特定用户故事
- [ ] 验收标准与PRD范围对齐
- [ ] 超出范围的内容与PRD排除项一致
- [ ] 成功指标支持PRD目标

Step 9: Generate Review Report

步骤9：生成评审报告

Compile findings using the template below.

使用以下模板整理评审结果。

Severity Levels

严重程度等级

Level	Definition	Action
BLOCKER	Cannot implement	Must fix before approval
CRITICAL	Will cause major issues	Should fix before sprint
MAJOR	Will cause rework	Should fix soon
MINOR	Nice to have	Can address during implementation

等级	定义	行动建议
BLOCKER	无法实施	批准前必须修复
CRITICAL	会导致重大问题	迭代开始前应修复
MAJOR	会导致返工	应尽快修复
MINOR	锦上添花的优化	可在实施过程中处理

Severity Examples

严重程度示例

BLOCKER:

No feature definition or user story
Multiple features bundled as one
No acceptance criteria
Missing critical error handling

CRITICAL:

Acceptance criteria not testable
Missing edge case categories
No performance requirements
Conflicting requirements

MAJOR:

Vague user story benefit
Incomplete error states matrix
Missing accessibility considerations
Technical dependencies unclear

MINOR:

Minor clarity improvements
Additional edge cases nice to have
Formatting inconsistencies
Could add more detail

BLOCKER：

无功能定义或用户故事
多个功能捆绑为一个
无验收标准
缺失关键错误处理

CRITICAL：

验收标准不可测试
缺失边缘场景分类
无性能要求
需求冲突

MAJOR：

用户故事收益模糊
错误状态矩阵不完整
缺失可访问性考虑
技术依赖不明确

MINOR：

轻微清晰度优化
可补充额外边缘场景
格式不一致
可增加更多细节

Review Report Template

评审报告模板

markdown

undefined

markdown

undefined

Feature Spec Review: [Feature Name]

功能规格说明书评审：[功能名称]

Reviewer: [Name] Review Date: [Date] Spec Version: [Version] Spec Author: [Name]

评审人： [姓名] 评审日期： [日期] 规格版本： [版本号] 规格作者： [姓名]

Summary

摘要

Status: [APPROVE / APPROVE WITH CHANGES / NEEDS REVISION / MAJOR REVISION]

Implementation Readiness: [Ready / Ready After Fixes / Not Ready]

Assessment: [2-3 sentences on overall quality and readiness]

状态： [批准/带条件批准/需修订/需大幅修订]

实施就绪度： [就绪/修复后就绪/未就绪]

评估： [2-3句话说明整体质量和就绪度]

Findings by Severity

按严重程度分类的发现

Blockers

阻塞问题

[Finding with location and recommendation]

[问题位置及建议]

Critical

关键问题

[Finding with location and recommendation]

[问题位置及建议]

Major

主要问题

[Finding with location and recommendation]

[问题位置及建议]

Minor

次要问题

[Finding with location and recommendation]

[问题位置及建议]

Section Ratings

各部分评级

Section	Rating	Notes
Feature Definition	[Strong/Adequate/Weak/Missing]
User Story	[Strong/Adequate/Weak/Missing]
Acceptance Criteria	[Strong/Adequate/Weak/Missing]
Edge Cases	[Strong/Adequate/Weak/Missing]
Error States	[Strong/Adequate/Weak/Missing]
Technical Constraints	[Strong/Adequate/Weak/Missing]

部分	评级	备注
功能定义	[优秀/合格/薄弱/缺失]
用户故事	[优秀/合格/薄弱/缺失]
验收标准	[优秀/合格/薄弱/缺失]
边缘场景	[优秀/合格/薄弱/缺失]
错误状态	[优秀/合格/薄弱/缺失]
技术约束	[优秀/合格/薄弱/缺失]

Edge Case Coverage

边缘场景覆盖

□ Empty state - [Covered/Missing] □ Minimum values - [Covered/Missing] □ Maximum values - [Covered/Missing] □ Null handling - [Covered/Missing] □ Concurrent access - [Covered/Missing] □ Timeout scenarios - [Covered/Missing] □ Partial failure - [Covered/Missing] □ Network conditions - [Covered/Missing]

Coverage Score: [X/8]

□ 空状态 - [已覆盖/缺失] □ 最小值 - [已覆盖/缺失] □ 最大值 - [已覆盖/缺失] □ Null值处理 - [已覆盖/缺失] □ 并发访问 - [已覆盖/缺失] □ 超时场景 - [已覆盖/缺失] □ 部分失败 - [已覆盖/缺失] □ 网络状况 - [已覆盖/缺失]

覆盖度得分： [X/8]

Testability Assessment

可测试性评估

Can QA write tests? [Yes / Partially / No]

Problematic Criteria:

[Criterion that's not testable and why]

QA能否编写测试用例？ [是/部分可以/否]

存在问题的标准：

[不可测试的标准及原因]

Strengths

优势

[What the spec does well]
[What the spec does well]

[规格的优点]
[规格的优点]

Risks

风险

[Risk and suggested mitigation]
[Risk and suggested mitigation]

[风险及建议缓解方案]
[风险及建议缓解方案]

Questions for Author

向作者提出的问题

[Clarifying question]
[Clarifying question]

[澄清问题]
[澄清问题]

Recommendation

建议

[Detailed recommendation with specific next steps]

undefined

[详细建议及具体后续步骤]

undefined

Examples

示例

Example 1: Strong Spec (Minor Feedback)

示例1：优秀规格（仅需轻微反馈）

Status: APPROVE WITH CHANGES

Assessment: Well-structured feature spec with clear definition and comprehensive acceptance criteria. Minor gaps in timeout handling edge cases.

Findings:

MINOR: AC for network timeout missing retry limit
MINOR: Consider adding concurrent edit scenario

Edge Case Coverage: 7/8 (Missing: Partial failure)

状态： 带条件批准

评估： 结构清晰的功能规格说明书，定义明确且验收标准全面。仅在超时处理边缘场景存在轻微漏洞。

发现：

MINOR：网络超时的验收标准缺失重试限制
MINOR：建议增加并发编辑场景

边缘场景覆盖度： 7/8（缺失：部分失败）

Example 2: Needs Work (Critical Gaps)

示例2：需优化（存在关键漏洞）

Status: NEEDS REVISION

Assessment: Good user story but acceptance criteria lack edge case coverage. Error states incomplete. Should add missing scenarios before sprint planning.

Findings:

CRITICAL: Only happy path acceptance criteria defined
CRITICAL: Error states matrix incomplete (missing network, timeout)
MAJOR: Performance requirements not specified
MAJOR: Mobile responsive behavior undefined

Edge Case Coverage: 2/8

状态： 需修订

评估： 用户故事质量良好，但验收标准缺少边缘场景覆盖，错误状态不完整。迭代规划前应补充缺失场景。

发现：

CRITICAL：仅定义了正常流程的验收标准
CRITICAL：错误状态矩阵不完整（缺失网络、超时场景）
MAJOR：未指定性能要求
MAJOR：未定义移动端响应式行为

边缘场景覆盖度： 2/8

Example 3: Major Problems

示例3：重大问题

Status: MAJOR REVISION REQUIRED

Assessment: Feature definition describes multiple features bundled together. Recommend splitting into separate specs.

Findings:

BLOCKER: "User authentication" bundles login, signup, password reset, MFA
BLOCKER: No acceptance criteria for individual flows
CRITICAL: User story is epic-sized
MAJOR: No error handling defined

Recommendation: Split into 4 separate feature specs.

状态： 需大幅修订

评估： 功能定义包含多个捆绑的功能，建议拆分为独立的规格说明书。

发现：

BLOCKER：「用户认证」捆绑了登录、注册、密码重置、多因素认证
BLOCKER：各流程无验收标准
CRITICAL：用户故事为史诗级粒度
MAJOR：未定义错误处理

建议： 拆分为4份独立的功能规格说明书。

Integration with Other Skills

与其他技能的集成

Reviews Output From:

```
feature-spec-writing
```
- Validate completed feature specs

Leads To:

```
technical-spec-writing
```
- After spec approved
```
sparc-planning
```
- After spec approved

评审输出来源：

```
feature-spec-writing
```
- 验证已完成的功能规格说明书

触发后续技能：

```
technical-spec-writing
```
- 规格批准后
```
sparc-planning
```
- 规格批准后

Resources

资源

See CHECKLIST.md for comprehensive review checklist

详见CHECKLIST.md获取完整评审清单

feature-spec-reviewing

Original

Translation

Feature Spec Reviewing

功能规格说明书评审

Purpose

目的

When NOT to Use This Skill

不适用场景

Review Workflow

评审流程

Step 1: Document Analysis

步骤1：文档分析

Step 2: Feature Definition Review

步骤2：功能定义评审

Step 3: User Story Quality

步骤3：用户故事质量评估

Step 4: Acceptance Criteria Review

步骤4：验收标准评审

Step 5: Edge Case Coverage

步骤5：边缘场景覆盖验证

Step 6: Error States Review

步骤6：错误状态评审

Step 7: Technical Feasibility

步骤7：技术可行性评估

Step 8: Parent PRD Alignment

步骤8：与上级PRD对齐验证

Step 9: Generate Review Report

步骤9：生成评审报告

Severity Levels

严重程度等级

Severity Examples

严重程度示例

Review Report Template

评审报告模板

Feature Spec Review: [Feature Name]

功能规格说明书评审：[功能名称]

Summary

摘要

Findings by Severity

按严重程度分类的发现

Blockers

阻塞问题

Critical

关键问题

Major

主要问题

Minor

次要问题

Section Ratings

各部分评级

Edge Case Coverage

边缘场景覆盖

Testability Assessment

可测试性评估

Strengths

优势

Risks

风险

Questions for Author

向作者提出的问题

Recommendation

建议

Examples

示例

Example 1: Strong Spec (Minor Feedback)

示例1：优秀规格（仅需轻微反馈）

Example 2: Needs Work (Critical Gaps)

示例2：需优化（存在关键漏洞）

Example 3: Major Problems

示例3：重大问题

Integration with Other Skills

与其他技能的集成

Resources

资源

Related Agent

相关Agent