Workflows in Action

The one line: run a ticket as two prompts, one that researches and writes a plan you review, one that executes it. Then read the diff yourself: the summary is not the change.

The ticket

Four button sizes, one of them dead. Collapse to three across a marketing site and a logged-in platform, with nothing changing on screen. Too big to hand-edit, and the failure is silent: buttons with no size set inherit the new default, and no type checker notices.

Prompt one buys the plan, not the code

The first prompt touches no source files. It reads the repo and writes a document.

ultracode: run a workflow that gathers all the context on what we should do
here, and draft me a plan document for how we handle this ticket.

That is the whole prompt. The workflow fans out across the component, the call sites, the siblings and the visual regression setup, converges on verify and synthesise-and-decide stages, and drops a markdown plan in docs/plans/.

The plan comes back with:

• A verdict. Take the shift: old sm becomes the new default, old default becomes lg, old lg becomes xl. Class strings move byte-identical, so nothing changes on screen.
• What you lose. The small size cannot come back: on mobile the button height is pinned to the input height, and the input has a floor so iOS Safari does not zoom on focus.
• Collision check. xl exists already with zero call sites, so the rename is safe.
• The silent break. Roughly 55 buttons carry no size prop. They shift when the default moves, invisible to the type checker.
• Scope and staging. One PR, three commits, each named.
• Risks and open questions, each with a recommended default.

Every open question ships with a recommendation, so answering nothing still ships a sane change: drop the small size, pin the 55 unsized buttons to their current size.

Reviewing the plan

Ten minutes here is worth an hour later. I take most recommendations as written, including both sizing ones, and reject one: the plan wants to delete the pagination component as unused, and it stays, because it will be needed.

You are reviewing scope and invariants, not code. Both are cheap to change in markdown and expensive in a merged branch.

Prompt two is the execution brief

Dictated, not typed (see Voice Dictation), because it is long and specific:

Launch the workflow that does this shift. Fully preserve styling. If something
can run as a script, run it as a script to preserve tokens; otherwise use
workflows and parallel agents, and use cheaper models for the obvious work.
On the sizing questions: go with the recommended answers. On pagination: do
not delete it, it may be used later. As part of verification, build, start the
server, and use the agent-browser CLI to navigate the site and take before and
after screenshots on the important pages, especially public ones. Test user
credentials are in `.env.local` — log into the platform and check there too.
End with a pull request.

Scripts over model edits keeps 55 mechanical renames out of the context window. Screenshots turn "should be identical" into a before/after pair, and the credentials let the agent see the logged-in half of the app.

What the workflow actually ran

The script is written under your session directory in ~/.claude/projects/; saving it from /workflows puts it in .claude/workflows/. In apply, the model wrote a code-mod script and ran it: one file from the model, 55 call sites from the script. Delete those scripts before you merge. Verify ran static gates plus visual diffs against the baseline, and nothing failed. The PR went through my pr-issue skill, so it came out in the house problem/solution format instead of a list of commits.

You still read the diff

Read the diff by route group against an invariant. Platform pages used the small size, so every platform file should show size="sm" removed; marketing and static pages used the default, so they should show lg added. Shared UI follows: alert dialog cancel and calendar go large. Open whatever breaks the pattern.

Then run it. pnpm install, then the dev server, which died on a port an earlier agent run left in use, then an internal server error the linter showed as a parse error. Both are normal, so budget for them.

Then click through the public pages, log in and walk the platform: catalog, forms, onboarding, calendar, phone input. Most of it looked identical. Ghost buttons on the calendar look wrong at the new size. That regression becomes its own issue, not scope creep here.

If a region of the diff makes you uneasy, do not squint at it. Fire a second workflow scoped to it: check the diff for this route group, verify every changed call site. That takes minutes.

The deviation

A workflow good enough to correctly disobey you is one you have to read. This one deviated once, on an input-group button that sized itself mid-range instead of following the rename, and it was right to.

What to do

• Split every non-trivial ticket into a research prompt and an execution prompt; the first never edits code.
• Make the plan carry a verdict, scope, staged commits, risks and open questions with recommended defaults.
• Spend real time on the plan, and answer only the questions where a wrong default would show.
• Demand scripts over model edits, cheap models for mechanical work, before/after screenshots, and a PR at the end.
• Review the diff by route group against a stated invariant, then click through it yourself.
• Scope a second workflow at any region you doubt; split real regressions into their own issue.