miko.new-cap

Files (1)

• SKILL.md

SKILL.md (first lines)

## 入力

```text
$ARGUMENTS
```

入力の形式: `<capability_name> <概要（自由記述、省略可）>`

- 例: `/miko.new-cap order_management 注文の作成・決済・キャンセルを管理する`
- 例: `/miko.new-cap notification`
- 空の場合はエラー: 「⛩️  ケイパビリティ名をお願いいたします（例: `/miko.new-cap order_management 注文管理`）」

---

## このスキルの役割

新規ケイパビリティの business_rules.md と high_level_design.md を **対話しながらゼロから定義する**。

人間の知識と AI の調査を組み合わせて正引きで作る。既存コードがあればそれを活用するが、なくても使える。

**出力:**
- `miko/<capability>/business_rules.md` — 初期ビジネスルール（実装マッピングは未決の場合あり）
- `miko/<capability>/high_level_design.md` — 初期ハイレベルデザイン

**catchup との違い:**

| 観点 | miko.new-cap | miko.catchup |
|------|-----------|---------------|
| 用途 | 新規作成 | 既存ドキュメントの更新 |
| 前提 | ドキュメントがまだない | ドキュメントが既にある |
| コード | あれば活用、なくてもOK | 既存コードから差分を検出 |
| 対話 | ヒアリング + 確認 3 箇所 | 確認 2 箇所 |

---

## 手順

### 1. 入力検証

- `$ARGUMENTS` の先頭ワードからケイパビリティ名を取得し、スネークケースに正規化する
- 残りの部分を概要として記録する

### 2. 既存ファイル確認

- `miko/<capability>/business_rules.md` または `miko/<capability>/high_level_design.md` が既に存在するか確認する
- **存在する場合はエラーとして中止する:**
  > ⛩️  `miko/<capability>/business_rules.md` が既に存在しております。
  > - 既存ドキュメントの更新は `/miko.catchup <capability>` をお使いください
  > - 既存ルールへの変更提案は `/miko.propose <capability>` をお使いください

### 3. ガイドと参考資料の読み込み

以下のファイルを **すべて** 読み込む。

**指示書（必須）:**
- `.miko/guides/business_rules_guide.md` — business_rules.md の生成ルール。判定テストの方法
- `.miko/guides/tone_guide.md` — ユーザーとの対話スタイル。**このファイルの口調・絵文字・出力言語ルールに従うこと**

**システム全体の文脈:**
- `miko/system_high_level_design.md` — システム全体のアーキテクチャ、**コード探索ガイド**（プロジェクトごとに異なる）
- `miko/glossary.md` — 用語集（存在する場合）

**実例（品質の基準）:**
- `.miko/examples/business_rules.md` — business_rules.md のサンプル
- `.miko/examples/high_level_design.md` — ケイパビリティ HLD のサンプル
- `.miko/examples/system_high_level_design.md` — システム HLD のサンプル。コード探索ガイドの書き方の参考

**プロジェクト固有の実例（あれば）:**
- `miko/` 配下に既存の business_rules.md や high_level_design.md があれば、それらも品質基準として参照する
- ただし既存 BR の書き方が常にガイドに適合しているとは限らない。ガイドと矛盾する書き方（コード語彙、UI 仕様等）は手本にしない。基準は常に `.miko/guides/business_rules_guide.md`

### 4. ケイパビリティのヒアリング

ケイパビリティの全体像を理解するために対話する。概要が十分に明確であればすぐに確認①に進む。

**ヒアリング観点:**
- **目的**: このケイパビリティは何を解決するか？ なぜ必要か？
- **主要な操作**: ユーザー（管理者/一般ユーザー/システム）は何ができるか？
- **データの核**: 中心になるデータ（テーブル/概念）は何か？
- **状態**: 状態遷移が存在するか？ ある場合はどんな状態があるか？
- **外部連携**: 他のシステムやケイパビリティとの接点は？
- **制約**: 知っている制約やビジネスルールは？（部分的でOK）

**注意:**
- 人間は全てを言語化できていないことが多い。「他に制約はありますか？」ではなく、具体的なシナリオを挙げて「この場合はどうなりますか？」と聞く
- 選択肢と推奨を提示する（「A と B がありえますが、〜の理由で A を推奨します」）
- 「わからない」「まだ決めていない」は正当な回答。未決事項として記録する

### 5. 【確認①】理解の確認

ヒアリング内容を「目的」「主要な操作」「中心データ」「状態遷移」「外部との接点」「既知の制約・ルール」「未決事項」にまとめて提示する。

加えて **ネガティブシナリオ確認** を含める:
- ヒアリングで明示されなかった境界条件を 3〜5 個、具体的な「〜は禁止ですか？許可ですか？」形式で提示する
- 以下の 5 分類を観点として使う:
  1. 境界ケース（ヒアリング内容から推測される限界値・端のケース）
  2. 操作の組み合わせによる衝突（同時操作、矛盾する操作の組み合わせ）
  3. 異常系・不正利用パターン
  4. 時間軸に関する境界（期限切れ、同時実行等）
  5. 権限・アクター間の境界
- 抽象的な「他にありますか？」ではなく、このケイパビリティ固有のシナリオを挙げる
- 回答から暗黙のルール候補を抽出する

ネガティブシナリオへのご回答もお願いする旨を明記する（「ネガティブシナリオへのご回答もお願いいたします。」等）。回答は次のステップで暗黙のルール候補を抽出するインプットとなるため、省略不可。

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

### 6. コード調査

承認された確認①に基づき、関連する既存コードと隣接ケイパビリティを探索する。

**6a. 既存コードの探索**

**探索対象:** `miko/system_high_level_design.md` の **コード探索ガイド** に従い、ケイパビリティに関連するファイルを探索する。

**探索対象外:** `.miko/` ディレクトリは miko の内部リソースであり、プロジェクトのコードではない。探索・精読の対象にしないこと。

**着目点チェックリスト（コード読解時に必ず確認する）:**
- [ ] **バリデーション**: モデル/フォームのバリデーション定義 → 制約ルールの候補

From studyplus/miko, MIT.

More from studyplus/miko