メニュー
Thin methodology for end-to-end tests of critical user journeys — define journeys by risk, use semantic locators and condition-based waits, quarantine flaky tests with a tracked reason, and capture artifacts on failure. Use when adding or stabilizing E2E coverage; the e2e-runner agent applies it in depth.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Index of this project's coding-practice rules — architecture, coding style, testing, security, git workflow, task management, context layering, anti-slop, performance, and language-specific rules. The thin always-on essentials live in .claude/rules/common/house-rules.md; the full per-topic detail ships under .claude/rules/reference/ and .claude/rules/<lang>/ and is read on demand. Invoke this skill when you need the project's standards for a task, then open the specific rule file it points to.
Design rigorous evaluations and benchmarks for AI agents, developer tools, retrieval systems, and repository-scale automation. Covers task selection, contamination control, metric choice tied to engineering decisions, and statistical validity. Use when asked to design an eval/benchmark, critique an existing benchmark, choose metrics for an agent or RAG system, or decide whether a measured improvement is real. NOT for running an existing performance-benchmark suite or a per-feature acceptance checklist, or one-off model spot-checks.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree one at a time. Use for ambiguous or complex collaborative specs before any code is written.
Decision framework for choosing between regex and LLM when parsing structured text — start with regex, add LLM only for low-confidence edge cases. Use when parsing quizzes, forms, invoices, or documents with repeating structure and cost matters.
Review a repository for long-term architectural leverage rather than code quality — system structure, module boundaries, dependency graph, coupling, and drift. Produces a ranked set of highest-ROI improvements with evidence, effort, and risk. Use when asked to review the architecture, assess a codebase's structure/design, find where complexity is concentrated, or decide what to refactor next. NOT for style, naming, formatting, or line-level bugs (use a code-review skill for those).
Analyze a software system, AI pipeline, or research direction by surfacing its underlying structure — invariants, hidden abstractions, weak assumptions, and the single highest-leverage direction — rather than optimizing local implementations. Use when asked to step back and think about a system's design at a conceptual level, find leverage points, evaluate a research direction for compounding impact, or decide where to invest for the long term. NOT for reviewing a specific repo's architecture (use repo-architecture-review) or local code cleanup.
| name | e2e-testing |
| description | Thin methodology for end-to-end tests of critical user journeys — define journeys by risk, use semantic locators and condition-based waits, quarantine flaky tests with a tracked reason, and capture artifacts on failure. Use when adding or stabilizing E2E coverage; the e2e-runner agent applies it in depth. |
| scope | universal |
| ported-from | global skill |
End-to-end tests are the last line of defense before production: they exercise real user journeys across the whole stack and catch integration failures unit tests structurally cannot. Keep the suite small, critical, and stable — a flaky E2E suite that nobody trusts is worse than none.
Test journeys, not pages. A journey is a full user-visible flow (sign in → create → see it persist). Rank them and cover top-down; do not chase 100% of screens.
For each journey cover the happy path first, then the one or two error paths that would actually hurt (declined payment, expired session).
[data-testid="…"] > role/label > CSS > XPath. A
test tied to DOM structure breaks on every refactor; one tied to intent does not.waitForResponse() / expect(...).toBeVisible(),
never waitForTimeout(3000). Time-based waits are the single largest source of
flake and they silently slow the suite.A flaky test that stays green-ish erodes trust in the whole suite. When a test flakes:
--repeat-each=10 or equivalent).test.fixme/test.skip) with a tracked issue
reference in the reason — never a bare skip that disappears silently.Configure screenshots, video, and traces to record on failure/first-retry (not always — artifacts are expensive). On CI, upload them and put the artifact path in the failure report so a red run is debuggable without a local repro.
Critical journeys pass 100%, overall pass rate > 95%, flaky rate < 5%, the suite finishes fast enough to run on every PR, and every failure produces an artifact that explains it. Report residual gaps in journey coverage explicitly rather than implying the suite is exhaustive.