version: "1.0.0" name: implementation description: 設計をもとにコードを書く実装フェーズのスキル。「実装して」「コードを書いて」「機能を追加して」と言われたとき、または詳細設計が固まりコーディングに入るタイミングで使う。

実装

目的

詳細設計の意図を正確にコードへ変換し、品質・保守性・セキュリティを担保した状態で動く機能を届ける。

使うタイミング

• 詳細設計 ([[detailed-design]]) またはタスク分割 ([[task-breakdown]]) が完了し、コーディングに入るとき
• 既存機能のバグ修正・改修・リファクタリングを行うとき
• 「実装して」「コードを書いて」「○○機能を追加して」と依頼されたとき

進め方

1. 着手前の把握

• CLAUDE.md を読み、プロジェクト固有の規約・禁止事項を確認する
• lint 設定・フォーマッタ設定 (.eslintrc, pyproject.toml 等) を確認する
• 類似の既存実装を検索し、命名規則・ディレクトリ構成・エラーハンドリングのパターンを把握する
• 詳細設計ドキュメントと突き合わせ、実装範囲と受け入れ条件を確認する

1. 実装計画メモの作成

• 変更ファイル一覧・実装順序・委譲計画を下記テンプレートで整理する
• インターフェース (型定義・API契約) を先に固定してから実装に入る

1. 小さく進める

• 動く状態を保ったまま小さい単位でコミットする
• 1 コミット = 1 意図 (機能追加・バグ修正・リファクタを混ぜない)
• コミットメッセージは「なぜ」を書く

1. 設計との突き合わせ

• 設計と異なる実装をする場合は、その理由をコメントまたはコミットメッセージに記録する
• 仕様の解釈に迷ったらコードを書く前に確認する

1. エラーハンドリング

• エラーを握りつぶさない。catch (e) {} は禁止
• ユーザー向けメッセージ (UI表示) とログ (内部調査用) を分ける
• 想定外の状態は早く失敗させる (fail fast)
• 回復不能なエラーは上位に伝播させる

1. ログ

• 後から障害調査できる粒度で記録する (リクエストID、入力サマリ、処理分岐など)
• APIキー・パスワード・個人情報をログに出力しない

1. セキュリティ基本

• 入力値は必ずバリデーションする
• SQLインジェクション・XSS 対策はフレームワークの標準機構 (ORM・テンプレートエスケープ) を使う
• 秘密情報 (APIキー・認証情報) をコードにハードコードしない・コミットしない。.env + .gitignore を使う

1. 依存ライブラリ追加の判断

• 本当に必要か (標準ライブラリや既存依存で代替できないか) を確認する
• メンテナンスが継続されているか (最終コミット日・Issue対応状況) を確認する
• ライセンスがプロジェクトと適合しているかを確認する

1. 自己レビュー

• git diff を読み直し、デバッグコード・console.log・print の残留を除去する
• TODO / FIXME コメントが残っている場合はタスク化してから消す
• lint・フォーマッタを実行してパスすることを確認する
• テスト ([[testing]]) を実行してグリーンを確認する

成果物テンプレート

# 実装計画メモ
 
## 対象タスク
-タスク名:
-関連Issue/チケット:
-受け入れ条件:
 
## 変更ファイル一覧
| ファイルパス | 変更種別 | 概要 |
|---|---|---|
| src/foo/bar.ts | 新規 | ○○サービスクラス |
| src/foo/bar.test.ts | 新規 | 上記のユニットテスト |
| src/routes/index.ts | 修正 | ルート追加 |
 
## 実装順序
1.インターフェース定義 (型・API契約)
2.ドメインロジック実装
3.インフラ層実装
4.ルーティング・コントローラ実装
5.テスト実装
6.自己レビュー・lint実行
 
## 委譲計画
| 担当モデル | 対象箇所 | 理由 |
|---|---|---|
| 司令塔 | 全体方針決定・タスク分割・成果物レビュー・統合 | オーケストレーション責務 |
| Opus | 複雑なアルゴリズム・難しいデバッグ・横断リファクタ | 深い推論が必要 |
| Sonnet | 通常の機能実装・CRUD・テスト・定型バグ修正 | 標準的な実装タスク |
| Haiku | ファイル探索・単純置換・定型コード生成 | 高速・低コスト |
 
## 確認コマンド

lint

npm run lint

テスト

npm test

型チェック

npm run typecheck

チェックリスト

• [ ] CLAUDE.md と lint 設定を確認した
• [ ] 類似実装のパターンを把握した
• [ ] インターフェースを先に固定した
• [ ] 1 コミット 1 意図で進めている
• [ ] 設計との差異を記録した
• [ ] エラーを握りつぶしていない
• [ ] ログに秘密情報が含まれていない
• [ ] 入力バリデーション・SQL/XSS 対策が入っている
• [ ] 秘密情報をハードコードしていない
• [ ] デバッグコード・不要な TODO を除去した
• [ ] lint・テストがグリーンになった

アンチパターン

• 既存パターンを無視した我流実装: プロジェクト固有の規約を確認せず、独自スタイルで書く
• 巨大な一括コミット: 複数機能・バグ修正・リファクタを1コミットにまとめる
• エラー握りつぶし: catch (e) {} や except: pass で例外を無視する
• テストを最後にまとめて書く: 実装完了後に全テストを書こうとして工数切れになる
• 動いたからOKでリファクタしない: 動作確認だけして技術的負債を放置する
• コードへの秘密情報埋め込み: APIキーを直書きしてコミット・プッシュする
• 設計ドキュメントとの乖離無記録: 設計と異なる実装をした理由を残さない

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

役割の目安

並列実装時の注意

同一ファイルを触るタスクは直列化する。 複数エージェントが同じファイルを並列編集するとコンフリクトが必ず発生する。

正しい並列化の手順:

1. インターフェースを先に固定する — 型定義・APIスキーマ・関数シグネチャを司令塔が決定し、コミットしてから並列化を開始する
2. ファイル単位で担当を分ける — 「Sonnet-A は src/user/ 配下」「Sonnet-B は src/order/ 配下」のように担当ファイルが重複しないよう指示する
3. 共有モジュールの変更は直列化する — utils/・types/・config/ など多数のファイルから参照されるモジュールの変更は1エージェントに集約する
4. 統合は司令塔が行う — 各エージェントの成果物を司令塔がレビューし、インターフェースとの整合を確認してからマージする

委譲例

# 司令塔 → Sonnet への指示例
src/user/userService.ts に createUser 関数を実装してください。
インターフェースは src/user/types.ts の UserCreateInput / User 型に従うこと。
エラーハンドリングは src/shared/errors.ts の AppError を使うこと。
テストは src/user/userService.test.ts に書くこと。
lint と typecheck がパスしたら完了を報告してください。

関連スキル

• [[detailed-design]] — 実装前に参照する設計ドキュメント
• [[testing]] — 実装と並走するテスト戦略
• [[task-breakdown]] — 実装タスクの分割方法
• [[orchestration]] — マルチエージェント共通原則
• [[architecture-design]] — 技術スタック・構成の決定
• [[mvp-development]] — 最小実装を素早く届ける場合