Your first review
beginner·8 min·Markdown for agents
What this lesson teaches
Ask an agent for a pricing card, review it with the skill, read the Before / After / Why table and apply the fixes.
This is the loop you will use for the rest of the course: build, review, fix, look. Here is the pricing card an agent made on its first try, and the review the skill wrote for it. Apply the fixes one at a time and watch the card change:
- Unlimited projects
- 10 teammates
- Priority support
color: #9ca3afcolor: oklch(0.45 0 0)Gray body text was 2.5:1. Now 7:1, readable.font-size: 16px (price)font-size: 40px; tabular-numsThe price is what people came for. Make it the biggest thing.3 filled buttons1 primary, 1 quiet linkOne obvious next step. Three equal buttons is no choice.no :active stylescale(0.97) on press, 160msThe button answers your finger.outline: none:focus-visible ring, 2pxKeyboard users can see where they are.Every row was small. Together they turn a card that looks generated into one that looks considered. Now do it yourself, in your own project.
1. Ask for a pricing card
In your project folder, with your agent running, ask for something small enough to check at a glance:
Make a pricing card component for a "Pro" plan at $24/month: the plan name, the price, three features and two buttons, "Start free trial" and "Compare plans". Put it on a page I can open in the browser. Don't use the design-engineering skill yet.
The last line is on purpose. You want to see the agent's default first, so you can see what the review changes.
Open the page and take a screenshot. You will want it later.
2. Run the review
Now ask the skill to review what it made. Give it the file it just wrote:
$ /design-engineering review src/PricingCard.tsx(Use whatever file name the agent created. With the plugin install, type /design-engineering:design-engineering review ….)
The review reads the code against a checklist of a few dozen common mistakes: animating everything, gray text that fails contrast, missing focus styles, buttons that do not respond to a press. It does not change anything yet. It reports.
3. Read the table
The review always comes back in the same shape: a table. One row per problem.
| Before | After | Why |
|---|---|---|
color: #9ca3af | color: oklch(0.45 0 0) | Body text was 2.5:1 contrast; now about 7:1 |
transition: all 300ms | transition: transform 160ms | Animate only what moves |
outline: none | a 2px :focus-visible ring | Keyboard users can see where they are |
Each column has a job:
Before
The exact line from your code, quoted. So you can find it.After
The replacement. Same job, better result.Why
One sentence of reason. If the agent cannot say why in a sentence, the change is probably not worth making.
Read the Why column first. It is where you learn. After a few reviews you will start spotting these problems before the agent does.
4. Apply the fixes
Once you have read the table, ask the agent to apply it:
Apply every row of that review table except any you think is wrong for this card; tell me which you skipped and why. Then show me the page again.
Reviews only report; you decide what changes. That is on purpose: the skill keeps "judge" verbs like review separate from "do" verbs like polish, so nothing is changed behind your back.
5. Compare before and after
Open the page again and put it next to your screenshot from step 1. Look for:
✕ Before (typical)
Light gray text that is hard to read. A small price. Three buttons fighting for attention. Nothing happens when you press a button. No visible focus when you press Tab.
✓ After
Text you can read. The price is the first thing you see. One obvious button. Buttons that dip slightly when pressed. A clear ring when you Tab through.
Try the keyboard too: press Tab to move between the buttons. If you cannot see where you are, the focus row was skipped.
Look at the screen, not just the table. A review that reads well and looks wrong is still wrong.The loop
That is it: build, review, apply, look. It works on any screen, and the next modules teach you what each row in a review means, so you can direct the fixes yourself instead of only accepting them.
Quick check
In a Before / After / Why review, why does every row need a Why?
In the skill
The nodes your agent reads when it does this work.
- /design-engineering review
commands/cmd-review - Review format (required)Mandatory format for UI code reviews — Before | After | Why markdown table.
meta/review-format - Review checklistAudit table — thirty-nine common UI issues, each with a grep and a fix. Scan against this before signing off.
meta/review-checklist
Connected lessons
What this lesson builds on and leads to, across every course.