---
name: implement-workflow
description: |
  実装タスクを一気通貫で実行するワークフロースキル。「実装して」「機能を追加して」
  「このバグを直して」「リファクタリングして」など、具体的なコード変更を伴う依頼で使う。
  計画済みのタスクにも、アドホックな修正にも適用可能。
  探索 → 実装 → 検証 → 修正のループを回し、tsc / build / test が全て通る状態まで
  自走して完了させる。ユーザーが「コードを書いて」「作って」「直して」と言った時は
  このスキルを検討すること。plan-workflow の出力（承認済み計画）を入力として受け取る
  こともできる。
---

# Implement Workflow — 探索から動作確認まで自走する実装ループ

ユーザーが実装を依頼した時、確認可能な品質に到達するまで自走する。

## 入力

このスキルは次のいずれかの形で起動する。

1. **計画からの入力**: `plan-workflow` や `plan-write` が出力した承認済み計画（`docs/plans/*.md`）
2. **アドホックな依頼**: ユーザーからの直接指示（「〇〇を実装して」「このバグを直して」）
3. **レビューからの修正**: `code-reviewer` の指摘に基づく修正タスク

## ループ

```
探索 → 実装 → 検証 → (失敗) → 修正 → 検証 → ... → (成功) → 完了
```

各フェーズの詳細を以下に示す。

### 1. 探索（Understand）

実装前に必ず現状を把握する。飛ばさないこと。

- 変更対象のファイルを読む（view ツールを使用）
- 関連する既存コード、パターン、命名規則を確認する
- 依存するモジュールのインターフェースを把握する
- 必要に応じて `context7-cli` でライブラリの最新ドキュメントを参照する
- スタック固有のスキルがあれば活用する（`hono`, `shadcn`, `vitest` など）

### 2. 実装（Implement）

**原則**:

- 一度に一つの変更に集中する。複数の論理的変更を同時に進めない
- 既存パターンに従う。新しいパターンを発明しない
- YAGNI: 要求されていない機能を追加しない
- KISS: 動く最も単純な実装を選ぶ
- DRY: 同じロジックを3回書く前に共通化を検討する

**ファイル操作**:

- 新規ファイル: `write_file` を使う
- 既存ファイルの編集: 必ず先に `view` で読んでから `string_replace_lsp` で編集する
- 編集箇所には十分なコンテキストを含め、一意に特定できるようにする

### 3. 検証（Verify）

**必須検証** — 実装後に毎回実行する:

| 検証       | コマンド                       | 実行タイミング               |
| ---------- | ------------------------------ | ---------------------------- |
| 型チェック | `tsc --noEmit` または `tsc -b` | TypeScript プロジェクト全般  |
| ビルド     | `vite build` など              | フロントエンド               |
| テスト     | `vitest run`                   | テストファイルが存在する場合 |

**追加検証** — UI変更やブラウザ動作確認が必要な場合:

| 検証             | 手法             | 実行タイミング                             |
| ---------------- | ---------------- | ------------------------------------------ |
| ブラウザ動作確認 | `playwright-cli` | UI変更・画面遷移・フォーム操作が関わる場合 |

`playwright-cli` の使い方:

```bash
# ブラウザを開いて対象ページに移動
playwright-cli open http://localhost:5173
# スナップショットでDOM構造を確認
playwright-cli snapshot
# 要素の操作（ref番号はスナップショットから取得）
playwright-cli click e3
playwright-cli fill e5 "入力テキスト"
# スクリーンショットで視覚確認
playwright-cli screenshot --filename=result.png
# 終了
playwright-cli close
```

- 開発サーバーが起動していない場合は先に起動する（`npm run dev` 等）
- スナップショットの ref 番号（`e3`, `e5` 等）を使って要素を特定・操作する
- コンソールエラーの確認: `playwright-cli console`

検証はツールを通じて実際に実行し、出力を確認する。推測で済ませない。

**検証が失敗したら**:

1. エラー出力を完全に読む。最初のエラーから対処する
2. 根本原因を特定する。症状だけでなく原因を直す
3. 適切な修正を行う。型キャストや `@ts-ignore` で隠さない
4. 再度検証する
5. **2回試して解決しない場合**: ユーザーに状況を報告し、対応を相談する

### 4. 完了条件

次のすべてを満たした時のみ、実装を完了とする。

- [ ] 実装したコードが要求を満たしている
- [ ] `tsc --noEmit` または `tsc -b` がエラーなしで通る（TypeScript の場合）
- [ ] ビルドが成功する（該当する場合）
- [ ] テストが全て通る（テストが存在する場合）
- [ ] UI変更がある場合、`playwright-cli` でブラウザ動作確認ができている
- [ ] デバッグ用コード（`console.log`、コメントアウトされたコード）が残っていない
- [ ] 半完成の機能が残っていない

## タスク管理

3つ以上のステップがある実装では `task_write` で進捗を管理する:

- タスクは常に FULL リストを渡して更新する
- 作業開始前に `in_progress` にする（同時に1つだけ）
- 完了直後に `completed` にする。まとめて完了にしない
- 全て完了したら `task_check` で確認する

## スコープの判断

実装の規模によってアプローチを変える。

| 規模 | 例                               | アプローチ                                          |
| ---- | -------------------------------- | --------------------------------------------------- |
| 小   | バグ修正、1ファイル変更          | このスキルのみで即実装                              |
| 中   | 新機能追加、3〜5ファイル         | task_write で管理しながら実装                       |
| 大   | アーキテクチャ変更、新モジュール | 先に `plan-workflow` で計画してからこのスキルで実装 |

**計画が必要か迷ったら**: 変更が3ファイルを超える、または既存の設計判断に影響するなら、まず計画を立てることを推奨する。ただし、既存パターンに従う明確な変更なら、そのまま実装してよい。

## 他スキルとの連携

このワークフローは単独で動くが、必要に応じて既存スキルを呼び出す。

| タイミング       | スキル                              | 用途                                               |
| ---------------- | ----------------------------------- | -------------------------------------------------- |
| 実装前           | `context7-cli`                      | ライブラリの最新API確認                            |
| 実装中           | `hono` / `shadcn` / `vitest`        | スタック固有の実装ガイド                           |
| 実装中           | `frontend-design` / `ui-ux-pro-max` | UI構築時のデザイン品質担保                         |
| 実装中           | `emil-design-eng`                   | アニメーション・インタラクションの磨き上げ         |
| 検証時           | `playwright-cli`                    | UI変更のブラウザ動作確認・スナップショット検証     |
| 実装完了後       | `code-reviewer`                     | 差分レビュー（ユーザーが求めた場合）               |
| レビュー指摘対応 | `implement-workflow`（自身）        | code-reviewer の指摘を修正する際もこのループで回す |
| 完了後           | `doc-spec-sync` / `doc-imple-sync`  | ドキュメント同期（ユーザーが求めた場合）           |
| 完了後           | `git-commit-message`                | コミット作成（ユーザーが求めた場合）               |
| 完了後           | `git-pr-create`                     | PR作成（ユーザーが求めた場合）                     |

## よくある失敗と回避策

- **コードを読まずに編集**: 必ず `view` で現状を確認してから変更する
- **一度に全てやる**: 一つの変更を完全にしてから次へ進む
- **検証をスキップ**: 「たぶん動く」ではなく、実際にコマンドを実行して確認する
- **壊れた上に積み増す**: エラーが出たら、その場で直してから先へ進む