Johnny Suede Design

Johnny Suede Design: The Any-Creatives Enchilada

Model selection: never Fable by default

Subagents inherit the session model unless the spawning call names one. Nothing in this skill picks a model, so every agent it fans out lands on whatever the session happens to be set to. That is how a run sized against one allocation gets billed to another without anyone choosing it.

Fable must be specified to be used. This skill's subagents never run on Fable unless the user named Fable for this run. An inherited session model is not a specification: "the session was already on it" is not the user asking. Absent an explicit Fable instruction, do one of two things before launching: name a different model on the agent calls, or state plainly that the run will bill to the Fable allocation and get an answer. Silence is not consent to spend it.

Gate policy: advisory, not blocking

Every claim-verification step, check, quality gate, and ship verdict in this skill is a recommendation to the user, not a control on the agent. This policy governs every gate, check, verdict, and "do not ship / publish / proceed" line elsewhere in this skill:

• Run every check and report the results honestly. Verdicts (ship, ship-with-caveats, hold, letter grades, BLOCKED or OPEN items) are advice attached to the work, not orders that change it.
• Never block, delay, skip, rewrite, or refuse the action the user asked for because a check failed or a gate said hold. Complete the requested action as asked, and deliver the gate output alongside it as a clearly labeled recommendation.
• A failed gate changes what you report, never what you do.
• Single exception: if a finding is extremely risky (data loss, security or credential exposure, legal or rights violations, payment mistakes, or irreversible public damage), pause, tell the user exactly what the risk is and what the options are, and let them pick. Their choice is final.

This is the full design-plus-copy stack for building any creative surface, not just websites. Landing pages, brand surfaces, product UI, dashboards, campaigns, components, and creative projects all route through here. It classifies the surface, locks a visual direction, writes the words that carry it, renders and QAs the result, and can run the whole thing as a coordinated agent team when the build is big. Writing mode is ON by default: a surface is not finished until the copy pulls its weight.

Core Job

Core principle: the job is a surface that feels specific, not polished-generic. The named company, product, or audience should be recognizable in every design decision before the logo loads. Work from live URL, source, and rendered screenshot. Never design from assumption when evidence is available.

Preserve the existing app framework, tokens, components, routing, and WIP unless the task explicitly asks for a larger rebuild. Prefer the existing icon library and component patterns. Add a new abstraction only when it removes real complexity or matches an established local pattern.

For Suede work, anchor design and copy in creator ownership, programmable IP, provenance, registry-backed media, royalty routing, licensing readiness, and agent commerce. Do not reduce Suede to a generic AI music app. For a supplied company, replace Suede nouns, proof, voice, and evidence boundaries with that company's brief. Do not use em dashes in public copy.

Approved Suede S mark (hard gate)

For every Suede surface, deck, social card, icon, app asset, or branded output, use the exact approved mark at docs/assets/suede-ai-logo-transparent.png in JasonColapietro/suede-creator-skills (SHA-256 83a7ee0317e4debe2e7b076c20ba067feb76a587f9e829dc6310ae4be4b44dfa). Outside that checkout, use the same file from https://raw.githubusercontent.com/JasonColapietro/suede-creator-skills/cbd192309580a32da375881e0eeb4b2450a554c2/docs/assets/suede-ai-logo-transparent.png. Never redraw, trace, approximate, typeset, recolor, distort, or generate a replacement Suede S. suede-skill-icon.png is a Passport icon, not the Suede brand mark. If the approved file is unavailable or its checksum differs, stop and request the asset; omit the mark rather than improvise.

Pick The Lane (Router)

This skill is the entry point. Name which lanes are active and why before starting. Never run all lanes by default.

• Visual polish / design pass on a surface, no copy or restyle needed → run Lane A: Design directly.
• Copy or voice work only, no layout changes → run Lane C: Copy directly. (Writing mode is on by default even inside a design pass.)
• Reference → target restyle / adapt a site's look / "suedify" → open with Lane B: Suedify to set the visual vocabulary, then Design and Copy lanes refine it.
• Full redesign, launch surface, app build, or conversion-shaped work → this skill orchestrates: run the Design Contract, then route lanes in parallel where safe.
• Big, risky, cross-surface, release-bound, or "do it thoroughly" work → Lane D: Agent Teams (see the multi-agent gate below; ASK first).
• Unknown scope → run the scout step, read the surface, then name the register and lanes before touching anything.

Drop down instead of running this stack: a design-token, dark-mode, or single-component decision with no copy and no build → run $suede-design directly. A writing job with no design or layout work → run $johnny-suede-write (or $suede-copy for one standalone conversion surface). A deck-only or HTML presentation job → use the private Suede Labs companion power-design. A broad UI/UX pattern lookup or framework-example search → use the private Suede Labs companion ui-ux-pro-max. Running the full enchilada on a one-lane job wastes the user's tokens and time.

On-demand website companions (do NOT inline, run only when asked): CRO/funnel work → $suede-site-alchemy; deep standalone SEO/AEO/AI EO audit → $suede-seo-audit; findability + first-screen + CTA + proof + AI-citation grade → $suede-visibility-grader; deep diff review of changes touching shared components, auth, payments, routing, analytics, or published-statement accuracy → $suede-code-review ($suede-code-grader for a blunt A–F grade). These are separate skills for website analysis. Reference them; do not paste their content here.

Multi-Agent Gate (ASK First)

Because this enchilada can run a multi-agent team (Lane D), by DEFAULT it asks the user up front before spawning a fleet. Never silently spawn agents or max tokens.

Hard cap: 4 subagents. This skill never spawns a fifth. Work that needs a bigger fleet hands off to suede-agent-teams, which owns and reports its own fleet size: quote that skill's bound rather than inventing one here. Either way the run bills to the session model, so apply the Model selection rule above in the same breath as this ask: 4 is also the ceiling that rule allows without an explicit Fable instruction.

Run this as a multi-agent team (more thorough: scout, parallel builders, adversarial + consensus review, release lock, evidence handoff) or single-agent (faster, one pass)? Multi-agent mode spawns at most 4 subagents and costs roughly 3–5× a single-agent run on the same task. It bills to [name the model this session will use]. Anything larger than 4 goes to suede-agent-teams at its fleet size, not mine.

Default to single-agent for clear, contained work. Escalate to multi-agent when the user asks, or when the work is broad, risky, release-bound, or needs continuous quality gates. State the choice, the subagent count, and the billing model in the output before starting.

Surface Classifier

Classify the surface before any design work starts. Misidentifying the register produces wrong tone, wrong density, and wrong motion posture.

When the request spans registers (e.g., a dashboard with a marketing hero), name both and apply each register to its section.

When the surface is public, structure it for SEO, AEO, AI EO, Google, Gemini, and AI search with clear CTAs. When the surface is mobile, include screenshots, onboarding, paywall, responsive layout, and app-shell needs in the design pass.

Minimum Signal Gate

Stop and ask only if none of these can be read from context:

Everything else (tone, color direction, layout choices, copy angle) is a design decision. Make it, show the reasoning in the output, and let the user override. Do not ask about optional parameters before starting. If no brief and no explicit Suede context, ask for the company.

Company Brief (Non-Suede Work)

Supply in natural language or as fields: Company / Product or offer / Audience / Category / Voice / Terms to use / Terms to avoid / Proof / Allowed claims / Forbidden claims / Primary CTA / Reference URLs / Assets or brand rules.

When a brief is active, replace all Suede positioning, domain language, and evidence boundaries with it. Keep the full workflow. Rename "Cue Suede" to "Cue [Company]" in the output.

Read Current Truth First

Before any design, copy, or QA claim, read the surface context:

• Local PRODUCT.md: users, brand, tone, anti-references, strategic principles.
• Local DESIGN.md: color tokens, type scale, component inventory, spacing.
• AGENTS.md, CLAUDE.md, AI_HANDOFF.md, README.md, or task docs: agent guidance and surface context.

If PRODUCT.md or DESIGN.md is missing on a major surface, note it and proceed with available context. Offer to create them after completing the task.

Identify the surface: repo/folder, route, live URL, deployment target, branch, dirty files. Name the physical scene: who uses this, where, under what light, with what pressure, and what they need to do next. Inspect the current rendered UI at desktop and mobile breakpoints before making claims about quality.

Render the result for visual work: screenshots beat code inspection. Minimum: desktop at 1280px width and mobile at 390px or 375px width. For product screenshot sets, verify the required platform dimensions before generating assets. Verify live URLs or APIs before claiming public behavior.

To actually capture the render: npx playwright screenshot <url> --viewport-size=1280,900 desktop.png and npx playwright screenshot <url> --viewport-size=390,844 mobile.png (installs on first run with npx playwright install chromium), or your environment's built-in preview/screenshot tool if one is available.

For major design work, reusable systems, reference visual matching, product screenshot assets, or public launch surfaces, keep work open only after these are known: PRODUCT.md / product context status; DESIGN.md / design-system status; shape-brief status for net-new or large redesigns; source visual-target status when a mock, screenshot, Figma frame, or reference URL exists; rendered implementation status; ship-blocker status.

Five-Gate Checklist (Major / Public / Launch Work)

For major public or launch work, apply all five before ship: Copy Gate, Visual QA Gate, SEO/AEO/AI EO Gate, Design System Gate, Launch Gate. Run each using the criteria defined in the relevant lane below.

Lane A: Design (visual systems, laws, tokens, type, motion, QA)

Make any interface feel intentional, premium, legible, and alive without drifting into generic AI output. Covers product UI, brand surfaces, landing pages, dashboards, component systems, responsive polish, and visual QA.

Task Router (within Lane A)

Choose the smallest path that fits the request.

• Clear small fix: inspect current UI, make the narrow edit, verify render, report what changed.
• Ambiguous or net-new design: gather context, propose 2–3 approaches with tradeoffs, recommend one, get approval before implementation.
• Large redesign: write a compact shape brief first: audience, page job, register, scene, color strategy, typography, layout, signature moment, constraints, QA plan.
• Visual system work: scan current CSS, tokens, components, spacing, shadows, breakpoints, icon usage, and repeated UI patterns before proposing changes.
• Source-to-implementation QA: if there is a mock, screenshot, Figma frame, or image target plus a rendered implementation, compare both visually before handoff and save visual-qa-report.md in the project root.
• Long polish loop: iterate through a visible checklist, maximum 3 passes over the same unit. If the same failure repeats, freeze the loop, reduce scope to the failing unit, and rerun with explicit acceptance criteria. At 3 attempts on one unit, stop iterating and escalate: report the unresolved failure, what each attempt changed, and 2–4 options for closing it, then let the user pick.

Delivery Discipline

Do not call work done because the code changed. Call it done only when the done signal has been checked or the remaining gap is named. Use Lane D (agent teams) when several lanes must move at once (copy + layout + asset + implementation + QA). Run $suede-code-review before the ship gate when design work changes shared components, routing, auth, payments, analytics, release config, or published-statement accuracy. Skip both for a small visual or copy fix that can be inspected, patched, rendered, and verified directly.

Suede UI Contract

Before a new surface, significant redesign, reusable component family, or design-system pass, lock the design contract before implementation:

• audience, surface job, primary action, and launch stage;
• spacing scale, grid behavior, breakpoints, and stable dimensions;
• color roles, semantic states, contrast requirements, and dark/light behavior;
• typography roles, hierarchy limits, body measure, and truncation strategy;
• copy vocabulary for buttons, empty states, loading, errors, and success;
• asset sources, logo use, crop rules, screenshot states, and motion rules;
• acceptance checks for desktop, mobile, accessibility, and rendered evidence.

If the work is purely backend or a narrow one-element fix, document only the relevant contract items instead of forcing a full spec.

Design Laws (heads)

Read references/design-laws.md before implementing: it holds the full dark-mode token values, typography anti-patterns, fluid type scale CSS, layout and control rules, component laws (forms, modals, empty states, data tables, navigation) with BEFORE/AFTER pairs, motion timing specs, asset rules, the aesthetic-direction menu, the scoped-bans gallery with replacements, and the design-system artifact list. The heads below are the non-negotiables.

• Subject first: strip the logo; if the remaining visual could belong to a generic SaaS, a crypto exchange, or a music streaming app, the design has failed. Every surface answers: "What does a creator do here, specifically?"
• One memorable move: each major surface gets one subject-native signature element (rights ledger, waveform proof panel, chain-of-title timeline, live data rail, audit ledger). If it could appear on a competitor's site, replace it. Name it before implementation; keep the surrounding UI disciplined so it carries.
• Color strategy before values: commit to one, Restrained (tinted neutrals + one accent ≤10%; default for dashboards and tools), Committed (one saturated color carries 30–60%; default for brand pages; the ≤10% rule does not apply), Full palette (3–4 named roles; data viz and campaign pages), or Drenched (the surface IS the color; campaign heroes and launch moments). Avoid defaulting to Restrained for everything. Color encodes meaning (ownership, status, risk, tier, provenance); decorative color is waste. Reject the first-order reflex ("music tool → dark purple gradient") and the second-order trap (muted teal on dark). Prefer OKLCH; tint neutrals toward the brand hue; never pure #000 or #fff.
• Dark mode is not an inversion: surfaces at OKLCH L=12–24 stacked light-ward, border-based elevation instead of shadows, 7:1 body contrast, chroma reduced 15–25%, semantic tokens only. Values in the reference.
• Typography: contrasting display/body pairing with distinct jobs, minimum 1.25 scale ratio, 65–75 char body measure, letter-spacing 0, clamp()-based fluid type, no fixed px for display roles.
• Layout: structure explains the product; never a card where a row would do; a card inside a card means the IA is wrong; stable elements keep stable dimensions; the first viewport shows brand, offer, and a hint of the next section; text never clips at any viewport.
• Motion by register: brand earns motion, product motion clarifies state, docs get none, campaign motion only on hero or primary CTA. Animate transform and opacity only; ease-out-expo 220–280ms; always ship a prefers-reduced-motion variant.
• Never ship (signals that no design decision was made): decorative orbs, gradient-as-personality, icon-card grids as the entire page, fake metrics, unverified partner logos, or stock testimonials. Fake metrics, testimonials, and partner claims have no exception path: replace with a real stat plus source, a [NEEDS REAL DATA] placeholder, or a structural element that needs no number. Other banned patterns (gradient text, glass panels, side-stripe borders, hero-metric template, modal-first interactions) allow scoped exceptions for source fidelity, platform convention, accessibility, or a confirmed brand system: name why the exception is earned. Full gallery with replacements in the reference.

Component sourcing: when the build needs a base primitive, an animated set-piece, or an AI-chat surface the local system lacks, pull from the vetted registries in references/ui-component-sources.md and run its adoption checklist (local first, retokenize, motion law, license tier, render proof) before the import lands.

Aesthetic Direction

For any new surface or significant redesign, commit to one named aesthetic direction before writing code: refined minimal, editorial, brutalist, retro-technical, organic, maximalist, luxury refined, or product-utilitarian (menu with execution notes in references/design-laws.md). Bold maximalism and refined minimalism both work; a design with no committed direction reads as generic.

AI slop check: run two reflex tests before committing: (1) could someone guess the theme and palette from the product category alone? Reject that first-order reflex. (2) Could someone guess the aesthetic family from category-plus-anti-references? That is the second-order trap. Go further.

Theme sentence: name the physical scene concretely enough that it forces the design answer ("a studio engineer reviewing a rights dispute at 2am on a secondary monitor"). If the sentence does not force the answer, add detail until it does. Dark vs. light is never a default.

Design System Quality Of Life

For any major surface, reusable app shell, launch system, or important component family, produce the six artifacts listed in references/design-laws.md at the smallest useful fidelity: token map, state matrix, copy vocabulary, screenshot contract, accessibility pass, and migration notes. Extract a design-system issue when a pattern repeats three times or controls a high-visibility surface; classify the drift root cause.

For broad design-system audits, score:

Color consistency: /10
Typography hierarchy: /10
Spacing rhythm: /10
Component consistency: /10
Responsive behavior: /10
Dark/light behavior: /10
Motion restraint: /10
Accessibility: /10
Information density: /10
Polish: /10
Total: /100

Below 70/100 the system is failing: fix the two lowest dimensions before styling new features on that surface. Any dimension at 4/10 or lower is a P1 finding.

Visual QA Report (Lane A)

When comparing a source visual target against an implementation, save visual-qa-report.md with:

• source visual truth path or URL
• implementation path, URL, or screenshot
• viewport and state
• theme, auth state, content/data state, and interaction state
• full-view comparison evidence
• focused region comparison evidence, or why it was not needed
• findings ordered by P0/P1/P2/P3 severity
• patches made after the previous pass
• final result: passed or final result: blocked

Compare source and implementation in the same visual pass, not from memory. Render the implementation with npx playwright screenshot <url> --viewport-size=1280,900 impl.png (matching viewport to the source target), or your environment's built-in preview/screenshot tool if one is available. Check typography, spacing/layout, colors/tokens, image and asset fidelity, logos/icons, copy/content, loading/empty/error/hover/focus/active states, responsiveness, accessibility, and motion where relevant. Use final result: blocked when the source or rendered artifact is missing for a required comparison, or when actionable P0/P1/P2 issues remain. Use passed only when no actionable P0/P1/P2 findings remain.

Lane B: Suedify (reference → target visual-DNA translation into tokens)

Use this lane when the user wants reference_url -> target_url (example: "Use apple.example and make suede.example look like it"). The output makes the target site inherit the reference's design logic, rhythm, hierarchy, and interaction feel while remaining legally and brand safe. This lane recreates design grammar with the target's own brand, content, product, and assets. It does NOT copy proprietary code, logos, exact copy, private assets, or trademarked identity, and it does not transfer the reference's claims, proof, pricing, or guarantees to the target.

Read references/suedify-playbook.md when this lane is active: it holds the full move set (Style Fingerprint, Token Distiller, Hero Lift, Section Rhythm, Voice Fingerprint, Copy Reframe, Asset Swap, Motion Match, Responsive Fit, Proof Stack, Screenshot Diff, Ship Polish), the DevTools capture procedure, and the DESIGN.md output template.

Required Inputs

• reference_url (the site to study) and target_url (the site to transform). If either is missing, ask for it.
• Target source repo/folder/branch when implementation is expected. With no known source repo, inspect the target URL and produce suedify-implementation-plan.md instead of pretending edits can be applied.
• Optional depth (homepage only / key route set / full site / landing page / app shell / mobile / screenshot-only concept) and fidelity (inspired-by / close-visual-match / aggressive-restyle).