Designer Onboarding

Punch's core methodology — design and content fuse

Design and content cannot exist without one another. Neither is more important. They fuse to communicate.

This is the operating principle underneath every project Punch ships. Not a stylistic preference — it's how we work. Every deliverable, from a homepage hero to a one-pager, is a fusion: copy carries half the meaning, design carries the other half, and the experience only works when both halves support and emphasize each other.

For the designer specifically, this has three operational consequences:

1. You are not a stylist for someone else's text. The copy you compose into a page is half the brand. If a layout makes the copy harder to feel, the layout is wrong — even if it's pretty. If a hero animation is beautiful but doesn't reinforce the Big Idea the copy is carrying, the animation is decorative, not communicative. Push back when the fusion isn't there.
2. The Big Idea is yours too. Every project has a Big Idea — one or two words (e.g., "assurance," "ease," "control") locked in the strategist's themes work and carried in copy-brief.md. The Big Idea is the spine your design must reinforce. Type, color, motion, spacing — every visual decision answers "does this evoke [Big Idea]?" The same way the writer's word choices answer the same question.
3. Visual QA is fusion QA. When you review a composed page, you're not asking "is the design right" and "is the copy right" separately. You're asking "are the design and copy supporting and emphasizing each other to communicate the Big Idea?" If they're working against each other — copy is restrained but design is loud, or design is editorial but copy is sales-y — flag the misalignment back to the strategist or writer.

The principle applies just as strongly to the strategist's craft (audience definition without design awareness produces vague briefs) and the writer's craft (copy without design awareness reads flat). What ties Punch's team together — across roles, across phases — is the discipline of building toward fusion, not toward either pole.

What changed — and what evolved

We've always worked from a template, and the template got us most of the way. What's new is that the template is no longer just a starting point — it's a published Figma library of 44 token-bound components, paired with a small set of Claude skills that automate the parts of the Punch process that used to eat hours every project. Together they shorten the design-build-reconcile loop into something clients see results from much sooner.

Concretely, what each piece replaces:

• The hand-built-each-time page layout becomes a composition step. The strategist writes a structured content brief; Claude pours it into your Figma skeleton; the page renders in the client's brand instantly. No PunchProof export, no text reconciliation across docs, no separate wireframing pass.
• Hand-applying brand values across components becomes a token override. You edit the local Punch Tokens collection in your client fork once; every component on every page reskins to match. No per-component find-and-replace, no missed instances.
• Design-every-page becomes tiered. Showcase pages still get your full attention — that's the 20% that earns the client's budget. Standard pages template directly from the sandbox spec without a separate Figma pass. We've codified which page types get which treatment so you're not re-negotiating it project by project.
• The Figma-to-dev handoff becomes a real spec, not a screenshot. Token export produces tokens.css, tailwind.config.js, and tokens.json automatically from the variables in your fork. Dev consumes actual values instead of interpreting visuals.
• The client-sees-it-developed-and-reacts moment moves earlier. Because Claude composes directly into a token-bound library, the page renders close to its final developed state from day one. Late-stage changes that used to mean a Figma redo + reconciliation + dev cycle become a prompt away.

What you are doing: designing the showcase 20%, picking the visual direction within the system, styling composed pages — type weights, color emphasis, imagery, custom moments — and judging when a project's specific brief justifies breaking from the system intentionally.

The four-phase workflow at a glance

Four phases, ~8 weeks total for a typical project (4 weeks brand, 4 weeks website). Five roles, the tools used at each step. The red dot marks the role leading each phase. The diagram is the team's map — your specific responsibilities by phase are detailed in the table that follows.

Three designer roles during Phase 0 — which one are you on this project?

On most Punch website projects, the Phase 0 design work is split across multiple designers. Before you read the phase table below, identify which role you're playing — your week-by-week responsibilities differ.

• Theme designer (week 2). Punch typically assigns one designer per creative theme — three designers working in parallel on the three theme directions. As a theme designer, you build the visual half of one theme (logo direction, color palette, typography selection, brand collateral mockups, hero mockup on a laptop frame, design rationale) in an exploratory Figma file — NOT subscribed to the master library, NOT in the canonical client fork. You're making manual visual choices that align with one Big Idea direction. Your work appears in the Gate 1 presentation alongside the other two themes.
• Revise / build-out designer (weeks 2–3, post-Gate 1). After the client picks (often a hybrid of 2–3 themes), one designer — frequently one of the three theme designers, but not always — owns the reconciliation. You sit with the strategist in a working session to lock the combined direction, then flesh out the chosen brand: full icon system, button states, photography direction, illustration direction. This is also the designer who creates the canonical client fork for the first time (Module 3) — subscribes to the master library, duplicates the Punch Tokens collection locally, sets values to the reconciled chosen direction, smoke-tests with punch-rebind.
• Lead client designer (weeks 3–4 onward). Sometimes the same person as the build-out designer, sometimes different. You design the two homepage takes (weeks 3–4) in the canonical fork, present alongside the strategist at Gate 3, finalize the chosen homepage in Phase 1, bring interior showcase pages to life in Phase 2 via Cowork, and carry the project through Phase 3 to launch. You are the designer who runs punch-token-export at dev handoff and punch-omma-export for the omma integration.

Where designers fit, by phase

The supporting docs you'll use

This onboarding is one of five Punch website docs. Bookmark them all; you'll come back to them mid-project.

How the skills work and where they live

Before you do anything hands-on, here's the mental model for the Punch Claude skills — punch-rebind, punch-token-export, punch-content-brief, punch-sitemap, and others — that the rest of this doc references. If you understand this section, you'll know exactly where to point Cowork on day one and avoid the most common token + time waste.

Plugin model, not per-project duplication

All Punch website skills are bundled into a single Cowork plugin: punch-website. You install it once in your Cowork environment as part of onboarding (the CCO handles this — they own the system today; as Punch grows this may become a dedicated role). After that, every Punch client project you work on has every skill automatically available — there's no per-project copying, no folder duplication, no setup ritual.

This is important because the alternative — "copy skills into each client folder" — would mean stale versions across projects, no central fix path, and a lot of wasted time. The plugin model gives every project the same version of every skill, and a bug fix to punch-rebind rolls out everywhere the next time someone runs it.

Where things live (the mental model)

The plugin holds the capabilities. The folder holds the content. They never mix. A new client is a new fork + a new folder — never a new plugin.

Day-one questions you'll have, answered

"How do I get the skills?" The CCO installs the punch-website plugin in your Cowork as part of onboarding. You don't install it yourself.

"Do I copy the skills into each client folder?" No. The plugin is global; the folder holds only client-specific content (briefs, tokens, exports, etc.).

"What do I do when I start a new client?" Duplicate the master Figma fork template, create a new project folder (with subfolders for content/, assets/, etc.), and you're ready. The skills are already there.

"Where do I see what skills are available?" In Cowork, the available skills are listed in the session context. You can also just ask Claude: "What Punch skills do you have access to?"

Six principles for accurate, token-efficient Claude use

This is the difference between burning through your Claude usage in a day and getting twice as much done. None of these are clever — they're discipline.

1. Trust the skill. Don't re-explain. Call the skill by name and let it pull what it needs. Bad: pasting the brief into chat and saying "compose this following Punch conventions for cybersec marketing pages with our token system…" Good: "Build content/homepage.md into sandbox/index.html using the design system." The system already encodes every Punch convention. Pasting them into chat re-loads tokens you've already paid for.
2. Reference files, don't paste them. "Read content/homepage.md" beats pasting 4KB of brief text into chat. The file content gets read once, in context, not duplicated across turns.
3. Let Claude read Figma via the MCP, not via your description. "Look at the Homepage page" lets Claude pull structured data (frame hierarchy, layer names, applied variables, components used). Describing Figma in prose ("the hero has an eyebrow, then a headline, then…") burns tokens reproducing what the MCP exposes for free — and less accurately.
4. Don't restate session context across messages. Cowork preserves the working folder and Figma file across turns in a session. You don't need to repeat "in the Lattice file" every prompt. State context at the start of the session, not every message.
5. One skill per task, called by name. If you find yourself stitching together prompts that approximate what a skill does, call the skill instead. Re-deriving a skill's logic in chat is the most expensive way to do its job.
6. Don't pre-load skill content into chat. Resist the urge to paste a skill's SKILL.md into chat to "remind Claude." Cowork loads skill content only when invoked, which is the most efficient pattern. Pre-loading is paying twice for the same information.

Self-check before moving on

• I can name the four phases without looking
• I know which phase I'm in when a project starts
• I know the difference between showcase and standard tier
• I know what designers do and don't do in each phase
• I understand skills live in the punch-website plugin (installed once) — not in client folders
• I can name the four "where things live" layers and which are duplicated per client
• I can recite at least three of the six token-efficiency principles

Study these first — the bar Punch holds itself to

Before you open the master file, spend 10 minutes on these three cybersec marketing sites. None of them are Punch-designed, but they're the bar we hold our work against. Understand what makes each one good before you go looking at how our system enables that quality.

• dope.security — confident, restrained, type-led. Notice how product capability is communicated without ever feeling like a product tour.
• tines.com — long-scroll product page craft. Pay attention to the rhythm between dense feature detail and breathing room, and how the brand voice stays consistent across long pages.
• torq.io — strong visual identity carried across an information-heavy site. Notice how integration density and compliance signals are handled without overwhelming the page.

The goal of looking at these isn't to copy them. It's to absorb what "this is a great cybersec marketing site" feels like before you start composing your own. Pay attention to typography rhythm, where they use color sparingly vs aggressively, how they treat the demo/conversion moment, and how the page feels at the breakpoint between hero and first product section.

Open the master and orient yourself

The master file is Punch · Website Starter (Master) in the team's Figma space. It has 5 content pages, organized into two groups:

1. Reference pages (Cover & README, ◆ Foundations · Tokens, 🪧 Brand Assets, ⊟ Layout & Grid, ✅ Handoff Checklist)
2. The Components page (🧱 Components — 45+ published components, the library you'll instance from)

Previously the file also carried three Showcase scaffolds (Product/Solution, Service Page, About Page), a Standard-Tier Wires page, a Copy Composition page, and a Pattern Archetypes page. Those were removed in v0.2 because showcase pages now compose in Cowork against the live design system, standard-tier pages get generated by the /website-design-amplifier:amplify Claude Code skill, and Pattern Archetypes duplicated what the Components page already covers at higher fidelity. Figma is no longer the place where full pages get composed.

The Components page — the center of gravity

This is the page you'll use most. It has 45+ published components organized roughly into:

• Primitives (8) — Button (3 variants), Link, Input, Textarea, Tag, Avatar, Eyebrow, Icon
• Section pieces (9) — Nav, Footer, SectionHeader, FeatureTile, Stat, Quote, ProjectCard, ProcessStep, MediaBlock
• Full patterns (12+) — Hero (3 variants), FeatureGrid, BentoGrid, StatStrip, Gallery, CTAStrip, IntroStatement, ServicesList, FeatureSplitRows, ProcessSteps, StickyLeadCards, StaggeredCards, ContentSplit, ManifestoBlock, EditorialDualImage, IntegrationGrid, ComplianceRow, ComparisonTable, FAQ, ResourceTeaser, NewsletterSignup, DemoForm, TeamGrid, TeamMember
• Mega menu (4) — MenuLink, MenuColumn, MegaMenuFooter, MegaMenuPanel — plus a "MegaMenuPanel · Schema (for Claude Code)" frame that spells out the JSON data contract Claude Code reads when implementing the mega menu

Every component is token-bound. When you drop one into a client fork (with tokens overridden), it reskins automatically.

Self-check before moving on

• I can find any component on the Components page in under 10 seconds
• I understand that full-page composition happens in Cowork (showcase) and the Claude Code amplifier (standard 80%) — not in Figma
• I know where Brand Assets lives and which variant the nav/footer default to (Logo · Full Color)
• I know the three desktop breakpoint widths (1280 / 768 / 375)

When you DON'T set up the fork

If you're a theme designer for this project, skip this module — you don't create the canonical client fork. Your week 2 work happens in an exploratory Figma file (your drafts, or a dedicated exploration file) where you make manual visual choices, build your theme's logo / palette / type / collateral / hero mockup, and hand off to the Gate 1 presentation. You can stop reading this onboarding here; Modules 4–7 are for the build-out and lead client designer.

When you DO set up the fork

If you're the build-out designer (post-Gate 1 revise) or the lead client designer (carries the project through Phases 1–3), you own the canonical fork setup. This module's hands-on practice is for you. Continue reading.

The five-step fork setup

The build-out / lead client designer runs this sequence once per project, post-Gate 1. Memorize it.

1. Create the file. In the Punch team space, new file named Punch · [Client] · Website.
2. Subscribe to the library. Assets panel → Libraries → toggle on Punch · Website Starter (Master). All 44 components become available.
3. Create the local Punch Tokens collection. Either duplicate the Cendrix sample fork's tokens collection as a template, or build fresh.
4. Fill in token values. Match the client's brand guide. Colors, type sizes, radii, spacing.
5. Smoke test. Drop a component (e.g., Nav) onto a test page, run punch-rebind, confirm it renders in the client's brand.

Why "local Punch Tokens" instead of a mode on the subscribed collection?

Short answer: Figma Pro caps you at 4 modes per collection. For an agency with many clients, that ceiling hits fast. Local per-fork tokens scale to unlimited clients and let designers edit values directly in the Variables panel without architectural friction. The punch-rebind skill handles the connection — see Module 5.

Long version is in the Library & Modes Guide. You don't need to understand it to use the system; you do need to follow the convention.

Token names must match the master exactly

This is the single most important rule of fork setup. The rebind connects library components to local tokens by exact name match. If the master has color/brand/primary and your fork has colorBrandPrimary (camelCase), the rebind won't see them as related. Use the master's naming as the contract.

The 59 variable names in master:

• Color (18): color/brand/{primary, secondary, accent}, color/surface/{1, 2, 3, inverse}, color/text/{strong, muted, dim, inverse, accent}, color/border/{subtle, strong, accent}, color/status/{success, warning, error}
• Type sizes (15): type/size/{display-xl, display-lg, display, h1-lg, h1, h2-lg, h2, h3-lg, h3, h4, body-lg, body, body-sm, eyebrow, caption}
• Line heights (4): type/lh/{tight, snug, normal, loose}
• Spacing (13): space/0 through space/12
• Radius (6): radius/{none, sm, md, lg, xl, full}
• Motion (3): motion/duration/{fast, base, slow}

Self-check before moving on

• My practice file is subscribed to the master library
• My local Punch Tokens collection exists with Lattice values
• A Nav instance from the library renders (in master neutral, that's fine for now)
• I can recite the five-step setup from memory

Where this module sits in the new flow

Showcase pages are the 20% that earn the budget — the homepage, the flagship product page, the brand-defining case study. They get a real designer's pass, by you. The other 80% of the site — standard service pages, list pages, generic content templates — get generated by Production using /website-design-amplifier:amplify from your homepage + the sitemap. You don't build those, you don't review them frame-by-frame; Production owns that output, the TDM QAs it.

This module is about the 20%. Specifically, about how showcase pages now get built in code, in Cowork, against the live design system — not skeletoned in Figma first.

Before you compose: the wireframe phase

By the time you start composing a showcase page in Cowork, the page's copy and structure have already been locked. That happened at Gate 4 (Wireframe sign-off) at the end of Phase 1. You inherit the locked artifact; you don't re-litigate it. Knowing what was decided — and what the wireframe looks like — is part of starting Phase 2 on the right foot.

What the wireframe phase locks for you:

• Copy. Every word the client will see has been read, edited, and signed off. You're not waiting on copy during composition; you're composing against final prose.
• Section structure. The brief's section keys (hero, intro, feature_split_rows, cta, etc.) and their order are locked. You can adjust visual treatment within a section, but you don't re-architect the page.
• Page-level decisions. Bio treatment (flyout / separate pages / inline), FAQ pattern (single-open / all-open / tabbed), logo / proof layout (marquee / grid / tabs) — strategist locked these in content/wireframe-config.yaml. Compose against the chosen pattern.
• SEO / AEO baseline. Meta descriptions, robots noindex (on staging), canonical URLs, Organization JSON-LD, Person microdata on leadership cards, FAQPage microdata on FAQ sections — all baked in at the wireframe stage and carried into your composed pages.

Your role during the wireframe phase (Phase 1):

• Internal review pass when invited. Before the strategist sends the wireframe to the client, they walk you (and the PM) through it internally. Your eyes catch things the strategist may not — section pacing that won't compose cleanly, a card pattern that's overloaded, an interaction the design system won't carry. Flag those now, not at composition.
• Don't redline copy. That's the strategist + writer's territory at this stage. If a phrase reads off, mention it; don't rewrite it.
• Take note of compositional implications. A page with 14 stats wants a different bento layout than a page with 4. A leadership page with 12 people wants a flyout, not inline cards. The wireframe will already reflect these decisions — your job is to register them so your composition matches the intent.

After Gate 4 (the client signs off): the wireframe becomes the contract for the page's copy and structure. Compose against it. If the client raises a content change after sign-off, that goes back to the strategist to re-brief, not into your composition.

The composition pattern, in three sentences

1. The strategist creates a content brief with Claude — a structured Markdown file with section keys (hero, intro, feature_split_rows, etc.) that map to components in the design system. The brief lives in the project repo's content/ folder.

2. You open Cowork pointed at the project repo. The design system in sandbox/ is already there — tokens, components, page primitives, all built from your Figma token exports and the homepage you finished in Phase 1.

3. You direct Cowork to build the page. It drafts the HTML/CSS using the design system, hands you something structurally correct, and then you iterate. Cowork is your surface for this — not Claude Code.

Figma's role in this flow

Figma is no longer where pages get assembled. It still does three jobs, all of them important:

• Token source of truth. Any change to the brand palette, type scale, space rhythm, or radius happens in the Figma Variables collection first. The punch-token-export skill then writes tokens.css for the sandbox so Cowork has the latest values to compose against.
• Optional visual exploration surface. When you have a strong opinion about section order or hierarchy and want to study it visually before building, you can pull library component instances into a Figma page by hand and paste the brief's copy in. This is a sometimes-useful detour for exploration or stakeholder review, not the default path for building.
• Hero explorations + early visual direction. Photography, illustration, custom typography moments, the "what does this brand FEEL like" exercise — Figma is still the right surface for that work. Once you've picked a direction, the design system in code is where it lives.

What it looks like — brief in, page out

Three inputs on the left (brief + design system + your direction), Cowork in the middle, page on the right. Your role is choosing the inputs and the direction. Cowork composes against the system.

Standard showcase page structures

For reference, here are the typical section sequences for the most common cybersec showcase page types. The brief is always the authority — these are just starting points.

The brief schema is unchanged

Section keys (nav, hero, intro, feature_split_rows, etc.) still map to components in the design system. The strategist still writes the brief against this schema. What's new is where the composition happens — in Cowork against code, not in Figma against component instances. Same contract on either side of the change.

Self-check before moving on

• I've opened sandbox/components.html and seen what's already in the Lattice design system
• I've re-read the Lattice Big Idea in copy-brief.md before composing
• sandbox/product.html exists, renders, and uses Lattice brand tokens
• I understand Figma's three remaining jobs (token source, optional exploration, hero/visual direction)
• I understand showcase pages are MY work and standard pages are Production's

What the design system gives you for free

Because you're composing against the live design system, a lot of work is already decided. Tokens are bound to CSS variables. Components have their structural defaults baked in. The 12/8/4 column grid responds at the breakpoints already. Type ramp, space scale, radius — all from tokens.css. Cowork pulls from these by default. You almost never have to say "use the brand color" — you say "make this section feel anchored," and Cowork reaches for --color-brand-primary because that's what's available in the system.

What's NOT free: which component a section uses when the brief is ambiguous, the spacing rhythm choices, which moments get a custom layout vs the default, image vs photograph vs illustration, motion direction, and any intentional break from the system. That's your call — and the way you make the call is through how you direct Cowork.

How reskin works in the new flow — same hero, three brands

The structural shape of the hero is identical across all three. What changes per fork: 4 brand color tokens, the radius scale, sometimes the type sizes — all defined in that fork's tokens.css. The design system component reads those tokens via CSS variables. The same principle that made Figma rebind work for the old flow now happens automatically in code: one component definition, swap the tokens, get the brand.

Cowork is your surface — not Claude Code

When this doc says "open Claude," it means Claude Cowork — the designer-facing surface. Cowork is chat plus file tools plus Figma MCP, all in one interface. You point it at your project folder, give it natural-language direction, and it composes, codes, and iterates with you. You never drop into a terminal.

Claude Code is what Production and Dev use for the standard 80% of pages, the amplification runs, and the CMS migration. It's terminal-based, repo-focused, and it's not your surface. You don't open Claude Code. If you find yourself thinking "I need to switch tools to do X," you're probably reaching for Code when Cowork can handle it. Ask Cowork first.

Standard invocation patterns

For a clean first build (covered in Module 4):

Build the product page from content/product-page.md into sandbox/product.html.

For an iteration round on a specific section:

The hero feels too restrained for the headline. Let's try an oversize treatment — keep the eyebrow, move the headline to type/h1-display, push the CTA below with extra space.

For a structural rethink mid-page:

Re-compose the middle of this page. The feature split rows are landing too uniform — try staggered cards instead, with the middle one getting a different background treatment.

For a token-level adjustment (rare but sometimes useful):

The accent color is reading too saturated in the CTA section. Use color/brand/primary-muted just for that section, leave the rest of the page on color/brand/primary.

When something's off in the composed page

The page renders, but something feels wrong. Tell Cowork what you see, specifically:

• "The hero is rendering with master neutral fallback colors, not the Lattice brand." → Cowork will check token bindings and likely surface that tokens.css is stale or a class is referencing a token name that doesn't exist in this fork.
• "The integration grid is showing 5 logos in the first row, should be 6 at 1280." → Cowork can adjust the grid columns at that breakpoint.
• "The CTA section is rendering broken at 768 — the button wraps under the headline." → Cowork will inspect the breakpoint and fix the responsive layout.

If the issue is in a design system component rather than the page-level composition, Cowork will tell you and surface it — "this looks like a component-level issue in component-feature-grid; want me to fix it in the system or just work around it on this page?" Default answer: fix it in the system if it'll happen on other pages too. Work around it on this page only when the workaround is a one-off intentional break.

Building from inspiration — how to give Cowork a specific vision

The brief gets you a structurally correct page. When you've also got a specific visual vision in mind — pulled from inspiration sites, a moodboard, or a single screenshot you can't stop thinking about — the question becomes how to transfer that vision faithfully. From experience: dropping a screenshot into chat and saying "match this" rarely lands. Cowork interprets pixels loosely. Here's the honest hierarchy of what actually moves accuracy, in descending order:

1. Existing structural draft + named tokens + named components. "Iterate the hero from sandbox/product.html — use the oversize hero variant, set --space-section-y to xl, push --color-accent usage in the eyebrow only." Numbers and component names beat adjectives. Cowork can't infer these from a screenshot.
2. Intent description, not appearance description. "The eyebrow should feel like a press-release dateline — small caps, muted, set above the headline with breathing room" is more useful than "match this." You're telling Cowork what to optimize for, not what to copy.
3. Annotated screenshots. A screenshot with 2–4 callouts ("this asymmetric offset is intentional," "ignore the photography style here," "the negative space matters") is dramatically better than a raw screenshot. You're directing attention.
4. Counter-examples. "Like this Linear page, but not centered the way Vercel does it." Eliminates the wrong neighborhoods.
5. Multiple inspirations with role labels. "Layout from A. Type rhythm from B. Color discipline from C." Three labeled references beat three loose ones.
6. A Figma exploration frame, pointed at via MCP. If you've already explored the section in Figma — frames named correctly, layout decided, tokens applied — you can point Cowork at the Figma file and say "match the structure of the hero frame in the Figma file." Useful when a specific layout decision is worth the Figma round-trip. Deliberate detour, not the default.
7. A raw screenshot with no scaffolding. Lowest signal. Often produces vibes-adjacent results. Reach for this last, not first.

Two specific failure modes worth naming

The "Claude improved it" failure. Cowork has a strong default toward making things "balanced" and "complete." If your inspiration deliberately violates a convention — asymmetric, intentionally sparse, weirdly cropped — Cowork will normalize it unless you tell it not to. Annotate the violation explicitly: "leave this asymmetric on purpose," "the empty column on the right is intentional, do not fill it."

The "wrong reference dimension" failure. Designers will share an inspiration for layout but Cowork picks up typography choices from the same image. Or you share it for color emphasis and Cowork copies the photography style. Always tell Cowork which dimension of the inspiration matters: layout? rhythm? color emphasis? Voice? One or two of those, not all.

Self-check before moving on

• I know the fidelity hierarchy — named tokens + components beats screenshot every time
• I can name the two failure modes (Claude improves it; wrong reference dimension) and explain how to avoid each
• I know when to fix a problem in the design system vs work around it on a single page
• I've iterated the Lattice hero at least once with specific direction, not "make it more like the inspiration"
• I understand Cowork is my surface and Claude Code is not

What's already done for you

Composition output is structurally correct: components instanced, copy populated, brand colors applied via tokens, grid aligned. It looks like a finished page from a distance. The question is whether it earns the client's premium budget — and that's your job.

The five passes that turn a composed page into a designed page

Each pass below is a visual decision in service of the Big Idea. None of them are mechanical — they're judgment calls that fuse type, color, imagery, spacing, and motion into one coherent communication of the chosen direction.

Pass 1 — Type weight & hierarchy

The composer applies default token-sized type, but emphasis and hierarchy are designer decisions. The Big Idea drives the call. A Big Idea of "assurance" wants restrained hierarchy — the eye moves calmly through the page. A Big Idea of "earned" might want one declarative moment per section that lands like a statement. Walk the page and decide:

• Which words in headlines deserve weight emphasis to make the Big Idea land?
• Where does the eye need to land first vs second vs third — and is that order serving the Big Idea?
• Are there sections where the default H2 size is too aggressive for the Big Idea's tonal register? (Or too small to carry it?)

Adjust per-instance — override the text style without changing the underlying token. If you find yourself making the same adjustment three times, that's a signal to update the master component.

Pass 1.5 — Eyebrow scarcity check

Before you start making color decisions, do a structural check on every eyebrow on the page. Punch has a hard rule about eyebrows that prevents the most common pattern failure in our work — eyebrows quietly doing heading work without being headings.

The rule of thumb: an eyebrow should provide categorization the heading wouldn't carry on its own — like LEADERSHIP · PROFILE above Avery Chen, where the heading is the anchor and the eyebrow tells the reader what kind of section this is. If the eyebrow and the heading basically say the same thing, drop the eyebrow.

Walk every section on the page and ask:

• Does this section have an eyebrow? If no, move on. If yes, continue.
• Is there a real H2 or H3 immediately after it? If yes, the section is structurally fine — proceed to the frequency check. If no, fix it: either promote the eyebrow content to a real heading and drop the eyebrow, or add a real heading underneath that carries the section's meaning.
• Across the page, how many eyebrows are there total? Three or fewer is the working ceiling. If four or more, ask which can be dropped — usually at least one is redundant with its heading.

punch-copy-lint auto-checks both the orphan-eyebrow and eyebrow-overuse patterns on composed pages, but the cheapest fix is at composition time, before lint runs. See wireframe-copy-and-seo-rules.md Section 8 for the canonical rationale.

Pass 2 — Color emphasis

The brand accent (color/text/accent) is applied to eyebrows by default. Decide where else it should appear. The Big Idea constrains the answer — restrained Big Ideas ("ease," "unhurried") want scarce accent (one or two moments per page); louder Big Ideas ("ready," "direct") can carry slightly more. Decide:

• Highlighted words within headlines — does pulling one phrase into accent make the Big Idea more visible, or just busier?
• Underlines on key links — is the accent earning its place there?
• Active states in nav, FAQ accordions — does the interaction moment carry the Big Idea, or just show the system works?

Don't go too far — the accent should pop, not overwhelm. If a single page has the accent on 12 elements, you've lost the signal AND diluted the Big Idea.

Pass 3 — Photography & imagery

Composed pages have placeholder gray rectangles. Replace them with real assets:

• Hero image (if a hero variant uses one) — product screenshot, abstract visual, photography
• FeatureSplitRows mockups — actual product UI screenshots
• Team photos — real headshots in consistent treatment (BW, duotone, etc.)
• Integration logos — the client's actual partner logos

For cybersec sites, abstract security-themed visuals (graph networks, code, light/dark contrast) work better than literal photography of people-at-laptops. Whatever imagery you choose — abstract or literal — test it against the Big Idea. A Big Idea of "assurance" wants imagery that feels grounded, considered, not hectic. A Big Idea of "ready" can carry more energetic imagery. If the imagery and the Big Idea pull in different emotional directions, fusion breaks.

Pass 4 — Section spacing & rhythm

The composer applies default section padding (80px top/bottom on most sections). The Big Idea drives the rhythm. Restrained Big Ideas ("ease," "unhurried," "assurance") want generous breathing room — push padding up so sections feel like they've been considered. Louder Big Ideas ("ready," "direct") can carry tighter rhythm — sections following each other with intent. Some pages benefit from variable rhythm:

• A hero might want more vertical breathing room (120-160px padding) before the intro — especially with a quiet Big Idea
• A demo form section might want less padding to feel transactional
• The footer should always end at the natural last section without floating

Override per-instance padding when the default rhythm feels wrong for the Big Idea this page is carrying.

Pass 5 — Custom moments (the bespoke 20%)

Every showcase page should have at least one moment that couldn't exist on any other site. This is where craft lives — not because the system can't handle generic, but because clients pay premium for the parts of their site that feel uniquely theirs. Custom moments are also fusion at maximum amplitude: a great custom moment makes the Big Idea unmistakable to a first-time visitor in under 50 milliseconds. Examples:

• An animated, scroll-triggered, or otherwise interactive hero
• A scroll-triggered diagram in the product narrative
• A custom illustration or data visualization
• A typography lockup that's specific to this brand
• A component-level interaction (card flip, scroll stack, hover reveal, marquee variation) adapted to brand tokens

The system gives you two specific tools for building these moments: omma.build and 21st.dev. They cover different scales and don't overlap. Picking the wrong one wastes hours. Both ultimately hand off to Cowork, which is the actual composition surface for the page.

Decision tree — which tool for which moment

Working with omma.build — for page-level moments

When: Phase 1 (homepage hero) or Phase 2 (any showcase page that earns a custom moment). Always after visual styling is locked in Figma, before you code the homepage / before dev builds the page.

Why we invest in the custom hero — the research

The hero isn't a decoration. It's the highest-leverage moment on the page. A few research anchors explain why Punch defaults to investing here:

• Motion is processed preattentively. Basic visual perception research (Treisman, Wolfe, and the broader feature-integration / guided-search literature) shows movement in the visual field captures attention before conscious processing engages — the eye is involuntarily pulled to it. A well-tuned interactive hero is the difference between a user scrolling past in two seconds and pausing long enough for the rest of the page to do its work.
• Above-the-fold attention is disproportionate. Eye-tracking studies (Nielsen Norman Group, Chartbeat) consistently find users spend the majority of their viewing time on content above the fold — far more than on content below it. The hero is the bulk of that content. It is the page, for engagement purposes, until the user scrolls.
• The cybersec B2B credibility dimension. Our buyers are pattern-matching for seriousness in the first seconds. They've seen a hundred stock-template security sites. A well-crafted custom hero answers "is this a real, serious company?" before they read a word of copy. A stock hero leaves them unsure — and on a security purchase, unsure is the same as no.

This is why a well-placed interactive hero is worth the time it takes — it determines whether the rest of the work on the page ever gets read. 99% of the time on a Punch showcase page, the answer to "should this get a custom moment?" is yes. The question is what kind.

The workflow:

1. Start from "this gets a custom moment" — figure out what kind. For every Punch showcase page, default to a custom moment. The exploration is about what serves the page's argument, not whether to invest. Skip only if you've genuinely explored and there's no moment that earns its place — which is rare.
2. Open omma.build, start a project named [client]-[page]-[moment]. E.g., cendrix-home-hero, lattice-product-scroll-diagram. Naming matters — the export becomes a folder in the project repo later.
3. Build static first. Lay out the visual structure without interactions. Paste the client's token values (colors, type sizes, spacing) directly into omma.build's style settings so the prototype is on-brand from the start. If the moment doesn't look right static, it won't look right animated.
4. Layer interactions in. Scroll triggers, hover states, parallax, timing curves. Iterate until the motion serves the message — not until it's impressive on its own. Restraint is a signal of craft.
5. Test on mobile. Interactive moments break responsive in ways static designs don't. Resize the omma.build preview to 375px before locking the interaction. If it doesn't work there, redesign — don't punt to dev.
6. Get a feedback pass from your art director or the CCO before exporting. Don't ship a custom moment to dev without a second set of eyes. That review is where someone catches "this feels off-brand" before you've committed to the export.
7. Export the repo. omma.build produces a code project. The export is the canonical artifact.
8. Hand the repo to Cowork pointed at your project. Open Cowork in the client project's working directory and say: "This is the [moment-name] from omma.build. Adapt it to our project stack — [Next.js / Webflow / WordPress]. Connect colors and spacing to our Punch Tokens. Integrate into the [page-name] page." Claude restructures, swaps token references, integrates with the rest of the page.
9. Review the result in dev preview. Not in Figma, not in omma.build — in the actual built page. Custom moments live or die based on how they feel in context.
10. Commit the integrated code and link the Asana task to the omma.build URL so the source is findable for future iterations.

Constraints:

• One custom moment per showcase page is plenty. Two is rare. Three means you're over-investing or the page is doing too much.
• Don't break the rest of the page's rhythm. If the hero takes 90% of the visual energy, the body should be calmer than usual.
• Reduced-motion support is required. If a user has prefers-reduced-motion: reduce, the moment must fall back to a static or low-motion version. Build this into the omma.build prototype, not as an afterthought.
• Performance budget. A custom hero should add no more than ~50KB of JS over the page baseline. If your prototype is heavier, simplify.

omma.build tips & tricks (from experience)

• Use the team account. The CCO holds the team credentials. Don't sign up with your personal account or you'll lose work when you switch — and the project won't be accessible to the rest of the team.
• Paste tokens into the project's style settings first thing. Before you build anything visual, load the client's color, type, and spacing values into omma.build's design system / style settings. Designing on top of placeholder values and re-skinning later doubles your time — and it's easy to miss a hardcoded value at export.
• Design at full desktop viewport (1280 or 1440). omma.build's preview defaults can be misleadingly small. Stretch the canvas to your target viewport before you start composing — what works at 800px often falls apart at 1440px.
• Build static first, layer interactions second. If the moment doesn't earn its place as a still composition, no amount of motion will save it. Lock the visual layout, get sign-off from the art director or CCO, then add scroll / hover / parallax.
• Treat scroll triggers as expensive. Every trigger adds JS weight and a chance to break responsive. Two coordinated scroll moments are a lot. Five is too many. The most memorable heroes do one thing well.
• Name the project [client]-[page]-[moment]. E.g., cendrix-home-hero, lattice-product-scroll-diagram. The exported folder uses this name and gets dropped into the project repo — clean naming saves dev time and makes the source findable later.
• Test mobile (375px) in omma.build itself before export. Interactive moments break responsive in ways static designs never do. If the moment doesn't degrade gracefully at 375 inside omma.build, it definitely won't degrade gracefully in production — fix it here, not at handoff.
• Export as a code project, then immediately hand to Cowork. Don't try to manually adapt the export to the project stack. Hand the omma.build folder to Cowork pointed at your project repo with the prompt in step 7 of the workflow above. Cowork rewires it into the client's Next.js / Webflow / WordPress build with tokens connected.
• Link the omma.build project URL on the Asana task for the page. Future you, dev, and the next designer will all want to find the source. Don't make them ask.

Working with 21st.dev — for component-level patterns

When: anytime you need a flourish smaller than a hero. Typically Phase 2, during styling or just before dev handoff for a specific page.

21st.dev components ship with their author's stylistic opinions baked in — colors, transition curves, padding, type choices. Trying to adapt a raw snippet by stripping and rebuilding that styling burns 30–60 minutes per component, and the result is always slightly off-brand. We don't do it. Use the prompt route below.

The workflow:

1. Find the component on 21st.dev that has the interaction pattern you want.
2. Click Copy prompt. 21st.dev gives you an AI prompt describing the component's behavior in natural language.
3. Open Cowork pointed at your project.
4. Paste the prompt with this prefix: "Generate a [component description] for Punch's [client] cybersec site. Use these tokens: [paste relevant tokens or link to tokens.css]. Match the visual style of [reference existing component, e.g., 'our existing FeatureSplitRows']. Then: [paste 21st.dev prompt]."
5. Claude generates a fresh component that's on-brand from birth — born in Punch's token system, not adapted to it.
6. Iterate by telling Claude what to change: "make the hover transition slower," "use radius/sm instead of radius/md," "tighten the type ramp."
7. Drop into /components/custom/[component-name]/.

Why this is the path we use:

• The component is born in Punch's token system, not adapted to it. No style stripping.
• You're not bound to the original author's interaction timing or visual choices. You can tell Claude "but with a slower, more considered feel."
• It's faster end-to-end — 10–15 minutes start to finish.
• You learn the pattern by reading what Claude generates, which compounds across projects.

Constraints:

• Token discipline. Every color, spacing, radius in the new component must reference a Punch Token. Inspect each addition's CSS in dev tools — fix any hardcoded values. (No dedicated skill for this yet; if it keeps coming up, flag at the next retrospective as a candidate skill.) Hardcoded values are a regression of the entire system.
• Accessibility. New components must support keyboard navigation, visible focus states, and prefers-reduced-motion. 21st.dev components vary wildly on a11y — assume they don't, then add what's missing.
• One component-level flourish per page max unless there's a strong reason. They're seasoning, not the main course.
• Don't promote to master library yet. Custom components live in the project repo under /components/custom/. If a custom component gets used in 3+ projects, then it earns promotion to the master via a CCO review.

21st.dev tips & tricks (from experience)

• Browse 21st.dev/community/components — not the homepage. The community gallery is where the interaction patterns live. The marketing surface around it is noise.
• Search by interaction pattern, not visual style. "Scroll reveal," "card flip," "marquee with pause on hover," "accordion." The original component's colors and type will be replaced — what you're actually shopping for is the behavior.
• Never download or copy raw code. Every time you do, you commit to 30–60 minutes of un-styling, and the result is always slightly off-brand. Use the prompt route — the component will be born in Punch's token system instead of dragged into it.
• Tell Cowork what to strip from the original. When you paste the 21st.dev prompt into Cowork, lead with what to ignore: "Use this 21st.dev component as a behavioral reference only. Ignore the original's color choices, font choices, padding, and transition curves. Rebuild in Punch's token system." Otherwise Cowork tends to preserve the original's stylistic opinions.
• Anchor on an existing Punch component for the visual language. Tell Cowork "match the visual style of FeatureSplitRows" or whatever in your project's component set is closest in feel. This gives Claude a concrete styling reference instead of leaving it to invent one.
• Iterate with short prompts, not full re-prompts. Once the component is generated, refine it with one-line asks: "slower hover transition," "use radius/sm," "tighten the type ramp," "add focus state matching our button." Re-prompting from scratch loses progress.
• Bookmark patterns you reach for repeatedly. If you keep coming back to the same kind of scroll-reveal or marquee, save the 21st.dev URL in the Punch shared resources doc. The first three uses are research; the fourth should be a one-prompt task.
• Test the generated component in isolation first. Drop it on a stub page (or use Cowork's preview), confirm it works at desktop + mobile + with reduced-motion before integrating into the showcase page. Easier to debug in isolation than in context.
• Always cite the source. Add a comment at the top of the generated component file: /* Inspired by [21st.dev URL] · adapted to Punch tokens via Cowork */. Future you and the next designer will thank you.

Handing custom moments to dev

The dev team needs to know:

1. Which moments are custom (vs library-instanced)
2. Where the source lives — omma.build URL, 21st.dev component link, or both
3. Integration notes — where in the page DOM, what controls the trigger, any timing dependencies
4. Performance and accessibility considerations specific to that moment

Until the punch-handoff-{nextjs,webflow,wordpress} skills are built, document custom moments in the Asana task for that page: tool used, source URL, integration notes. Dev should be able to read the task and know exactly what they're integrating.

Additional QA for custom moments (on top of the standard gate-4 pass)

• Interaction works in dev preview, not just in Figma/omma.build/21st.dev preview
• Reduced-motion fallback works (toggle the OS setting and reload)
• Mobile at 375px doesn't break the interaction
• No console errors in the browser
• Performance impact acceptable — check Lighthouse before/after if you can

This is what justifies showcase-tier. If a page can ship without any custom moments, it should have been standard-tier — you're over-investing.

Discipline around tokens

Visual styling means making decisions WITHIN the token system, not breaking out of it. If you're hand-coding a hex value (#123456) into an override, stop and ask:

• Should this be a new token? (If you'll use it three times, yes.)
• Is there an existing token I should be using? (Probably yes.)
• Is this a one-off that doesn't deserve a token? (Rare; flag it for the CCO.)

Hardcoded values defeat the entire reskin architecture. Audit yourself.

Self-check before moving on

• I've run all five styling passes on my homepage
• At least one custom moment is sketched
• Token audit returns clean (no hardcoded values)
• Grid alignment is intact (Shift + G to verify)

The eight gates, your responsibility per gate

QA skills available to designers

You don't need to remember all of them — the orchestrator runs the right ones at the right time. But knowing what each catches helps you self-QA at composition time so you're not surprised at Gate 5 or Gate 6.

Designer brings every showcase page to life — via Cowork

Per the workflow, designers (not dev) take the Phase 0 two homepages and every Phase 2 showcase page from Figma composition to a working desktop-only static preview in the project's stack. Dev then cleans up what you built — extends it to tablet and mobile, wires it to the CMS, handles a11y and performance polish. They are not re-coding from scratch. Your code is the foundation; theirs is the cleanup pass.

This split reflects who's closest to each kind of work: showcase pages live or die on the craft and visual judgment you bring at desktop scale; the responsive math, CMS integration, and performance work live or die on the rigor dev brings.

Phase 0 weeks 2–4 — brand elements + two homepage takes. Once the strategist locks the chosen Big Idea in copy-brief.md, you ramp up. First couple days: build out the brand element samples (type system, color usage, collateral examples) so the chosen Big Idea has visual form. Then code two homepage takes with different hero interactions — one "safe" (calmer, more straightforward), one "creative/interactive" (more motion-forward) — for the client to pick from at Gate 3. Both takes are real functioning code at desktop, not static mockups. Both carry the same Big Idea; they differ specifically in how the hero interaction expresses it.

Phase 1 — finalize chosen homepage + sandbox spec. After Gate 3 the client has picked one take. You finalize that one (refine to ship quality, pour real copy from the writer's draft at draft lock) and build the sandbox spec alongside — tokens.css, components.html, typography.html, sample-page.html. This becomes dev's reference for the rest of the site. ~1 week of focused work in Cowork.

Typical Phase 0 + Phase 1 homepage output:

• tokens.css — generated automatically by punch-token-export from your Figma variables
• components.html — 6–8 core components rendered in every state
• typography.html — every type style with sample copy
• home-a.html + home-b.html at end of Phase 0 — the two takes, desktop-only at 1280px, fully token-bound. After Gate 3, one becomes sample-page.html (the canonical reference for dev).

Phase 2 — every other showcase page. For each one (product page, key use case pages, about, etc.), the loop is:

1. Partial design in Figma — skeleton + initial styling, enough to lock visual direction
2. Bring to life in Cowork — point Cowork at your project folder, ask it to generate the desktop static preview from your Figma + the brief
3. Iterate via prompts in Cowork — "make the hero bigger," "swap this section's CTA to /demo," "tighten the vertical rhythm in the features section"
4. Add custom moments per Pass 5 (omma.build for page-level, 21st.dev for component-level)
5. Result: a desktop-only static preview of the showcase page in the project's stack — token-bound, at 1280px, with the responsive intent notes (below) written into the page's brief file so dev knows where you want it to go on smaller screens

Per-page time budget: 4–8 hours per showcase page depending on custom moments. You are not shipping production responsive code, hand-writing React component files, or wiring up CMS data. You are producing a polished, opinionated desktop reference that dev cleans up. Optimize for "the page reads correctly at 1280px and the visual system holds up."

Responsive intent notes — your handoff to dev's cleanup pass

You design at desktop. Dev codes the responsive math. The bridge between you is a short responsive intent note for each showcase page, dropped into the page's brief file. Dev reads this during cleanup so they don't have to guess what you wanted at tablet and mobile.

What to include per page (3–6 bullets max — keep it tight):

• Hero behavior at <1024: stack/reflow/swap to mobile-only variant?
• Section spacing scale: any section where you want spacing to not collapse at mobile (e.g., editorial breathing room you want preserved)
• Image crops: if a hero or feature image needs an alternate crop at mobile, name the asset (or just say "use the square crop from Standard Page Assets")
• Custom moments: what should the omma.build/21st.dev moment degrade to on mobile? Static image? Simplified animation? Skip entirely?
• Type scale: any place you want type to not auto-scale down (e.g., a manifesto heading you want to keep big even at 375)

If you don't write this, dev's cleanup will be slower and they'll make guesses you may not love. 10 minutes per page now saves an hour of back-and-forth later.

Copy lock moments — when content stops moving

The client's website content/copy goes through three lock moments. Knowing when each happens prevents the most expensive design problem: re-doing layout because copy changed under you.

If a client wants to change copy after a lock, that's fine — it's their site. But flag it to the strategist as a change request rather than absorbing it silently. Otherwise the page count of "1.5–2 days per showcase" stops being honest.

The tool: Cowork, not Claude Code. Cowork is your surface — chat + Figma MCP + project file tools all in one. You're not opening a terminal. You're not writing React/Next code by hand. You're prompting Claude through Cowork to do that while you stay focused on visual decisions and pacing. If you find yourself wishing for a terminal, you're probably reaching for the wrong tool — ask Cowork first.

What dev actually does after handoff (so you know what you're handing to). Dev takes your desktop static preview as the spec and the responsive intent notes as the playbook. They extend your existing code — they're not starting over. Their work is: build 768 and 375 breakpoints from your responsive notes, swap any mobile-specific assets, wire sections to the CMS, run performance and a11y polish, and template the standard pages off your sandbox. The faster and clearer your desktop preview is, the faster their cleanup goes.

Standard pages — designer's only deliverable is visual assets

Standard pages (services, contact, legal, blog index, article, news, team, etc.) get templated by dev directly from the sandbox spec without a Figma pass. Your role on these is narrower than showcase pages, and important:

Maintain a single Figma frame in your client fork called "Standard Page Assets". This frame contains every visual asset the standard pages need across the project — hero photos, brand-specific illustrations, custom icons, data viz, anything that isn't system-provided. Dev exports from this frame at build time.

Rules of thumb for this frame:

• Organize by page. Group assets under sub-frames named after each standard page (e.g., "About page assets," "Contact page assets," "Blog index assets"). Dev should be able to find what they need by page name.
• Name layers clearly. about-hero-photo, contact-illustration, blog-list-thumbnail-template. Dev exports based on these names.
• Provide at correct resolution. 2x for raster, vector where possible. Don't make dev guess at sizes.
• Don't open the standard pages themselves in Figma. No skeleton, no composition, no per-section design. Dev handles that from the sandbox. Your job ends at the asset frame.

This means standard pages don't take design time beyond asset preparation. Resist the urge to design them anyway — that's the over-investment trap.

Per-batch QA, Gate 5 — the 15-minute version

At the end of every Phase 2 batch (usually 3–4 showcase pages), the four roles meet for 15 minutes: PM, Strategist, Writer, Lead Designer. Production Artist has already run punch-production-artist-qa on each page before this meeting — so copy-lint and link-check issues are surfaced (and ideally fixed) before you walk in. Gate 5 is the strategic alignment pass, not the bug hunt.

Your specific QA pass before the meeting (5–10 minutes per page during composition):

1. Visual consistency (3 min): Scroll all pages in batch side-by-side. Same eyebrow rhythm (and same eyebrow scarcity — see Module 6), same headline rhythm, same section spacing? Anything that breaks pattern?
2. Mobile/tablet (3 min): Resize to 768 then 375 on the static preview. Anything broken? Touch targets too small? Content collapsing weirdly?
3. Token discipline (3 min): Inspect each page's CSS in dev tools — fix any hardcoded color/spacing values that should be tokens. If you spot a pattern, surface it to the asset audit team. (No dedicated skill for this — manual check.)
4. Copy match (3 min): Run punch-copy-lint on the composed page. Cross-check the page's text against the locked brief — anything missing or extra? Anything that broke the wireframe's structural decisions (orphan eyebrows, period drift, heading skips)?
5. Accessibility quick-pass (3 min): Run design:accessibility-review. Address color contrast, focus states, alt text gaps.

If any of these fail at the gate, the batch isn't done. Either fix on the spot (if <15 min) or push to the next batch with a written note.

Self-check before moving on

• I can name all eight gates (G1–G7 plus G7+1 retro) and which I own
• I know the 5-step per-batch QA pass and can run it in 15 minutes
• I know which QA skills run on my composed pages (copy-lint, link-check, accessibility-review) and which the orchestrator handles (pre-launch-qa, term-drift)
• I understand "desktop-only static preview" is my output — dev cleans up to responsive production
• I know to write responsive intent notes (3–6 bullets per showcase page)
• I can name the three copy lock moments and what each unlocks
• I know Phase 4 happens (retrospective within 2 weeks of launch) and that I participate
• I've run the practice QA on my Lattice homepage

When in doubt, ask these five questions

1. Whose work is this? If it's not yours, you're supporting, not owning.
2. Which gate are we at? If you can't name it, you've drifted off the workflow.
3. Showcase or standard tier? If standard, you probably shouldn't be designing it.
4. Does this evoke the Big Idea? Open copy-brief.md. If unsure, the answer is usually no.
5. Has a human signed off on this change? If not, it doesn't ship to client preview.