Quarterly Refresher · Issue 01

Part 1 How this works

Docs don't drive vet behavior — they get skimmed once and ignored. Slack pings get lost. The Quarterly Refresher is a small, repeatable ritual that gets the existing team to actually absorb the last quarter's process changes, and gives leadership a structured signal on what's confusing.

Cadence

Last week of each quarter. Four issues a year: Q1 (late March), Q2 (late May/June), Q3 (late September), Q4 (late December). Skip a quarter only if nothing meaningful changed — which is the wrong reason to be congratulating yourselves and probably means the team has stopped iterating.

Who runs it

Until a "skill sommelier per role" is designated (currently deferred), leadership runs it — either the Creative Director or the Operations lead. Once sommeliers exist, they take turns: Designer sommelier runs one issue, Strategist sommelier the next, PM sommelier after that, then leadership covers Q4. Rotation builds shared ownership of the system.

How to assemble each issue

1. Open Whats-New-at-Punch.html. Look at every entry added since the last refresher.
2. Pick the top 3. Criteria: (a) does it change someone's day-to-day, (b) is there a real risk of vets defaulting to the old way, (c) would a new hire learn this in onboarding but a vet wouldn't have seen it. Skip cosmetic changes, doc renames, and internal cleanups.
3. For each change, write a 1-sentence framing. Not the changelog one-liner — the why it matters version. Example: changelog says "no-enhancement rule introduced." Refresher says "the renderer stopped silently cleaning up your typos — what you write is now what ships."
4. Record the Loom. Use the script structure in Part 2. Don't over-prepare. Five takes is too many. The Loom is meant to feel like a short walk-through, not a polished presentation.
5. Write the three async questions. Use the question framework in Part 2. The questions are about what the team is confused by, not about whether they watched.
6. Post in #punch-process. One message: Loom link + three questions + 1-week deadline. Pin until next refresher ships.
7. Archive in this folder. Save as Quarterly-Refresher-Q[X]-[YEAR].html using this file as a template. Past issues become a paper trail of how the system has evolved.

What this isn't

• Not training. Training lives in the onboarding docs. This is a re-engagement nudge, not a new-hire orientation.
• Not a status update. Not for "here's what shipped this quarter" — that's a different doc and a different audience.
• Not optional. The whole point is rhythm. A refresher that lands six weeks late stops working. Block the calendar time.

Part 2 The Loom script

15 minutes total. Same structure every issue — vets learn the rhythm and stop tuning out. The structure is intentional: each change gets four minutes, which is enough to explain the why and show one concrete example, but not enough to drift into philosophy.

The three async questions

Same shape every issue. Adapt the wording to each change, but keep the intent.

Part 3 This issue · Q2 2026

The three changes featured in this issue, drawn from What's New at Punch. Use these as the Loom script content. The wording below is the "why it matters" framing — the changelog one-liners are too short to record against.

Change 1 · Wireframe principles codified

Why it matters: the way we build wireframes was always going to drift unless we wrote down the rules. The Auria build forced us to. There are now ten principles that govern every wireframe — source-fidelity rendering (no auto-fixes), eyebrow scarcity, light/dark theme toggle, the canonical Punch Docs feedback tutorial on every splash, multi-H1 allowance on index.html only, and a few others. The biggest behavior change for vets: if you've been muscle-memory-fixing copy as you build, stop. The renderer no longer does it for you — see Change 2.

What to show on screen: open the Auria splash. Show the feedback tutorial. Show the theme toggle. Open wireframe-principles.md and scroll through the ten.

Where it'll show up first: next wireframe build. If you build wireframes the old way, the lint will flag it.

Change 2 · No-enhancement rule

Why it matters: for a long time the renderer silently cleaned up source copy — stripped trailing periods on H2s, normalized eyebrows, fixed quote styles. That was convenient but it papered over copy discipline problems and meant the source of truth was a lie. As of now, the renderer pours copy verbatim. If you wrote it wrong, it ships wrong. Copy discipline is now a writer and strategist responsibility, not a renderer responsibility.

What to show on screen: open no-enhancement-rule.md. Walk through the worked examples. Show a brief that has trailing periods and what happens when you wireframe it.

Where it'll show up first: next brief that goes to wireframe. The first time it ships with a typo, you'll feel it.

Change 3 · Two new operating skills

Why it matters: the system has been good at executing but bad at learning. Two new skills close that loop. punch-term-drift auto-catches stale terminology against terminology.yaml — so when "warm gray" gets renamed to "neutral gray" in the new wireframe palette, the skill flags every doc still using the old term. punch-retrospective ritualizes the end-of-project learning meeting and feeds findings back into the skills and rules. Without these, the system rots quietly.

What to show on screen: the Skill Reference entries for both. A worked example of the drift skill catching a stale term. A sample retrospective output.

Where it'll show up first: retrospective runs at the end of your next project. Drift catches happen continuously in the background.

The three questions for this issue

Part 4 Assembling the next issue

A short checklist for whoever runs Q3 2026 (late September). Use this to prep without re-reading Part 1.