アプリのテストはすべてこのスキルを使う。開発中のTDD（テストファースト）から、 ユーザー目線のE2E・受入テスト、インフラ/デプロイ検証、リリース前の網羅テストまでを1つに統合。 「テストを書いて」「テストして」「動作確認して」「TDDで進めて」「カバレッジを確認」 「E2Eテスト」「リリース前にちゃんとテストしたい」「本番で動くか確認」「回帰テスト」 などの文脈で必ず使用する。§0「適用段階」に従い、たたき台〜v1 では「壊れたら困る順」の最小テスト、 固定化段階(v1 到達後のブラッシュアップ)ではユーザーがテストと明示しなくてもTDDサイクルを適用する。 セキュリティ・コスト・パフォーマンスの監査は Skill launch-security を併用する。
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
テストは「書いたコードの確認」ではなく「アプリがユーザーの目的を果たすことの証明」。 開発中はTDDで守り、リリース前は4層（ユニット→統合→E2E→インフラ/受入）で網羅する。
本スキルは mvp-first-development §9「たたき台 → 確認 → 固定化」と app-orchestrator 裁定ルール4に従って段階的に適用する。
| 段階 | 書くテスト | 本スキルの適用範囲 |
|---|---|---|
| たたき台〜確認（v0 まで） | 計算ロジック・パーサー・集計と、理由表示など「文言が出ること」の固定だけ | §4 のインフラ検証（デプロイ後のスモーク）のみ必須。§2 の TDD サイクルと §5 は使わない |
| v1 までに | 上に加え、最頻業務と必須業務フローの E2E を「壊れたら困る順」に最小本数 | §3 を最小本数で。カバレッジは v0・v1 いずれのゲートにもしない |
| 固定化（v1 到達後のブラッシュアップ） | OK が出た主要フローの回帰テスト。以後の新機能・バグ修正は §2 の TDD サイクル | §1〜§6 を全て適用。カバレッジ 80% はこの段階の目標 |
リリース可否は INV-5 の3判定だけで決まり、本スキルのチェックリスト（§5）は公開を止める理由にならない（INVARIANTS.md）。
| 層 | 対象 | ツール | 目安 |
|---|---|---|---|
| ユニット | 関数・ユーティリティ・コンポーネント | Vitest/Jest | 多数・高速 |
| 統合 | APIエンドポイント・DB操作・認可 | Vitest + ローカルD1/モック | 主要API全部 |
| E2E（ユーザー目線） | クリティカルユーザーフロー | Playwright | 主要フロー3〜10本 |
| インフラ/受入 | 本番相当環境での実動確認 | curl・wrangler・実ブラウザ | リリース毎 |
ユニット・統合は pnpm test、E2E・受入は pnpm run preview で立てたローカル本番相当環境（既定は http://localhost:8787）に対して実行する。
カバレッジ目標は固定化段階で80%以上（§0）。ただし数字合わせより「壊れたら困る順」にテストする。
新機能・バグ修正は必ずこの順で進める（詳細パターンは references/tdd-and-patterns.md）:
1. RED : ユーザージャーニーからテストケースを書く → 実行して失敗を確認
2. GREEN : テストを通す最小実装
3. REFACTOR: テストが通ったまま整理（immutability・小さい関数）
4. 検証 : カバレッジ確認（固定化段階では80%+）
references/tdd-and-patterns.md 参照。pnpm run preview で本番相当のローカル環境を起動し、そのURLに対して実行する。ハッピーパスだけでなく:
デプロイ後（またはプレビューURL）で必ず実行:
# スモークテスト: トップ・主要API・認証が生きているか
curl -sf "$ORIGIN/" -o /dev/null && echo "OK: top"
curl -s "$ORIGIN/api/health" | head -c 200
# SPA配信時: APIがフォールバックに横取りされていないか
curl -H "Accept: text/html" -H "Sec-Fetch-Mode: navigate" "$ORIGIN/api/me" | head -c 100
wrangler d1 migrations listで未適用ゼロ）wrangler tailでエラーログが出ていない本チェックリストは固定化段階の品質目標であり、v0・v1 の公開可否は INV-5 の3判定（launch-security の段階別ゲートを含む）で決まる。未達項目は残課題リストへ記録する。
テスト結果:
ユニット/統合: X件 pass / Y件 fail（failの内容と対処）
E2E: シナリオ別の結果
カバレッジ: XX%
インフラ検証: 各項目の実測結果（コマンド出力の要点）
未実施・未確認: 残っている事実だけを明示（「たぶん動く」で完了報告しない）
references/tdd-and-patterns.mdまだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
アプリ・Webサービス・業務ツールの制作を、証拠分析→確定的な初稿→要件定義→体験設計→機能分解→実装→品質ゲート→リリース判定の手順ゲート制で進めるスキル。質問で要件を埋めるのではなく、依頼文・既存コード・資料・ログから最有力案を選び、動く成果物を先に出して差分で改善する。ユーザーが「アプリを作りたい」「ツールを作って」「〜を自動化したい」「システム化したい」「要件定義」「仕様を決めたい」「UI/UXを設計して」「体験を良くしたい」「機能を洗い出して」「MVPを決めたい」「品質チェック」「リリースしていいか判断して」などと言ったら必ず使用する。外部データの取込・マスタ・締め処理を伴う業務システムでは references/data-lifecycle.md も併用する。新規・既存を問わずアプリの制作・改善・リニューアルで使用する。
Webアプリの準備→要件定義→設計→実装→公開→品質ゲートを実行する内部オーケストレーター。Claude Codeの /build-app /improve-app、Codexの $build-app / $improve-app から明示的に委譲された場合、custom agent起動時、または利用者が $app-orchestrator を明示した場合だけ使用する。一般のアプリ相談から暗黙起動しない。
run-extract-blueprint が生成した章別ブループリントの忠実性を独立 context で評価したいとき、事実/推測区別と粒度と被覆を検証し draft_hash に束縛した PASS/FAIL verdict をローカル品質ゲート (C01 の周回内の受入判定・差し戻し) へ渡したいときに使う。
確認点で利用者が見る深さを選んだあと打ち合わせ資料を作り手とは別の目で確かめたいとき、正確さ・言葉・見た目・シンプルさの指摘を資料の編集なしで受け取りたいときに使う。
生成した handout 資料が初心者に伝わるか読みやすさレビューを依頼したいとき、独立 context のレビュアーから指摘と根拠つきの verdict を回収したいときに使う。
Notion ページを描画する直前に粒度を検証したいとき、info-collector-agent ページと同等の section 充足度を section_canonical_map 基準で機械検証したいときに使う。