scope-check

スコープチェック

このスキルは読み取り専用です。調査結果を報告しますが、ファイルは書き込みません。

当初の計画スコープと現在の状態を比較し、スコープクリープを検出、定量化、トリアージします。

引数： $ARGUMENTS — 文字列全体。機能名（複数語の場合もあります）、スプリント番号、またはマイルストーン名です。

---

フェーズ 1：当初の計画を探す

指定された引数に対応するベースラインスコープ文書を特定します。

• 機能名 → design/gdd/[feature].md または design/ 内の一致するファイルを読みます
• スプリント番号（例：sprint-3）→ production/sprints/sprint-003.md（/sprint-plan が出力する名前）または同様のファイルを読みます
• マイルストーン → production/milestones/[name].md を読みます

文書が見つからない場合は、見つからないファイルを報告して終了します。比較対象となる ベースラインなしで先に進まないでください。GDD はセクションごとに読みます。Grep ツールで 必要な見出し（パターン ^#、コンテンツモード）を見つけ、offset と limit を指定して該当範囲を読みます。

---

フェーズ 2：現在の状態を確認する

実際に実装済み、または進行中の内容を確認します。

• コードベースを調べ、機能／スプリントに関連するファイルを探します
• この作業に関連するコミットについて git log を確認します（git log --oneline --since=[start-date]）
• スコープへの追加が未完了であることを示す TODO/FIXME コメントを確認します
• 機能がスプリントの途中であれば、進行中のスプリント計画を確認します

---

フェーズ 3：当初のスコープと現在のスコープを比較する

比較レポートを作成します。

## Scope Check: [Feature/Sprint Name]
Generated: [Date]

### Original Scope
[List of items from the original plan]

### Current Scope
[List of items currently implemented or in progress]

> **If Phase 4 will return NOT ASSESSED, do not render the numeric block below.**
> Replace the counts and the Bloat Score with
> `[Baseline | Current state] unusable — see verdict` (whichever side could not
> be read) and give the reason. A rendered
> `Original items: 0 / Net scope change: 0%` one section above a NOT ASSESSED
> verdict re-creates the exact "0% reads as on track" hazard Phase 4 exists to
> kill, one phase earlier — and readers trust a number over a caveat.

### Scope Additions (not in original plan)
| Addition | Source | When | Justified? | Effort |
|----------|--------|------|------------|--------|
| [item] | [commit/person] | [date] | [Yes/No/Unclear] | [S/M/L] |

### Scope Removals (in original but dropped)
| Removed Item | Reason | Impact |
|-------------|--------|--------|
| [item] | [why removed] | [what's affected] |

### Bloat Score
- Original items: [N]
- Current items: [N]
- Items added: [N] (+[X]%)
- Items removed: [N]
- Net scope change: [+/-N] ([X]%)

### Risk Assessment
- **Schedule Risk**: [Low/Medium/High] — [explanation]
- **Quality Risk**: [Low/Medium/High] — [explanation]
- **Integration Risk**: [Low/Medium/High] — [explanation]

### Recommendations
1. **Cut**: [Items that should be removed to stay on schedule]
2. **Defer**: [Items that can move to a future sprint/version]
3. **Keep**: [Additions that are genuinely necessary]
4. **Flag**: [Items that need a decision from producer/creative-director]

---

フェーズ 4：判定

スコープの純増減に基づき、標準判定を割り当てます。

純増減	判定	意味
≤10%	PASS	順調 — 許容範囲内の差異です
>10–25%	CONCERNS	軽微なクリープ — 対象を絞った削減で対応可能です
>25–50%	FAIL	大幅なクリープ — 削減するか、正式にスケジュールを延長する必要があります
>50%	FAIL	制御不能 — 作業を停止し、計画を練り直して、プロデューサーにエスカレーションしてください

この表を適用する前に、割合に意味があるか確認してください。次のいずれかに該当する場合は、 計算した割合を出さず、代わりに NOT ASSESSED としてください。

• ベースライン文書は存在するが、スコープ項目が列挙されていない（見出し、 プレースホルダー、または [TO BE CONFIGURED] だけで構成されている）。フェーズ 1 で 対象となるのは、ファイルが 存在しない 場合です。ここではファイルは存在しますが空です。 項目が 0 件だと純増減が 0% となり、PASS — 順調 と判定されるため、こちらのほうが危険です。 比較は行われていません。順調なものは何もありません。
• 現在の状態を特定できない — 関連するソースファイルがなく、期間内のコミットもなく、 確認できる進行中の作業もない場合です。実際のベースラインと読み取れない現状との比較は、 0% の変化でもなければ、現在の項目数が 0 のときに算出される −100% でもありません。 どちらも表では PASS になります。
• その他の理由で分母が 0 になる。ベースライン項目がない状態から計算した割合は、 小さな数値ではありません。数値ではありません。

NOT ASSESSED は PASS より優先されます（比較が行われていない以上、スコープが順調だとは示されていません）。 一方で、CONCERNS および FAIL より下位です（測定不能なベースラインより、測定されたクリープのほうが対処に役立ちます）。

判定を目立つように出力します。

**Scope Verdict: [PASS / CONCERNS / NOT ASSESSED / FAIL]**
Net change: [+X%] — [On Track / Minor Creep / Significant Creep / Out of Control]
           [or: NOT ASSESSED — [which side could not be read, and why]]

---

フェーズ 5：次のステップ

レポートを提示した後、具体的なフォローアップを提案します。

• PASS → 対応は不要です。次のマイルストーンの前に再実行することを提案します。
• NOT ASSESSED → どちら側が読み取れなかったのか、また何をすれば評価可能になるのかを伝えます（ベースライン文書に内容を記入するか、実際に作業が行われている場所をスキルに指定します）。 同じ入力での再実行は提案しないでください。同じ未回答の結果になります。
• CONCERNS → 削減効果が最も高い追加項目を2～3個特定することを提案します。正式にスコープを再設定するには /sprint-plan update を参照します（デフォルトの最小ワークフローのようにプロジェクトにスプリント計画がない場合は、ブリーフのビルド順序を編集してスコープを再設定します）。
• FAIL → プロデューサーへのエスカレーションを推奨します。計画を立て直すには /sprint-plan update を参照します（デフォルトの最小ワークフローのようにプロジェクトにスプリント計画がない場合は、ブリーフのビルド順序を編集します）。または、タイムラインのベースラインを再設定するには /estimate を参照します。

NOT ASSESSED 以外のすべての判定の末尾に、次を付けます。

"変更を削減した後、判定が改善したか確認するため、再度 /scope-check [name] を実行してください。"

（NOT ASSESSED の場合は、上記のとおり、評価可能にするために必要な内容で終わります。同じ入力で再実行しても、同じ未回答の結果になります。）

---

ルール

• スコープクリープとは、それに相応する削減やスケジュール延長を伴わない追加のことです。
• 追加項目がすべて悪いわけではありません。発見された要件もあります。ただし、それらを認識し、考慮に入れる必要があります。
• 削減を提案する際は、あれば便利な機能よりも、プレイヤー体験の中核を維持することを優先します。
• スコープの変更は必ず数値で示します。「大きくなった気がする」では実行に移せません。「項目が35％増加」のように示します。