القائمة
世界トップクラスのQAエンジニアとして、Multi-Vendor ECプロジェクトのテスト設計・実装・品質検証を行う。 単なるテスト作成にとどまらず、境界値、異常系、冪等性、競合状態を網羅した「壊れないシステム」を保証する。 「テストを書いて」「品質を上げて」「エッジケースを考慮して」といった指示に適用する。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Keeps spec documents and coverage reports in sync after test implementation, feature implementation, or phase completion. Updates quantitative metrics (test count, suite count, type error count), regenerates coverage-dashboard.html, and syncs functional specs (04-interfaces.md, 05-workflows.md, 08-open-questions.md) and progress trackers (docs/design/*/PROGRESS.md, docs/PROGRESS.md next-actions) when new server actions, pages, or workflows were implemented. Triggered by: "仕様書更新", "ドキュメント更新", "テスト後の仕様同期", "spec sync after test", "update docs after test", "テスト実装後の更新", "カバレッジダッシュボード更新", "update coverage dashboard", "フェーズ完了", "機能実装後の仕様同期", "phase complete", "feature sync".
Runs unit tests (Jest), optional E2E tests (Playwright), TypeScript type check, and ESLint, then reports results with pass/fail details, coverage, and a clear commit-readiness judgment. Recommended before every commit. Triggered by: "テスト実行", "テスト確認", "カバレッジ確認", "品質チェック", "テストチェック", "コミット前確認", "test run", "run tests", "check coverage", "quality check", "pre-commit check".
Regenerates the data-model ER diagram from prisma/schema.prisma and visually declutters edge routing (lines must not overlap entity boxes) without ever hand-editing the generated .drawio. Manual layout intent is captured in the layout-overrides side-car so it survives regeneration. Triggered by: "ERD調整", "ER図調整", "データモデル図", "data-model.drawio", "drawio調整", "図の線が重なる", "線がボックスを突き抜ける", "erd:generate後の調整", "ERD再生成", "モデル追加後の図更新", "adjust ERD diagram", "fix ER diagram routing", "regenerate data model diagram", "erd layout".
Diagnoses CI-only test flakes — tests that pass locally but fail intermittently on GitHub Actions. Triaged via gh CLI log inspection and event-pair comparison (push vs pull_request on the same SHA). Recommends minimal diagnostic instrumentation (Jest --verbose --ci) before any code change. Triggered by: "CI が落ちる", "CI でだけ失敗", "テストがフレーキー", "ローカルでは通る", "間欠的に失敗", "CI flake", "intermittent failure", "flaky test", "passes locally fails in CI".
Generates consistent server action templates in src/queries/ by learning existing patterns. Produces implementation file, Zod schema addition, and unit tests (AAA pattern) in a single scaffold. Only triggered when a new server action is explicitly requested. Triggered by: "新しいサーバーアクション", "サーバーアクション追加", "server action作成", "新しいserver actionを追加", "add server action (query)", "new server action", "add server action", "scaffold action", "create query".
Detects and reports divergences across four layers: (1) specs ↔ implementation, (2) steering rules ↔ rules/skills/agent docs, (3) top-level docs (CLAUDE.md / README.md / GEMINI.md / .agent/) ↔ steering, and (4) SSOT duplication. Never auto-fixes — always reports to the human for judgment. Follows SDD (Spec-Driven Development) principles where specs are the single source of truth, while extending coverage to the operational layer that teaches the rules. Triggered by: "仕様確認", "仕様同期", "spec確認", "仕様書チェック", "仕様と実装の整合性", "仕様乖離", "ルール確認", "規約整合性チェック", "規約浸透チェック", "ドリフト確認", "skill 整合", "rule 整合", "spec check", "sync check", "check spec", "verify spec alignment", "rule sync", "skill sync", "drift check", "仕様乖離をチェック".
| name | ec-qa-expert |
| description | 世界トップクラスのQAエンジニアとして、Multi-Vendor ECプロジェクトのテスト設計・実装・品質検証を行う。 単なるテスト作成にとどまらず、境界値、異常系、冪等性、競合状態を網羅した「壊れないシステム」を保証する。 「テストを書いて」「品質を上げて」「エッジケースを考慮して」といった指示に適用する。 |
Jest (Unit/Integration) と Playwright (E2E) を駆使し、ビジネスロジックからUI/UXまで、プロジェクト全体の品質を保証します。
src/config/test-fixtures.ts を使用し、型安全なデータ生成を行う。ハードコードは避け、必要に応じて Partial<T> でオーバーライドする。src/config/test-scenarios.ts の相対日付（now(), tomorrow()）を使用し、テスト実行時の日付に依存しない堅牢なテストを書く。jest.spyOn や jest.mock を使用し、テスト終了後は必ず mockRestore() する。DBは MockPrismaClient を活用する。.test.ts で配置する。getByRole, getByLabelText など、ユーザーが認識する要素でのセレクタ選択を優先する（実装詳細に依存しない）。data-testid を使用する。tests/e2e/seed/ を使用して、各テストワーカーに独立したデータセットを用意し、並列実行時の干渉を防ぐ。src/config/ 配下の共通定数・ヘルパーを確認し、車輪の再発明を避ける。テストを追加・変更した場合、コードと同一コミット or 直後のコミットで以下を更新すること。
| 更新ファイル | 更新内容 | 必須条件 |
|---|---|---|
docs/testing/TEST_IMPLEMENTATION_PLAN.md | 完了 Step に ✅ Completed (日付) を付与 | Step が完了したとき |
docs/testing/QA_HANDOFF.md (SSOT) | テスト統計テーブル更新 + Open Issues 状態更新 + 次着手明記 + 「次回着手用 依頼プロンプト」セクション同期 | セッション終了時（必須）/ テスト統計変動時 / Next Actions 変動時 |
docs/testing/COVERAGE_REPORT.md §3 | タスク（A/B/C）の完了記録・ヒートマップ更新 | セル状態（◯/◐/✦）が変化したとき |
docs/testing/SECURITY_GAP_REPORT.md | IDOR/RBAC の発見・修正・テスト追加を記録 (3 階層パターン (a)(b)(c) 必須) | セキュリティ脆弱性の修正時 |
docs/PROGRESS.md | テスト統計（テスト数・型エラー数）を QA_HANDOFF.md から転記同期 | 統計値が変化したとき |
scripts/coverage-dashboard/render-html.ts (SSOT) | NEXT_ACTIONS 配列の編集 (high/medium/low の追加・完了・削除) | Next Actions に変動があるとき |
docs/coverage-dashboard.html | bun run coverage:dashboard を実行して再生成 (手動編集禁止) | テストの追加/変更・カバレッジ更新時 / render-html.ts 編集時 |
重複防止: 即時 TODO は
QA_HANDOFF.mdのみに書く。COVERAGE_REPORT.md §3には「なぜやるか」の根拠のみ。 二重 SSOT 同期:scripts/coverage-dashboard/render-html.tsのNEXT_ACTIONS配列とQA_HANDOFF.md「次回着手用 依頼プロンプト」セクションは一対一で対応する。タスク完了/追加時は必ず両方を同一コミット内で更新すること（片方だけ更新すると drift する）。 詳細なルールは.claude/steering/documentation-guide.mdのdocs/testing/ 各ファイルの更新ルールおよび.claude/skills/spec-sync-after-test/SKILL.mdStep 3 (QA_HANDOFF.md 最優先) を参照。