Strategist 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 strategist specifically, this has three operational consequences:

1. Every content decision has design implications. The Big Idea you land on through the themes exercise has to be expressible in both language AND visual posture. If a Big Idea can only be carried by words ("we use 'unhurried' a lot"), it's not a Big Idea yet — it's a tagline. Push it until the designer can see how to express it visually, too.
2. The brief is a design document as much as a content document. Audience, differentiators, messaging themes — they feed not just what gets written but how it gets composed visually. A brief light on specifics produces both vague copy and vague design.
3. Strategic QA is fusion QA. When reviewing a page, you're not asking "is the copy right" and "is the design right" separately. You're asking "are the copy and the design supporting and emphasizing each other to communicate the Big Idea?" If they're working against each other — copy is direct but design is decorative, or design is restrained but copy is loud — flag the misalignment.

The principle applies just as strongly to the writer's craft (copy without design awareness reads flat) and the designer's craft (design without content sensitivity reads decorative). 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

The core strategist deliverables are the same: Creative Brief, Theme Taglines, Sitemap, strategic QA across the project. What's new is that each of those starts with a Claude-drafted first-pass instead of a blank page, the chosen theme becomes a machine-readable voice anchor that the rest of the team's tools consume downstream, and the timeline compresses to roughly 4 weeks for Phase 0 inside an 8-week total project (the designer ramps up in weeks 2–4 of your phase to build brand elements and deliver two homepage takes for the client to pick before the website build begins).

Concretely, what each piece replaces:

• The hand-assembled Creative Brief becomes a Claude-drafted first-pass via punch-content-brief. You drop in kickoff transcripts, questionnaire responses, the client's existing brand work, public press. Claude synthesizes into the Punch brief template structure with every claim source-cited. You edit, sharpen, fill gaps. The structuring labor goes away; the judgment stays.
• The three-themes exercise from scratch becomes Claude proposing three meaningfully different directions via punch-theme-taglines — each with tagline candidates, positioning concept, voice notes, supporting phrases, and strategic ties back to the brief. You refine and present. The blank page goes away.
• The hand-built sitemap becomes a Claude proposal informed by the brief's audience + messaging themes + competitive landscape via punch-sitemap. AEO-aware page structure, IA suggestions you accept or override.
• The implicit brand voice — previously in your head, transmitted to the writer + designer through conversation — becomes a structured copy-brief.md derived from the chosen theme. The Primary Writer reads it. omma reads it. The voice is no longer something you have to re-explain three times per project.
• The strategist-as-author model becomes strategist-as-reviewer-and-shaper. You're not transcribing anymore. You're judging, picking direction, sharpening, and running the client conversations.

What you are still doing: every piece of strategic judgment, every direction call, every client gate, every QA pass at the strategic level. The first-pass is the floor; your work is the ceiling.

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 — strategist leads Phase 0. The diagram is the team's map; your specific responsibilities by phase are detailed in the table that follows.

Where strategists fit, by phase

The supporting docs you'll use

This onboarding is one of several Punch website role docs. Bookmark the ones you'll actually touch.

How the skills work and where they live

Before you do anything hands-on, the mental model for the Punch Claude skills you'll use — punch-content-brief, punch-theme-taglines, punch-sitemap. 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. The CCO installs it once in your Cowork environment as part of onboarding. 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.

Where things live

The plugin holds the capabilities. The folders hold the content. They never mix. A new client is a new project folder, never a new plugin.

Six principles for accurate, token-efficient Claude use

1. Trust the skill. Don't re-explain. Call the skill by name and let it pull what it needs. Bad: pasting kickoff transcripts into chat with "draft a brief in the Punch format with all our sections and citations and..." Good: "Run punch-content-brief on discovery in /clients/cendrix/discovery/." The skill already knows the Punch brief structure. Pasting it in chat re-loads tokens you've already paid for.
2. Reference files, don't paste them. Point the skill at file paths. Don't paste a 12-page kickoff transcript into chat — the skill reads files directly, more efficiently than chat-pasted content.
3. Don't restate session context across messages. Cowork preserves the working folder across turns. You don't need to repeat "for the Cendrix project" every prompt. State context at the start of the session.
4. One skill per task, called by name. If you find yourself stitching prompts to 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.
5. Don't pre-load skill content into chat. Resist the urge to paste a skill's SKILL.md to "remind Claude." Cowork loads skill content only when invoked, which is the most efficient pattern.
6. Lock briefs before downstream work runs. The Creative Brief feeds punch-theme-taglines and punch-sitemap. If you re-run those after editing the brief, you re-pay for the synthesis. Lock first, then run downstream skills.

Self-check before moving on

• I can name the four phases without looking
• I know which phase I lead (Phase 0) and where my QA touches the rest
• I understand my three big deliverables: Creative Brief, Theme Taglines, Sitemap
• I understand skills live in the punch-website plugin (installed once) — not in project folders
• I can recite at least three of the six token-efficiency principles
• I know what I don't do anymore (transcribing, structuring from scratch) and what I still own (judgment, direction, sharpening)

What the Creative Brief is

The Creative Brief is Punch's project-level discovery synthesis — a structured document capturing everything the team needs to know about the client to do good work. Historically it was assembled by a PM by hand from discovery materials (3–6 hours of structuring and writing). Now Claude drafts the first-pass from those same materials and the strategist reviews, sharpens, and locks.

The brief covers the following sections (mapped to Punch's existing Google Doc template):

1. Approvers — roles, not names. Personnel tracking lives on Asana.
2. Project quick links — Drive folder, Asana project, discovery materials, SOW
3. Project scope — timeline, kickoff, theme status, sitemap status, copywriting status, design status
4. Project objective — what the website needs to do for the business
5. Company overview — 2-sentence elevator pitch
6. Company origin — founding moment, milestones, what they've built
7. Why they exist (the pain point) — customer pain, why it matters, what happens if it's not solved
8. Core value proposition — the customer benefit, stated from the customer's perspective
9. Core differentiators / USP — what sets this company apart, with proof points
10. Relevant product / solution details — capabilities, integrations, technical scope
11. Brand personality / tone of voice — adjectives with one-sentence elaboration each
12. Competitive advantage — the specific moves that produce wins
13. Core messaging themes — the 3–5 things the audience MUST take away
14. Target audiences — primary buyer + influencers, what they care about, what they fear, how they buy
15. Performance metrics / impact — customer wins, stats, case stories
16. Category + competitors — where this company sits, who it beats and how
17. Other important resources — glossary, regulatory constraints, brand assets, technical dependencies

The tool

Gathering discovery materials

Before running the skill, the PM or strategist gathers the discovery inputs in one place. Keep everything in the client project folder so the skill can read it all at once.

What to gather

• Kickoff call transcripts — full recordings transcribed (any Otter/Fireflies/Granola output works). Speaker-labeled is ideal but plain transcripts are fine.
• Discovery meeting notes — notes the PM or strategist took during discovery sessions
• Client questionnaire responses — if you sent a pre-kickoff questionnaire, the responses
• Client-provided brand docs — brand guidelines, positioning decks, previous brand briefs, anything they sent
• Public press + About content — relevant press mentions, blog posts, About page content. Links are fine; the skill fetches them.
• SOW or proposal — the engagement scope

Folder convention

Store everything under /clients/[client]/discovery/ with descriptive filenames so the citations in the brief make sense later:

/clients/cendrix/
├── discovery/
│   ├── kickoff-transcript-2025-04-12.txt
│   ├── kickoff-notes-2025-04-12.md
│   ├── pre-kickoff-questionnaire-responses.pdf
│   ├── client-brand-guide.pdf
│   └── press-links.md
└── brief.md  (output of punch-content-brief)

How to invoke

Open Cowork pointed at the client project folder. Make sure the punch-website plugin is installed (the CCO handled this). Then say:

Run punch-content-brief for Cendrix. Discovery is in /clients/cendrix/discovery/. Write the brief to /clients/cendrix/brief.md.

Or any of these natural phrasings:

• "Draft the brief for [client]."
• "First-pass the creative brief — discovery is in [folder]."
• "Synthesize the discovery into a brief."
• "Build the brief from these kickoff notes."

The skill reads every file under /discovery/, fetches any URLs listed, synthesizes into the Punch brief structure, and writes to the output path. Returns a summary including section count, gap count, and source count.

Reviewing the first-pass

The skill's output is structurally complete but never finished. Your job is the review pass. Work through it in this order:

1. Read top to bottom once — full read, no editing yet. Get a sense of which sections feel sharp and which feel thin.
2. Read the Citations section at the bottom. Every major section should be source-cited. If a section isn't cited, that's a flag — Claude may have synthesized loosely. Verify against the source or flag as a gap.
3. Read the Gaps section. The skill explicitly surfaces what discovery couldn't cover. These need your judgment or a client follow-up.
4. Sharpen "Why they exist" and "Core value prop." These two sections drive everything downstream — themes, messaging, page content. If either is generic, the downstream work will be generic. Specificity here matters more than anywhere else.
5. Audit "Core differentiators." Every differentiator should be specific and ideally have a proof point. If a differentiator is "we're faster" without a number or example, mark it as needing follow-up or rework.
6. Check "Target audiences" for primary-buyer specificity. "Director of Security at mid-market SaaS" is specific. "Security professionals" is not. Sharpen until the audience has a job title, a context, and a set of fears and motivations.
7. Audit "Category + competitors." Each competitor should have a positioning note ("their angle") and a beat-them note ("our edge"). Generic competitor descriptions are gap candidates.
8. Read aloud the "Core messaging themes" and the "most important takeaway." If the most-important-takeaway sentence isn't a sentence you'd say to a colleague to describe the brand, rework it.
9. Final pass: format, project links, scope status. Make sure the Approvers block has roles (not names — names live on Asana). Make sure Drive/Asana/SOW links are filled in.

Handling Citations and Gaps

The skill produces two structural blocks at the bottom of the brief that earn your trust in the first-pass:

Citations

An index of which discovery source informed which section. Every claim that came from a specific source should be traceable. Use this to spot-check claims that feel surprising — go to the source, verify, and either confirm or rewrite.

If a section has no citation, Claude either inferred broadly across multiple sources or was working without a source. Both are flags — the first usually OK after spot-checking; the second is a real gap.

Gaps

A list of sections that discovery didn't fully cover. The skill explicitly flags these rather than fabricating content. For each gap, the strategist decides:

• Follow up with the client — schedule a brief async or sync conversation to fill the gap before locking
• Fill with your judgment — when the gap is small and you have enough context to make a defensible call
• Mark "not applicable" — sometimes a section doesn't really apply to this project (e.g., a re-launch project may not have "founding origin")

Never lock a brief with un-addressed gaps. Even "filled with judgment" should be explicit — note it in the section so the next person reading the brief knows that claim came from you, not the discovery.

The hard rule (v0.7.7) — never fabricate, always FLAG + ASK

This rule exists because the worst failure mode in agency work is confident-sounding fabrication that ends up in front of a client SME. (The Auria CERUX product pages in May 2026 — fabricated capability claims caught at SME review — is the case study that drove this rule.) The cure is to stop fabricating, ever, without you saying it's okay.

What counts as fabrication

Anything that's a claim about reality the skill can't trace back to a source:

• Product capabilities, specs, performance numbers, integrations, compliance certs
• Customer counts, named customers, partnerships, awards
• Leadership team members, headcount, funding, founding dates
• Plausible-sounding stats ("47% reduction in response time")
• Made-up testimonials, example quotes, example customers
• Bracketed placeholders like [STAT: ...] or [example: ...] — these count as fabrication and were retired in v0.7.7

What doesn't count as fabrication

• Synthesis from grounded material. Restating, paraphrasing, structuring claims that ARE in a source. "Mara said X" → "the team's tension is Y" is synthesis. Cite the underlying quote.
• Creative framing and judgment. Brand voice, audience tier descriptions, big idea framing, design direction language. These are your strategic synthesis, not factual claims.

The source/ folder

{client}/source/ is where authoritative client-provided material lives — data sheets, technical specs, capability docs, integration matrices, compliance certs. PM owns it; your job is to make sure it's populated before you run punch-content-brief on any factual page (products, capabilities, technical detail). Organize by subfolder however helps (per product, per page, per topic). The skill auto-discovers files by scanning the tree — no manifest required.

If a section can't be grounded, the skill writes a MISSING SOURCE marker in the brief AND auto-appends a one-line chase-list entry to source/_missing.md. That file is the PM's tracker — checked off when the source lands. No proactive maintenance.

What to do when a MISSING SOURCE marker appears

1. Don't strip it. The marker is the system's way of telling you (and the wireframe, and the client) that this section can't ship until source lands. punch-wireframe renders the marker as a loud red block — that's by design.
2. Decide per section: wait for source (preferred), draft from the open web with a citable URL (acceptable, mark the source as "Tier 2 — verify"), or fabricate with your explicit go-ahead (only when you've consciously decided the risk is acceptable).
3. If waiting: chase the PM, who chases the client. The chase item is in source/_missing.md.
4. If fabricating with go-ahead: mark the section with a comment so the next reviewer knows it's not grounded: <!-- fabricated with strategist go-ahead, [date], pending SME verification -->.

Common failure modes

1. Stripping MISSING SOURCE markers without addressing them

If a section reads "this page needs the data sheet" and you delete the marker so the page looks cleaner, you've reintroduced the Auria failure mode. The marker is unmissable on purpose — it's the only thing that stops a half-grounded page from shipping. punch-copy-lint + punch-pre-launch-qa catch silent strips at QA gates, but don't rely on the gate — respect the marker.

2. Fabricated proof points (legacy, pre-v0.7.7)

If you're working with an older brief drafted before v0.7.7, it may have fabricated stats with no source citation. The Auria-era convention was to flag these in audit. The new convention prevents them at draft time. If you inherit a pre-v0.7.7 brief, re-run punch-content-brief against the current source folder — anything ungrounded will land as a MISSING SOURCE marker.

2. Marketing-speak instead of plain language

The brief is a working document for the design + content team. It should be plain, specific, factual. If a section reads like marketing copy ("revolutionary platform delivering unparalleled value"), rewrite as plain English.

3. Vague differentiators

"More secure," "easier to use," "more flexible" — these are claims, not differentiators. A real differentiator has a specific mechanism or proof. If a differentiator is too vague to verify, mark it as needing client follow-up.

4. Generic target audience

"Enterprise customers" is not a target audience. "Director of Security at mid-market SaaS, 200–2000 employees, reporting to CISO, evaluating tools alongside other priorities" is. Sharpen until you'd recognize the audience if you met them at a conference.

5. Ignoring the client's own brand guide

If the client provided a brand guide in discovery, claims in the brief should align with it. If Claude's draft says one thing and the brand guide says another, the brand guide wins (or the strategist explicitly reconciles them). Mismatches downstream burn trust.

Self-check before moving on

• I can name the foundational brief sections (or at least the ones that drive everything downstream)
• I know what discovery materials to gather and where to store them
• I can invoke punch-content-brief from natural language in Cowork
• I know the 9-step review pass and which sections matter most (Why they exist, Core value prop)
• I know how to handle Citations and Gaps — verify claims, address every gap before locking
• I can name at least three common failure modes (fabricated proof points, vague differentiators, marketing-speak)
• I've run the practice exercise with Lattice and locked a brief

What a "Theme" actually means at Punch

A theme is not a tagline. A theme is an abbreviated brand starter built around a single Big Idea — an emotional truth about the client expressed in one or two words: assurance, ease, control, earned, quiet, unblinking, ready. Every element of the theme reinforces the Big Idea and is designed to make the client feel the direction, not just read about it.

Each of the three themes Punch presents to the client is a small but real brand proposal. A theme deliverable typically includes:

• The Big Idea — the emotional truth, one or two words, plus a one-sentence "what it evokes"
• Tagline candidates — language that makes the Big Idea feel inevitable, not just describes it
• Logo treatment — a logo direction with construction rationale (abbreviated; the chosen direction gets refined and built out after the client picks)
• Color palette — 4–6 named colors that carry the Big Idea's emotional register
• Typography — a primary typeface selection with character rationale (why this typeface, in this voice, for this Big Idea)
• Brand collateral mockups — concrete examples of the brand in context: business card, mug, polo, pen, t-shirt. Small, real-feeling artifacts that prove the direction can carry across surfaces.
• A hero mockup for the website — a homepage hero composition shown on a laptop frame, showing how the Big Idea expresses on the actual surface clients are paying us to design
• Design rationale — one or two paragraphs explaining how the visual language reinforces the Big Idea (e.g., from a recent troj.ai theme: "Layered grids, lines, and nodal compositions create a sense of interconnected systems...")

All of it radiates from the Big Idea. When the strategist looks at the designer's hero mockup and asks "does this evoke assurance?" — that's the test. When the designer picks a typeface and asks "does this carry control?" — that's the test. The Big Idea is the answer key.

This is also where the fusion methodology becomes concrete. The strategist owns the strategic spine of each theme (Big Idea, tagline, voice, design direction signals). The designer creates the visual half (logo, palette, type, collateral mockups, hero mockup, rationale). Both halves get presented to the client together as a single coherent theme. Neither half makes sense without the other.

The Big Idea — the spine

Three things to know about Big Ideas as Punch uses them:

• All three Big Ideas are true about the client. The point of the exercise isn't to find the "right" emotional truth — it's to surface three different true truths and let the client pick which one they want to lean on. Assurance, ease, and control might all be defensibly true about the same client; the question is which one they want to anchor the brand around.
• The Big Idea is a feeling, not a feature. "Faster" is a feature. "Unhurried" is a feeling. Reach for the emotional posture, not the product attribute. Big Ideas are how the user/client should feel, not what the product does.
• The Big Idea makes the design language inevitable. Once you've named the Big Idea, every subsequent decision (color, type, layout, imagery, hero direction) has a clear test: does this reinforce the Big Idea, or does it drift? Without a Big Idea, the design becomes vibes-driven and arguments about "we're picking three different colors here, that should be considered" go on forever. With a Big Idea, the question is always "does this evoke [Big Idea]?" and the answer is usually visible.

What Claude does — and what Punch does

This is the most important distinction in this module. Read it before you run the skill.

The iterative loop

Big-picture flow from locked brief to client presentation:

1. Strategist runs punch-theme-taglines from the locked Creative Brief → file with three starting-idea themes (Big Ideas, taglines, voice, design direction, hero direction).
2. Strategist refines — sharpens Big Ideas, language, voice. Often the right Big Idea is in the first-pass but needs a stronger word. Sometimes a fourth Big Idea emerges and replaces one of the three. Budget 30–45 minutes here.
3. Strategist briefs the designer on the refined three directions. Designer creates visual elements, brand collateral, and a hero mockup for each.
4. Strategist pressure-tests the designer's visuals against each Big Idea. Does this evoke [Big Idea], or has it drifted? When unsure, ask Claude (in-chat pressure-test mode, below).
5. Strategist + Designer + CCO pressure-test for differentiation — does our direction stand apart from named competitors, or are we sitting in the same place? Claude can help here too.
6. Iterate on language and visuals until each theme is real. This is the work that earns the budget.
7. Present three full themes to the client — live walkthrough, full creative including hero mockups and collateral. Client picks (or asks for refinement).
8. Extract the chosen theme's voice block to copy-brief.md — the file the Primary Writer and omma both read downstream.

The tool

How to invoke

Open Cowork pointed at the client project folder. Make sure the punch-website plugin is installed (CCO handled this). Then say:

Run punch-theme-taglines for [client]. Brief is at /clients/[client]/brief.md.

Or any of these natural phrasings:

• "Draft the three themes for [client]."
• "Do the three-themes exercise — brief is locked."
• "Give me three Big Idea starters from the [client] brief."
• "What are our themes — start from the locked brief."

The skill writes the starting-ideas file to /clients/[client]/theme-taglines.md and returns a summary including the three Big Ideas it proposed and which axes it used to differentiate them.

Anatomy of a starting theme

Each of the three directions in the output file has the following fields. Knowing the structure helps you read the first-pass critically and refine fast.

Refining the starting ideas

The skill produces a structurally complete starting file. Your job is to make each direction feel real. Work through each theme in this order:

1. Read each Big Idea aloud. Does it feel like an emotional truth, or a marketing word? "Assurance" feels true; "intelligent" feels like a category descriptor. Replace anything that's not a feeling.
2. Test "all three are true." Each Big Idea has to be defensibly true about this client. If one feels like a stretch, rework the anchor or replace the Big Idea.
3. Check that the three are meaningfully different. If two Big Ideas collapse into the same emotional posture on a second read, swap one for a different direction.
4. Sharpen each tagline against competitors. Open competitor sites. If a tagline could appear there as-is, cut or rewrite.
5. Tighten each voice block for specificity. Replace any adjective that could apply to "any B2B company in the category."
6. Pressure-test the design direction. Re-read the design direction signals against the Big Idea. Do they reinforce the same feeling, or do they drift?
7. Strengthen the hero mockup direction. Make sure the emotional move is specific enough for the designer to interpret. Replace any direction that just describes a layout.
8. Re-read each refined theme aloud. If it reads like real Punch creative work, you're ready to brief the designer. If it still feels template-shaped, do another pass.

Pressure-testing the designer's visuals with Claude

Once the designer produces brand elements, collateral, or a hero mockup for a direction, the strategist's next move is to test alignment: does this design actually evoke the Big Idea, or has it drifted into something pretty but untethered?

This is a judgment call you make first as the strategist. But when you're not sure — when the design "feels right" but you can't articulate why it does or doesn't fit the Big Idea — ask Claude as a second opinion.

Invoke directly in Cowork chat with the theme file open as context:

This is the hero mockup for Theme 1 (Big Idea: assurance) [paste image or describe in detail].
Does this evoke assurance, or has it drifted? Be specific — name what works and what doesn't.

Or with brand elements:

Here are the type and color samples the designer proposed for Theme 2 (Big Idea: ease).
[paste/describe]. Does the design language lean into ease, or does it drift?
What would tighten the alignment?

Claude reads the Big Idea, the voice block, and the visual evidence, then names where the design reinforces the Big Idea, where it drifts, and what specifically would tighten the alignment. The strategist takes that signal back to the designer — or decides "this is the alignment we want, let's move forward."

Competitor differentiation check

Before presenting the three themes to the client, gut-check that each direction is genuinely distinct from named competitors. A direction that sits in the same emotional space as a competitor isn't a real choice for the client — it's a copy.

Invoke directly in chat:

Theme 1 for [client]: Big Idea is "unblinking." Voice is direct, quiet, technical.
Compare to [competitor A], [competitor B], [competitor C] — where are we sitting in the
same place, where are we genuinely distinct? Be honest. Flag overlaps.

Claude reads the chosen theme's Big Idea + voice + supporting phrases, reads the competitors' positioning (from the brief or by fetching their site), and names overlaps + distinctions. Use the signal to decide whether to refine a direction before client presentation.

Presenting to the client

The themes deliverable is always presented live — never emailed cold. The reaction in the room (which Big Idea they light up at, which they push back on, where they ask "what about a mix of 1 and 3") is more diagnostic than any written response. And the chosen direction often emerges through conversation rather than a single picking moment.

Format: each theme gets its own section of the presentation, walked through in order. Show:

• The Big Idea, named clearly
• Why it's true about the client (one or two specific brief anchors)
• The tagline candidates
• The brand design elements the designer created (color, type, imagery samples)
• The collateral pieces
• The hero mockup — this is the moment the theme becomes real for the client
• The voice samples (supporting phrases)

Order of presentation: start with the direction you find most strategically interesting, not the safest. Sets a high creative bar and frames the conversation around taste rather than risk.

After the client picks (including hybrid picks + the revise step)

Clients rarely pick one theme cleanly. The common case is a hybrid: "I love the Big Idea from #1, the color palette from #2, and the typography direction from #3 — combine those." That's expected, not a failure. Punch's job is to absorb the combo, revise into a single coherent direction, and produce the fleshed-out brand from there.

The post-pick sequence:

1. Capture the pick precisely. Write down what the client chose from each theme, in their words. "Big Idea + tagline from Theme 2. Color palette from Theme 1 (but pull the secondary accent from Theme 3). Type from Theme 2. Hero direction from Theme 1." Specificity here saves a week of clarifications later.
2. Mark status in theme-taglines.md — change status: starting idea to status: chosen on the dominant theme. Add a note at the top of the file listing what got pulled from the other two.
3. Strategist + designer revise. Take a working session (often the same day or next day) to reconcile the combo into one coherent direction. Strategist locks the Big Idea + tagline. Designer reconciles the visual decisions across the cherry-picked elements — does the Theme 1 palette actually work with the Theme 2 type, or do they fight? Make the fusion calls now, not later.
4. Carry the spine into copy-brief.md. Fill in the Big Idea + "what it evokes" sentence at the top, lifted from the chosen direction. The Big Idea is the spine every downstream tool aligns against — it doesn't live only in theme-taglines.md; it must be present here.
5. Extract the voice block as the third paragraph of copy-brief.md. Paragraphs 1 and 2 (visual-character and color-posture) get filled by the designer once the brand build-out is done.
6. Designer fleshes out the brand over the rest of Phase 0. Logo refinement, full icon system, button states, photography direction, illustration direction if applicable. This is the work that turns an abbreviated brand starter into a real brand the designer can use to build the two homepage takes.
7. Notify the team. Drop a note in Slack or Asana: "themes locked, Big Idea: [word] picked (with hybrid notes captured in theme-taglines.md). copy-brief.md updated. Designer building out brand + heading into the two-homepage takes." This is the signal that the rest of Phase 0 can proceed.

Once copy-brief.md is updated, the Primary Writer's punch-page-content and the designer's punch-omma-export both read the Big Idea + chosen voice as input. You don't re-explain. The file is the contract.

Common failure modes — what to push back on in the starting ideas

1. Big Ideas that are features, not feelings

"Faster," "smarter," "intelligent" — these are product attributes, not emotional truths. Replace with feelings: "unhurried," "earned," "ready."

2. Three variations of the same Big Idea

If two Big Ideas collapse into the same feeling on a second read, they're a single direction. Push one onto a meaningfully different emotional axis.

3. Fabricated brief anchors

If the brief doesn't actually contain the finding the anchor references, the anchor is fabricated. Read each anchor back against the brief. Cut or rework if it doesn't match.

4. Design direction that contradicts the Big Idea

If the Big Idea is "ease" and the design direction is "dense, intense, energy-forward," the direction is fighting the Big Idea. Rework one of them — usually the design direction needs to be re-aligned to the Big Idea, not vice versa.

5. Generic taglines and generic voice blocks

"Smarter [category]." "Modern, confident, professional." Filler. Push back hard until both are specific enough to direct concrete decisions.

6. Hero directions that describe a layout

"Two-column hero with image on the right" is not a hero direction; it's a layout. A hero direction is an emotional move: "feels like a held breath." Rework until each hero direction tells the designer what to evoke, not what to lay out.

Self-check before moving on

• I can explain what a "Big Idea" is at Punch and why it's the spine of each theme
• I know a theme is more than text — it's tagline + brand elements + collateral + hero mockup, all radiating from the Big Idea
• I understand the skill produces starting ideas, not the deliverable — Punch's value is the refinement
• I can name the 8-step refinement order for the starting ideas
• I know how to invoke the in-chat pressure-test pattern with Claude when assessing the designer's visuals
• I know to extract the chosen theme's voice block to copy-brief.md after the client picks
• I've run the practice exercise with Lattice and refined three directions

What the sitemap is

Punch's sitemap is a structured YAML file capturing every page in the site with its path, name, purpose, tier, hierarchy, and AEO/SEO targeting. It lives at /clients/[client]/sitemap.yaml and is read downstream by:

• The Primary Writer's punch-page-content — reads each entry to know which pages to draft and what each is for
• The designer — uses page count + tier mix to plan Phase 2 batches
• The PM — uses the same numbers to schedule the 4-week website sprint in Asana
• Dev — uses paths and tier classification to know what to template (standard) vs what's bespoke (showcase)

The sitemap.yaml format

Each page is a structured entry. Example for a typical cybersec site:

site: cendrix.com
brief: brief.md
chosen_theme: theme-2-assurance

pages:
  - path: /
    name: Homepage
    purpose: Convert security buyers to demo requests
    tier: showcase
    focus_keyphrase: security intelligence platform
    schema_type: Product
    parent: null

  - path: /platform
    name: Platform
    purpose: Explain core capabilities to evaluators
    tier: showcase
    focus_keyphrase: detection and response platform
    schema_type: SoftwareApplication
    parent: null

  - path: /solutions
    name: Solutions
    purpose: Audience-specific entry point hub
    tier: standard
    parent: null

  - path: /solutions/cloud-security
    name: Cloud Security
    purpose: Address cloud-specific buying audience
    tier: standard
    focus_keyphrase: cloud security solution
    parent: /solutions

  - path: /about
    name: About
    purpose: Company credibility and team
    tier: showcase
    focus_keyphrase: cybersecurity company
    parent: null

  - path: /demo
    name: Request demo
    purpose: Convert hot leads
    tier: standard
    parent: null

Tier assignment — the strategist's most important sitemap call

Every page gets a tier label: showcase or standard. This is the call that drives budget allocation across the project.

The strategist owns the tier call because it requires brief-level judgment: which pages does this specific client's audience need to actually convert vs which pages are table-stakes? Wrong tier assignment is one of the most expensive sitemap mistakes — over-tier and you blow the timeline; under-tier and the conversion-critical pages get templated and underperform.

The tool

How to invoke

Open Cowork pointed at the client project folder. Then say:

Run punch-sitemap for Cendrix from the locked brief. Write to /clients/cendrix/sitemap.yaml.

Or any of these natural phrasings:

• "Draft the sitemap from the brief."
• "Propose an IA for [client]."
• "What pages should this site have, based on the brief?"
• "First-pass the sitemap."

The skill writes the sitemap to the output path and returns a summary: total pages, tier mix, and any pages it flagged for strategist review (e.g., "should this be showcase or standard?").

AEO-aware sitemap structure

AEO (Answer Engine Optimization) shows up in the sitemap in two ways:

1. Topic coverage: the sitemap should include pages that match the questions the audience is actually asking. If the brief identifies a primary buyer concern (e.g., "compliance reporting for SOC 2") that doesn't have a page, that's a gap. Add a Solutions or Use Case page that addresses it.
2. Per-page focus keyphrase: each non-utility page gets a 1–4 word focus keyphrase. The Primary Writer uses this when drafting page content; AEO/SEO is enforced at content level, but the sitemap is where the keyphrase is assigned.

The skill proposes focus keyphrases per page based on the brief's category + audience signals. Strategist reviews — sometimes Claude's proposed phrase is generic or doesn't match how the buyer actually searches. Sharpen it if so.

What's NOT the strategist's job: page-level AEO optimization (question-answer cadence, schema markup beyond type, FAQ block presence) is the Primary Writer's domain. You assign the focus keyphrase; they execute on it.

Reviewing the first-pass

1. Total page count. Does the count fit the 8-week project scope? A typical project ships 15–25 pages. More than 30 and you're either in a bigger engagement than scoped, or the sitemap is bloated.
2. Tier mix. 4–6 showcase pages is the sweet spot. Re-tier anything that doesn't earn showcase status.
3. Audience coverage. Read the brief's primary audience section. Is there a page for each major concern that audience has? Flag gaps.
4. Hierarchy clarity. Does the IA make sense at the nav level? Could a first-time visitor find what they need without clicking past two levels of menu?
5. Focus keyphrase audit. Skim the keyphrases — anything too generic ("our platform")? Anything missing? Anything that overlaps with a competitor's known SEO position to a degree we shouldn't take on?
6. Competitor cross-check. Look at 2–3 named competitors from the brief. Do we have the page types they have (Pricing, Resources, Customers, etc.) plus what differentiates us? Or have we missed something everyone else has?
7. Page purpose lines. Each page should have a one-sentence purpose. If a page's purpose is generic ("explain what we do"), sharpen — the Primary Writer uses this line as their compass.

Presenting the sitemap to the client (G1)

The sitemap presentation is usually a 15–30 minute live walkthrough. Format:

• Walk the hierarchy top-down — show the homepage, then the main nav structure, then any secondary structure
• Name each showcase page and why it earns that tier (audience priority, conversion criticality)
• Note the page count and tier mix as a scope anchor
• Use the standard pulse-check feedback artifact (Module 5) to capture the client's reaction — overall 0–10 pulse, per-element ratings, any flags
• Lock the sitemap if green-lit. The locked file is the input to punch-page-content downstream.

Common failure modes

1. Too many showcase pages

The most common first-pass over-allocation. Every audience need wants to be a showcase page until you remember the 8-week timeline. Re-tier aggressively. Showcase is the tier that earns the budget, not the tier that gets it by default.

2. Generic page purpose lines

"Explain our solutions." "Tell the company story." If the purpose line could apply to any company in the category, the Primary Writer will struggle. Sharpen each line until it's specific to this client's audience.

3. Missing audience-coverage pages

The brief identifies primary buyers with specific concerns. If those concerns don't have pages — even a small ones — the audience won't find what they need. Audit the brief and add pages for unaddressed concerns.

4. Over-nested hierarchy

If a page sits three levels deep in the nav, users won't find it. Compress where possible. Most cybersec marketing sites can live within two levels of nav.

5. Focus keyphrases that fight the brief's "don't sound like X" notes

If the brief explicitly says "don't lead with 'intelligent platform'" and the skill assigns "intelligent platform" as a focus keyphrase, push back. The brief is the contract.

Self-check before moving on

• I understand the sitemap.yaml format and what each field is for
• I know how to assign tier (showcase vs standard) and the 4–6 showcase rule of thumb
• I can invoke punch-sitemap from natural language
• I know the 7-step review pass and the order it runs in
• I understand AEO at sitemap level (topic coverage + focus keyphrase) — and what's NOT my job (page-level AEO)
• I know to lock the sitemap before the Primary Writer starts drafting
• I've run the practice exercise and locked a sitemap

The pulse-check framing

Every client touchpoint during a website project (with one exception — the launch sign-off) is framed as a pulse check, not a feedback round. The difference matters:

• Feedback round: "What do you think? What would you change?" → invites the client to act as designer/strategist. Generates pages of vague impressions that conflict with each other. Burns days reconciling.
• Pulse check: "Anything to flag? Anything off-direction?" → invites the client to gut-check for red flags. Generates focused signal the team can act on quickly.

The framing shows up in every comm: the email/Slack note, the live presentation, the feedback artifact. The client learns the cadence after the first one — they know we're not asking them to redesign, we're asking them to tell us if anything tripped a sensor.

The structured feedback artifact

Every pulse check uses the same form structure. Three layers of signal, all minimal, none asking the client to redesign anything.

Overall pulse (0–10 slider)
  0 = full stop, reconnect and reframe
  10 = green light, proceed

Per-element ratings (0–10)
  [Element 1]  [slider]
  [Element 2]  [slider]
  [Element 3]  [slider]
  [Element 4]  [slider]
  [Element 5]  [slider]

Your gut reaction in a word (optional)
  [Element 1]  __________     [Element 2]  __________
  [Element 3]  __________     [Element 4]  __________

Anything to flag? (Optional. Skip if nothing stood out.)
________________________________________________________

The elements change per touchpoint. Below for each gate.

The content wireframe — Punch's Phase-1 deliverable

Between G3 (homepage pick) and G4 (wireframe sign-off), the Primary Writer produces a content wireframe — the complete copy and structure for every page in the sitemap, rendered in one end-to-end document. This is the first full client preview of the website content.

What the wireframe is: punch-wireframe takes the locked briefs, the chosen theme's copy-brief.md, and the sitemap, then generates a structured document with:

• Every page from the sitemap, in hierarchy order
• Complete copy sections (headlines, body, CTAs) poured verbatim from the writer's drafts
• Wireframe structure showing where copy goes visually (hero, body chunks, sidebar, footer)
• Any MISSING SOURCE markers that made it through (red blocks — client + team see them immediately)

Source-fidelity rendering: The renderer has one rule: pour the source copy verbatim. No auto-stripped periods. No invented eyebrows. No rephrasing CTAs. If the writer wrote "Explore our capabilities" but the brief says "capabilities" is a search keyphrase and they used the singular, that mismatch is in the wireframe. Copy discipline is the writer's job; the wireframe doesn't hide mistakes.

Your role at G4 (wireframe sign-off): Read end-to-end for strategic alignment. Does copy land the Big Idea? Does voice stay consistent across pages? Does structure serve the brief's audience intent? Flag at the strategic level ("this page's positioning is off," not "tighten this sentence"). Once you sign off, the wireframe goes to the client as notification ("here's what we're building, any red flags?") — not a formal review stage, but transparency before design finalizes layout.

Adapting the artifact per touchpoint

Same form shape every time. Client learns the cadence and knows exactly what they're being asked.

The gate scripts

G1 — Brief + Sitemap sign-off (End of Phase 0 week 1)

Hey [client] — on [day] we're walking you through the strategic
foundation of the project: your audience, what makes you different from
competitors, and the page structure we're proposing for the site.

This locks in our strategy for the build phase. Form follows with a
simple pulse check — anything feel off strategically?

Looking forward to it.

G2 — Theme pick (visual presentation, End of Phase 0 week 2)

Hey [client] — on [day] we're walking you through three creative
directions for the brand. Each anchors on a different emotional truth
about [client]. Your pick determines the feel of the entire site.

Pulse check — which direction resonates? After the walkthrough we'll
send a short form to capture your reaction. Takes 2 minutes.

Looking forward to it.

G3 — Homepage direction pick (the two-homepage delivery, End of Phase 0 week 4)

Hey [client] — on [day] we'll walk you through two homepage takes for
[client]. Both carry the brand direction we locked, both work with the
sitemap we landed on together. They differ in one specific dimension:
how the hero interaction feels. One is calmer and more straightforward;
one leans more on motion + interactivity.

This pulse check is the biggest one in the project — your pick locks
the direction we'll carry across every page. Form follows the meeting;
no rush, take a day or two to live with both before you respond.

G4 — Content wireframe sign-off (End of Phase 1)

G5 — Per-batch copy lock (during Phase 2)

Feeding structured feedback back into Claude

The structured feedback artifact's biggest value isn't the human readability — it's that the data is in a shape Claude can ingest and act on. After every pulse check, the strategist can feed the structured response back to the relevant skill to drive a refinement.

For creative themes (G2)

If the client picks a direction but rates tagline 4/10 with gut reaction "generic":

Theme 2 was picked. Client feedback on it: tagline 4/10 ("generic"),
typography 8/10, color 7/10 ("bold"), imagery 9/10, brand feel 8/10.
Refine theme 2's tagline candidates — current candidates feel generic
per client. Keep Big Idea (assurance) and voice block as is.

Claude reads the feedback, refines tagline candidates without touching what's working. Strategist reviews + presents the refined taglines back to the client.

For the two-homepage delivery (G3)

If the client picks "Homepage A (safer)" but flags voice 5/10:

Client picked Homepage A. Feedback: hero 9/10, layout 8/10, copy 7/10,
voice 5/10 ("flat"), overall feel 7/10. Refine Homepage A's copy
direction — voice is landing flat. Push toward chosen theme's voice
block in copy-brief.md more aggressively.

Claude refines the homepage copy with the writer in the loop. Strategist QAs.

For per-batch pulse checks (Phase 2)

If the client returns flags on specific pages:

Batch 1 feedback returned. Overall 8/10. Flags: "Use Cases page feels
disconnected from the homepage voice." Refine the Use Cases page copy
to align with the chosen theme more tightly. Other pages in batch
approved as-is.

Targeted refinement; rest of the batch isn't touched.

Common failure modes

1. Slipping into "feedback round" framing

"What do you think? Any suggestions?" → invites essays. Stick to pulse-check language even when it feels too restrained. The form does the structured signal; the comm sets the bounds.

2. Sending the feedback artifact before the live walkthrough

The client should have seen the work live before they fill out the form. The form captures the gut reaction after the walkthrough; if you send it ahead, you get cold ratings on incomplete context.

3. Reopening locked decisions on later pulse checks

If a client circles back at the homepage gate and says "actually I want to revisit the sitemap" — that's scope creep, not pulse feedback. Acknowledge, but flag to PM. Sitemap was locked at G1.

4. Treating the <7 score as failure

A 6/10 with a specific flag is more useful than a 9/10 with no notes. Low-ish scores with clear flags are how the system is supposed to work — they tell you exactly where to sharpen.

5. Skipping the team notify after the gate

After each gate, drop a 1-line note in Slack/Asana ("G1 closed, brief + sitemap locked, designer moving to themes"). This is the signal that downstream work can start. Quiet gate closures stall the next phase.

Self-check before moving on

• I can explain the pulse-check framing in one sentence and why it's different from a "feedback round"
• I know the structured feedback artifact's three layers: overall pulse, per-element ratings, single-word gut reactions, plus an optional flag
• I can name the four touchpoints and the per-element ratings for each
• I know the G3 (two-homepage) format and why it's the project's biggest decision
• I understand how to feed structured feedback back to Claude to drive refinements
• I can recognize at least three failure modes (feedback-round drift, sending artifact before walkthrough, reopening locks)

What strategic QA actually means

When a Primary Writer drafts a page from your locked brief + chosen theme, your review answers four questions:

1. Does this land the Big Idea? The chosen theme's Big Idea is the spine. Every page should reinforce it. If a page is on-brief mechanically but doesn't feel like the Big Idea, that's a strategic-level miss.
2. Is the voice right? Open copy-brief.md. The writer should be drafting in that voice. If a paragraph reads in a different voice — even a good voice — that's a flag.
3. Does this serve the audience as the brief defined them? Re-read the audience section of the locked brief. If a page is speaking to a different reader than the brief's primary audience, push back.
4. Does the page argue what its purpose says it should argue? Each sitemap entry has a one-sentence purpose. The page's content should deliver on that purpose. If purpose says "explain core platform capabilities to evaluators" and the page reads like a brand manifesto, flag.

None of these are about commas, character counts, or whether the meta description is exactly 156 characters. Those are the writer's craft. Your job is strategic alignment.

The three copy lock moments

Copy moves through three locks during the project. Each lock unlocks specific downstream work; reopening a lock has a cost. Strategist owns the call on when each one closes.

If a client request comes in after a lock (e.g., they want to revise a Phase 1 homepage paragraph during Phase 2), that's a change request — flag to the PM. Don't quietly absorb post-lock changes; they break the schedule downstream.

Handing off to the Primary Writer

At the end of Phase 0, you hand the writer everything they need to start drafting:

• Locked Creative Brief — the strategic foundation
• Locked sitemap — every page they'll draft, with purpose + tier + focus keyphrase per entry
• Chosen theme + copy-brief.md — the voice anchor, the Big Idea, the tagline candidates that got the client to pick this direction
• A short "handoff note" from you — anything the writer should know that isn't in the structured docs (e.g., "client pushed back on the word 'intelligent' — avoid"; "Big Idea is assurance — every page should reinforce that")

When the client wants to write their own copy

Some clients prefer to write their own website content. Common reasons: a founder with strong opinions about voice, an in-house content team that wants ownership, an established brand voice they don't want relinquished, internal stakeholders who'd be uncomfortable signing off on copy they didn't author. This path is fully workable inside Punch's process, but it changes who does what — and you have to set it up correctly in Phase 0 or it derails the timeline.

Surface this in Phase 0, ideally during discovery or SOW

The single biggest mistake on a client-writes project is finding out mid-Phase 2 that the client wanted to write. By then you've planned the timeline around Punch drafting and the writer is mid-batch. Ask explicitly during kickoff: "Will Punch be drafting all the content, some of it, or are you writing?" Get the answer in writing — SOW, kickoff doc, or Asana project notes.

Three common variations to plan for:

• Client writes everything. Punch's Primary Writer becomes an editor + polish role, not a drafter.
• Client writes some pages, Punch writes the rest. Usually the client takes pages they have strong opinions on (About, founder story, key product positioning) and Punch handles the structural pages. Map the split page-by-page in the sitemap with a tier-style label.
• Client wants ownership, but doesn't realize the lift. Sometimes a client says they'll write and then doesn't have the bandwidth. Watch for this — if drafts aren't arriving by lock dates, escalate to PM early.

Your Phase 0 work doesn't change

Brief, themes, sitemap, copy-brief.md — all still happen exactly the same way. These are the strategic foundation regardless of who writes the content. If anything, the Big Idea and voice block become more important when the client is writing, because they're the only handrail keeping the client's drafts aligned with the brand direction we collectively landed on.

The writing kit you give the client

If the client is writing, your end-of-Phase-0 handoff includes them, not just the Primary Writer. Package up:

• The locked Creative Brief — the strategic foundation
• The locked sitemap — every page they'll write, with purpose + focus keyphrase per entry
• Their copy-brief.md — the Big Idea, the "what it evokes" sentence, voice block. Frame it explicitly: "This is how the brand sounds. Write in this voice."
• 2–3 sample sentences in the voice — pulled from the chosen theme's supporting phrases. Concrete examples are worth more than adjectives.
• Character count targets per page type — homepage hero headline (max ~80 chars), body chunks (max ~160 chars per paragraph), CTA labels (max 3 words), meta descriptions (≤156 chars), etc. The mechanical guardrails distilled into bullets.
• A short "things to avoid" list — drawn from the brief's "don't sound like" notes and any competitor language the client wants distance from.

The Primary Writer's role shifts to editor

The client drafts; the writer edits. Editor scope:

• AEO/SEO mechanics (focus keyphrase placement, schema-friendly headings, meta data)
• Character counts — tighten or expand to fit the page architecture
• Voice consistency — check each draft against copy-brief.md and flag where the voice has drifted
• Flagging strategic misalignment up to the strategist (not fixing it inline)

What the writer doesn't do: rewrite from scratch. If a client's draft is fundamentally off-direction, that's a strategist conversation, not a writer rewrite.

Your QA changes shape — same questions, different dynamic

The four strategic questions still apply (Big Idea, voice, audience, page purpose). What changes is the conversation around feedback. With an internal writer, you flag and they re-draft. With a client-author, the dynamic is more deferential but still expert. Frame feedback the same way the Client-Facing Team training teaches: confident, declarative, not deferential.

Example wording (Punch voice, not deferential): "Read the About page draft. The voice lands on most sections, but the third paragraph drifts from the assurance Big Idea — it reads more like a feature list than something that makes the reader feel held. Suggest tightening or rephrasing in the chosen voice. Happy to redline a version if useful."

Pulse checks adapt — same artifact, slightly different question

The structured feedback artifact (Module 5) still runs at each gate. But the question shifts subtly. Instead of "here's what we drafted, pulse check it," the pulse becomes "here's your draft as we edited it for voice and mechanics. Anything we changed that doesn't sit right?" The client is reacting to their own work through Punch's editorial lens, not to fresh Punch output.

Lock moments still apply

Draft lock, showcase lock, final copy lock — the strategist closes each one. Client-authored doesn't bypass locks. If a client wants to revise after a lock, that's a change request — flag to PM. The lock discipline is what keeps the 8-week timeline alive.

Negotiate the boundary explicitly + watch the timeline

Get the editorial boundary in writing: "We edit for voice consistency, AEO/SEO, and character counts. Substantive rewrites are change requests after locks." And budget for it — client-written content typically adds 1–2 weeks to the project because the back-and-forth on client drafts is slower than internal drafting. If the 8-week timeline matters, surface this trade-off in Phase 0.

Reviewing the Writer's homepage draft (Phase 1)

The writer drafts homepage content from your locked brief + chosen theme. You QA before the draft lock closes. Read in this order:

1. Read top to bottom once, without editing. Get the gestalt — does this feel like the chosen Big Idea?
2. Check the voice — open copy-brief.md side by side. Is the writer in this voice, or has it drifted toward generic?
3. Check the hero — does it land the Big Idea in the first 50ms? (Most homepage decisions happen there.) If the hero doesn't evoke the Big Idea, the whole page's premise is off.
4. Check the audience match — would the brief's primary audience read this and feel addressed?
5. Flag anything strategically off, in one short Slack/Loom — not a redline. The writer re-drafts. Don't rewrite their work; tell them what's not landing.

When the draft lands strategically, you close draft lock. Signal it: Slack/Asana note — "draft lock closed for [client] homepage, designer can finalize."

Per-batch QA in Phase 2 — your role at G5

G5 is the per-batch copy lock moment where strategist, writer, designer, and PM all converge briefly before the next batch starts. It's typically a 15-minute meeting (often async). Your specific responsibilities at G5:

1. Strategic alignment check — same four questions as homepage QA, applied to every showcase page in the batch.
2. Voice continuity — across pages, is the voice holding? If page 3 in the batch reads in a noticeably different voice from page 1, flag.
3. Client pulse signal — the per-batch pulse check (Module 5) returns structured client feedback. Read it before the G5 meeting and bring the highlights into the conversation.
4. Close showcase lock for the batch — once strategic alignment is confirmed, the lock closes and writer can move to the next batch.

If the strategic alignment isn't there on one page, that one page goes back to the writer for re-draft — the rest of the batch isn't held up. Surgical, not sweeping.

Final copy lock in Phase 3

Before the final copy lock (Phase 3), copy goes through one last strategic-level read. By this point the writer has incorporated all per-batch feedback, the pages are coded, and the team is preparing to pour content into the CMS for staging. Your job:

1. Read the full site in dev preview, top to bottom, as a first-time visitor would. Does the site feel like one coherent brand voice, or do you hit pages that feel disconnected?
2. Spot-check edge pages — the standard tier pages templated by dev from the sandbox. Are they on-voice, or do they read flat because they didn't get the writer's per-page craft? If yes, flag the worst offenders to the writer for a quick pass.
3. Final flag pass — anything that catches your eye as strategically off, flag to PM. The CCO does an internal review before the client preview ships (G6).
4. Close final copy lock — once the read is clean, signal: Slack/Asana note that final copy lock is closed and the site can move to CMS pilot.

The launch sign-off — the one non-pulse-check moment

At G6, the client reviews the final preview URL before launch. This is the only client touchpoint in the project that isn't framed as a pulse check. The framing is:

It's still expert-confident in tone — we're not asking for "feedback" or for permission in a deferential way; we're telling the client the site is ready and inviting them to flag anything serious before launch. The Client-Facing Team training's "be a professional, don't act professional" principle is at maximum amplitude here.

Strategist's role at launch sign-off: co-present the preview URL with the PM (or solo, depending on the client relationship). Frame the call as the closing moment of the project, not as another review cycle. If the client comes back with a "wait, can we change X" — that's a change request, not pulse feedback. Flag to PM and CCO; don't absorb silently.

Common failure modes

1. Reaching for the red pen

You see a paragraph that's "not quite right" and start rewriting it inline. Stop. The writer's craft is theirs. Tell them what's not landing strategically and let them solve it.

2. Skipping the handoff note

The structured docs are clean, the writer can technically work from them, so you skip the 3-sentence context note. The writer guesses on texture and gets it ~60% right. Adding the note costs you 5 minutes; missing it costs the writer an hour.

3. Reopening a lock to address taste-level changes

Locks exist for a reason. If you re-edit homepage copy mid-Phase 2 because you woke up and decided the eyebrow should be different, you're causing rework downstream. Either it's strategically off (in which case lock should've never closed) or it's taste — and taste-level changes wait until after launch.

4. Over-coaching during G5

The per-batch copy lock is 15 minutes. If you're using it to teach the writer how to write better, you're using the wrong forum. Strategic flag, move on. Mentorship conversations happen outside G5.

5. Treating the launch sign-off as a re-review

If you arrive at G6 with a long list of things you want changed, your strategic QA at G5 and final copy lock failed. The launch sign-off is the close, not another revision round. Address strategic issues earlier.

6. Going silent during the writer's drafting

The writer is drafting; you're "letting them work." When the draft lands and it's off, you both have to re-litigate. Better: short, frequent check-ins ("How's the homepage hero copy going? Want me to read what you have so far?"). The Client-Facing Team's "acknowledge before you answer" principle applies internally too — don't go silent on your team.

Phase-1 hands-on exercises (extending the Lattice practice)

The practice exercises in Modules 2–4 cover Phase 0 (brief, themes, sitemap) using the Lattice fictional client. Below are four concrete exercises that extend the Lattice practice into Phase 1 workflow — the moments where your strategic QA work intersects with the writer and designer.

Hero headline: "Lattice secures your cloud infrastructure"
Hero subheadline: "Real-time visibility into every asset, every connection,
every vulnerability."

[Image: cybersecurity operations center, calm, controlled aesthetic]

First section (Why Lattice):
Cybersecurity teams are drowning in alert fatigue. You've stacked tools on
tools — vulnerability scanners, network monitors, container watchers — and
now you're spending 60% of your time synthesizing data that already exists
somewhere in your stack.

Lattice unifies that view. One interface. Real-time signals from every layer
— network, cloud, application, infrastructure. You see what's actually
happening (not what the last tool saw two hours ago). Your team can finally
breathe.

Self-check before moving on

• I can articulate the difference between strategic QA and proofreading (and know which is mine)
• I can name the three copy lock moments and what each unlocks
• I know what to hand off to the Primary Writer at the end of Phase 0 (locked docs + handoff note)
• I know my role at G4 (wireframe sign-off) and how it differs from the writer's role
• I know my role at G5 (per-batch QA) and the four strategic questions I ask
• I understand the launch sign-off is the one non-pulse-check moment and how to frame it
• I've completed the four Phase-1 hands-on exercises extending the Lattice practice

When in doubt, ask these five questions

1. Whose deliverable is this? If it's not yours, you're supporting, not owning. (And if you're discussing it with a client, replace "deliverable" with "next step" or the specific item.)
2. Which lock are we at? If you can't name it, you've drifted off the workflow.
3. Is this strategic or proofreading? If it's about commas, leave it for the writer.
4. Am I asking the client to react, or to redesign? If redesign, reframe.
5. Did I notify the team after closing this gate/lock? If not, downstream is stalled.