miko.quick-impl

Files (1)

• SKILL.md

SKILL.md (first lines)

## 入力

```text
$ARGUMENTS
```

入力の形式: 以下のいずれか

- proposal のパス（例: `/miko.quick-impl miko/order_management/proposals/2026-03-01-fix-trial-grace-period.md`）
- 変更指示の自由記述（例: `/miko.quick-impl OrderService を OrderFacade にリネーム`）
- 空の場合はエラー: 「⛩️  proposal のパスまたは変更指示をお願いいたします（例: `/miko.quick-impl miko/order_management/proposals/2026-03-01-fix-trial-grace-period.md`）」

---

## このスキルの役割

小規模な変更を speckit フロー（specify → clarify → plan → tasks → analyze → implement）をスキップして直接実装する。proposal がある場合は BR 変更を含めて、ない場合は変更指示から直接、実装とドキュメント追従まで行う。

miko の原則として BR ルール本文の変更には proposal が必要。proposal がない入力で BR 本文変更が必要になると判定された場合は propose に誘導する。

**対象外（フルフローまたは propose に誘導）:**
- 複数の意図が絡む変更
- 影響範囲の見極めに追加の調査・探索が必要な変更
- 既存の処理フローの構造が大きく動く変更
- BR ルール本文を変える変更で、それを認可する proposal がない

**迷ったらフルフローを推奨する。**

---

## 手順

### 1. 入力解決

`$ARGUMENTS` を以下のルールで解決する:

- `miko/` で始まり `.md` で終わるパス → そのパスを proposal として使用。パスから cap 名を抽出
- 上記に該当しない → `$ARGUMENTS` を変更指示として扱う（proposal なし）

**proposal があった場合の追加検査:**

- 親プロポーザル（umbrella proposal）の検出 — 先頭に `<umbrella-proposal>` マーカーがある場合、エラーとして中止する:
  > ⛩️  親プロポーザルは直接実装できません。サブプロポーザルを指定してください。
- 未分割プロポーザルの検出 — 先頭に `<needs-split>` マーカーがある場合、エラーとして中止する:
  > ⛩️  このプロポーザルは分割が必要です。
  > まず `/miko.split-proposal` でフェーズ分割してから、サブプロポーザルを指定してください。

### 2. 資料読み込み

**共通:**
- `.miko/guides/business_rules_guide.md` — ルールの書き方、実装マッピングの表記規約
- `.miko/guides/tone_guide.md` — 対話スタイル。**このファイルの口調・絵文字・出力言語ルールに従うこと**
- `miko/system_high_level_design.md` — コード探索ガイド
- `miko/glossary.md` — 用語集（存在する場合）

**proposal がある場合の追加:**
- `miko/<capability>/business_rules.md` — 現在のビジネスルール
- `miko/<capability>/high_level_design.md` — 現在の構造（あれば）
- proposal ファイル

**proposal がない場合:** 上記共通のみを先に読み込む。コード調査中に cap 固有の BR/HLD が必要になった時点で随時参照する（どの cap に触れるかは調査結果で決まる）。

### 3. コード調査

`miko/system_high_level_design.md` の **コード探索ガイド** に従い、変更に関連するコードを探索・精読する。

- proposal がある場合: proposal の変更対象コードを調査
- proposal がない場合: 変更指示の対象コードを調査

いずれの場合も、影響範囲（他ファイル・他モジュール・他 cap からの参照）を把握する。

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

### 4. スコープガード

コード調査の結果を踏まえ、以下の 4 軸で判定する。いずれかに該当すれば中止し、適切なスキルに誘導する。

**(a) 意図の単一性** — 変更が単一の意図・目的で説明できるか。BR ルールが何本に分解されるかは問わない（例: 「キャンセル後通知」は 1 ルールでも 3 ルールでも意図は単一）。複数の関心事が絡む場合:

> ⛩️  この変更は複数の意図が絡んでおります。フルフローをお勧めいたします。

**(b) 影響範囲の明瞭さ** — 変更点から波及先がコード上素直に辿れるか。波及の見極めのために広範な探索（当たりをつけるためのプロトタイプ、仮説検証、多段の読み込み）を要する場合:

> ⛩️  この変更は影響範囲の見極めに追加の探索が必要です。フルフローをお勧めいたします。

**(c) 機械性または局所性** — 機械的な変換（リネーム、シグネチャ変更、参照の一括置換 等）か、あるいは局所的な変更で完結するか。既存の処理フローの構造が大きく動く場合:

> ⛩️  この変更は処理構造に大きく影響いたします。フルフローをお勧めいたします。

**(d) BR ルール本文の変更を伴う場合、それを認可する proposal があるか。** proposal がない、または proposal に記載のない BR 本文変更が必要な場合:

> ⛩️  この変更はビジネスルールに影響いたします。
> `/miko.propose <capability>` でプロポーザルをお作りしてからお進みくださいませ。

**注記:**
- ケイパビリティ境界を跨ぐこと自体は中止理由にしない。BR 本文を変えないリファクタリングなら、複数 cap の実装・実装マッピングを同時に動かしてよい
- ファイル数・行数は目安にすぎない。機械的なリファクタリングなら多くのファイルに及んでも対象内。上記の 4 軸で判定する

**対象と判定した場合、次に進む。**

### 5. 【確認】実装方針の提示

変更内容（ファイルごとの変更概要）、テスト方針、ドキュメント更新の見込み（BR 本文・実装マッピング・HLD・harae のうち、実際に触る予定のもの）を簡潔に提示し、確認を取る。

### 6. 実装 + テスト

確認された方針に従い、実装とテストを行う。

**実装後、セルフレビューを実行:**
- **責務の配置**: フレームワークの規約上正しいレイヤー/ファイルに置かれているか
- **命名**: メソッド名・変数名がそのレイヤーの責務を正しく反映しているか
- **フレームワークの機能活用**: フレームワークが提供する仕組みで実現できることを自前で実装していないか
- **意図外の変化がないか**: 手順 5 で宣言した意図の外に、挙動・副作用の変化が生じていないか。変更対象の旧コード/旧仕様が扱っていたケース（正常系・エラーパス・nil 等の境界）を列挙し、新コードで各ケースが同等に扱われるか確認する（意図的に変える場合は手順 5 で宣言されているはず）。

  **帯域外シグナルを変える場合はリポジトリ全体を見る**: 例外の送出、グローバル/静的状態の変更、イベント・通知の発行、ライフサイクルフックの発動、メタプログラミングによる動的挙動の変更など、**呼び出し元ではなく別の箇所で受信・観測される信号**を変える場合、受信側は immediate caller に現れない。この種の信号を変える時は受信側（例外なら捕捉箇所、イベントなら購読箇所、等）をリポジトリ全体で検索し、更新または互換性を確保する。戻り値や引数のように呼び出し元で完結する契約は、通常どおり呼び出し元の更新で足りる。

  **識別子をリネームした場合はリポジトリ全体を grep する**: クラス名・モジュール名・ファイルパス・関数名・定数名等を変更した場合、型チェッカーやテストでは捕捉できない参照（文字列リテラル、コメント、テストフィクスチャ名、設定ファイル、動的ロードのパス、`miko/` 配下の design docs・proposals・harae、README やその他 markdown、CI 設定など）が残る。`grep` でリポジトリ全体から旧名を洗い出し、ヒットごとに以下を判断する:

  - 同名の別概念ではないか（語境界・文脈の一致）

From studyplus/miko, MIT.

More from studyplus/miko