ワンクリックで
client-validation-document
// Produce the Part 5 Client Validation Document — the one true stop where unbiased v1 findings meet the client. Each finding gets ACCEPT/REJECT/EDIT/DEFER decision.
// Produce the Part 5 Client Validation Document — the one true stop where unbiased v1 findings meet the client. Each finding gets ACCEPT/REJECT/EDIT/DEFER decision.
Audit a brand's existing live campaigns across every active channel — paid, organic, email, social, content, SEO. Produce a current-state inventory, quick-wins backlog, and red-flags list. Use during agency onboarding or before any /campaign-plan refresh.
Run the unified pre-publish quality gate on marketing content — hallucination detection, claim verification, brand voice scoring, structure validation. Use before publishing any marketing copy.
Run Part 12 — the continuous improvement loop. Aggregates market + operating signals into product/offering recommendations. Runs alongside live operations, not as a one-time activity.
Run a full marketing engagement using the 12-Part methodology. Use when starting a new engagement, advancing parts, applying the Decision Matrix, or showing engagement status.
Produce the Four Core Documents at strategic depth (61 total steps): Business & SBU Analysis, Segmentation Framework, Brand Positioning, DMFlow. Use when running Part 3 of the engagement methodology.
Produce the 11-section Growth Plan — the flagship Part 8 client-facing deliverable that synthesises the entire engagement into a single executable strategy.
| name | client-validation-document |
| description | Produce the Part 5 Client Validation Document — the one true stop where unbiased v1 findings meet the client. Each finding gets ACCEPT/REJECT/EDIT/DEFER decision. |
| 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 |
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.
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.
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 client's responses then feed the Decision Matrix in Part 6 to determine which v2 re-runs are needed.
Before running this skill:
_engagement.json must show Parts 3 and 4 as completedIf pre-conditions fail, do NOT produce output. Instruct the user on what is missing.
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.
Length: 1 page.
Content:
Each category contains its findings as structured blocks. Categories:
Findings about the business reality — SBU separation, unit economics, value chain, growth levers, constraints, risks. Typically 3–5 findings.
Findings about target groups, persona priority, decision-making units, MQL/SQL definitions. Typically 3–5 findings.
The chosen positioning, messaging pillars, tone-of-voice, don't-say rules, sensitive-topic handling. Typically 3–5 findings.
Channel selections, in-market vs out-market split, budget allocation, channel sequencing. Typically 2–4 findings.
Competitor list, competitive positioning, Three-Question outputs (do well / do poorly / not doing). Typically 2–4 findings.
Market sizing, customer behaviour patterns, demand signals. Typically 2–4 findings.
Questions that the unbiased research could not resolve and need client input. The client provides answers here.
How the client returns their responses (typically a structured response file or a meeting walkthrough).
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
- [ ] DEFER — needs further investigation; reason below
**If REJECT or EDIT, client correction:**
{Client fills in: what the correct finding is, with their evidence}
**If DEFER, reason and follow-up plan:**
{Client fills in: what additional research / data is needed, who is accountable, deadline}
Each finding gets a Materiality rating that indicates how consequential the response is:
The client should focus most attention on High materiality findings; Medium and Low are still presented for completeness.
After the client provides responses, the responses are categorised into Decision Matrix triggers:
| Client decision pattern | Decision Matrix trigger |
|---|---|
| Any competitor finding REJECTED or EDITED with new competitors | competitors_changed |
| Any market sizing finding REJECTED or EDITED | target_market_changed |
| Any segmentation finding REJECTED or EDITED with persona changes | audiences_changed |
| Any positioning finding REJECTED or EDITED | positioning_changed |
| Any budget / scope finding REJECTED or EDITED | budget_or_scope_changed |
| Any pricing or offering finding REJECTED or EDITED | pricing_or_offering_changed |
| Any unit economics finding REJECTED or EDITED | unit_economics_changed |
| Only Low-materiality EDITs / minor wording corrections | minor_corrections_only |
The skill compiles the trigger list and runs:
python ${CLAUDE_PLUGIN_ROOT}/scripts/engagement-state.py decision-matrix \
--brand {slug} --id {id} \
--triggers "{comma-separated-trigger-list}"
The output then feeds the Part 6 v2 re-run plan.
Verify pre-conditions — Parts 2, 3, 4 completed.
Read the v1 source documents:
part-03-four-core-documents/v1/3.1-business-and-sbu-analysis.mdpart-03-four-core-documents/v1/3.2-segmentation-framework.mdpart-03-four-core-documents/v1/3.3-brand-positioning-and-communications.mdpart-03-four-core-documents/v1/3.4-dmflow.mdpart-04-competitive-customer-market/v1/4.1-competitor-ad-analysis.mdpart-04-competitive-customer-market/v1/4.2-competitor-positioning.mdpart-04-competitive-customer-market/v1/4.3-customer-analysis.mdpart-04-competitive-customer-market/v1/4.4-market-analysis.mdExtract material findings. For each source document, identify the 2–5 most strategically consequential findings. Materiality rating: prefer High and Medium; include Low only if the client specifically benefits from confirming.
Synthesise findings into the structured format. Use plain client-facing language, not internal jargon. Each finding stands alone — do not require the client to read the source documents.
Add Open Questions section drawn from the "Open questions" sections of each source document.
Add response mechanism section — instruct the client how to return responses (recommended: produce a paired client-validation-responses.json file alongside the document).
Save the document to:
engagements/{id}/part-05-client-validation/client-validation-document.md
Generate the response template:
engagements/{id}/part-05-client-validation/client-validation-responses.template.json
Containing one entry per finding with empty decision/correction fields.
Mark Part 5 as awaiting_input in _engagement.json (not completed — Part 5 is only complete when the client responses are recorded).
Brief the user on the document, the response mechanism, and the typical 7–14 day decision window.
When the client returns responses (filled-in JSON file or verbal walkthrough captured in a meeting):
Save the populated response file to:
engagements/{id}/part-05-client-validation/client-validation-responses.json
Run engagement-state.py decision-matrix --validation-file <path> to determine the v2 re-run plan.
Mark Part 5 as completed.
Advance to Part 6 (v2 re-runs).
User: We've completed Parts 2, 3, 4 for Acme. Time to prepare the Client Validation Document.
Skill response:
1. Verify pre-conditions ✓
2. Read all 8 source documents (4 from Part 3 + 4 from Part 4)
3. Extract 18 material findings across categories A–F:
- 4 in Business & SBU
- 3 in Audience & Segmentation
- 4 in Positioning & Communications
- 3 in Channel & Budget
- 2 in Competitive
- 2 in Market & Customer
4. 12 are High materiality, 5 Medium, 1 Low
5. 4 Open Questions identified from source docs
6. Save document at engagements/2026-q2/part-05-client-validation/client-validation-document.md (~22 pages)
7. Save response template at engagements/2026-q2/part-05-client-validation/client-validation-responses.template.json
8. Mark Part 5 as awaiting_input
9. Brief: "Document ready. 18 findings, 4 open questions. Recommend client meeting in 5–7 days for live walk-through, with responses returned within 2 weeks."
User: Acme client returned responses. They accepted most but rejected the positioning finding (they want to keep their existing positioning) and added 2 new competitors we missed.
Skill response:
1. Read the populated client-validation-responses.json
2. Categorise responses: 16 ACCEPT, 1 REJECT (positioning), 1 EDIT (competitor list)
3. Determine triggers: positioning_changed + competitors_changed
4. Run engagement-state.py decision-matrix --triggers "positioning_changed,competitors_changed"
5. Output: triggered re-runs = 3.1, 3.2, 3.3, 3.4, 4.1, 4.2 (the union of both triggers' re-run sets)
6. Estimate cost: ~85K tokens
7. Mark Part 5 completed
8. Brief: "Part 5 closed. 6 v2 re-runs triggered. Recommend reviewing the re-run plan and approving before invoking four-core-documents and competitor-analysis with view=v2."
engagement-workflow — orchestrates the 12-Part flowfour-core-documents — produced the v1 docs being validated; will produce v2 re-runs after Part 5competitor-analysis, audience-intelligence, market-intelligence skills produced the Part 4 docs