By name: code-quick description: >- 会話で渡された指示を仕様として、ドキュメントを参照・作成せずに TDD で小規模な実装・修正を行う時に使用する。 RED → GREEN → REFACTOR のサイクルで実装し、テスト・lint の検証ゲートを満たす。quick-coder サブエージェントが使用する。 user-invocable: false allowed-tools: [Read, Write, Edit, Glob, Grep, Bash, TodoWrite]
クイック TDD 実装ワークフロー
quick-coder サブエージェントが従う軽量な実装ワークフローと TDD 方法論を定義する。
渡された指示の範囲に留まり、前工程のドキュメント参照や成果物のドキュメント化は行わない。
レビューは呼び出し元の判断に委ねる。
準備
呼び出し元（メイン）から渡された実装指示を仕様として把握する。
前工程のドキュメント（task_<phase_num>_<task_num>.md・specification.md・project_architecture.md 等）は存在しない前提とし、
これらを探しに行かない。指示が曖昧で実装方針を決められない場合は停止し、呼び出し元へ確認する。
次に、変更対象になりそうなファイル周辺の既存コードを Read / Grep で読み、命名規約・パターン・
既存テストを把握する。
フェーズ 1: 指示の把握
- 渡された指示から、実装・修正すべき振る舞いと対象範囲・制約を整理する。
- 対象ファイル周辺の既存コードを読み、命名規約・パターン・既存テストを把握する。
- 既存の流儀に沿って実装できるよう、類似実装を確認する。
フェーズ 2: TDD で実装
渡された指示のスコープ内で、次の RED → GREEN → REFACTOR サイクルに従って実装する。 スコープ外の変更や機能追加はしない。
Step 1: RED — 失敗するテストを書く
期待する振る舞いを記述したテストを書き、意図した理由で失敗することを確認する。 RED が確認されるまでプロダクションコードには触れない。
Step 2: GREEN — 最小限の実装を書く
失敗しているテストをパスさせるために必要な実装だけを行う。再実行して GREEN を確認する。
Step 3: REFACTOR — コードを改善する
重複を除去し、命名を改善し、最適化する。すべてのテストが GREEN のまま維持されること。
フェーズ 3: 検証
実装した変更に対し、対象言語のスキル（base-python など）が定めるテストと lint の検証ゲートを実行し、
満たされるまで修正する。
- テストランナー・lint の具体的なコマンドは言語スキルを参照する。 ワークフローとしてのスコープは「ゲートを実行し満たすこと」であり、言語固有のコマンドは持たない。
- lint は編集ごとのフックでは実行されない（フックは format のみ）。このゲートで必ず lint を通すこと。
フェーズ 4: 完了の扱い
検証が満たされた時点で本スキルの責務は完了とする。
成果物のドキュメント化（サマリー追記・state.db 記録・タスクファイル更新）は行わない。
結果は呼び出し元である quick-coder エージェント定義の報告フォーマットで返す。
カバーすべきエッジケース
- Null / 未入力 の入力
- 空 の配列や文字列
- 無効な型: 期待する型や形式外の値
- 境界値（最小 / 最大）
- エラーパス（ネットワーク障害・外部サービスエラー）
- 並行操作（該当する場合のレースコンディション）
- 指示の範囲に留まる: 渡された指示を仕様とみなし、その範囲内で変更する。指示外の機能追加や 広範なリファクタはしない。
- ドキュメントを参照しない・作成しない: 前工程の仕様書・タスク仕様を前提にせず、summaries/phase_
.md・ state.db・タスクファイル等の成果物ドキュメントも生成・更新しない。 - 振る舞いをテストする: 実装の詳細（内部状態）ではなく、外から観察できる振る舞いを検証する。
- テスト間を独立に保つ: 共有可変状態を持ち込まず、各テストが単独で実行できるようにする。
- 意味のあるアサーションを書く: 検証対象の振る舞いを明確に表現するアサーションを用いる。
- 外部依存を分離する: データベース・API・サービスはモックまたはフィクスチャで切り離す。
- 言語スキルと組み合わせる: テストコマンド・構造・スタイルを言語に合わせるため、
base-pythonなどの 言語スキルと併用する。