What's New at Punch

This is the re-entry point for the existing team. Every meaningful change to the Punch website system — a new skill, a new rule, a tweaked workflow — gets logged here. Skim it as often as you'd skim a #channel; read in full when a major version lands.

Recent updates

Most recent first. Each entry: date, what changed, where to read more.

To add an entry: append a new row at the top of this table with today's date, a one-sentence summary, and a pointer to the canonical doc or skill. If the change is big enough to need its own anchor section (like the May 2026 reset), add it below and link to it.

What's NOT changing

Worth saying upfront — the parts of Punch that make Punch are intact:

• Fusion of design and content. Still inseparable. Still our core craft argument — the headline of how Punch makes things.
• Big Idea methodology. Every project still carries one emotional truth. The anchor every Fusion decision pulls toward.
• Write for clarity, against hype. Anti-hype is still the voice principle.
• Content-first wireframe. Still our signature deliverable. Copy ships before design.
• Three creative themes for brand projects. Two homepage directions for websites.
• Five sectors of deepest experience: cybersecurity, defense tech, B2B tech, GovCon, nonprofits. Not exclusive — any project that aligns with Punch's values is welcome.
• Five disciplines: brand, websites, UX/UI, video + motion, campaigns.
• Five departments: Strategy, Client Services, Creative, Technical, Operations.
• Client-Facing posture. No "approval" language. No "final" until it's final. Still applies.

If you know how Punch worked six months ago, those things are unchanged. The mechanics underneath are what shifted.

Shift 1 — Two AI surfaces, not one

We now operate two distinct AI surfaces, and which one you use depends on the work:

This split matters because it means showcase pages now compose in Cowork directly against the design system in code, not by skeletoning frames in Figma. The Figma master library still holds tokens, hero explorations, and stakeholder-review surfaces — but page composition has moved to code.

Before vs. now — composing a page

punch-figma-compose has been retired in plugin version 0.7.1. The rare cases where studying layout in Figma before code is useful are now handled by direct Figma work — no skill needed. See Designer Onboarding Modules 4 and 5 for the long version.

Shift 2 — QA is structural now, not vibes

A recent launch was the wake-up call. A live page shipped with copy that read "Is there a way to emphasize 100%Test 5–10x more hypotheses per analyst." Two failures: a BugHerd comment got executed as copy, AND a missing space between "100%" and "Test." Both 100% catchable by regex. Neither caught by humans.

We now have an automated QA system built around two principles:

1. Whoever produced the work isn't the final QA gatekeeper. Production Artists run their own self-QA first, then hand to TDM. TDM runs Pre-Launch QA before client preview. Different eyes at each gate.
2. The dumb stuff is machine-caught. Comment leaks, missing spaces, broken links, wrong assets, accessibility violations — these are detected by skills running at the gates, not by humans scrolling pages hoping to notice.

The QA skills you'll actually use

Shift 3 — Nine gates, named owners, real machinery

The gate model has shifted from "we check work before passing it forward" (good but vague) to nine named gates with named owners and automated machinery behind most of them. Three big changes: we split the old single-direction gate into Gate 2 (creative theme pick — 1 of 3) and Gate 3 (homepage variation pick — 1 of 2) because they're separate decisions made at different times; we added Gate 6 (The Build) — the client signs off on the complete designed website in code before CMS migration begins, because copy and structure rework inside a CMS is the most expensive rework Punch ships; and we added Gate 9 (Post-launch 48hr) because too many issues only surface after CMS migration.

Why Gate 6 exists

The Build is where everything we've built converges — every page, every breakpoint, every word, every interaction, with the Lead Designer's rich visual layer applied. If a CMS migration starts before the client has signed off on The Build, we end up doing copy edits and structural reworks inside the CMS, which is slower, riskier, and harder to undo. CMS migration cannot begin until Gate 6 passes. The CMS pilot in Phase 2 is the only exception — it's a sandboxed feasibility test on one page, not production migration. The Build is also the client's: when they forward it inside their organization for marketing or executive review, the term reads cleanly — *"Forwarding The Build for your read."*

Why Gate 9 exists

CMS migration introduces issues pre-launch QA can't catch: redirects that work in staging but break in production, third-party scripts that throttle performance, analytics that don't fire, CMS-format polish that loses content. The 48-hour window after launch is when we re-check the live site ourselves — before the client calls.

Shift 4 — One plugin, all the Punch skills

Every Punch-specific Claude skill now lives in a single installable plugin: punch-website. The CCO maintains it. Every Punch person installs it once on their Cowork; from then on, every client project has every skill available.

What's in v0.7.1 (the current release)

Roughly four categories of skills:

Plus punch-omma-export for omma.build inputs.

Installing the plugin

The CCO handles installation as part of your onboarding. If yours hasn't happened yet — or you need to update to the latest version — find the .plugin file in the team plugin registry (or wherever Punch is sharing it), drop it into a Cowork chat, click the install button. Done. Restart Cowork after install if Cowork doesn't refresh automatically.

To verify you have the right version, ask in any Cowork chat: "What Punch skills are available?" You should see 17 skills. If you see fewer, your plugin is stale.

What this means for your day-to-day, by role

Where things live (quick reference)

Per-client project structure created by punch-project-init:

{client-slug}/
├── README.md                  ← project meta
├── brand/
│   ├── copy-brief.md         ← Big Idea, voice, banned words
│   ├── theme-notes.md         ← visual direction notes
│   └── visual-direction.md    ← idioms borrowed from decoded refs (Cowork reads this)
├── content/
│   ├── sitemap.yaml           ← every page
│   ├── homepage.md            ← homepage brief
│   ├── _brief-template.md     ← copy this for new page briefs
│   └── assets-manifest.yaml   ← canonical map of every asset to page+section
├── sandbox/
│   ├── tokens.css             ← from punch-token-export
│   ├── text-styles.css        ← from punch-component-export
│   ├── components.html        ← from punch-component-export
│   ├── wireframe/             ← from punch-wireframe (regenerated on demand)
│   └── index.html, etc.       ← composed pages
└── assets/
    └── logo.svg               ← from punch-component-export
    └── ...                    ← images, illustrations, videos

Shared across all projects (lives at the Process-folder level, not per-client):

decoded-references/             ← shared library of decoded Webflow / reference templates
    volio-saas-ui-kit-home-01.md
    linear.md
    ...

The decoded references library is the agency's accumulated vocabulary of named visual idioms. Every project's brand/visual-direction.md cites these by path.

Where to go for more depth

This doc is the training. For full reference, dig into the role-specific docs:

Sub-systems worth knowing exist

• Rush Test Runbook — for compressed timelines, the abbreviated path from existing materials to a homepage design
• Decoded References library — at decoded-references/ in Process. Currently has Volio + Linear; growing as the team adds templates
• Companion Claude Code plugins — website-design-amplifier + website-to-static. Lives on Production + Dev machines only.