Make the skill 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 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.

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.

gotchas.md: the lived failures

gotchas.md is append-only. Every time the agent gets a UI detail wrong in practice, you add one dated line.

- [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.

/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:

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.

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.

1. Loading

   Ten queries that should load the skill; it loads on all ten.

2. Not loading

   Ten nearby queries that shouldn't; it loads on none.

3. The right node

   Five queries mapped to specific nodes; the agent opens those.

4. 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.

Measure whether a change helped

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

"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 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.