e2e-flow-planner

E2E Flow Planner

Deciding "what to write first" for E2E tests Planner is the step. The deliverable is not code, but a human-reviewed markdown test plan다.

This skill's philosophy (why we do it this way)

We do not test everything. The purpose is to prevent incorrect changes from breaking existing behavior, not to make tests break every time the code changes. Laying down exhaustive tests at the screen level only increases maintenance burden and misses the regressions that actually matter.

So we start with one question: "What is the most important user workflow?"

Here, the criterion for "important" is clear. If that flow fails,

• revenue is blocked (payment, application, or subscription cannot be completed),
• data is lost (user input or transaction records are lost),
• trust is broken (identity verification, authentication, or amount display errors)

— these are the parts. This is Critical User Flow(CUF) . The essence of this skill is to narrow down the places where developers can gain confidence that "up to here is safe."

Core output discipline: before writing code, first produce a plan that a human can read and judge as "this is the right priority." The human review gate is the heart of this skill. We do not move on to test code until the plan is approved.

What we do not do (boundaries)

• Test We do not write or run code. That is the job of a separate step (Author/Runner) that takes the approved plan as input.
• In browser exploration, we do not arbitrarily carry login, payment, or identity verification through to completion. If we hit an authentication wall, we stop there and record that point in the plan as "manual precondition/mocking required."
• We do not scan every screen exhaustively. We explore only as much as needed to narrow down CUF candidates.

The approved plan is handed off to the next step: code implementation is e2e-test-generator, hardening is e2e-test-hardener, failure diagnosis is e2e-test-healer. This skill is responsible only for the front end (what and why to test + human review).

Workflow

Follow the order. Each step has a verification point that checks for itself whether it is okay to move to the next step.

1. Identify domain and scope → Verification: wrote 3–7 CUF candidates, one line each

First, identify what core value this app promises to users. Possible input sources:

• Domain/feature description provided by the user
• Route and page structure of the codebase (for Next.js, app/ or pages/, route definitions, navigation menu)
• Issues and planning documents (MCP exploration in step 2 below)

When narrowing down candidates, filter them through the "revenue/data/trust" lens. For detailed criteria and anti-patterns, read references/cuf-criteria.md .

2. Explore issues and planning documents (MCP) → Verification: evidence (issue/document/route) has been attached to each CUF candidate

If an available MCP exists, look through related issues and planning documents to gather signals on "what people actually care about and what frequently breaks." For how to use which MCP and the fallback paths when there is no MCP (issue tracker CLI, grep of documents in the repo), read references/discovery-sources.md .

A CUF without evidence is a guess. For each candidate, support "why this matters" with one of route/issue/document.

3. Actually explore routes and screens (playwright-cli) → Verification: the flow steps match the actual screens

Browse the actual screens of the CUF candidates and check the steps (entry → input → branching → completion) and screen transitions. At this point, the existing playwright-cli skill is used as-is as the exploration tool — do not re-explain how to drive the browser here. The minimum commands needed for exploration are as follows.

playwright-cli open <url>      # 앱 진입
playwright-cli snapshot        # 화면 구조·요소(ref) 확인 → 플로우 단계 추출
playwright-cli goto <url>      # 다음 화면으로 이동하며 단계 따라가기

For the full commands, sessions, and options, refer to playwright-cli SKILL.md(.claude/skills/playwright-cli/SKILL.md). For the concrete method of turning exploration into a plan (where to stop, what to write as steps), read references/exploration-with-playwright.md .

If you hit an authentication/payment wall during exploration, stop and record that point as a "prerequisite." Do not read credentials off the screen and enter them.

4. Write the plan → Verification: all sections of the template below are filled in, and each flow has a priority, rationale, steps, expected results, and prerequisites

references/test-plan-template.md Use the structure of e2e-test-plan.mdas-is and write it to (or a path specified by the user). Write scenarios as prose steps so a human can read and review them — do not put selectors/code here (the plan is "what," and selectors are "how," which is the Author stage's responsibility).

5. Human review gate → Verification: the user has explicitly agreed on the priorities/scope

Present the plan to the user and request a review. Do not skip this gate. Example wording:

E2E 테스트 계획서 초안을 e2e-test-plan.md 에 작성했습니다.
Critical User Flow를 우선순위 순으로 N개 추렸습니다.

검토해주실 점:
1. 우선순위가 맞나요? (실패 시 매출/데이터/신뢰 영향 기준)
2. 빠진 핵심 플로우가 있나요?
3. 과한(=테스트 가치 낮은) 플로우가 섞여 있나요?

승인해주시면 이 계획서를 기반으로 테스트 작성 단계로 넘어갑니다.

Revise the plan to reflect user feedback. Do not move on to the test code stage before approval.

Deliverables at a glance

• One file: e2e-test-plan.md (a Markdown file that a human reviews and approves).
• Contents: CUF list (priority/rationale), per-flow scenarios (steps/expected results/prerequisites), explicit out-of-scope items, assumptions and open questions.
• No selectors or test code. That is the next stage after approval.

Domain application example (Naver Pay loan type)

This is an example to get a feel for "what to extract as CUF." Don't copy it as-is; substitute the target app's revenue/data/trust points.

• Loan limit inquiry flow: Home entry → Terms agreement → Mobile phone authentication/identity verification → Limit/interest rate result inquiry. (On failure = the core value itself doesn't work → trust collapse)
• Loan application flow: Applicable product list → Product details → Application complete. (On failure = directly tied to revenue)

These two are the "most important workflows." Something like whether a banner is displayed on the My Page is not a CUF — even if it breaks, there's no direct hit to revenue/data/trust.

Reference files (read when needed)

• references/cuf-criteria.md — CUF determination criteria, revenue/data/trust lens, common anti-patterns (over/under selection).
• references/discovery-sources.md — How to explore issues/planning documents via MCP and alternative paths when MCP is absent.
• references/exploration-with-playwright.md — How to explore with playwright-cli to extract flow steps and move them into a plan (including handling authentication walls).
• references/test-plan-template.md — Plan markdown template (use this format as-is).