implement

name	implement
description	コード変更（機能追加・バグ修正・リファクタリング）のフルサイクルを実行する。ユーザーが「実装して」「直して」「対応して」等のコード変更を依頼したとき、または「/implement」と言ったときに使う。

実装フルサイクル

コード変更を調査からコミットまで一気通貫で進めるワークフロー。KISS/DRY/SRP/YAGNI・既存パターン踏襲・「症状でなく根本原因を直す」は常に前提とする。

ステップ 1: 明確化

• 要件・目的の不明点があれば、作業を始める前にまとめて質問する
• 複数ファイルにまたがる大きな機能追加・リファクタリングは plan モードで設計を先に提示し、承認後に実装へ入る

ステップ 2: ブランチ確認

• git status が clean であることを確認する
• main 上にいる場合は {prefix}/{issue番号}-{英語で内容の説明} の作業ブランチを先に切る（プレフィックス: feature/ fix/ hotfix/ release/ test/ docs/ refactor/）
• issue 起点の作業なら /start-issue の利用を案内する

ステップ 3: 調査

• 関連する関数の使用箇所を検索し、影響範囲を確認する
• 対称的なコードパス（追加/削除、成功/失敗）がある場合は両方を確認する
• 変更しないと判断したファイルについても、その根拠を確認する
• .github/workflows/ci-build.yml を読み、変更が CI で正しく検証されるか確認する

ステップ 4: テストを先に書く（Red）

• 期待する振る舞いをテストコードとして先に書き、失敗することを確認する
• テストの種類と置き場: フック → renderHook（src/hooks/*.test.ts）、ライブラリ → 純粋関数（src/lib/*.test.ts）、コンポーネント → render + jsdom（src/components/*.test.tsx）
• 削除リファクタリングは Red が書けないため、「削除対象の本番使用ゼロ」を grep で前提検証し、期待外のヒットが出たら中止する
• ドキュメント更新や CI 設定変更などテスト追加が不適切な作業は、理由をコミットメッセージまたは PR 説明に明記する
• 新規テストファイルを追加した場合: ci-build.yml で実行されるか・tsconfig.json の exclude に追加が必要か・vitest.config.ts の include が検出するかを確認する

ステップ 5: 実装（Green）

• テストを満たす最小限のコードを書き、テストが通ることを確認する

ステップ 6: 検証フェーズ（条件発火）

変更が触れた領域に応じて、該当する検証スキルを実行する（複数該当なら複数実行）:

変更が触れた領域	発火するスキル
src-tauri/src/commands/・invoke ラッパー（src/lib/）・src/types/generated/	/ipc-check
既存関数のコピー改変、追加/削除・成功/失敗の対称ペア	/symmetry-check
キャッシュ・fingerprint・request_key・DB スキーマ	/cache-check
UI 操作・言語表示・フォーム	E2E 手動実行の要否を判断し /e2e を案内（E2E は CI に含まれず、手動確認が唯一の統合テスト手段）
エンコーディング・日本語パス / UI デザイン / SQL・スキーマ / セキュリティ	対応するレビュー系サブエージェント（encoding-reviewer / ux-reviewer / sqlite-tuning / security-reviewer）に検査を委譲

どの領域にも該当しない場合はその旨を報告して次へ進む。

ステップ 7: 締め

• コード変更が以下に影響する場合、同一コミットで対応ドキュメントも更新する（ドキュメント drift 防止）:

  コード変更	同期するドキュメント
  振る舞い・DB スキーマ・コマンド仕様	SPEC.md
  src-tauri/src/commands/ 等へのモジュール（ファイル）新設・移動・削除	SPEC.md §3.2 モジュール表
  src/locales/*.json のキー増減	docs/locale-customization.md のキー一覧
  安全網（ci-build.yml・clippy.toml・scripts/hooks/・.claude/settings.json）の新設・変更	/commit チェックリスト（グループ A/B）との整合を突合して同期する
  アーキテクチャ・横断パターンの変更（書込経路・キャッシュ機構・スキーマ方式等）	.claude/skills/ を関連語で grep し、化石化するスキル記述を同一 PR で更新する

• /commit へ接続する（チェックリストの実行とコミットは /commit の責務）

注意事項

• コミットの実処理は /commit、PR 作成は /pr に委譲する。手順をこのスキルに重複記載しない
• 修正後に症状が別のテストへ移動した場合は根本原因に未達のサイン。同一パターンのバグを検索してから完了とする