// TDD（RED→GREEN→REFACTOR）でフェーズ単位の新機能実装やバグ修正を行う。docs/TODO.md があるとフェーズ管理し、なければ単独タスクとしてサイクルを回す。テストファーストを厳格に遵守。「実装したい」「TDDで実装」「機能を追加」「バグを修正」などで起動。
React 19 + Vite+ (`vp`) + TypeScript + Tailwind CSS v4 + React Router v7 (HashRouter) でモバイル向け静的SPAデモサイトをTDDで構築し、Cloudflare Workers (Static Assets) へ自動デプロイするまでの標準ワークフローを提供する。テンプレートリポジトリ `skanehira/demo-site-template` を `gh repo create --template` で clone することで scaffold を省略する。`localStorage` でフロントエンドのみ完結する"フロントのみ完結デモ"に特化。デザインコンセプトの確立には `frontend-design` スキルを呼び出して連携する。起動トリガー：「デモサイトを作りたい」「モバイル向け静的デモ」「SPAを作ってCloudflareにデプロイ」「静的プロトタイプを公開」「localStorage でフロントだけ完結」。ユースケース：(1)クライアント提案用のUI/UXたたき台、(2)新機能のプロトタイプ、(3)モバイル向けランディング。ツールチェーンは Vite+ (`vp`) で統合（内部 PM は pnpm）。
ローカルのコミット履歴と差分からDraft PRを作成する。ブランチ未作成・コミット未作成の状態でも、必要に応じてブランチ作成とコミットを行ってからPRを作成する。`.github/` にPRテンプレートがあれば内容を埋めて、なければ作業内容から本文を生成し、`AskUserQuestion`で作成可否を確認してから `gh pr create --draft` を実行する。「PRを出したい」「draft PRを作成」「プルリクを作って」「PR本文を生成」などのリクエストで起動。
TDD方法論に従ってテストを作成します。テスト対象コードの分析、AAA/Given-When-Thenパターンの適用、正常系・エッジケース・エラー系のカバレッジを確保します。「テストを書いて」「テストを作成」「単体テストを追加」などのリクエストで起動します。
対話的計画コマンド。requirements-analyzing-requirementsとimplementation-planning-tasksスキルを統合実行してDESIGN.mdとTODO.mdを生成
複数サブエージェントに異なる立場を与えて議論を反復し、相違が収束するまで議題を検証して結論を提示する。設計妥当性検証・実装方針比較・原因分析のセカンドオピニオン・アイデアの壁打ちに使用。「議論したい」「壁打ちしたい」「セカンドオピニオン」「複数視点で検証したい」などで起動。
変更内容を分析し、Conventional Commit形式でコミットする (pushはユーザが手動)
| name | implementation-developing |
| description | TDD（RED→GREEN→REFACTOR）でフェーズ単位の新機能実装やバグ修正を行う。docs/TODO.md があるとフェーズ管理し、なければ単独タスクとしてサイクルを回す。テストファーストを厳格に遵守。「実装したい」「TDDで実装」「機能を追加」「バグを修正」などで起動。 |
| argument-hint | [タスク説明] |
Kent Beck の TDD 方法論と高凝集度・低結合度・コロケーションの原則に従って実装する。 RED→GREEN→REFACTOR サイクルをテストファーストアプローチで厳格に遵守する。
references/architecture-patterns.md (高凝集度・低結合度・コロケーションの詳細)/implementation-developing ログインフォームにバリデーションを追加
/implementation-developing
事前の会話でタスクが明確な場合、コンテキストから理解する。
引数からタスク説明を取得する：
$ARGUMENTS が存在する場合: そのまま使用$ARGUMENTS が空の場合: ユーザーに質問タスク説明: $ARGUMENTS
$ARGUMENTS が空の場合、以下の質問をする:
「どのようなタスクを実装しますか？具体的なタスク説明を入力してください。
例：
実装前に以下の観点で設計を検討する:
1. 責務の明確化
2. 依存関係の分析
3. 配置の決定
Read ツールで docs/DESIGN.md と docs/TODO.md の存在を確認する。
docs/TODO.md が存在する場合：
TODO.md の構造例：
### フェーズ1: バージョン計算関数の実装 (semver.rs)
- [ ] [RED] calculate_latest_patch のテスト作成
- [ ] [GREEN] calculate_latest_patch の実装
- [ ] [REFACTOR] calculate_latest_patch のリファクタリング
### フェーズ2: API統合 (api.rs)
- [ ] [RED] fetch_versions のテスト作成
- [ ] [GREEN] fetch_versions の実装
- [ ] [REFACTOR] fetch_versions のリファクタリング
docs/DESIGN.md が存在する場合：
TODO.md / DESIGN.md がない場合：
現在のフェーズのタスクを TodoWrite で管理する:
TodoWrite({
todos: [
{ content: "[RED] calculate_latest_patch のテスト作成", activeForm: "テストを作成している", status: "pending" },
{ content: "[GREEN] calculate_latest_patch の実装", activeForm: "実装している", status: "pending" },
{ content: "[REFACTOR] calculate_latest_patch のリファクタリング", activeForm: "リファクタリングしている", status: "pending" },
// ...
]
})
フェーズ内の各タスクを順番に実行する。
in_progress に更新docs/TODO.md の該当行を [x] に更新completed に更新in_progress に更新docs/TODO.md の該当行を [x] に更新completed に更新in_progress に更新docs/TODO.md の該当行を [x] に更新completed に更新設計原則チェックリスト:
| カテゴリ | チェック項目 | 確認内容 |
|---|---|---|
| SOLID | 単一責任原則 (SRP) | 1つの関数/モジュールが1つの責務のみを持っているか |
| 依存性逆転原則 (DIP) | 具象ではなく抽象（インターフェース/トレイト）に依存しているか | |
| インターフェース分離原則 (ISP) | 使わないメソッドへの依存を強制していないか | |
| テスタビリティ | 依存性注入 | 依存関係が外部から注入可能か（モックしやすいか） |
| 純粋関数 | 副作用を分離し、可能な限り純粋関数にしているか | |
| グローバル状態 | グローバル変数や静的状態に依存していないか | |
| 構造 | 高凝集度 | 関連する機能が同じモジュールにまとまっているか |
| 低結合度 | モジュール間の依存が最小限か | |
| 重複排除 (DRY) | 同じロジックが複数箇所に存在していないか | |
| シンプルさ | YAGNI | 現時点で不要な抽象化や機能を追加していないか |
| KISS | 必要以上に複雑な実装になっていないか | |
| 境界 | 公開API最小化 | 公開する関数/型は必要最小限か |
| モジュール境界 | 責務ごとに適切にモジュール分割されているか |
リファクタリングの優先順位:
トークン消費を抑えるため、テスト実行は Agent ツールでサブエージェントに委譲する。
Agent({
description: "テスト実行",
prompt: `プロジェクトのテストを実行し、結果を報告してください。
テストコマンド: [プロジェクトに応じたコマンド]
報告形式:
- 全テスト成功の場合: "SUCCESS: X tests passed"
- 失敗がある場合: "FAILED: 以下のテストが失敗" + 失敗したテスト名とエラーメッセージのみ
注意: 成功したテストの詳細は報告不要。失敗したテストの情報のみ返すこと。`,
subagent_type: "general-purpose",
model: "haiku"
})
サブエージェントの報告例:
# 成功時
SUCCESS: 15 tests passed
# 失敗時
FAILED: 以下のテストが失敗
- test_calculate_latest_patch: expected "1.2.5" but got "1.2.3"
- test_calculate_latest_minor: assertion failed at line 42
実装のルール:
フェーズ内のすべてのタスク（RED/GREEN/REFACTOR）が完了したら、以下を実行する。
# プロジェクトに応じたコマンドを実行
npm run lint # または cargo clippy, go vet など
npm run format # または cargo fmt, gofmt など
npm run build # または cargo build, go build など
npm test # または cargo test, go test など
品質チェック失敗時:
フェーズの差分を確認し、以下のチェックリストでレビューする:
git diff HEAD~N # フェーズ開始からの差分（N はフェーズ内のコミット数）
セルフレビューチェックリスト:
| 観点 | 確認項目 |
|---|---|
| テスト | テストが意図した振る舞いを検証しているか。重要なエッジケースが漏れていないか |
| 命名 | 変数・関数・型の名前が意図を正確に表しているか |
| 設計 | 単一責任原則に違反していないか。不要な依存関係を作っていないか |
| 重複 | 同じロジックが複数箇所に存在していないか |
| エラー処理 | エラーが適切に処理され、握りつぶされていないか |
問題を発見した場合:
問題がない場合:
自動的に次のフェーズに進む:
✓ 開発が完了しました
実装内容:
- [実装した機能/修正のリスト]
作成/変更したファイル:
- [ファイルパスのリスト]
テスト結果:
- [テスト数] tests passed
完了したフェーズ:
- [x] フェーズ1: バージョン計算関数の実装
- [x] フェーズ2: API統合
AskUserQuestion({
questions: [
{
question: "すべてのフェーズが完了しました。次のアクションを選択してください。",
header: "次のアクション",
options: [
{ label: "コミット", description: "変更をコミットする" },
{ label: "完了", description: "開発を終了" }
],
multiSelect: false
}
]
})
「コミット」を選択された場合:
workflow-commit スキルを使用してコミットを作成 (push はユーザが手動)覚えておくこと: すべての実装はテスト駆動でなければならない。例外なし。