# Developer Specialist

> Developer Specialist

- Skill: `mae616/developer-specialist` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mae616/developer-specialist`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mae616/developer-specialist/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: mae616 (https://skillmd.com/u/mae616)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/mae616/developer-specialist

---


# Developer Specialist Skill

## 発火条件（リポジトリ判定）
- 依頼が「実装」「設計・実装の落とし込み」「リファクタ」「テスト追加」「バグ修正」「品質改善」なら適用する。
- `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に変更を詰め込みすぎてレビュー不能になる
- テストが「実装の写経」になり、安心が増えていない
- 先に共通化して読みづらくし、実装速度と品質が両方落ちる