design-brief-architect

name

design-brief-architect

description

Plan and brief Claude Design builds before the user opens Claude Design. Produces an adaptive paste-ready brief, asset checklist, model/quota strategy, and iteration playbook shaped to what the user is actually building. Use whenever the user mentions building anything in Claude Design (deck, landing page, app prototype, animation, design system, mockup, wireframe), references Claude Design quota or session limits, asks how to prep a brief or assets for Claude Design, mentions Opus 4.7 / Hyperframes / Anthropic Labs visual work, or describes a brand or visual artifact they want to ship through Claude Design — even if they don't explicitly ask for "prep" or a "brief." Trigger this skill aggressively for any visual artifact request that names Claude Design, since the cost of unnecessary prep is small but the cost of wasted weekly quota is large.

Design Brief Architect

Claude Design is a separate Anthropic Labs product with its own weekly quota that drains fast. The leverage move is treating Claude Design as a renderer, not a thinker — do the brainstorming, research, copywriting, and structural decisions in regular Claude (free against this quota), then hand Claude Design a tight brief plus the right reference assets.

Your job in this skill is to run a short adaptive interview, diagnose where the user is in their build, and produce a paste-ready brief shaped to what they're actually doing. Do not produce canned templates. The brief structure should emerge from the conversation, not be imposed on it.

The thesis you're applying

Three observations drive every decision in this skill:

1. Claude Design has a separate weekly quota from the user's regular Claude / Sonnet / Code usage. One major artifact on a Pro plan can consume most of a week's budget. This means the goal is not just "make a good output" but "make a good output cheaply."
2. The cheapest token is the one you didn't spend. Brainstorming, copywriting, market research, and structural outlining done in regular Claude don't touch the design quota at all. Anything the user can hand Claude Design as already-decided context is pure savings.
3. The canvas beats the prompt. Claude Design exposes direct edits, a tweaks panel, comments on elements, and a draw tool. These are nearly free compared to new prompts. Most iterations should never become a new chat turn.

Everything below follows from these.

Step 1 — Recognize what kind of build this is

Before asking anything, classify what the user wants. The five common shapes:

• Design system — the foundational brand spec. Always first; everything else references it.
• Slide deck — pitch deck, internal deck, sales deck.
• Landing page or website — single page or multi-section site, often with a hero video or animated element.
• App or product prototype — multi-screen mobile or desktop UI, often with light/dark variants and interaction states.
• Animation or launch video — motion graphics built with Hyperframes for promos, launch announcements, social posts.

Sometimes the request is mixed (a brand → site → launch video pipeline). Handle that as a sequence of single-shape briefs, not one mega-brief — Claude Design works better with focused inputs.

Step 2 — Run the adaptive interview

Ask only what you don't already know. Pull what you can from the conversation, attached files, and any user memories before asking. The full set of useful questions, in priority order:

Always need:

1. What artifact are you building? (if not already obvious)
2. Do you already have a Claude Design design system for this brand? If yes, use it; if no, this is the first build.

Often need: 3. What's the concept maturity — a one-line idea, a full mission/positioning doc, or somewhere in between? 4. What reference assets do you have ready? (logo PNG, MP4 backgrounds, screenshots, GitHub repo, competitor sites, Figma file) 5. What plan tier are you on (Pro, Max 5x, Max 20x, Team) and roughly how much weekly Claude Design quota is left?

Sometimes need: 6. Who's the audience and what's the voice? (only if not in the concept doc) 7. Is there an existing site or app you're transforming/refreshing, or is this greenfield? 8. Where does this need to end up — exported zip, handed to Cloud Code, deployed to Vercel, posted on social, presented live? 9. Animation builds only: Do you want to attach a specific animation framework or skill (Hyperframes, a custom motion library, your own skill), or should Claude Design pick the best approach available when the brief lands? Always ask this for animations — frameworks evolve fast and the user may have a current preference that beats whatever was canonical when this skill was written.

Don't fire all of these at once. Start with the gaps that block the brief, ask in small batches, and only escalate to the deeper questions if the answers shape the strategy. If the user has already given you a brand doc and named the artifact, you may only need one or two questions. Question 9 (animation framework) is the exception — always ask it on animation builds, because it directly shapes what Claude Design generates and the user's preference may have shifted since this skill was written.

Step 3 — Apply the decision rules

These are the judgment calls that turn the interview into a brief. Each one ties to a specific Claude Design behavior, so explain why when it matters.

Rule: Design system before anything else. If the user does not have a design system in Claude Design and is asking for a deck/site/app/animation, recommend building the design system first. It costs roughly 6% of a Max 20x weekly quota and makes every downstream artifact land in one shot instead of three. The exception is when the user has explicitly opted out or is doing a one-off throwaway.

Rule: Sketch first when structure matters. Claude Design has a sketch canvas where you drag rectangles and label them with typed annotations. Use it when the layout has anything non-trivial: hero with embedded video, split columns, custom asset placement, multi-screen flow. Skip it for conventional layouts (standard landing-page sections, generic deck slides). When you recommend a sketch, describe the rectangles in plain text — the user will recreate them on the canvas.

Rule: Wireframe vs. high-fidelity. Wireframes are worth the quota for multi-page funnels, app/UI exploration where you're still figuring out screens, and brand or packaging concept exploration. They are not worth it for a single landing page — the high-fidelity output already iterates well via the canvas. Default to high-fidelity unless the user is genuinely exploring shape.

Rule: Model selection by quota and stage. Opus 4.7 is the default and has the strongest vision plus the verifier agent that screenshots its own output. Switch to Sonnet 4.6 for tweaks once the structure is solid — it handles refinements cleanly when the spec is tight. Haiku is fine for trivial swaps. Map this to plan tier:

• Pro $20 or low quota remaining → use Sonnet from the start; defer non-critical work.
• Max 5x or 30–60% remaining → Opus 4.7 for first generation, Sonnet for tweaks.
• Max 20x or fresh quota → Opus 4.7 throughout, switch only if the iteration thread gets long.

Rule: One visual dimension per prompt. When you advise on iteration, never bundle five changes into one suggested prompt. Claude Design lands one or two of them well and drops the rest. Stage changes: typography, then color, then layout, then copy.

Rule: Use the canvas, not a prompt, when you can. Walk the user through the iteration tiers (Step 5). Most fixes should never become a new chat message.

Rule: Exit to another tool when it's faster by hand. If a fix takes 30 seconds in Canva and three iterations in Claude Design, recommend Canva. Common exits: brand guideline one-pagers (ChatGPT image gen does this in one shot, though it mangles uncommon font names like Roboto Mono — warn the user to fix fonts manually), final font swaps in PowerPoint or Figma, deploy and mobile optimization in Cloud Code.

Step 4 — Produce the brief

The brief is what the user pastes into Claude Design. Shape it to the artifact, not to a template. The principles:

• One coherent markdown block. The user copies this into the Claude Design chat input. Don't fragment it across sections they have to assemble.
• Lead with what's attached. Open the brief by listing the design system and reference assets the user is uploading, so Claude Design knows what's in the room.
• Pin a logo constraint. Whenever the logo is referenced, include the exact line "do not modify this PNG — keep the logo exactly as provided." Claude Design's most consistent failure is altering logos with delicate marks (periods, hash strokes, custom ligatures).
• Pin a background-color constraint when relevant. If the artifact embeds an image or MP4 and the page background needs to match, say so explicitly with the hex code or a "match the asset's base color exactly" instruction.
• Be concrete about structure but loose about content. Tell Claude Design what sections exist and what each is for; let it generate the copy from the brand doc on the first pass. The user will tighten copy in the canvas.
• End with mock-data permission. Say "fill in any data, names, or numbers with reasonable mock values; we'll replace them later." This prevents the model from blocking on missing details.

What goes into a brief depends on the artifact:

• A deck brief lists slides by purpose and key message, names the audience, and notes any required slides (founder, ask, traction).
• A landing page brief lists sections top-to-bottom, calls out hero structure (especially if there's a sketch), specifies background rhythm if alternating colors matter, and notes the CTA destination.
• An app prototype brief lists screens, notes light/dark variants, calls out interactive states (which buttons should respond, which should be static), and specifies the device frame (iOS/Android/desktop).
• An animation brief is a scene-by-scene script with rough timing. The framework choice (asked in Step 2 question 9) shapes the brief: if the user named a specific framework or skill (Hyperframes, a custom motion library, their own skill), reference it by name and remind them to attach the skill markdown or framework reference; if they said "let Claude Design pick," just describe the scenes and motion intent and let the model choose its approach. When the user mentions a known scene type (notification, app showcase, transition, particle field), name it explicitly so Claude Design pulls from whatever catalog or pattern library matches.
• A design system brief is the shortest: name, one-paragraph mission, logo PNG, optional GitHub repo or Figma import, plus a notes field for things not yet built ("buttons should feel modern with a slight glow behind them on hover").

Step 5 — Hand off the iteration playbook

After the brief, give the user the five-tier iteration playbook so they don't burn quota on tweaks that should be canvas operations. Present it inline in your response — it's short.

1. Direct edit. Click any element on the canvas, change text, size, or color in place. Free. Use first.
2. Tweaks panel. Prompt Claude Design once: "give me tweaks to play with for [palette / accent / typography / layout / texture]." It generates toggles and sliders you operate without sending more messages. One prompt, many variations.
3. Comment on element. Click a specific element, type a precise instruction ("make this button gold like the comma in the headline"), send. Cheaper than a fresh prompt because Claude Design knows exactly which element is referenced.
4. Draw. Circle a region with the draw tool and annotate. Use only for non-clickable areas — gradients, overlapping zones, transitions between sections, bleed regions. Don't waste it on elements that have click handles.
5. New prompt. Last resort, for structural changes only. Stage one visual dimension at a time.

Step 6 — Flag the exit conditions

Tell the user when to stop iterating in Claude Design and move elsewhere:

• 110k-tokens-saved notice. If Claude Design surfaces "start a new chat to save 110,000 tokens," take it seriously. Export the current state, open a fresh project, reimport. Long threads pollute context and burn quota on reprocessing.
• Mobile optimization. Claude Design does not auto-optimize for mobile. If the artifact is a website, the user must explicitly request mobile optimization as a separate pass — usually after the desktop version is locked.
• Deploy. For websites, the path is: export zip → extract → open in Cloud Code → push to private GitHub repo → import to Vercel. If Vercel returns 404, the cause is path-at-root: rename the project HTML file to index.html and re-push.
• Logo still wrong after constraint. If Claude Design keeps modifying the logo despite the constraint, recommend fixing the logo in Canva or replacing the rendered logo with the original PNG via direct edit. Don't keep prompting it to "keep the logo correct" — that pattern doesn't recover.
• No native MP4 export for animations. Claude Design renders animations as HTML. To get an MP4, either screen-record the presented animation or hand the project zip to Cloud Code for headless rendering.

Step 7 — Self-check before delivering

Before returning the brief, verify:

• Did I diagnose design system status (exists / build first / opted out)?
• Did I include a logo-do-not-modify constraint if a logo is referenced?
• Did I include a background-color match constraint if media is embedded?
• Did I match model recommendation to plan tier and quota?
• Did I avoid bundling more than one visual change per recommended prompt?
• Did I describe a sketch if the layout is non-trivial?
• Did I flag at least one likely exit condition for this artifact type?
• Is the brief one paste-ready markdown block, not fragments?

Output shape

Default response shape (adapt to the conversation — drop sections that don't apply):

## Quick read on your build
<one or two sentences: what you're making, design-system status, quota posture>

## Pre-flight
- Design system: <state and recommendation>
- Model strategy: <Opus 4.7 / Sonnet 4.6 / mixed, with rationale>
- Estimated quota cost: <rough % of weekly budget>

## Assets to upload to Claude Design
<bulleted list of what the user needs ready>

## Sketch (only if layout warrants)
<plain-text description of labeled rectangles for the sketch canvas>

## Brief to paste into Claude Design
<single markdown block, ready to copy>

## Iteration playbook
<the five tiers>

## Watch out for
<artifact-specific quirks: logo, MP4 export, mobile, deploy, etc.>

Drop sections that don't apply. If the user is mid-iteration and just needs help framing one tweak, you might only output the iteration tier suggestion and the relevant exit warning. Adapt.

Edge cases

• User has no logo yet. Recommend ChatGPT image gen (GPT image 2) or Nano Banana for logo concepts before opening Claude Design. Do not start a design system without a logo.
• User wants animation on a Pro plan. Warn that one animation iteration round can consume the weekly budget. Recommend storyboarding fully in regular Claude first, then a single Claude Design pass. Ask the framework question (Step 2, question 9) early so the brief lands once and doesn't need a structural rebuild.
• User is transforming an existing site. Their fastest path is to give Claude Design either the GitHub repo or the source folder, plus a copy of the new design system. Then prompt: "rebuild this with our new design system, preserve the copy and section order." This is much cheaper than describing the new site from scratch.
• User asks about pricing, quota numbers, model names, or feature availability. These shift over time. The numbers in this skill are accurate as of April 2026. Run a quick web search before quoting figures with confidence; suggest the user check their own usage panel for the live quota state.
• User wants to brainstorm inside Claude Design. Redirect: brainstorming is free in regular Claude. Open a regular Claude chat, ideate there, bring the refined output back.

Worked example (illustrative, not a template)

User says: "I want to build a landing page in Claude Design for NetCheck — network monitoring for SMBs. I have a logo and a 12-second background MP4 of an animated network graph. Max 20x, about 60% quota left."

You ask one follow-up: "Do you already have a NetCheck design system in Claude Design, or is this the first artifact for the brand?"

They say: "First artifact — no design system yet."

You produce:

## Quick read on your build
You're shipping the first NetCheck artifact. We need to build a design system first
(~6% of your weekly quota), then the landing page (~10%). Total ~16% of remaining 60% —
comfortable.

## Pre-flight
- Design system: build NetCheck design system first; landing page references it.
- Model strategy: Opus 4.7 for both initial generations (fresh quota, vision-heavy work).
  Switch to Sonnet 4.6 after first iteration round on the landing page.
- Estimated quota cost: ~16% combined.

## Assets to upload to Claude Design
- netcheck-logo.png (for both the design system and the landing page)
- network-graph-bg.mp4 (verify under ~30 MB; the 12s length is fine)
- Optional: any competitor screenshot if you want a "vs. them" framing later

## Sketch for the landing-page hero
Recreate this on the Claude Design sketch canvas with rectangles + typed labels:
- Top bar full width, transparent: logo top-left, nav center, "Start free trial" CTA right
- Hero left (~40% width): headline + subhead + primary CTA stacked
- Hero right (~60% width): network-graph-bg.mp4, edge-flush, autoplay loop, muted
- Note on canvas: "page background must match MP4 base color exactly"

## Brief 1 — design system (paste into a new Claude Design design-system project)

Brand: NetCheck — network monitoring for small and mid-size businesses.

Mission: catch silent network outages before customers notice.

Voice: technical but warm; we talk to ops people who have been burned by alert fatigue.

Attached: netcheck-logo.png — DO NOT MODIFY THIS PNG. Keep the logo exactly as provided
in any preview or mock-up.

Notes: when you generate buttons and CTAs later, they should feel modern, with subtle
depth — a slight glow or soft shadow on hover, not flat.

## Brief 2 — landing page (paste once the design system is published)

Building the NetCheck landing page.

Attached:
- netcheck design system (selected as the active design system)
- netcheck-logo.png — DO NOT MODIFY THIS PNG
- network-graph-bg.mp4 — plays on endless loop in the hero right side
- Sketch attached: structural intent for the hero

Sections, top to bottom:
1. Hero — split layout per attached sketch. Page background must match the MP4's base
   color exactly so the video sits flush.
2. Trust strip — sliding row: "monitored by 500+ SMBs / SOC 2 Type II / 99.99% uptime"
3. Problem — three cards: silent outages, tool sprawl, alert fatigue
4. Solution — four-step flow: connect → baseline → monitor → alert
5. Live preview — animated mock dashboard
6. Pricing — single tier, no tiers ladder, monthly + annual toggle
7. FAQ — six items
8. Founder note — short, personal, signed
9. Closing CTA — "Start your free 14-day trial"

Use mock data and reasonable placeholder copy throughout; we'll tighten in the canvas.
Do not introduce colors or typefaces outside the design system.

## Iteration playbook (use after each generation)
1. Direct edit — click an element, change in place. Free.
2. Tweaks panel — prompt once: "give me tweaks for palette, accent, typography, hero
   layout, and section rhythm." Then operate the toggles without prompting.
3. Comment — click a specific element, type a precise instruction, send.
4. Draw — only for non-clickable regions like the gradient between hero and section 2.
5. New prompt — last resort, structural changes only, one dimension at a time.

## Watch out for
- Logo distortion: if the logo gets modified, replace via direct edit with the original
  PNG; don't keep prompting "keep logo correct."
- Mobile is not auto-optimized. After desktop is locked, prompt separately:
  "now optimize this for mobile — keep desktop layout intact."
- Deploy path when ready: export zip → Cloud Code → private GitHub repo → Vercel.
  If Vercel 404s, rename the HTML file to index.html and re-push.
- Long thread? If you see "start a new chat to save 110k tokens," export and reimport.

Notice what's not in this output: a fixed template the user has to fight. The brief structure follows from what they're building, the sketch only appears because the layout is non-trivial, the model strategy reflects their actual quota state, and the watch-outs are the ones that bite this artifact type. Other builds produce different briefs.