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