القائمة
ロジックの変更とUIの変更に対するテスト戦略と基準を定義する。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | testing_criteria |
| description | ロジックの変更とUIの変更に対するテスト戦略と基準を定義する。 |
開発スピードとアプリケーションの安定性のバランスを取るため、本プロジェクトでは的を絞ったテスト戦略を採用しています。
lib/, hooks/, types/, および複雑なAPIルートハンドラ内のファイル。vitest を使用します。npm run test を実行し、すべてのテストがパスすることを確認します。components/ および app/ 内のファイル。browser_subagent を使用します。browser_subagent に指示して対象のページに移動し、新しい要素とインタラクション（ツールチップのホバー、該当セクションへのスクロール等）を行い、スクリーンショットをキャプチャします。walkthrough.md アーティファクトに埋め込んでください。__tests__/*.test.ts を作成/修正し、npm run test を実行して確認する。e2e/*.spec.ts）において、.locator('text=...') などのUI表示テキストに依存した要素検索は翻訳や文言変更に極めて弱いため禁止とします。必ず対象のコンポーネントに data-testid を付加し、getByTestId で検索してください。npm run test:e2e を実行し、全てパスするか検証すること。browser_subagent を実行し、スクリーンショットを撮影して確認する。npm run lint と npm run typecheck を実行し、エラーが0件であることを確認する。lib/ 配下の関数は最低限の単体テストを持つことを目標とします。__tests__/ にファイルごとのテストが存在しない場合、ロジック変更時にテストを追加します。__tests__/[対象ファイル名].test.ts[!CAUTION] テストの期待値（アサーション）は「現在のコードの挙動」ではなく「blueprint.md / README.md の仕様」から導出すること。
// ❌ 危険: 「コードがこう動いているから、これが正しい」
const data = await db.getCreatorData('any-id');
expect(data.supporters.length).toBeGreaterThan(0); // ← コードを見て書いた期待値
// ✅ 安全: blueprint.md の仕様「非デモIDは空データで開始」から導出
const data = await db.getCreatorData('any-id');
expect(data.supporters).toHaveLength(0); // ← 仕様書から書いた期待値
[!IMPORTANT] 実装の前にテストの「期待値」を仕様から確定させる。これにより、AIが仕様にない挙動を勝手に実装し、それを"正解"としたテストを書いてしまう問題（トートロジー）を防ぐ。
blueprint.md に起案するblueprint.md に先行言語化する実装 → テスト（コードを見て期待値を書く）← トートロジーの温床
LLMはコンテキストが長くなると中間の指示を忘却する（Lost in the Middle）。以下のタイミングでスキルファイルを再読み込みし、重要ルールをリフレッシュする：
core_commit_standard と core_testing_criteria を再読み込みcore_bug_fix_protocol を再読み込みテストで環境変数を操作する際は、vitest の vi.stubEnv() / vi.unstubAllEnvs() を必ず使用する。process.env への直接代入は禁止。
// ✅ 正しい
beforeEach(() => {
vi.stubEnv('NEXT_PUBLIC_USE_MOCKS', 'true');
});
afterEach(() => {
vi.unstubAllEnvs();
});
// ❌ 禁止（テスト間で環境変数がリークする）
process.env.NEXT_PUBLIC_USE_MOCKS = 'true';
理由: process.env の直接代入はテスト間で状態がリークし、テスト実行順序に依存した不安定なテスト（Flaky Test）の原因となる。
AI開発チームの役割定義。各エージェントの責務・行動指針・実行ステップを規定する。
AI同士のバトンタッチ（タスク委譲）とチェック体制。セッション開始時のPR確認から終了時のIssue作成までのルールを定義する。
バグ修正時のリグレッションテスト作成義務と、グローバル状態共有の禁止ルール。
コーディング規約。ESLint/TypeScript/React/Next.jsの品質基準と、AIエージェントがコミット前に守るべきルールを定義する。
Defines the standard format and rules for git commit messages in this project.
README.mdとblueprint.mdの役割分担と更新義務を定義するドキュメント管理ポリシー。