Multi-Vendor-E-Commerce

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", "仕様乖離をチェック".

世界トップクラスのQAエンジニアとして、Multi-Vendor ECプロジェクトのテスト設計・実装・品質検証を行う。 単なるテスト作成にとどまらず、境界値、異常系、冪等性、競合状態を網羅した「壊れないシステム」を保証する。 「テストを書いて」「品質を上げて」「エッジケースを考慮して」といった指示に適用する。

Backend implementation and fixes for multi-vendor e-commerce projects, including server actions, database and authentication.

Analyzes existing production code, identifies untested paths and edge cases, and generates comprehensive test cases using the project's test infrastructure. Supports unit (Jest), component (RTL), and E2E (Playwright) test generation. Triggered by: "テスト追加", "テストケース追加", "テスト補完", "テスト生成", "カバレッジ改善", "不足テスト", "テストギャップ", "add tests", "generate tests", "test gap", "improve coverage", "missing tests", "write tests for".

Multi-Vendor ECプロジェクトのフロントエンド（UI、コンポーネント、状態管理）の実装や修正を行う際に使用する。 「UIを作って」「画面を修正して」「カートの状態管理」「フロントエンドの実装」といった指示が出た際に適用すること。

Generates a comprehensive implementation plan before any new feature development begins. Reads all relevant spec files, analyzes existing patterns, and presents a structured plan for user approval. Must be triggered BEFORE writing any code. Triggered by: "新機能実装", "機能追加", "新しい機能", "実装計画", "feature追加", "implementation plan", "add feature", "new feature", "plan this feature", "機能を追加したい", "追加してほしい".

Multi-Vendor ECプロジェクトのデータベーススキーマ（prisma/schema.prisma）の変更、マイグレーション、シードデータの投入を行う際に使用する。 「DBのスキーマを変更して」「マイグレーションを実行して」「Prismaの設定」「データベースの更新」といった指示が出た際に適用すること。

テスト駆動開発 (TDD) のスペシャリストとして、Red-Green-Refactor のプロセスを回し、バグの発生を未然に防ぐ。 「TDDで進めて」「テストを先に書いて」「バグを再現させて」といった指示に適用する。

Safely executes Prisma schema migrations using migrate dev (db push is strictly forbidden). Verifies spec alignment, confirms backup, detects destructive operations, regenerates the Prisma client, and proposes related code updates. Only runs when the user explicitly requests it. Triggered by: "マイグレーション実行", "migrate実行", "Prismaマイグレーション", "schema変更", "DB変更", "スキーマ更新", "run migration", "apply migration", "prisma migrate", "/safe-migration".