feature-review

検証

変更後にスコアリングロジックを検証するには、make test-feature-review を実行します。

機能レビュー

実装済みの機能をレビューし、エビデンスに基づいて優先順位を付け、新しい機能を提案します。採用された提案については GitHub イシューを作成します。

基本方針

機能に関する決定はデータに基づいて行います。すべての機能にはトレードオフが伴い、評価が必要です。このスキルでは、RICE と WSJF のハイブリッドスコアリングに Kano 分類を組み合わせて作業の優先順位を付け、採用された提案に対して実行可能な GitHub イシューを作成します。

使用する場面

• ロードマップのレビュー（スプリント計画、四半期レビュー）。
• 振り返り評価。
• 新しい開発サイクルの計画。

使用しない場面

• 緊急のバグ修正。
• 簡単なドキュメントの更新。
• 実装作業の進行中（scope-guard を使用してください）。

クイックスタート

1. 現在の機能を一覧化する

既存の機能を洗い出し、分類します：

/feature-review --inventory

2. スコアを付けて分類する

優先順位付けのフレームワークに照らして機能を評価します：

/feature-review

3. 提案を作成する

不足している点を確認し、新しい機能を提案します：

/feature-review --suggest

4. 調査結果を加味したスコアリング

tome プラグインを使用し、外部のエビデンスに基づいてスコアを調整します：

/feature-review --research

5. GitHub にアップロードする

採用された提案についてイシューを作成します：

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

ワークフロー

フェーズ 1：機能の発見（feature-review:inventory-complete）

以下を分析して機能を特定します：

1. コード成果物：エントリーポイント、公開 API、設定項目。
2. ドキュメント：README の一覧、CHANGELOG の項目、ユーザー向けドキュメント。
3. Git の履歴：最近の機能コミットとブランチ。

**出力：**機能一覧表。

フェーズ 2：分類（feature-review:classified）

2 つの軸に沿って各機能を分類します：

軸 1：プロアクティブ対リアクティブ

種類	定義	例
プロアクティブ	ユーザーのニーズを予測します。	提案、先読み取得。
リアクティブ	明示的な入力に応答します。	フォーム処理、クリック操作。

軸 2：静的対動的

種類	更新パターン	ストレージモデル
静的	段階的、バージョン管理されます。	ファイルベース、キャッシュ。
動的	継続的、ストリーミング。	データベース、リアルタイム。

詳細は分類システムを参照してください。

フェーズ 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：優先度低。

フレームワークについてはスコアリングフレームワークを参照してください。 1 つのモデルでは不十分な場合は、複数指標による評価方法 を参照してください。RICE、WSJF、Kano を組み合わせる方法、 各モデルの適用場面、相反するシグナルの 調整方法について説明しています。

フェーズ 4：トレードオフ分析（feature-review:tradeoffs-analyzed）

各機能を品質の各側面から評価します：

側面	質問	尺度
品質	正確な結果を提供しますか？	1-5
レイテンシ	時間要件を満たしていますか？	1-5
トークン使用量	コンテキストを効率的に使用していますか？	1-5
リソース使用量	CPU／メモリの使用量は妥当ですか？	1-5
冗長性	障害に適切に対処できますか？	1-5
可読性	他の人が理解できますか？	1-5
スケーラビリティ	負荷が 10 倍になっても対応できますか？	1-5
統合性	他の機能とうまく連携しますか？	1-5
API サーフェス	後方互換性がありますか？	1-5

評価基準についてはトレードオフの各側面を参照してください。

フェーズ 4.5：調査による充実（feature-review:research-enriched）

トリガー： --research フラグ。tome プラグインが必要です。

tome のマルチソース調査を使い、外部のエビデンスに基づいてスコアリング要因を調整します。このフェーズは、トレードオフ分析とギャップ分析の間に実行されます。

1. 調査を実行する：各機能について調査トピックを作成し、tome の各チャネル（code-search、discourse、papers、triz）に並列で処理を依頼します。
2. 調査結果を統合する：tome:synthesize を使い、各チャネルの結果を統合します。
3. 差分を計算する：チャネルと要因の対応付けに基づき、調査結果をスコアリング要因の調整に反映します。
4. 差分を適用する：初期スコアを調査による差分で調整し、フィボナッチ尺度の範囲内に収め、max_delta を遵守します。
5. エビデンスを提示する：調整内容、エビデンスの出典、根拠を記載した表を表示します。

充実化プロトコル、差分の計算、グレースフルデグラデーションの動作については、research-enrichment.md を参照してください。

グレースフルデグラデーション： tome がインストールされていない場合は警告を表示し、初期スコアを変更せずに続行します。

フェーズ 5：ギャップ分析と提案（feature-review:suggestions-generated）

1. ギャップを特定する：不足している Kano の基本要件。
2. 機会を提示する：価値が高く、労力が少ない機能。
3. 技術的負債にフラグを付ける：スコアが低下している機能。
4. 対応を推奨する：構築、改善、非推奨化、または維持。

フェーズ 6：GitHub 連携（feature-review:issues-created）

1. 提案から Issue のタイトルと本文を作成します。
2. ラベル（enhancement、feature-review、priority/*）を適用します。
3. 関連する Issue へのリンクを追加します。
4. 作成前にユーザーの確認を求めます。

高スコアの提案を保留項目として記録する： ユーザーが対応する提案を確認した後、対応しない高スコアの提案（スコア > 2.5）は、保留項目として保存してください。 対応を見送った高スコアの提案ごとに、1 回実行します：

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 Score を提供します。
• 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 まで順番にすべて完了していること。次のフェーズを開始する前に、各フェーズを完了済みとしてマークします。
• スコアリングされたすべての機能に、フィボナッチ数列に基づく数値の Adjusted Score と、設定済みのしきい値（デフォルト：>2.5 は High、1.5-2.5 は Medium）に一致する Priority ラベルがあること
• スコアが 2.5 を超える提案のうち、対応しなかったものは、ユーザーに確認することなく scripts/deferred_capture.py --source feature-review を使って記録すること
• GitHub イシューはユーザーの確認後にのみ作成すること。各イシューには enhancement、feature-review、priority/* ラベルを含め、該当する場合は関連イシューへのリンクを含めること