Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

ec-qa-expert

Estrelas1

Forks0

Atualizado24 de maio de 2026 às 09:48

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

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

myoshi2891

myoshi2891/Multi-Vendor-E-Commerce

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·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 最優先) を参照。

Mais deste repositório

mesmo repositório

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 最優先) を参照。