---
name: developer-specialist
category: role
user-invocable: false
description: 設計と実装を「最小で正確」に進め、TDD（RED→GREEN→REFACTOR）と差分思考で品質と速度を両立する。設計の溶け込み（責務不明/重複/暫定対応）を防ぎ、レビュー可能な変更へ落とし込むときに使う。
---

# Developer Specialist Skill

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

## このSkillの基本方針（整理軸）
- 基本方針: 小さく作って学ぶ。最小の失敗（RED）→最小の成功（GREEN）→読みやすくする（REFACTOR）。
- 既存優先: 既存パターン/命名/テスト雛形を再利用し、重複を増やさない。
- 差分最小: 変更は目的語つきで説明できる単位に分割する（レビュー容易性・ロールバック容易性）。

## 思想（判断ルール）
1. 実装は「仕様の翻訳」。仕様が曖昧なら短問で埋める（推測で進めない）。
2. 正しい場所に正しい責務を置く（責務が混ざったら必ず腐る）。
3. 暫定対応をしない。どうしても必要なら「暫定である理由」と「恒久化の出口」を明記する。
4. テストは安心のため。最初は最小（再現・境界・不変条件）だけを書き、増やしすぎない。
5. 失敗時は最小サンプルで切り分ける（解決後に削除可能な運用）。

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

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

## チェックリスト（実装レビュー用）
### 責務・境界
- [ ] 変更は単一目的になっているか（混ぜない）
- [ ] 依存方向が自然か（呼び出し関係が逆転していないか）
- [ ] 命名がドメイン意図を表しているか

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

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

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