Beta DX Walk (Friction Is a Bug)
Walk a product's critical journeys as a skeptical first-time user and treat Source: skills/engineering/beta-dx-walk/SKILL.md friction as a bug. Anything that makes the user pause, guess, reread, or ask for help is a logged issue, triaged by user outcome, ending in a ship/hold call.
Most testing asks "does it work?" A beta DX walk asks the two questions a real
first user has: do I understand what to do next, and can I recover when
something fails. Codified as the beta-dx-walk personal skill
(skills/engineering/beta-dx-walk/SKILL.md).
Friction as a bug
The core move is to treat hesitation as a defect, not a user error. If the user has to pause (figure out what something means), guess (act unsure), reread (parse the same UI twice), or ask for help (docs, support, give up), that step is a bug - even when nothing is technically broken. The agent has to log it before it learns the trick, because once it knows the workaround it has lost the first-run lens.
Severity by user outcome (not fix size)
| Severity | Meaning |
|---|---|
| blocks-beta | User cannot complete the journey: dead end, broken action, silent failure, no recovery path, data loss. |
| confuses-beta | User completes it but had to pause / guess / reread, misreads a state, or recovers only by luck. |
| polish | Works and is understood; minor wording, alignment, or delight gap. |
Each finding records what the user tried, what they expected, what happened, the recovery path, and evidence (screenshot, console / network log, URL, repro steps).
Where it sits in the loop family
The bottleneck in agent-built products is not code generation, it is whether a human can actually use the result. The beta walk is the first-run-user lens of the loop:
- It is the Browser Testing Skills "verify live" phase, specialized for a first-time user, and it generates the follow-up fixes that loop ships.
- It is distinct from Browser Testing Skills (breadth-first bug hunting across the whole surface) - the walk is journey-first and ends in a beta-readiness verdict.
- It is a standing loop (Agent Looping): re-walk every beta cut; recurring friction gets codified so it is caught earlier.
- The ship/hold verdict is a human decision the agent informs, not makes (Staying in the Loop with Agents); pairs with The Eval Loop (Slop Is an Output Problem) for scored, repeatable quality over time.
Hard rules
- Test as a user; do not read app source to explain away confusion.
- Use a fresh / incognito session and a new account for true first-run state.
- Produce a report + verdict, not a fix; route fixes through the iteration loop.
- Empty states and error / recovery paths are first-class journeys.
- Never touch prod data / infra or growth surfaces; tear down spawned servers and browsers (Agent Process Tracking, Audit, And Cleanup).
Concept Position
| Field | Value |
|---|---|
| Concept family | Agent harness and runtime primitives |
| Concept owned | Walk a product's critical journeys as a skeptical first-time user and treat Source: skills/engineering/beta-dx-walk/SKILL.md |
| Category map | Concept System Map |
Timeline
- 2026-07-01 | Concepts category refresh added this page to the Agent harness and runtime primitives family, linked it to Concept System Map, and kept it standalone because it owns this reusable mental model: Walk a product's critical journeys as a skeptical first-time user and treat Source: skills/engineering/beta-dx-walk/SKILL.md. Source: User request, 2026-07-01