e2e-scenario-design
Deep E2E Scenario Design
Shallow tests verify that features exist. Deep tests verify that the product holds up when used.
Context
Use this skill when the existing test strategy is directionally correct, but the scenario depth is still too thin for real confidence. The failure mode it targets is not "there are no tests." It is "the tests pass, but the product still breaks under realistic extended use."
If every test in the suite can be described as "open X, do Y, see Z" in one sentence, the suite is shallow. It mostly verifies what the developer already checked manually. Real production failures happen at state accumulation, cross-boundary navigation, session re-entry, input boundaries, and mid-session dependency failure.
This skill does not replace testing-strategy. testing-strategy decides the test layers and coverage priorities. e2e-scenario-design deepens the scenario and edge-case layers once that strategy exists.
Inputs
- source-code -- The product surface and implementation seams that the scenarios must exercise realistically.
- task-list -- The current slice, risk boundary, or release scope that the scenarios must protect.
- test-strategy-doc -- The upstream decision on which layers matter now, which risks are critical, and which flows belong in E2E versus lower layers.
Process
More from yknothing/prodcraft
system-design
Use when reviewed requirements or specifications are ready and the team must decide high-level architecture, component boundaries, integration seams, or brownfield coexistence strategy before API design, technology selection, or task planning.
6ci-cd
Use when a reviewed implementation slice needs an automated build, test, and deployment pipeline, especially when brownfield rollback, release-boundary checks, contract/integration gates, and staged delivery must be explicit before shipping.
6intake
The mandatory gateway for all new engineering work. Triage and route new products, apps, features, migrations, tech-debt, or any 'not sure where to start' request to the correct lifecycle path. Use before starting design or implementation. Do not use for ongoing tasks, specific debugging, or PR reviews.
6feature-development
Use when a reviewed task slice has tests or acceptance targets and the team must turn it into a small, mergeable implementation increment without expanding scope, breaking contracts, or hiding release-boundary risk.
6monitoring-observability
Use when a live service or newly delivered release needs actionable telemetry, dashboards, and alerts that expose real user-impactful boundaries, especially when brownfield coexistence rules, unsupported-flow safety, rollback health, or queue/backfill behavior must be visible before incidents escalate.
6incident-response
Use when a live production issue needs coordinated containment, severity triage, stakeholder communication, and evidence capture, especially when a recent release, brownfield coexistence rules, rollback decisions, or unresolved contract boundaries must be handled before root-cause work.
6