Part 2 is the build-and-polish episode. study-buddy, the made-up flashcards app from Part 1, has a FlipCard component that grew three nested ternaries and a copy-pasted animation hook, and it still has no landing page. Three commands cover that: /effort to set how hard Claude thinks, /simplify to tidy what changed, and /frontend-design to build the page. Facts are Anthropic's; the app, its components and every prompt are illustrative.
TL;DR
- /effort takes low, medium, high, xhigh or max, plus status, auto and ultracode. The level is saved per model; max only lasts the session.
- Opus 5.5 and Sonnet 5.5 default to medium. For the full low-vs-max story, read our effort levels deep dive.
- /simplify runs four review agents in parallel to clean up your changed code and applies the fixes. It doesn't hunt bugs; /code-review does.
- frontend-design lives in Anthropic's example-skills plugin: install it, then call /example-skills:frontend-design with a real brief.
- A UI isn't done until you've seen it at real widths. Screenshots or it didn't happen. 📸
/effort in 60 seconds
The full syntax is /effort [level|auto|status|ultracode [on|off]]. The levels are low, medium, high, xhigh and max. status prints where you are, auto clears the saved level for the active model, and ultracode is Part 3's problem.
/effort status # what am I on?
/effort high # verification matters on this one
/effort auto # clear my saved level for this model
/effort max # this session onlyTwo details people miss. First, effort is saved per model. In the effort slider, Enter saves the level as that model's default, while s applies it to this session only, and max never sticks because it's session-only by design. Second, the defaults differ: Opus 5.5 and Sonnet 5.5 start at medium, Opus 4.7 at xhigh, and other models at high. Switch models and your effort can quietly change with them. One more: changing effort mid-turn can show a prompt-cache warning. Our tip: switch between turns, and see our effort levels post for how caching behaves.
Which level for which job? We already wrote the long version: Claude Code effort levels: low, medium, high or max? breaks down Thariq Shihipar's "Spending your effort" post with build times and benchmark charts. For this part our plan is simple: the cleanup and the landing-page build run on the default, and we bump to high for the final verification pass.
/simplify: a cleanup crew, not a bug hunter
/simplify [target] is a bundled skill that reviews your changed code for cleanup opportunities and applies the fixes. Under the hood, four review agents run in parallel, each with one lens:
/simplify
Reviews your changed code, or the path or PR you point it at.
Reuse
Is this rebuilding a helper that already exists?
Simplification
Can it be shorter and clearer?
Efficiency
Is it doing work it doesn't need to?
Abstraction level
Is the code pitched at the right level?
Fixes applied
Then you run your check again.
The docs are explicit that the review "doesn't look for correctness bugs". It only runs when you invoke it directly, and you can aim it at a path or a PR reference. For study-buddy:
/simplify src/components/FlipCard.tsxWhy aim it at one file? Because /simplify applies its fixes instead of just listing them, and a tight target keeps the resulting diff small enough to actually read before you move on. Big refactor energy is great; a big unreviewed diff is not.
Bugs are a different command. /code-review checks the current diff for correctness bugs and can apply what it finds with --fix; /code-review high 1234 reviews a PR, and /code-review ultra runs a multi-agent review in the cloud. Since v2.1.218 it runs as a forked subagent. Side by side:
| /simplify | /code-review | |
|---|---|---|
| Looks for | Cleanup: reuse, simplification, efficiency, abstraction level | Correctness bugs in the current diff |
| Finds bugs? | No, by design | Yes, that's the job |
| Applies fixes | Yes | With --fix |
| Targeting | A path or a PR reference | A PR number, e.g. /code-review high 1234 |
| How it scales | Four review agents in parallel | ultra: multi-agent review in the cloud |
Our order on study-buddy: /code-review first, so we're not polishing a bug, then /simplify, then the deck tests again. Cleanup that breaks the tests isn't cleanup, it's a new bug with nicer formatting.
/frontend-design: install it, then brief it like you mean it
frontend-design isn't built in. It ships in Anthropic's public skills repo inside a plugin called example-skills, which sits next to document-skills (the PDF, DOCX, PPTX and XLSX one). Install both the marketplace and the plugin from inside Claude Code:
/plugin marketplace add anthropics/skills
/plugin install example-skills@anthropic-agent-skillsPlugin skills are namespaced as /plugin-name:skill-name, so the full call is /example-skills:frontend-design. The bare /frontend-design also works, unless another command already uses that name.
The skill is only as good as the brief you hand it. Every line of a good brief does a job: the audience sets the tone, real copy stops placeholder text from shipping, constraints stop it from inventing a second component library, and the "done when" line is Part 1's check wearing a UI outfit. Same command, two very different inputs:
😶 Vibes-only brief
what most of us type
One line. No audience, no copy, no constraints.
You get whatever the model's default taste is today, with nothing to check it against.
/example-skills:frontend-design make a landing page for my app🎯 Checkable brief
what we'd send
Who it's for, the real words, the sections, the constraints and how you'll judge it.
Now there's something concrete to compare the result against.
/example-skills:frontend-design Landing page for study-buddy.
For: uni students cramming the week before exams.
Hero: "Your notes, now flashcards." One button: Try a deck.
Sections: how it works (3 steps), a live FlipCard, FAQ.
Use: Tailwind and the existing FlipCard. No stock photos.
Done when: no sideways scroll on a phone or a wide desktop.Both briefs are illustrative, written for this post.
Screenshots or it didn't happen
A page that looks great in the one window you happen to have open is a vibe, not a result. Anthropic's best practices suggest pasting a screenshot or a design and asking Claude to screenshot its result and compare the two. For study-buddy we check at least one phone width and one wide desktop, flip a card in each, and look for overflow, clipped text and a button that has wandered below the fold.
Two more commands close the loop. /verify (a bundled skill) builds and runs your app to confirm a change does what it should, not just that tests and type checks pass. /run launches and drives the app. After that: /code-review the diff, /simplify the new page, and run your check one last time. That's three commands and one brief between "no landing page" and "a landing page we've actually looked at".
The whole series
- Part 1: Audit your prompts with /claude-api prompt-audit
- Part 2: /effort, /simplify and /frontend-design (this post)
- Part 3: ultracode, /batch, /compact and /rewind
- Part 4: build-eval and hillclimb for your Claude app
Next up: Part 3 goes big, with ultracode, /batch, /compact and /rewind for migrating study-buddy's components to TypeScript without losing the plot.