Run any Skill in Manus with one click

ec-qa-expert

Stars1

Forks0

UpdatedMay 24, 2026 at 09:48

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

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

myoshi2891

myoshi2891/Multi-Vendor-E-Commerce

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

SKILL.md

readonly

name

ec-qa-expert

description

品質保証・QAエキスパート（World-Class Standard）

Overview

Jest (Unit/Integration) と Playwright (E2E) を駆使し、ビジネスロジックからUI/UXまで、プロジェクト全体の品質を保証します。

開発規約 (Rules & Best Practices)

1. テスト設計戦略

✅ 境界値分析 (BVA) & 同値分割 (EP): 入力値の最小・最大・無効値（例: 0円, 1円, 在庫数+1, 特殊文字）を必ず網羅する。
✅ 異常系 (Negative Testing): 権限不足 (Unauthorized/Forbidden)、DB接続失敗、外部API (Stripe/PayPal) タイムアウト等のエラーハンドリングを 100% 検証する。
✅ 冪等性 (Idempotency): 決済や注文など、同じ操作が2回行われてもデータが破損しない（二重決済防止等）ことを検証する。
✅ 競合状態 (Race Condition): 在庫の引き当てなど、同時実行時に整合性が保たれるかを意識する。

2. ユニット・統合テスト (Jest)

✅ Fixtures 活用: src/config/test-fixtures.ts を使用し、型安全なデータ生成を行う。ハードコードは避け、必要に応じて Partial<T> でオーバーライドする。
✅ 相対日付: src/config/test-scenarios.ts の相対日付（now(), tomorrow()）を使用し、テスト実行時の日付に依存しない堅牢なテストを書く。
✅ モック戦略: jest.spyOn や jest.mock を使用し、テスト終了後は必ず mockRestore() する。DBは MockPrismaClient を活用する。
✅ 配置: 原則としてソースファイルと同階層に .test.ts で配置する。

3. UI・E2Eテスト (Testing Library / Playwright)

✅ User-Centric Testing: getByRole, getByLabelText など、ユーザーが認識する要素でのセレクタ選択を優先する（実装詳細に依存しない）。
✅ データ属性: 最終手段として data-testid を使用する。
✅ E2E安定性: tests/e2e/seed/ を使用して、各テストワーカーに独立したデータセットを用意し、並列実行時の干渉を防ぐ。

Step-by-Step Guide

マインドセット: 「どうすればこのシステムを壊せるか？」という視点でテストケースを洗い出す。
テストインフラ確認: src/config/ 配下の共通定数・ヘルパーを確認し、車輪の再発明を避ける。
カバレッジと質: 命令網羅だけでなく、条件網羅 (C1)・判定条件網羅 (C2) を意識したケースを作成する。
回帰防止: 修正したバグが二度と発生しないよう、そのバグを狙い撃ちしたテストを組み込む。
ドキュメント更新（必須）: テスト実装完了後、以下を必ず更新してコミットする。

テスト実装後のドキュメント更新義務

テストを追加・変更した場合、コードと同一コミット 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.md Step 3 (QA_HANDOFF.md 最優先) を参照。

More from this repository

same repository

spec-sync-after-test

myoshi2891/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".

2026-06-151

test-complete

myoshi2891/Multi-Vendor-E-Commerce

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".

2026-06-151

erd-diagram-adjust

myoshi2891/Multi-Vendor-E-Commerce

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".

2026-06-051

ci-flake-diagnosis

myoshi2891/Multi-Vendor-E-Commerce

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".

2026-05-241

server-action-scaffold

myoshi2891/Multi-Vendor-E-Commerce

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".

2026-05-241

spec-sync-check

myoshi2891/Multi-Vendor-E-Commerce

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

2026-05-241

name

ec-qa-expert

description

品質保証・QAエキスパート（World-Class Standard）

Overview

Jest (Unit/Integration) と Playwright (E2E) を駆使し、ビジネスロジックからUI/UXまで、プロジェクト全体の品質を保証します。

開発規約 (Rules & Best Practices)

1. テスト設計戦略

✅ 境界値分析 (BVA) & 同値分割 (EP): 入力値の最小・最大・無効値（例: 0円, 1円, 在庫数+1, 特殊文字）を必ず網羅する。
✅ 異常系 (Negative Testing): 権限不足 (Unauthorized/Forbidden)、DB接続失敗、外部API (Stripe/PayPal) タイムアウト等のエラーハンドリングを 100% 検証する。
✅ 冪等性 (Idempotency): 決済や注文など、同じ操作が2回行われてもデータが破損しない（二重決済防止等）ことを検証する。
✅ 競合状態 (Race Condition): 在庫の引き当てなど、同時実行時に整合性が保たれるかを意識する。

2. ユニット・統合テスト (Jest)

✅ Fixtures 活用: src/config/test-fixtures.ts を使用し、型安全なデータ生成を行う。ハードコードは避け、必要に応じて Partial<T> でオーバーライドする。
✅ 相対日付: src/config/test-scenarios.ts の相対日付（now(), tomorrow()）を使用し、テスト実行時の日付に依存しない堅牢なテストを書く。
✅ モック戦略: jest.spyOn や jest.mock を使用し、テスト終了後は必ず mockRestore() する。DBは MockPrismaClient を活用する。
✅ 配置: 原則としてソースファイルと同階層に .test.ts で配置する。

3. UI・E2Eテスト (Testing Library / Playwright)

✅ User-Centric Testing: getByRole, getByLabelText など、ユーザーが認識する要素でのセレクタ選択を優先する（実装詳細に依存しない）。
✅ データ属性: 最終手段として data-testid を使用する。
✅ E2E安定性: tests/e2e/seed/ を使用して、各テストワーカーに独立したデータセットを用意し、並列実行時の干渉を防ぐ。

Step-by-Step Guide

マインドセット: 「どうすればこのシステムを壊せるか？」という視点でテストケースを洗い出す。
テストインフラ確認: src/config/ 配下の共通定数・ヘルパーを確認し、車輪の再発明を避ける。
カバレッジと質: 命令網羅だけでなく、条件網羅 (C1)・判定条件網羅 (C2) を意識したケースを作成する。
回帰防止: 修正したバグが二度と発生しないよう、そのバグを狙い撃ちしたテストを組み込む。
ドキュメント更新（必須）: テスト実装完了後、以下を必ず更新してコミットする。

テスト実装後のドキュメント更新義務

テストを追加・変更した場合、コードと同一コミット 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.md Step 3 (QA_HANDOFF.md 最優先) を参照。