# Make the skill yours

> Fork the skill's taste in pov.md, log every lived failure in gotchas.md, write lines that actually change an agent's behaviour, and test that they work across models.

Module: Directing your agent · Level: advanced · 9 min · https://school.agents.org.in/foundations/agents/make-it-yours

Two teams install the same skill. One makes a calm banking dashboard. The other makes a language-learning app where every button looks pressable and every win gets confetti.

Same skill, opposite answers. The difference is two small files the skill tells you to edit.

## pov.md: your taste overrides

The skill's canon comes from people like Emil Kowalski, Benji Taylor and Jakub Krehel. pov.md (The file where you override the skill's taste with your own. Where it disagrees with the canon it wins; where it's silent, the canon holds) is the layer where **you** override it. Where it disagrees with canon, it wins. Where it's silent, canon holds.

The install this course is built on is forked to Duolingo's design language: physical buttons with a 4px lip in a darker shade of their own fill, colours that each carry one meaning, rounded lowercase headlines, celebration on the reward beat. Those calls flip several defaults, like whisper-thin shadows and one-accent palettes.

  **Changes nothing (avoid):**

I like clean UI.

  **Changes output (do this):**

1px borders everywhere. If a border needs more weight, raise its contrast, never its width.

Two kinds of entry are useful: **hard overrides** ("I never use X") and **taste calls** ("when in doubt, lean toward A because B"). A taste call should orient a decision, not amputate a possibility.

> **Two things outrank taste.** The accessibility floor and reduced motion. White text on a bright green fill fails contrast however on-brand it is; celebration is the first thing to drop when someone asks for less motion.

## gotchas.md: the lived failures

gotchas.md (One dated line in gotchas.md recording something the agent got wrong in practice, and the fix. The file only grows, and negative examples teach the agent the most) is append-only. Every time the agent gets a UI detail wrong in practice, you add one dated line.

```text
- [2026-10-30] Agent declared color-scheme: light dark on a light-only app; phones in dark mode rendered dark inputs on white cards. → Declare only the schemes that were designed. See [[contrast-and-color-scheme]].
```

Why it matters: the main nodes encode the happy path. Gotchas encode the failure, with the exact mistake. Perplexity's agent-skills team found negative examples are often the highest-signal content in a skill over time. The description should change rarely; this file should grow steadily.

| Put it in gotchas | Put it in pov |
|---|---|
| "The agent did this wrong; here's the right answer." | "I prefer this default over the canon's." |
| one line, linked to a node | as long as the call needs |

**Log a gotcha (paste into your agent):**

```text
/design-engineering pov gotcha "the agent hid the closed drawer with opacity: 0 and keyboard users tabbed into it"
```

## Lines that change behaviour

Agents are probabilistic: ask twice, get two answers. A skill can't force the same *output*. It can force the same *process*, so the reasoning is yours every run. The skill's writing rules (How to write a skill that changes behaviour: encode a process, write the why, be strict, make every line earn its place, keep one skill per job, and test by running):

1. **Encode process.** Give a decision tree the agent walks every time.
2. **Write down the why.** A rule with its reason gets extended to cases you never wrote.
3. **Be strict.** "Reasonably short" changes nothing; "under 300ms" does.
4. **Every line earns its place.** Explaining what a button is dilutes the lines that matter.
5. **One skill per aspect.** Building animations and reviewing them are different jobs.
6. **Test by running.** Unsure if a line matters? Run with it and without it.

Try it on a draft. Tap each line to rewrite it by those rules.

*[Interactive demo: Hedges become numbers, rules gain a why, and what the agent already knows gets deleted.]*

**Strict is not long.** A strict file is usually shorter than the hedged one it replaces, because every hedge was a sentence that did nothing.

## Test across models

A skill that loads perfectly on one model may never load on another. Perplexity's team put it plainly: Sonnet and GPT behave quite differently with skills. Most authors test on the model they happen to use.

  **Step: Loading.** Ten queries that should load the skill; it loads on all ten.

  **Step: Not loading.** Ten nearby queries that shouldn't; it loads on none.

  **Step: The right node.** Five queries mapped to specific nodes; the agent opens those.

  **Step: The right output.** "Review this CSS" comes back as the table.

Known patterns: GPT routes on broad nouns like "CSS" more eagerly; Sonnet can skip a description over about 80 words; Haiku may stop at the top file and never open the notes; Opus over-reads. A gap of 5% or more between models on the same set is a routing problem.

*(Use real queries from real users. Ones you wrote yourself only prove the description matches you.)*

## Measure whether a change helped

Taste is trained, but it can also be measured. Two public benchmarks show the shapes worth borrowing:

| Benchmark | What it measures | Borrow |
|---|---|---|
| DesignBench (WebPAI) | generation, editing and repair of real web UI, scored by compiling, visual similarity and a model judge | the three tasks: real work is mostly edit and repair |
| Design Arena | anonymous side-by-side votes, ranked with a Bradley-Terry fit | blind pairwise judging |

"Is this good?" has no honest answer. "Which of these two is better?" does. So when you change a node that alters output, generate before and after for a few fixtures, judge them blind, and record the win rate. A node that loses the pairwise (Judging two outputs side by side, without knowing which is which, and picking the better one. Honest where 'is this good?' isn't; the win rate tells you if a change helped) more than it wins gets reverted, however good it reads.

One trap: similarity scores reward matching the reference, flaws included. A repair that fixes an overflow the reference also had can score *lower*. Read the pairwise result first.

**Check yourself:** Your team always wants 1px borders, raising contrast instead of width when a border needs more weight. Canon doesn't say this. Where does it go?

- [ ] gotchas.md, as a dated failure line
- [x] pov.md, as a strict taste call: '1px borders everywhere; for more weight raise contrast, never width'
- [ ] The skill's description, so it loads more often
- [ ] Nowhere: mention it in each prompt

*Why:* A preference that overrides or extends the canon is a taste call, so it belongs in pov.md, written strictly. gotchas.md is for a specific thing the agent got wrong, with its fix.

## In the skill

- https://school.agents.org.in/skill/meta/pov.md
- https://school.agents.org.in/skill/meta/gotchas.md
- https://school.agents.org.in/skill/meta/skill-writing-rules.md
- https://school.agents.org.in/skill/meta/cross-model-testing.md
- https://school.agents.org.in/skill/meta/design-benchmarks.md