miko.split-proposal

Files (3)

• SKILL.md
• cross_capability_sub_proposal.md · examples/
• umbrella_proposal.md · examples/

SKILL.md (first lines)

## 入力

```text
$ARGUMENTS
```

入力の形式: `<proposal_path>`

- 例: `/miko.split-proposal miko/order_management/proposals/2026-03-18-cancel-notify.md`
- 空の場合はエラー: 「⛩️  プロポーザルのパスをお願いいたします（例: `/miko.split-proposal miko/order_management/proposals/2026-03-18-cancel-notify.md`）」

---

## このスキルの役割

既存のプロポーザルを、PR 単位でフェーズ分割して実装するために、親プロポーザル（umbrella proposal）+ サブプロポーザルに分割する。

**前提:** 分割元のプロポーザルは `/miko.propose` で作成済みであること。`/miko.harae` による検証も完了していることが望ましい（分割前に検証しておくと手戻りが少ない）。

**想定フロー:**

```
/miko.propose → proposal 作成
/miko.harae → proposal 検証（推奨）
/miko.split-proposal → 親 + サブに分割
→ 各サブに対して /miko.speckit.specify → 実装フロー
```

---

## 手順

### 1. 入力検証・資料読み込み

**入力検証:**
- `$ARGUMENTS` をプロポーザルのパスとして使用。パスからケイパビリティ名を抽出
- 選択されたプロポーザルの先頭に `<umbrella-proposal>` マーカーがある場合、既に親プロポーザルである。エラーとして中止する:
  > ⛩️  このプロポーザルは既に親プロポーザル（umbrella proposal）です。サブプロポーザルの追加・修正が必要な場合はお知らせください。
- 選択されたプロポーザルの先頭に `<sub-proposal@{親のmiko相対パス}>` マーカーがある場合、既にサブプロポーザルである。エラーとして中止する:
  > ⛩️  このプロポーザルは既にサブプロポーザルです。分割対象は未分割のプロポーザルのみです。

**祓え検証の確認:**
- プロポーザルに「祓え検証」セクションがない場合、先に `/miko.harae` の実施を提案する:
  > ⛩️  このプロポーザルにはまだ祓え検証が行われていないようです。分割前に `/miko.harae <capability> <proposal>` で検証しておくと手戻りが少なくなります。スキップして分割に進むこともできますが、いかがいたしましょうか？
- スキップする場合はそのまま次に進む

**読み込むファイル:**
- `.miko/guides/tone_guide.md` — 対話スタイル。**このファイルの口調・絵文字・出力言語ルールに従うこと**
- `.claude/skills/miko.split-proposal/examples/umbrella_proposal.md` — 親プロポーザルのサンプル
- `.claude/skills/miko.split-proposal/examples/cross_capability_sub_proposal.md` — 横断サブプロポーザルのサンプル（横断分割の場合）
- 指定されたプロポーザルファイル
- `miko/system_high_level_design.md` — ケイパビリティ一覧の確認（cross-cap 分割時に使用）
- 横断分割の場合: 影響先ケイパビリティの `business_rules.md` と `high_level_design.md` も読み込む

### 2. プロポーザルの分析

プロポーザルの内容を分析し、フェーズ分割の案を策定する。

**分割の観点:**
- 独立した関心事ごとに分ける（例: 基盤整備 → 機能追加 → 連携拡張）
- DB マイグレーションや環境変数の追加など、インフラ・環境の変更は独立したフェーズに切り出す（デプロイリスクの分離）
- 各フェーズが単独で PR としてマージ可能になるようにする
- フェーズ間の依存関係を最小限にする（Phase N+1 は Phase N の完了を前提としてよいが、循環依存は不可）
- BR 変更と機能仕様を適切なフェーズに振り分ける
- **フェーズ数は最大 3〜4 に抑える。** 4 フェーズは相当大きな変更の場合のみ。それ以上に分かれそうな場合はスコープの見直しを提案する

**クロスケイパビリティの分割（`<needs-split>` マーカーあり、または「他ケイパビリティへの影響」セクションあり）:**

プロポーザルに「他ケイパビリティへの影響」セクションがある場合、**フェーズ × ケイパビリティのマトリクス**でサブプロポーザルを生成する。

- あるフェーズにメインケイパビリティだけ、影響先だけが入ることもある（全フェーズが必ず複数ケイパビリティである必要はない）
- 「他ケイパビリティへの影響」セクションの BR 変更を、適切なフェーズの影響先サブプロポーザルに振り分ける

### 3. 【確認】分割案の提示

以下を提示して確認を取る:

- フェーズ数と各フェーズの概要
- 各フェーズに含まれる BR 変更・機能仕様の振り分け
- フェーズ間の依存関係
- **クロスケイパビリティの場合:** フェーズ × ケイパビリティのマトリクス表を提示する

フィードバックがあれば反映して再提示、承認されたら次に進む。

### 4. ファイル生成

承認された分割案に基づき、以下のファイルを生成する。

**親プロポーザル（新規作成）:**
- 元のプロポーザルには変更を加えない（分割完了後に削除を提案する）
- ファイル先頭に `<umbrella-proposal>` マーカーを付与
- 背景・動機（元のプロポーザルから引き継ぐ）
- `## フェーズ構成` セクション — ネストリスト形式。各フェーズにサブプロポーザルへのリンクを配置する。**リンクのパスは `miko/` からの相対パスで記述する**（ケイパビリティを跨ぐため、`proposals/` からの相対パスだと壊れやすい）
- 検討・却下した代替案（元のプロポーザルから引き継ぐ + 分割に関する判断を追加）
- BR 変更・機能仕様は含めない（サブに振り分けるため）
- 「他ケイパビリティへの影響」セクションは含めない（影響先サブに分離するため）
- 元のプロポーザルに「祓え検証」セクションがある場合、**その内容は各サブプロポーザルに振り分ける**（フェーズ固有の指摘は該当サブに、フェーズをまたぐ指摘は親に残す）。横断プロポーザルで影響先ケイパビリティごとのサブセクション（例: `### 影響先: notification`）がある場合、その指摘は対応する影響先サブプロポーザルに振り分ける

フェーズ構成の記述例:
```markdown
## フェーズ構成

- [ ] Phase 1 — メール通知基盤
  - [メール通知の実装](miko/order_management/proposals/2026-03-18-cancel-notify-phase1.md)
  - [通知配信ルール追加](miko/notification/proposals/2026-03-18-cancel-notify-phase1.md)
- [ ] Phase 2 — Slack 連携
  - [Slack 連携の実装](miko/order_management/proposals/2026-03-18-cancel-notify-phase2.md)
```

影響先ケイパビリティのサブプロポーザルがない場合も同じ形式。パスからケイパビリティが読み取れる。

**各フェーズのメインサブプロポーザル（新規作成）:**
- ファイル先頭に `<sub-proposal@{親のmiko相対パス}>` マーカーを付与（例: `<sub-proposal@order_management/proposals/2026-03-18-cancel-notify-umbrella.md>`）
- 背景・動機（このフェーズの動機。親プロポーザルへの `miko/` からの相対パスリンクで参照しつつ、このフェーズで達成すること）
- ビジネスルールの変更（元のプロポーザルから該当分を振り分け）
- 機能仕様（元のプロポーザルから該当分を振り分け）
- 影響範囲（このフェーズに関連する範囲）
- 祓え検証（元のプロポーザルに祓え検証があれば、メインケイパビリティの指摘のうち該当フェーズ分を振り分け）
- **「他ケイパビリティへの影響」セクションは含めない**（影響先サブに分離するため）

From studyplus/miko, MIT.

More from studyplus/miko