miko.speckit.implement

Files (1)

• SKILL.md

SKILL.md (first lines)

## 入力

```text
$ARGUMENTS
```

---

## 対話スタイルと出力言語

`.miko/guides/tone_guide.md` に従うこと。対話の口調・絵文字に加え、生成するドキュメントの言語も同ガイドの「出力言語」ルールに従う。

---

## このスキルの役割

speckit.implement のワークフローを基盤として実行し、以下を変更する:

1. **フェーズごとに止まる** — 各フェーズ完了後に人間の確認を挟む
2. **test_design.md の活用** — テスト作成時に合意済みテストケースを参照する
3. **機能ごとのセルフレビュー** — テスト完了後にセルフレビュー → /simplify
4. **最終フェーズの実行** — 機能横断リファクタリング
5. **デザインドキュメントの更新** — business_rules.md と high_level_design.md にプロポーザル・実装の変更を反映

---

## 手順

### 1. speckit.implement の実行（Miko 拡張）

speckit の `implement` の手順を以下の順で探索して読み込み、基盤として実行する:

1. `.claude/skills/speckit-implement/SKILL.md` — spec-kit の skills モード（`--ai claude` の現デフォルト）
2. `.claude/commands/speckit.implement.md` — commands モード（旧レイアウト）

どちらも存在しない場合はエラー中止する:
> ⛩️  speckit の `implement` スキルが見つかりません。`specify init --ai claude` を先にお願いいたします。

**以下の点を変更する:**

#### 追加の文脈読み込み

speckit.implement のステップ 3（Load context）で、以下のファイルも追加で読み込む:

- `test_design.md`（FEATURE_DIR 内） — テスト観点とテストケース一覧
- spec.md 内の「Miko コンテキスト」からケイパビリティ名を取得
- `miko/<capability>/business_rules.md` — ルール ID の参照用

#### フェーズごとの確認停止

speckit.implement のステップ 6（Execute implementation）を以下に置き換える:

**実行開始前に、タスク全体の規模を判断する:**

- tasks.md のフェーズ数とタスク数を確認する
- **シンプルな場合**（フェーズが2つ以下、かつタスク総数が10件以下）:
  - 「タスクがシンプルですので一気に実装してもよろしいでしょうか？フェーズごとにお止めすることもできます。」と確認する
  - 承認されたら全フェーズを連続実行する（最終フェーズの前では必ず止まる）
- **それ以外の場合**:
  - フェーズごとに実行・確認を繰り返す

**フェーズ完了時の確認:**

各フェーズの全タスクが完了したら、完了タスク・変更ファイル・次のフェーズの概要を提示して確認を取る。

- フィードバックがあれば反映してから次に進む
- **「戻って修正して」と言われた場合:** 該当フェーズ（または該当タスク）に戻り、指摘箇所を修正してから再度確認を取る。前のフェーズへの差し戻しも受け付ける

**最終フェーズの前では必ず止まる**（一気通貫モードでも）。

#### テスト作成時のルール

テストタスクを実行する際:

**test_design.md がある場合:**
- test_design.md のテストケース一覧を **チェックリスト** として使う
- 各テストケースに対応する spec を作成する
- テストケース一覧にないテストは原則追加しない
- 追加が必要と判断した場合は、理由をコメントで明記する

**test_design.md がない場合:**
- spec.md の Acceptance Scenarios からテストを生成する

**テスト除外ルール（常に適用）:**
- フレームワークが保証する振る舞い（validates のパラメータチェック等）のテストは書かない
- 親クラス・共通基盤が担保する処理（認可、認証）のテストは書かない

#### 機能ごとのセルフレビュー

各機能のテストフェーズが完了したら、次の機能に進む前に以下を実行する:

**1. セルフレビュー**

実装したコードを読み返し、以下の観点でチェックする:

- **責務の配置**: 各コードが、使用フレームワークの規約上正しいレイヤー/ファイルに置かれているか
- **命名**: メソッド名・変数名が、そのレイヤーの責務を正しく反映しているか（他レイヤーの用語を使っていないか）
- **フレームワークの機能活用**: フレームワークが提供する仕組みで実現できることを自前で実装していないか

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

- 同名の別概念ではないか（語境界・文脈の一致）
- 過去の経緯記録（解決済み harae 項目・廃止 proposal・過去の commit log を引いた docs 等）として旧名のまま残すべきか
- リネーム結果が文脈上正しい表記か（複合語・派生語の扱い）

機械的な一括置換はしない。判断に迷うヒットは、置換せずに主さまに提示して確認する。

問題を発見したら、その場で修正する。

**2. /simplify 実行**

セルフレビュー完了後、`/simplify` を実行してコードの重複・品質・効率をチェック・修正する。

**注意:** 機能が1つしかない場合はこのステップをスキップし、最終フェーズで一括実行する。

#### 最終フェーズの実行

tasks.md の最終フェーズに到達したら、以下の順序で実行する:

From studyplus/miko, MIT.

More from studyplus/miko