scope-guard

最も低コストな機能とは、作らずに済ませた機能です。 Scope-guard は、提案された各機能の価値、コスト、ブランチ予算を比較して評価し、 見合うものだけをリリースします。

Scope Guard

ブレインストーミング、計画、実行のワークフロー中に、Claude と人間の両方による過剰なエンジニアリングを防ぎます。提案された機能すべてについて、ビジネス価値、機会費用、ブランチの制約に照らして明示的に評価することを徹底します。

考え方

中核となる信念： すべての機能に実装する価値があるわけではありません。ほとんどのアイデアは、必要性が証明されるまでバックログに保留すべきです。

3つの柱：

1. 価値スコアリング - 構築前に価値とコストを定量化する
2. 機会費用 - 既存のバックログと比較する
3. ブランチ規律 - サイズのしきい値を守る

使用する場面

• 設計を文書化する前のブレインストーミング
• 実装計画を確定する前の計画セッション
• 「これを追加すべきか？」を判断するとき
• ブランチがしきい値に近づいたときにフック経由で自動実行する場合
• 新機能、抽象化、パターンを提案するとき

使用しない場面

• 明確で範囲が限定されたバグ修正
• ドキュメントのみの変更
• 些細な単一ファイルの編集（50行未満）
• 本番環境の緊急修正

クイックスタート

1. 機能をスコアリングする

価値スコアの計算式を使用します：

(Business Value + Time Criticality + Risk Reduction) / (Complexity + Token Cost + Scope Drift)

確認方法： --help フラグを指定してコマンドを実行し、利用可能であることを確認します。

詳しくはdecision-framework.mdを参照してください。

しきい値：

• 2.0超 → 今すぐ実装
• 1.0～2.0（両端を含む） → まず相談
• 1.0未満 → バックログに保留

2. バックログと照合する

docs/backlog/queue.md と比較します：

• 優先度の高いキュー項目を上回りますか？
• ブランチ予算に余裕はありますか？

3. ブランチ予算を確認する

デフォルト：1ブランチあたり主要機能3件

上限に達している場合は、既存の機能を削除するか、新しいブランチに分割するか、例外を正当化する必要があります。

4. しきい値を監視する

Yellow/Red ゾーンに注意します：

• 行数： 1000/1500/2000
• コミット数： 15/25/30
• 日数： 3/7/7+

監視についてはbranch-management.mdを参照してください。

中核となるワークフロー

ステップ 1：価値を計算する（scope-guard:worthiness-scored）

各要素をスコアリングします（1、2、3、5、8、13）：

• 価値要素： ビジネス価値、時間的緊急性、リスク低減
• コスト要素： 複雑さ、トークンコスト、スコープの逸脱

詳細：decision-framework.md

ステップ 2：バックログと比較する（scope-guard:backlog-compared）

1. 既存の項目がないかdocs/backlog/queue.mdを確認します
2. 価値スコアを比較します
3. 新しい項目は、優先度の高いキュー項目を上回るか、ブランチ予算内に収まる必要があります

ステップ 3：ブランチ予算を確認する（scope-guard:budget-checked）

ブランチ内の現在の機能数を数えます。予算（デフォルト：3）に達している場合、新機能を追加するには次のいずれかが必要です：

• 既存の機能を削除する、または
• 新しいブランチに分割する、または
• 理由を明記して明示的に例外を認める

ステップ 4：判断を文書化する（scope-guard:decision-documented）

結果を記録します：

• 実装する場合： 価値スコアと予算枠を記録します
• 保留する場合（必須の手順）：
  1. 直ちに GitHub issue を作成する - github-integration.mdの手順1～3を参照してください
  2. scope-guard:github-issue-createdを完了としてマークします
  3. Discussion を作成する - github-integration.mdの手順4を参照してください。 プロンプト：「判断の根拠をすべて記載した Discussion を作成します。［Y/n］」 デフォルトでは公開します。ユーザーが明示的に拒否した場合は、Discussion の作成を省略します。公開に失敗した場合は、そのまま続行します。
  4. 必要に応じて、issue のリンクを付けてdocs/backlog/queue.mdに追加します
• 却下する場合： その理由（価値が低い、範囲外など）を記録します

重要： GitHub issue が作成されるまで、保留は完了しません。これにより、ブランチがマージまたは放棄されたときのコンテキストの喪失を防ぎます。

過剰な設計を避けるルール

基本原則：

• 解決策を提案する前に、明確化のための質問をする
• 3つ目のユースケースまでは抽象化しない
• 「あると便利」な機能は後回しにする
• ブランチの予算内に収める

ルールと警告サインの詳細については、anti-overengineering.mdを参照してください。

バックログ管理

ディレクトリ構成

**Verification:** Run the command with `--help` flag to verify availability.
docs/backlog/
├── queue.md              # Active ranked queue
└── archive/
    ├── ideas.md          # Deferred feature ideas
    ├── optimizations.md  # Deferred performance work
    ├── refactors.md      # Deferred cleanup
    └── abstractions.md   # Deferred patterns

確認方法： コマンドに--helpフラグを付けて実行し、利用可能であることを確認してください。

キュールール

• アクティブキューの項目は最大10件
• 30日以上着手されていない項目はアーカイブに移動
• 毎月、またはプロジェクトのコンテキストが変わったときに再評価する

キューへの追加

後回しにする場合は、docs/backlog/queue.mdに追加してください。

| Rank | Item | Worthiness | Added | Branch/Epic | Category |
|------|------|------------|-------|-------------|----------|
| 1 | [New item description] | 1.8 | 2025-12-08 | current-branch | idea |

確認方法： コマンドに--helpフラグを付けて実行し、利用可能であることを確認してください。

追加後、価値スコアに基づいて順位を付け直してください。

統合ポイント

superpowers:brainstormingとの連携

ブレインストーミングの最後に、設計を文書化する前に：

1. 提案されたすべての機能／コンポーネントを列挙する
2. それぞれを価値の計算式で採点する
3. スコアが1.0未満の項目はバックログに回す
4. 残りの項目がブランチの予算内に収まるか確認する

自己呼び出しプロンプト：「この設計を文書化する前に、scope-guardを使って提案された機能を評価します。」

superpowers:writing-plansとの連携

実装計画を最終確定する前に：

1. 計画中のすべての項目の価値が1.0以上であること、および「検討」範囲の各項目に正当化の理由があることを確認する
2. バックログキューと照合する
3. ブランチの予算内に収まることを確認する
4. 後回しにする項目を記録する

自己呼び出しプロンプト：「この計画を最終確定する前に、scope-guardを使って範囲を確認します。」

superpowers:executing-plansの実行中

実行中に定期的に：

1. 閾値を確認する：行数、ファイル数、コミット数、日数
2. イエローゾーンに達したら警告する
3. レッドゾーンに達したら正当化の理由を必須とする

自己呼び出しプロンプト：「このブランチは大幅に増大しました。scope-guardの閾値を確認します。」

必須の進捗項目

機能を評価するときは、次のToDoを作成してください。

1. scope-guard:worthiness-scored
2. scope-guard:backlog-compared
3. scope-guard:budget-checked
4. scope-guard:github-issue-created（後回しにする場合は必須。ステップ5の実行条件です）
5. scope-guard:decision-documented

注： 項目を後回しにする場合、ステップ4（github-issue-created）は必須です。後回しにする項目についてgithub-issue-createdを完了する前に、decision-documentedを完了としてマークすることはできません。

関連スキル

• superpowers:brainstorming - このスキルがガードするアイデア創出ワークフロー
• superpowers:writing-plans - このスキルが検証する計画ワークフロー
• imbue:review-core - レビュー手法のパターン
• imbue:karpathy-principles - 範囲、シンプルさ、外科的な編集、検証可能な目標を扱う、4つの原則を簡潔にまとめたもの
• ゲートスキル連携の全体図については、docs/quality-gates.md#skill-level-quality-gate-compositionを参照してください

モジュールリファレンス

• decision-framework.md - 価値の計算式、スコアリング、閾値
• github-integration.md - 後回しにする項目のイシュー作成（必須）
• anti-overengineering.md - ルール、パターン、警告サイン
• branch-management.md - 閾値、監視、ゾーン
• baseline-scenarios.md - テストシナリオと検証

終了基準

• 提案されたすべての機能について、次の式に基づいて価値スコアを算出し、対応方針を決定します。 (Business Value + Time Criticality + Risk Reduction) / (Complexity + Token Cost + Scope Drift) 対応方針は、実装（>2.0）、検討（1.0-2.0）、または延期（<1.0）です。
• scope-guard:decision-documented を完了とする前に、延期項目の GitHub issue を作成します。issue の URL を todo に記録します。
• ブランチの上限を確認します。主要機能が 3 つある場合、新しい機能を追加するには、既存の機能を 1 つ削除するか、新しいブランチに分割するか、理由を明記した明示的な書面による例外承認が必要です。
• ブランチのしきい値ゾーンを確認します（行数 1000/1500/2000、コミット数 15/25/30、日数 3/7/7+）。イエローゾーンでは警告を出し、レッドゾーンでは正当な理由がない限りブロックします。