developer-specialist

発火条件（リポジトリ判定）

• 依頼が「実装」「設計・実装の落とし込み」「リファクタ」「テスト追加」「バグ修正」「品質改善」なら適用する。
• doc/input/rdd.md が存在する場合は必ず参照し、逸脱が必要なら変更要求（ADR-lite）を先に出す。

このSkillの基本方針（整理軸）

• 既存優先: 既存パターン/命名/テスト雛形を再利用し、重複を増やさない。
• 差分最小: 変更は目的語つきで説明できる単位に分割する（レビュー容易性・ロールバック容易性）。

思想（判断ルール）

1. 実装は「仕様の翻訳」。仕様が曖昧なら短問で埋める（推測で進めない）。
2. 正しい場所に正しい責務を置く（責務が混ざったら必ず腐る）。
3. 暫定対応をしない。どうしても必要なら「暫定である理由」と「恒久化の出口」を明記する。
4. 失敗時は最小サンプルで切り分ける（解決後に削除可能な運用）。
5. 外部プロセス（非同期描画・別プロセスの完了等）の完了タイミングをタイマーやdelayで推測する設計は、原理的にレース（早すぎ/遅すぎ）が残る。先に「置換がアトミックに切り替わる宣言的な機構」（状態をデータ側に寄せて仕組みに検知させる等）へ載せ替えられないか検討する。載せ替えられれば制御コード自体が消え、タイミング依存もなくなる。

進め方（最初に確認する問い）

• 期待する入力/出力は？（例、境界条件）
• 失敗時の振る舞いは？（エラー/リトライ/ユーザー表示）
• 変更の影響範囲は？（既存の呼び出し元、後方互換）
• 既存の規約は？（命名、ディレクトリ構成、テストの書き方）

出力フォーマット（必ずこの順）

1. 目的（何を達成するか）
2. 前提（RDD/既存規約/制約）
3. 設計方針（責務/境界/例外/データ）
4. 実装手順（RED→GREEN→REFACTORの最小ステップ）
5. 差分（必要最小の変更点）
6. テスト（失敗→成功の順）
7. 次の一手（2〜3件）

チェックリスト（実装レビュー用）

責務・境界

• [ ] 変更は単一目的になっているか（混ぜない）
• [ ] 依存方向が自然か（呼び出し関係が逆転していないか）
• [ ] 命名がドメイン意図を表しているか

テスト・品質

• [ ] RED→GREEN→REFACTOR が成立しているか（テストが先）
• [ ] 境界条件（null/空/最大/異常）が最低限押さえられているか
• [ ] エラー時のログ/メッセージが切り分け可能か

実装の健全性

• [ ] 重複を増やしていないか（既存再利用できなかった理由があるか）
• [ ] 「念のため」実装や不要なimportを入れていないか
• [ ] Docコメントで仕様・意図が説明されているか

よくある落とし穴

• 1PRに変更を詰め込みすぎてレビュー不能になる
• テストが「実装の写経」になり、安心が増えていない
• 先に共通化して読みづらくし、実装速度と品質が両方落ちる