メニュー
Writes and runs end-to-end tests that prove critical user flows work in a real browser. Use when unit tests pass but user journeys need verification, before release of UI flows, or when regressions happen only in full-stack integration.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Meta-skill that routes a task to the right engineering skill. Load this at the start of a session or when unsure which skill applies — it maps intent to the process that should govern the work.
Catches breaking changes between services before they ship, by testing the contract each consumer actually depends on instead of spinning up the whole system. Use when services deploy independently, when a provider API change could break a consumer, or when end-to-end integration tests are too slow and flaky to guard every service boundary.
Proves whether a change actually moves the metric, with a valid A/B test instead of a guess — a hypothesis, a primary metric, a pre-computed sample size, guardrail metrics, and an honest readout. Use when shipping a change meant to improve a number (conversion, retention, performance), running an A/B or holdout, or deciding whether a feature "worked."
Decouples deploy from release using feature flags — ship code dark, roll out gradually, kill instantly, and remove the flag once it's done. Use when releasing risky or large changes, rolling out by percentage/cohort, delivering A/B variants, or when stale flags are accumulating as debt.
Finds security risks at design time — before code exists — by mapping the system, enumerating how it could be attacked, and deciding what to do about each threat. Use when designing a feature that touches auth, data, money, or external input, when changing a trust boundary, or when a security-sensitive change needs a structured risk pass rather than a code-level review.
Designs durable, curated memory that an agent carries across sessions — what to persist, how to scope and retrieve it, and how to stop it from drifting or poisoning later runs. Use when an agent needs to remember decisions, preferences, or project facts beyond one context window, or when stale/over-generalized memory is corrupting its behavior.
| name | e2e-testing |
| description | Writes and runs end-to-end tests that prove critical user flows work in a real browser. Use when unit tests pass but user journeys need verification, before release of UI flows, or when regressions happen only in full-stack integration. |
Unit tests prove functions work; E2E tests prove users can complete journeys. A checkout flow, login, or "first connection" path that only works in isolation is not shippable — exercise it in a real browser against a running app.
Pairs with [[test-first]] for unit/integration layers, [[browser-checks]] for manual/exploratory verification, [[spec-first]] for scenarios to automate, [[pipeline-ops]] to run E2E in CI, and [[launch-readiness]] before promoting to production.
Use the e2e testing checklist alongside this process.
Skip for pure backend/API changes with no user journey impact — use [[test-first]] only.
Prioritize by risk and frequency:
| Tier | Examples | E2E depth |
|---|---|---|
| P0 smoke | Login, signup, core happy path | Every PR / nightly |
| P1 | Settings, secondary flows | Nightly |
| P2 | Edge cases, admin | Weekly or pre-release |
Start with 3–5 P0 flows max — flaky huge suites get ignored.
Each test = one user goal from [[spec-first]] acceptance criteria:
Given [starting state]
When [user actions]
Then [observable outcome]
One behavior per test. Name tests after the user outcome, not the selector.
Pick one and stick to it:
Conventions:
data-testid for stable selectors — avoid CSS classes and nth-child1. Arrange — seed user/data, navigate to start URL
2. Act — user clicks, fills, submits (one journey)
3. Assert — URL, visible text, API side effect, DB state
4. Cleanup — delete test user/data if needed
Rules:
test+${runId}@example.com)