miko.catchup

Files (1)

• SKILL.md

SKILL.md (first lines)

## 入力

```text
$ARGUMENTS
```

入力が空の場合はエラー: 「⛩️  ケイパビリティ名をお願いいたします（例: `/miko.catchup order_management`）」

---

## 手順

### 1. 入力検証

- `$ARGUMENTS` からケイパビリティ名を取得し、スネークケースに正規化する

### 2. system_high_level_design.md の追従確認

ユーザーに確認する:

> ⛩️  キャッチアップの前に確認でございます。`/miko.catchup-system-hld` は実施済みでしょうか？
> `system_high_level_design.md` が古いままですと、コード探索のスコープがずれる恐れがございます。

- ユーザーが「実施済み」「不要」等と回答した場合 → 次に進む
- ユーザーが「まだ」「やってほしい」等と回答した場合 → `/miko.catchup-system-hld` の実行を案内し、完了後に `/miko.catchup` を再実行するよう伝えて中止する

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

- `miko/<capability>/business_rules.md` が存在するか確認する
- **存在しない場合はエラーとして中止する:**
  > ⛩️  `miko/<capability>/business_rules.md` が見つかりません。
  > - 新規作成は `/miko.new-cap <capability>` をお使いください
- 存在する場合:
  - 「🌿 既存の business_rules.md を読み込み、コードとの差分をキャッチアップいたします。」

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

以下のファイルを **すべて** 読み込む。これらはこのスキルの動作を規定する指示書および実例である。

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

**システム全体の文脈:**
- `miko/system_high_level_design.md` — システム全体のアーキテクチャ。テナント構造、API構造、レイヤー構成、**コード探索ガイド**を把握するために読む（プロジェクトごとに異なる）
- `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`

**既存ドキュメント:**
- `miko/<capability>/business_rules.md` — 現在のルール一覧、ルール ID 体系を把握
- `miko/<capability>/high_level_design.md` — 現在の構造を把握（存在する場合）
- 既存ドキュメントから以下を抽出・記録:
  - 既存ルール ID と内容の一覧
  - 人間が書いた/編集したと思われるセクション（背景など）
  - 実装マッピングの現状

### 5. コード探索

ケイパビリティに関連するファイルを網羅的に探索する。

`miko/system_high_level_design.md` の **コード探索ガイド** を参照し、プロジェクトのディレクトリ構成・レイヤー構成・命名規約に従って探索する。

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

**探索の手順:**
1. コード探索ガイドのディレクトリ構成・レイヤー構成を確認する
2. Glob と Grep でケイパビリティ名（およびその変形: 命名規約に沿った単数/複数、ケース変換等）に一致するファイルを検索する
3. スキーマ定義やデータモデルから関連するエンティティを特定し、リレーションを辿って隣接するモデルも探索範囲に含める
4. ルーティング定義や API 定義から関連するエンドポイントを特定し、対応するハンドラを探索する
5. 見つかった全ファイルのリストを記録する（後のステップで精読する）

### 6. 【確認①】探索スコープの確認

探索結果をカテゴリ別のファイル数・主要ファイルと、スコープの境界（中核/隣接/除外）としてユーザーに提示し、承認を取る。調整指示があれば修正して再提示する。

### 7. コード精読（サブエージェント並列）

ステップ 6 で承認されたスコープのファイルを、**カテゴリ別にサブエージェント（Agent ツール、`subagent_type: "Explore"`、`model: "sonnet"`）を並列起動して読み込む。**

**各サブエージェントに渡す共通コンテキスト:**
- `miko/system_high_level_design.md` の **ビジネスルール抽出の着目点**（プロジェクト固有のパターン: バリデーションの書き方、状態定義の方式、認可の仕組み等）
- 既存の `miko/<capability>/business_rules.md` のルール一覧（差分検出のため）
- 担当カテゴリのファイルパス一覧

**カテゴリ分割の基準:** ステップ 6 の探索結果テーブルのカテゴリ（Models, Controllers, Services 等）をそのまま使う。カテゴリが 2 つ以下の場合はサブエージェントを使わず直接精読する。

**各サブエージェントの作業:**
- 担当ファイルを全文読み込む
- ビジネスルール候補を抽出する
- 各候補について「コードの振る舞い」ではなく「**なぜそうなっているか**（背後にあるビジネス判断）」を言語化する
- 既存ルールとの対応（一致/新規/改訂/確認不能）を判定する

**全サブエージェントの完了後、** 結果を統合して次のステップに進む。

### 8. 禊 — 判定テスト・語彙検査（サブエージェント）

ステップ 7 の候補のうち新規追加・改訂提案を、サブエージェント（Agent ツール）1 体で事前審査する。コードを読みながら起草した候補は実装トレースやコード語彙が本文に漏れやすいため、会話とコードの文脈を持たない審査役にテキストだけで判定させる。

**サブエージェントに渡す情報:**
- `.miko/guides/misogi_guide.md` のパス — 「このファイルを読み、指示に正確に従え」と指示する
- ケイパビリティ名（審査役はここから判定材料を自分で読み込む）
- 審査対象のルール候補テキスト（ルール ID または仮番号、[制約]/[導出] タグ付き。まだファイルに存在しないため本文を渡す）

**会話の経緯・コードの引用・検出元の説明は渡さない。** 文脈が審査を汚染するため、判定材料は候補テキストとガイドだけにする。

**審査結果の裁定（メインセッション）:**
- 違反が妥当 → 書き換え案を適用する。BR 不適格は候補から外す
- 違反を覆す（出力内容そのものがビジネス判断である場合等）→ 覆す理由を明示し、本文は「判断だけを書く」形に整える
- 判定不能 → 「暗黙のルール（要確認）」セクションに列挙する

### 9. 【確認②】ルール候補の確認

From studyplus/miko, MIT.

More from studyplus/miko