feature-review

验证

更改后，运行 make test-feature-review 验证评分逻辑。

功能评审

评审已实现的功能，并基于证据确定优先级，提出新功能建议。为已接受的建议创建 GitHub issue。

理念

功能决策依赖数据。每项功能都涉及需要评估的权衡。本技能采用结合 RICE+WSJF 的评分方式，并通过 Kano 分类确定工作优先级，为已接受的建议生成可执行的 GitHub issue。

适用场景

• 路线图评审（冲刺规划、季度评审）。
• 回顾性评估。
• 规划新的开发周期。

不适用场景

• 紧急错误修复。
• 简单的文档更新。
• 正在进行的实现（使用 scope-guard）。

快速开始

1. 清点当前功能

发现并分类现有功能：

/feature-review --inventory

2. 评分与分类

根据优先级框架评估功能：

/feature-review

3. 生成建议

审查差距并提出新功能建议：

/feature-review --suggest

4. 结合研究结果进行评分

使用 tome 插件，根据外部证据调整评分：

/feature-review --research

5. 上传到 GitHub

为已接受的建议创建 issue：

/feature-review --suggest --create-issues

工作流

阶段 1：发现功能（feature-review:inventory-complete）

通过分析以下内容识别功能：

1. 代码产物：入口点、公共 API 和配置界面。
2. 文档：README 中的列表、CHANGELOG 条目和用户文档。
3. Git 历史记录：近期的功能提交和分支。

输出： 功能清单表。

阶段 2：分类（feature-review:classified）

从两个维度对每项功能进行分类：

维度 1：主动式与响应式

类型	定义	示例
主动式	预判用户需求。	建议、预取。
响应式	响应明确输入。	表单处理、点击操作。

维度 2：静态与动态

类型	更新模式	存储模型
静态	增量式、版本化。	基于文件、缓存。
动态	持续、流式。	数据库、实时。

详情请参阅 classification-system.md。

阶段 3：评分（feature-review:scored）

应用结合 RICE+WSJF 的评分方式：

Feature Score = Value Score / Cost Score

Value Score = weighted_avg(Reach, Impact, Business Value, Time Criticality)
Cost Score = weighted_avg(Effort, Risk, Complexity)

Adjusted Score = Feature Score * Confidence

评分尺度： 斐波那契数列（1、2、3、5、8、13）。 默认权重（价值：触达范围 0.25、影响 0.30、业务价值 0.25、 时间紧迫性 0.20；成本：工作量 0.40、风险 0.30、复杂度 0.30） 以及如何覆盖这些权重，详见评分框架模块。

阈值：

• > 2.5：高优先级。
• 1.5 - 2.5：中优先级。
• < 1.5：低优先级。

框架详见 scoring-framework.md。 当单一模型不足以满足需求时，请参阅 multi-metric-evaluation-methodology.md， 其中介绍如何结合 RICE、WSJF 和 Kano，各模型的适用场景，以及如何 协调相互冲突的信号。

阶段 4：权衡分析（feature-review:tradeoffs-analyzed）

从各项质量维度评估每项功能：

维度	问题	评分范围
质量	是否能给出正确结果？	1-5
延迟	是否满足时间要求？	1-5
Token 用量	是否能高效利用上下文？	1-5
资源用量	CPU/内存占用是否合理？	1-5
冗余性	是否能妥善处理故障？	1-5
可读性	他人是否能理解？	1-5
可扩展性	是否能应对 10 倍负载？	1-5
集成性	是否能与其他部分良好协作？	1-5
API 接口范围	是否向后兼容？	1-5

评估标准详见 tradeoff-dimensions.md。

Phase 4.5：研究补充（feature-review:research-enriched）

触发条件： 使用 --research 标志。需要 tome 插件。

使用 tome 的多来源研究结果，结合外部证据调整评分因素。此阶段在权衡分析和差距分析之间运行。

1. 分派研究：为每项功能构建研究主题，并行分派 tome 渠道（code-search、discourse、papers、triz）。
2. 综合发现：使用 tome:synthesize 汇总各渠道的结果。
3. 计算调整值：根据渠道与因素的映射关系，将研究发现转换为评分因素调整值。
4. 应用调整值：根据研究调整值调整初始评分，将结果限制在 Fibonacci 量表范围内，并遵守 max_delta。
5. 呈现证据：显示调整表，并列出证据来源和理由。

完整的补充流程、调整值计算和优雅降级行为，请参阅 research-enrichment.md。

优雅降级：如果未安装 tome，则打印警告，并保持初始评分不变，继续执行。

Phase 5：差距分析与建议（feature-review:suggestions-generated）

1. 识别差距：找出缺失的 Kano 基本项。
2. 发掘机会：找出价值高、成本低的功能。
3. 标记技术债务：找出评分不断下降的功能。
4. 推荐行动：构建、改进、弃用或维护。

Phase 6：GitHub 集成（feature-review:issues-created）

1. 根据建议生成 issue 标题和正文。
2. 添加标签（enhancement、feature-review、priority/*）。
3. 链接相关 issue。
4. 创建前征求用户确认。

高分建议的延后记录： 用户确认要采取哪些建议后，任何未采取行动的高分建议（评分 > 2.5）都应保存为延后事项。 对每条被跳过的高分建议运行一次：

python3 scripts/deferred_capture.py \
  --title "<suggestion title>" \
  --source feature-review \
  --context "RICE score: <score>. <description>"

此操作会自动运行，不会提示用户。 评分为 2.5 或更低的建议无需记录。

配置

Feature-review 使用经过精心设计的默认设置，但支持自定义。

配置文件

在项目根目录创建 .feature-review.yaml：

# .feature-review.yaml
version: 1.9.3

# Scoring weights (must sum to 1.0)
weights:
  value:
    reach: 0.25
    impact: 0.30
    business_value: 0.25
    time_criticality: 0.20
  cost:
    effort: 0.40
    risk: 0.30
    complexity: 0.30

# Score thresholds
thresholds:
  high_priority: 2.5
  medium_priority: 1.5

# Tradeoff dimension weights (0.0 to disable)
tradeoffs:
  quality: 1.0
  latency: 1.0
  token_usage: 1.0
  resource_usage: 0.8
  redundancy: 0.5
  readability: 1.0
  scalability: 0.8
  integration: 1.0
  api_surface: 1.0

可用选项请参阅 configuration.md。

防护规则

以下规则适用于所有配置：

1. 最低维度数：至少评估 5 个权衡维度。
2. 置信度要求：复核置信度低于 50% 的评分。
3. 破坏性变更警告：API 接口变更必须获得确认。
4. 待办队列上限：建议队列最多包含 25 项。

必需的进度项

1. feature-review:inventory-complete
2. feature-review:classified
3. feature-review:scored
4. feature-review:tradeoffs-analyzed
5. feature-review:research-enriched（如果使用 --research）
6. feature-review:suggestions-generated
7. feature-review:issues-created（如果有此请求）

集成点

• imbue:scope-guard：为建议提供 Worthiness Scores。
• sanctum:do-issue：优先处理评分较高的 issue。
• superpowers:brainstorming：根据现有功能评估新想法。
• tome:research：用于补充评分的多来源研究（可选，使用 --research）。

输出格式

功能清单表

| Feature | Type | Data | Score | Priority | Status |
|---------|------|------|-------|----------|--------|
| Auth middleware | Reactive | Dynamic | 2.8 | High | Stable |
| Skill loader | Reactive | Static | 2.3 | Medium | Needs improvement |

研究补充表（使用 --research）

| Feature | Type | Score | Adj. | Priority | Evidence |
|---------|------|-------|------|----------|----------|
| Auth    | R/D  | 2.8   | 3.1  | High     | 3 sources |
| Loader  | R/S  | 2.3   | 2.3  | Medium   | none      |

## Research Evidence

### Code Search (GitHub)
- 12 implementations, avg 340 stars
- **Reach**: +1 (broad adoption)

### Discourse (HN/Reddit)
- 47 mentions, 78% positive
- **Impact**: +1 (strong demand)

建议报告

## Feature Suggestions

### High Priority (Score > 2.5)

1. **[Feature Name]** (Score: 2.7)
   - Classification: Proactive/Dynamic
   - Value: High reach
   - Cost: Moderate effort
   - Recommendation: Build in next sprint

相关技能

• imbue:scope-guard：防止过度设计。
• sanctum:pr-review：代码级审查（范围不同：此技能优先评估功能想法，pr-review 审查差异）。

参考资料

• scoring-framework.md：RICE+WSJF 混合模型。
• classification-system.md：维度定义。
• tradeoff-dimensions.md：质量属性。
• research-enrichment.md：由 tome 驱动的分数调整、渠道到因素的映射、优雅降级。
• multi-metric-evaluation-methodology.md：当单一模型无法满足需求时，结合 RICE、WSJF 和 Kano。
• configuration.md：自定义选项。

退出标准

• 按顺序完成全部 7 个进度阶段，直至 feature-review:issues-created；每个阶段必须先标记为完成， 才能开始下一阶段
• 每个评分功能都具有 Fibonacci 量表上的数值调整后分数和与配置阈值匹配的优先级标签（高/中/低）（默认：>2.5 为高，1.5-2.5 为中）
• 对于任何分数 >2.5 且未采取行动的建议，均通过 scripts/deferred_capture.py --source feature-review 记录，且无需 提示用户
• 仅在用户确认后创建 GitHub issue；每个 issue 均包含 enhancement、feature-review 和 priority/* 标签， 并在适用时附上相关 issue 的链接