Deckle paper

Deckle: Direction Before Pixels

Taste is not a style. It is the discipline of choosing one direction deliberately, executing it with craft, and critiquing the result against the choice. Generic output happens when the model skips the choice and follows its statistical center of gravity. This skill makes the choice explicit, every time.

When NOT to use this skill

Skip this skill for backend or API work, pure copywriting, image-generation requests (the imagegen skills own those), and non-visual code review. If the user names a single specific aesthetic skill they want, use that skill directly.

The Taste Protocol

Run these five moves in order for any design task:

1. Read the brief

Write a one-line Design Read before anything else: what is this product, who is it for, and what should a visitor feel in the first 3 seconds. If the brief is genuinely ambiguous on audience or purpose, ask at most one clarifying question. Product category drives everything downstream: a fintech dashboard and a perfume house cannot share a direction.

2. Propose directions before building

The model's first idea is the distribution's center; the interesting work starts at option two. Propose 4 distinct visual directions tailored to the brief, each as: background hex / accent hex / typeface, plus a one-line rationale. Ask the user to pick one, then implement only that direction. (This is Anthropic's tested pattern for design variety on current models; do not skip it for open-ended briefs. For tightly specified briefs where the user already gave a direction, restate their spec and go.)

3. Lock the direction into a spec

Convert the chosen direction into concrete values before producing anything visual: full palette (all hexes, one gray temperature, max one accent), type pairing (display + body + mono if needed), one radius system, spacing scale, motion budget (what animates, what never animates), and density dial. A direction without exact values regresses to the default under pressure. Write the spec down (in Paper: as the brief; in code: as CSS variables or a DESIGN.md). Prompt like a design system, not a wish; this skeleton is the minimum to lock:

DIRECTION  one line: what it is, who it's for, the 3-second feeling
PALETTE    bg / surface / text / one accent (all hex) · one gray temperature
TYPE       display / body / mono · weights · tracking on micro-labels
STRUCTURE  radius system (one) · spacing scale · density dial (airy ↔ dense)
MOTION     what animates, what never · budget per element class
LAYOUT     grid + hero composition (asymmetric split / centered / image-first)
CONSTRAINTS the 1-2 things that must not change

4. Route to the direction pack and apply the always-on rules

references/craft-rules.md holds the always-on layer: 17 consensus rules every direction obeys, plus the conditional rules that resolve where the taste skills disagree (serifs, centered heroes, motion loops, radius, glass). references/direction-packs.md maps the chosen direction to the installed specialist skill to defer to, with the overrides that stay in force. When the direction needs a specific effect or layout system — layered shadows, gradient borders, progressive blur, edge-fade masks, mesh atmosphere, scroll-reveal or masked-word motion, marquees, editorial-grid / technical-split / image-first layouts — references/craft-recipes.md gives the exact values, and works even when no specialist pack is installed. Working in Paper or another canvas tool: references/paper-workflow.md is the build loop. When the brief is a fixed reference to match 1:1 (a screenshot, a competitor page, a dribbble shot): references/reference-recreation.md replaces steps 1-3 with measurement and adds the renderer-probing and vector-illustration loop.

5. Critique from the render, not the code

After each meaningful build step, look at the actual render (screenshot in Paper, browser in code) and judge it against the locked spec and the craft rules. Fix the single worst thing first, re-render, repeat. Ship only when a screenshot passes the exit checklist in references/paper-workflow.md. Code that reads well and renders generic is a failure; only the render is real.

Reference routing

Need	Read
Always-on craft rules and conflict-resolving conditionals	references/craft-rules.md
Which installed skill owns which direction, with overrides	references/direction-packs.md
Concrete recipes with exact values (depth, atmosphere, motion, layout systems)	references/craft-recipes.md
Building and critiquing in Paper (canvas workflow)	references/paper-workflow.md
Recreating a fixed reference 1:1, isometric/vector illustration, shader-style atmosphere	references/reference-recreation.md

Non-negotiables

1. One direction per surface. Commit fully. Mixing two directions reads as no direction.
2. Exact values or it did not happen. Hexes, font names, radius numbers, durations. "Warm and minimal" is a mood, not a spec.
3. The default is the enemy. Cream plus serif plus terracotta, purple gradients, Inter everywhere, three equal cards: these are the model's gravity wells. The craft rules name them so you can steer past them.
4. Motion is a budget, not a garnish. Decide upfront what moves and why. User-initiated feedback stays under 300ms; scroll entrances may take 600-800ms; infinite loops only on live or status elements, at most one per viewport.
5. Critique the render. Screenshot, judge, fix the worst thing, repeat. Never declare a design done from code alone.
6. Real content. No lorem ipsum, no John Doe, no Acme, no emoji as icons, no "Elevate your workflow". Write plausible copy for the actual product.