// TDD方法論に従ってテストを作成します。テスト対象コードの分析、AAA/Given-When-Thenパターンの適用、正常系・エッジケース・エラー系のカバレッジを確保します。「テストを書いて」「テストを作成」「単体テストを追加」などのリクエストで起動します。
| name | implementation-writing-tests |
| description | TDD方法論に従ってテストを作成します。テスト対象コードの分析、AAA/Given-When-Thenパターンの適用、正常系・エッジケース・エラー系のカバレッジを確保します。「テストを書いて」「テストを作成」「単体テストを追加」などのリクエストで起動します。 |
TDD方法論に従ってテストを作成する。
rules/core/testing.md（AAA、命名規則、テストダブル）rules/core/design.md（コロケーション）rules/core/tdd.mdテスト対象のコードを読み込み、以下を把握する：
Claude指示: テストを書く前に、必ず対応するリファレンスファイルをReadツールで読み込んでください。
プロジェクトの言語を特定し、以下のリファレンスをReadツールで読み込む：
| 言語/フレームワーク | リファレンス |
|---|---|
| React + TypeScript | references/react-typescript.md |
| Go | references/go.md |
| Rust | references/rust.md |
// 例: Goプロジェクトの場合
Read(file_path=".claude/skills/writing-tests/references/go.md")
リファレンスを読まずにテストを書くことは禁止です。
テストは実装の近くに配置する（コロケーション）。
詳細は rules/core/design.md を参照。
テスト名には3要素を含める。詳細は rules/core/testing.md を参照。
AAA (Arrange-Act-Assert) パターンを基本とする。
詳細は rules/core/testing.md を参照。
テスティングトロフィー（優先順位）：
依存性注入を活用してテスト可能にする。
テストダブルの種類は rules/core/testing.md を参照。
テスト作成後、以下のチェックリストで確認する。
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（RED→GREEN→REFACTOR）でフェーズ単位の新機能実装やバグ修正を行う。docs/TODO.md があるとフェーズ管理し、なければ単独タスクとしてサイクルを回す。テストファーストを厳格に遵守。「実装したい」「TDDで実装」「機能を追加」「バグを修正」などで起動。
対話的計画コマンド。requirements-analyzing-requirementsとimplementation-planning-tasksスキルを統合実行してDESIGN.mdとTODO.mdを生成
複数サブエージェントに異なる立場を与えて議論を反復し、相違が収束するまで議題を検証して結論を提示する。設計妥当性検証・実装方針比較・原因分析のセカンドオピニオン・アイデアの壁打ちに使用。「議論したい」「壁打ちしたい」「セカンドオピニオン」「複数視点で検証したい」などで起動。
変更内容を分析し、Conventional Commit形式でコミットする (pushはユーザが手動)