Choose your target

This step settles two things. Which track your app belongs to, and which flows in that app would stop the business if they broke. Those two become tests, directly, in the next step.

In Claude Code, this step is handled by the /3-analyze-target skill. Depending on the rhythm you set earlier (novice or experienced), the questions arrive one at a time or in bundles.

1) Which track is my app

Pick one or more of three tracks. Usually it is just one.

What your app looks like	Track	Tool used
A website, SPA, or PWA you open in a browser	web	Playwright
A desktop app you install and run (Electron)	electron	Playwright _electron
An app you install on a phone	mobile	Maestro

If you are unsure which track applies, go by how you open the app. Type a URL into the address bar and you are in — that is web. Double-click an icon and a window appears — electron. Tap it from the phone’s home screen — mobile.

For mobile, start with Maestro. Within mobile there are finer choices depending on whether it is Expo, React Native, or native, but those branches are covered in the Expert manual. On a non-developer’s rhythm, “mobile means Maestro” is enough.

2) How will the tests reach my app

For the tests to knock on your app, you have to tell them where the app is. The approach differs slightly by track.

• web: a local dev server command (for example, npm run dev brings it up at http://localhost:5173) or a staging URL.
• electron: the path to a built app binary, or the project folder.
• mobile: an Expo, React Native, or native build, installed on a simulator or emulator.

What you answer here is where the app lives and how to bring it up. Real values like a test account password are not asked at this seat. You write those into .env.test.local yourself (number 6 in Prerequisites).

Never point at production or a real database

The “where the app lives” you give here has to be a local, staging, or dedicated test environment. Never point it at the live production server real users depend on, or at a real database.

The tests sign up, click checkout, create and delete data. If the target is the production server, real user data gets corrupted, real charges fire, and real accounts can disappear. The AI also warns you if you try to enter a production URL and steers you toward staging or a dedicated environment. This is the seat this base guards hardest.

If you do not have a staging environment yet, bringing up a dev server locally and pointing the tests there is the safest and fastest route.

3) Lay out the flows that would be fatal if they broke

This is the most important seat. Pull three to five user flows out of your app at the “if this breaks, the business stops” level.

The AI asks it like this.

Tell me the user flows that would stop the business if they broke. (e.g. log in → check out → dashboard)

Write each flow as one line of “who / does what / and what result.” That one line becomes one test later. For example:

• A logged-out visitor clicks Pro checkout on the pricing page and lands in the dashboard
• A logged-in user changes their profile name in settings and it saves
• A new user finishes signup and a welcome screen appears

Resist the urge to overreach here. Try to test every screen at once and it never ends. Pick the three to five most fatal flows first, and out of those, mark the one or two to automate first. Those one or two are the smoke candidates — the first tests you build. The rest you expand later.

4) Where the result gets recorded

When you finish answering, the AI writes it into a file called docs/design/e2e-spec.md. §1 holds the app overview (name, description, track, approach, environment), and §2 holds the list of critical flows with their priorities. That file becomes the reference point for the tests from here on. After the AI writes it, it shows you what changed, so glance over it once to confirm the flows you meant landed correctly.

When you cannot think of what to test

If you have an app but cannot pin down which flows are fatal, call /brainstorm-e2e first. In a short conversation it narrows down “which app, and which flows would stop the business if they broke” with you. Run it once, then move to /3-analyze-target and the answers come a good deal easier.

Next

With the track and the critical flows set, it is time to turn one of them into an actual test. Head to Your first test.