# Your first review

> Ask an agent for a pricing card, review it with the skill, read the Before / After / Why table and apply the fixes.

Module: Start from zero · Level: beginner · 8 min · https://school.agents.org.in/foundations/start/your-first-review

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:

*[Interactive demo: Each row of the review is one change. Apply them one by one, then press the buttons to feel row 4.]*

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:

**Build the card (paste into your agent):**

```text
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:

```bash
/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` verb (The first word after /design-engineering, like review, polish or motion. It picks which procedure the skill follows) 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 Before / After / Why (The table a design-engineering review comes back in: the exact line, its replacement, and one sentence of reason. One problem per row) 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:

  **Step: Before.** The exact line from your code, quoted. So you can find it.

  **Step: After.** The replacement. Same job, better result.

  **Step: 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.

> **You can disagree.** A review is advice, not orders. If a row is wrong for your design ("no, I want the price small, it is a quiet page"), say so. If you disagree with the skill often in the same way, write it in `pov.md` and it will stop suggesting it.

## 4. Apply the fixes

Once you have read the table, ask the agent to apply it:

**Apply the review (paste into your agent):**

```text
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) (avoid):**

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 <kbd>Tab</kbd>.

  **After (do this):**

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 <kbd>Tab</kbd> through.

Try the keyboard too: press <kbd>Tab</kbd> 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.

**Check yourself:** In a Before / After / Why review, why does every row need a Why?

- [ ] To make the table longer
- [x] So you can judge whether the change is right, and learn the rule for next time
- [ ] Because the agent cannot apply a fix without it
- [ ] To link to the documentation

*Why:* The Why is what lets you accept, reject or learn from a change. A change nobody can explain in a sentence is usually not worth making.

## In the skill

- https://school.agents.org.in/skill/commands/cmd-review.md
- https://school.agents.org.in/skill/meta/review-format.md
- https://school.agents.org.in/skill/meta/review-checklist.md