identify-user-flows

Identify User Flows

Writes the flows a real user performs, as recipes a browser can replay:

• <recon-dir>/user-flows.json — shared config (base URL, viewports, auth) and cross_feature_flows[]
• <recon-dir>/flows/{slug}.json — one file per feature, written by one agent each

One recipe, two consumers — /test-user-flows runs it to find out what breaks, and /create-demo-videos runs it to film what works.

This is the step where a static report becomes something executable. The sweep already described this codebase's flows in prose and said where each one stops; this turns those sentences into selectors.

Bundled files live beside this SKILL.md (${CLAUDE_PLUGIN_ROOT}/skills/identify-user-flows/): reference/flow-spec.md, templates/user-flows.example.json, templates/feature-flows.example.json. The agent lives at ${CLAUDE_PLUGIN_ROOT}/agents/recon-test-engineer.md. Always pass absolute paths.

Procedure

1. Resolve arguments

• <recon-dir> — default docs/recon, or --dir <path>.
• --base-url <url> — where the app is running. Default http://localhost.
• Explicit feature list, if the user gave one → only those features.
• --sequential → no fan-out; do the work yourself, one feature at a time.

2. Find the app, and confirm it is up

A recipe written against a guess is worthless, so establish these before anything expensive:

• The base URL and how the app is started. Read the README, compose.yaml/docker-compose.yml, Procfile, package.json scripts, Makefile. Do not start it yourself without asking.
• How login works — the login route, the field selectors, where a logged-in user lands. Open the login page component; do not assume #email / #password.
• Whether there are test credentials — .env.example, CLAUDE.md, seeders, factories.

Then check the app actually answers:

curl -s -o /dev/null -w '%{http_code}' <base-url>

If it is not up, say so and stop. Everything downstream needs a live app, and a recipe written blind will be wrong in ways nobody can see until the run fails.