/client-validation-document

name: client-validation-document
description: "Produce the Part 5 Client Validation Document — the one true stop of the 12-Part engagement where unbiased v1 findings from Parts 2-4 are compiled into 12-25 evidence-cited finding blocks, each awaiting an ACCEPT / REJECT / EDIT / DEFER client decision, plus a paired JSON response template. Recorded responses feed the Part 6 Decision Matrix (engagement-state.py) to determine v2 re-runs. Triggers on \"/digital-marketing-pro:client-validation-document\", \"prepare v1 findings for client review\", \"run part 5 client validation\", \"the one true stop\", \"record the client's validation responses\". Requires Parts 3-4 marked completed in _engagement.json; reads the eight v1 core documents; pairs with /digital-marketing-pro:engagement-workflow and /digital-marketing-pro:four-core-documents."
user-invocable: true
triggers:
  - produce client validation document
  - run part 5 client validation
  - prepare findings for client review
  - client validation deliverable
  - the one true stop
  - prepare v1 findings for client
allowed-tools: Read Write Edit Bash Glob Grep
engagement-part: "5"
view-preference: v1-only

/digital-marketing-pro:client-validation-document — Part 5: The One True Stop

This skill produces the Part 5 deliverable: the Client Validation Document. It is the only point in the engagement where unbiased v1 findings are formally presented to the client for accept/reject/edit decisions.

Context efficiency

Heavy skill. **Grep before Read** any referenced file, then `Read` only matched ranges with `offset` + `limit`. List `${CLAUDE_PLUGIN_DATA}/<brand>/` before opening files. On re-invocation mid-session, skip files already in context.

This is the **one true stop** in the 12-Part flow. Nothing in Parts 6+ proceeds until this is signed off.

What this document is

The Client Validation Document compiles the most strategically consequential findings from Parts 2, 3, and 4 (the unbiased research and the four core documents) into a structured review document. For each finding:

• The finding itself
• Evidence / sources
• Proposed implication if accepted
• Three response options for the client: ACCEPT / REJECT / EDIT / DEFER
• (For REJECT or EDIT) — the client provides their corrected version and the rationale

The client's responses then feed the Decision Matrix in Part 6 to determine which v2 re-runs are needed.

What this document is NOT

• **Not a Growth Plan.** This is research findings, not strategic recommendations dressed up. The Growth Plan is Part 8.
• **Not exhaustive.** It includes only findings that have material strategic implications. Detail belongs in the source documents.
• **Not a slide deck.** It is a written document the client reads carefully and responds to. Slides do not capture the rigor required.
• **Not optional.** Every engagement runs Part 5. No shortcut to Part 6 without it.

Pre-conditions

Before running this skill:

1. Parts 2, 3, 4 must be completed (or substantially complete with explicit acknowledgment that some research continues) 2. The engagement state file `_engagement.json` must show Parts 3 and 4 as `completed` 3. The Living Project Instruction File should be up to date with the v1 strategic facts

If pre-conditions fail, do NOT produce output. Instruct the user on what is missing.

Document Structure

The Client Validation Document is organised by category of finding. Each category has 3–8 findings; total document is typically 12–25 findings across categories.

Section 1: Executive Briefing

**Length:** 1 page.

**Content:**

• Purpose of this document
• How to read it (the ACCEPT / REJECT / EDIT / DEFER framework)
• What happens after the client responds (Part 6 v2 re-runs governed by the Decision Matrix)
• Decision deadline (typically 7–14 days)

Section 2: Findings — by category

Each category contains its findings as structured blocks. Categories:

A. Business & SBU Findings (from 3.1)

Findings about the business reality — SBU separation, unit economics, value chain, growth levers, constraints, risks. Typically 3–5 findings.

B. Audience & Segmentation Findings (from 3.2 + 4.3)

Findings about target groups, persona priority, decision-making units, MQL/SQL definitions. Typically 3–5 findings.

C. Positioning & Communications Findings (from 3.3)

The chosen positioning, messaging pillars, tone-of-voice, don't-say rules, sensitive-topic handling. Typically 3–5 findings.

D. Channel & Budget Findings (from 3.4)

Channel selections, in-market vs out-market split, budget allocation, channel sequencing. Typically 2–4 findings.

E. Competitive Findings (from 4.1 + 4.2)

Competitor list, competitive positioning, Three-Question outputs (do well / do poorly / not doing). Typically 2–4 findings.

F. Market & Customer Findings (from 4.3 + 4.4)

Market sizing, customer behaviour patterns, demand signals. Typically 2–4 findings.

Section 3: Open Questions

Questions that the unbiased research could not resolve and need client input. The client provides answers here.

Section 4: Response Mechanism

How the client returns their responses (typically a structured response file or a meeting walkthrough).

Finding Block Format

Each finding follows this exact structure:

### Finding {ID}: {Short title}

**Category:** {A/B/C/D/E/F}
**Source:** {Document and step references — e.g., "3.1 Step 4, 4.1 Three-Question Output"}
**Materiality:** {High / Medium / Low}

**Finding:**
{2–4 sentences stating the finding from the unbiased research}

**Evidence:**
- {Cited source 1 with specific data point}
- {Cited source 2}
- {Cited source 3}

**Proposed implication if accepted:**
{1–3 sentences on what this means for the strategy if the client accepts}

**Client response:**

- [ ] ACCEPT — finding is correct as stated
- [ ] REJECT — finding is wrong; correction below
- [ ] EDIT — finding is partially correct; amended version below
- [ ] DEFE