[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M75DTM296TTD0MTY4H83JS70":3,"skill-same:01M75DTM296TTD0MTY4H83JS70":57},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":38,"repositoryHtmlUrl":39,"repositoryHomepageUrl":40,"ownerHtmlUrl":41,"ownerBlogUrl":42,"ownerDescription":6,"updatedAt":43,"install":44,"resources":56},"01M75DTM296TTD0MTY4H83JS70","client-validation-document",null,"Produce the Part 5 Client Validation Document — the one true stop where unbiased v1 findings meet the client. Each finding gets ACCEPT\u002FREJECT\u002FEDIT\u002FDEFER decision.","LongLeo287\u002FSEOSONA-OS","LongLeo287","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F141803367?v=4","01M6JK75C62VCNZKR5BRZ386YV","LongLeo","01M75CK60XQGYJY3YDGGFJQDYT",2,"MIT","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FSEOSONA-OS\u002Fblob\u002Fmain\u002F2_KNOWLEDGE\u002Fframeworks\u002Fdigital-marketing-pro\u002Fskills\u002Fclient-validation-document\u002FSKILL.md",[],[],"2026-11-12 13:55:43",false,"---\nname: client-validation-document\ndescription: \"Produce the Part 5 Client Validation Document — the one true stop where unbiased v1 findings meet the client. Each finding gets ACCEPT\u002FREJECT\u002FEDIT\u002FDEFER decision.\"\nuser-invocable: true\ntriggers:\n  - produce client validation document\n  - run part 5 client validation\n  - prepare findings for client review\n  - client validation deliverable\n  - the one true stop\n  - prepare v1 findings for client\nallowed-tools: Read Write Edit Bash Glob Grep\nengagement-part: \"5\"\nview-preference: v1-only\n---\n\n# \u002Fdigital-marketing-pro:client-validation-document — Part 5: The One True Stop\n\nThis 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\u002Freject\u002Fedit decisions.\n\n## Context efficiency\n\nHeavy skill. **Grep before Read** any referenced file, then `Read` only matched ranges with `offset` + `limit`. List `${CLAUDE_PLUGIN_DATA}\u002F\u003Cbrand>\u002F` before opening files. On re-invocation mid-session, skip files already in context.\n\nThis is the **one true stop** in the 12-Part flow. Nothing in Parts 6+ proceeds until this is signed off.\n\n## What this document is\n\nThe 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:\n\n- The finding itself\n- Evidence \u002F sources\n- Proposed implication if accepted\n- Three response options for the client: ACCEPT \u002F REJECT \u002F EDIT \u002F DEFER\n- (For REJECT or EDIT) — the client provides their corrected version and the rationale\n\nThe client's responses then feed the Decision Matrix in Part 6 to determine which v2 re-runs are needed.\n\n## What this document is NOT\n\n- **Not a Growth Plan.** This is research findings, not strategic recommendations dressed up. The Growth Plan is Part 8.\n- **Not exhaustive.** It includes only findings that have material strategic implications. Detail belongs in the source documents.\n- **Not a slide deck.** It is a written document the client reads carefully and responds to. Slides do not capture the rigor required.\n- **Not optional.** Every engagement runs Part 5. No shortcut to Part 6 without it.\n\n## Pre-conditions\n\nBefore running this skill:\n\n1. Parts 2, 3, 4 must be completed (or substantially complete with explicit acknowledgment that some research continues)\n2. The engagement state file `_engagement.json` must show Parts 3 and 4 as `completed`\n3. The Living Project Instruction File should be up to date with the v1 strategic facts\n\nIf pre-conditions fail, do NOT produce output. Instruct the user on what is missing.\n\n## Document Structure\n\nThe Client Validation Document is organised by category of finding. Each category has 3–8 findings; total document is typically 12–25 findings across categories.\n\n### Section 1: Executive Briefing\n\n**Length:** 1 page.\n\n**Content:**\n\n- Purpose of this document\n- How to read it (the ACCEPT \u002F REJECT \u002F EDIT \u002F DEFER framework)\n- What happens after the client responds (Part 6 v2 re-runs governed by the Decision Matrix)\n- Decision deadline (typically 7–14 days)\n\n### Section 2: Findings — by category\n\nEach category contains its findings as structured blocks. Categories:\n\n#### A. Business & SBU Findings (from 3.1)\n\nFindings about the business reality — SBU separation, unit economics, value chain, growth levers, constraints, risks. Typically 3–5 findings.\n\n#### B. Audience & Segmentation Findings (from 3.2 + 4.3)\n\nFindings about target groups, persona priority, decision-making units, MQL\u002FSQL definitions. Typically 3–5 findings.\n\n#### C. Positioning & Communications Findings (from 3.3)\n\nThe chosen positioning, messaging pillars, tone-of-voice, don't-say rules, sensitive-topic handling. Typically 3–5 findings.\n\n#### D. Channel & Budget Findings (from 3.4)\n\nChannel selections, in-market vs out-market split, budget allocation, channel sequencing. Typically 2–4 findings.\n\n#### E. Competitive Findings (from 4.1 + 4.2)\n\nCompetitor list, competitive positioning, Three-Question outputs (do well \u002F do poorly \u002F not doing). Typically 2–4 findings.\n\n#### F. Market & Customer Findings (from 4.3 + 4.4)\n\nMarket sizing, customer behaviour patterns, demand signals. Typically 2–4 findings.\n\n### Section 3: Open Questions\n\nQuestions that the unbiased research could not resolve and need client input. The client provides answers here.\n\n### Section 4: Response Mechanism\n\nHow the client returns their responses (typically a structured response file or a meeting walkthrough).\n\n## Finding Block Format\n\nEach finding follows this exact structure:\n\n```markdown\n### Finding {ID}: {Short title}\n\n**Category:** {A\u002FB\u002FC\u002FD\u002FE\u002FF}\n**Source:** {Document and step references — e.g., \"3.1 Step 4, 4.1 Three-Question Output\"}\n**Materiality:** {High \u002F Medium \u002F Low}\n\n**Finding:**\n{2–4 sentences stating the finding from the unbiased research}\n\n**Evidence:**\n- {Cited source 1 with specific data point}\n- {Cited source 2}\n- {Cited source 3}\n\n**Proposed implication if accepted:**\n{1–3 sentences on what this means for the strategy if the client accepts}\n\n**Client response:**\n\n- [ ] ACCEPT — finding is correct as stated\n- [ ] REJECT — finding is wrong; correction below\n- [ ] EDIT — finding is partially correct; amended version below\n- [ ] DEFER — needs further investigation; reason below\n\n**If REJECT or EDIT, client correction:**\n{Client fills in: what the correct finding is, with their evidence}\n\n**If DEFER, reason and follow-up plan:**\n{Client fills in: what additional research \u002F data is needed, who is accountable, deadline}\n```\n\n## Materiality Classification\n\nEach finding gets a Materiality rating that indicates how consequential the response is:\n\n- **High** — accepting vs rejecting would meaningfully change the channel mix, budget, positioning, or audience priority. Triggers v2 re-runs per Decision Matrix.\n- **Medium** — accepting vs rejecting would change tactical execution but not strategic direction. May or may not trigger re-runs.\n- **Low** — accepting vs rejecting changes phrasing or examples but not substance. No re-run triggered.\n\nThe client should focus most attention on High materiality findings; Medium and Low are still presented for completeness.\n\n## Response Categorisation for the Decision Matrix\n\nAfter the client provides responses, the responses are categorised into Decision Matrix triggers:\n\n| Client decision pattern | Decision Matrix trigger |\n|---|---|\n| Any competitor finding REJECTED or EDITED with new competitors | `competitors_changed` |\n| Any market sizing finding REJECTED or EDITED | `target_market_changed` |\n| Any segmentation finding REJECTED or EDITED with persona changes | `audiences_changed` |\n| Any positioning finding REJECTED or EDITED | `positioning_changed` |\n| Any budget \u002F scope finding REJECTED or EDITED | `budget_or_scope_changed` |\n| Any pricing or offering finding REJECTED or EDITED | `pricing_or_offering_changed` |\n| Any unit economics finding REJECTED or EDITED | `unit_economics_changed` |\n| Only Low-materiality EDITs \u002F minor wording corrections | `minor_corrections_only` |\n\nThe skill compiles the trigger list and runs:\n\n```bash\npython ${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fengagement-state.py decision-matrix \\\n  --brand {slug} --id {id} \\\n  --triggers \"{comma-separated-trigger-list}\"\n```\n\nThe output then feeds the Part 6 v2 re-run plan.\n\n## Production Steps\n\n1. **Verify pre-conditions** — Parts 2, 3, 4 completed.\n\n2. **Read the v1 source documents:**\n   - `part-03-four-core-documents\u002Fv1\u002F3.1-business-and-sbu-analysis.md`\n   - `part-03-four-core-documents\u002Fv1\u002F3.2-segmentation-framework.md`\n   - `part-03-four-core-documents\u002Fv1\u002F3.3-brand-positioning-and-communications.md`\n   - `part-03-four-core-documents\u002Fv1\u002F3.4-dmflow.md`\n   - `part-04-competitive-customer-market\u002Fv1\u002F4.1-competitor-ad-analysis.md`\n   - `part-04-competitive-customer-market\u002Fv1\u002F4.2-competitor-positioning.md`\n   - `part-04-competitive-customer-market\u002Fv1\u002F4.3-customer-analysis.md`\n   - `part-04-competitive-customer-market\u002Fv1\u002F4.4-market-analysis.md`\n\n3. **Extract 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.\n\n4. **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.\n\n5. **Add Open Questions section** drawn from the \"Open questions\" sections of each source document.\n\n6. **Add response mechanism section** — instruct the client how to return responses (recommended: produce a paired `client-validation-responses.json` file alongside the document).\n\n7. **Save the document** to:\n   ```\n   engagements\u002F{id}\u002Fpart-05-client-validation\u002Fclient-validation-document.md\n   ```\n\n8. **Generate the response template:**\n   ```\n   engagements\u002F{id}\u002Fpart-05-client-validation\u002Fclient-validation-responses.template.json\n   ```\n   Containing one entry per finding with empty decision\u002Fcorrection fields.\n\n9. **Mark Part 5 as `awaiting_input`** in `_engagement.json` (not `completed` — Part 5 is only complete when the client responses are recorded).\n\n10. **Brief the user** on the document, the response mechanism, and the typical 7–14 day decision window.\n\n## Recording Client Responses\n\nWhen the client returns responses (filled-in JSON file or verbal walkthrough captured in a meeting):\n\n1. Save the populated response file to:\n   ```\n   engagements\u002F{id}\u002Fpart-05-client-validation\u002Fclient-validation-responses.json\n   ```\n\n2. Run `engagement-state.py decision-matrix --validation-file \u003Cpath>` to determine the v2 re-run plan.\n\n3. Mark Part 5 as `completed`.\n\n4. Advance to Part 6 (v2 re-runs).\n\n## Quality Discipline\n\n1. **Plain client language.** No \"MQL\u002FSQL pipeline funnel architecture\" jargon. Translate to \"the way leads move from interested to ready-to-buy.\"\n2. **Each finding stands alone.** Client should not need to consult the source docs to understand the finding.\n3. **Evidence is cited explicitly.** Vague claims (\"market data shows...\") are unacceptable. Cite the specific source with the data point.\n4. **Materiality is honest.** Don't downgrade an uncomfortable finding to \"Low\" to make it easier to accept.\n5. **Open Questions are real questions.** Don't fabricate questions for the sake of having an Open Questions section.\n6. **The response mechanism is structured.** Free-form client emails are hard to translate into Decision Matrix triggers; the JSON response template makes the pattern unambiguous.\n\n## Examples\n\n### Example 1: Producing the document\n\n```\nUser: We've completed Parts 2, 3, 4 for Acme. Time to prepare the Client Validation Document.\n\nSkill response:\n1. Verify pre-conditions ✓\n2. Pull findings from the 8 source documents (4 from Part 3 + 4 from Part 4) using grep first to locate each category's section, then targeted Read with offset+limit — avoid bulk-Read on all 8 files up front or you'll blow the per-skill 5K-token budget\n3. Extract 18 material findings across categories A–F:\n   - 4 in Business & SBU\n   - 3 in Audience & Segmentation\n   - 4 in Positioning & Communications\n   - 3 in Channel & Budget\n   - 2 in Competitive\n   - 2 in Market & Customer\n4. 12 are High materiality, 5 Medium, 1 Low\n5. 4 Open Questions identified from source docs\n6. Save document at engagements\u002F2026-q2\u002Fpart-05-client-validation\u002Fclient-validation-document.md (~22 pages)\n7. Save response template at engagements\u002F2026-q2\u002Fpart-05-client-validation\u002Fclient-validation-responses.template.json\n8. Mark Part 5 as awaiting_input\n9. 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.\"\n```\n\n### Example 2: Recording client responses\n\n```\nUser: 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.\n\nSkill response:\n1. Read the populated client-validation-responses.json\n2. Categorise responses: 16 ACCEPT, 1 REJECT (positioning), 1 EDIT (competitor list)\n3. Determine triggers: positioning_changed + competitors_changed\n4. Run engagement-state.py decision-matrix --triggers \"positioning_changed,competitors_changed\"\n5. Output: triggered re-runs = 3.1, 3.2, 3.3, 3.4, 4.1, 4.2 (the union of both triggers' re-run sets)\n6. Estimate cost: ~85K tokens\n7. Mark Part 5 completed\n8. 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.\"\n```\n\n## Related skills\n\n- `engagement-workflow` — orchestrates the 12-Part flow\n- `four-core-documents` — produced the v1 docs being validated; will produce v2 re-runs after Part 5\n- Existing `competitor-analysis`, `audience-intelligence`, `market-intelligence` skills produced the Part 4 docs\n\n## Related references\n\n- [engagement-flow-methodology.md](..\u002Fcontext-engine\u002Fengagement-flow-methodology.md) — Part 5 in context\n- [decision-matrix-rerun.md](..\u002Fcontext-engine\u002Fdecision-matrix-rerun.md) — how responses translate to re-runs\n- [two-views-model.md](..\u002Fcontext-engine\u002Ftwo-views-model.md) — v1 + v2 architecture\n- [stone-vs-opinion.md](..\u002Fcontext-engine\u002Fstone-vs-opinion.md) — confidence tagging context\n","# \u002Fdigital-marketing-pro:client-validation-document — Part 5: The One True Stop\n\nThis 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\u002Freject\u002Fedit decisions.\n\n## Context efficiency\n\nHeavy skill. **Grep before Read** any referenced file, then `Read` only matched ranges with `offset` + `limit`. List `${CLAUDE_PLUGIN_DATA}\u002F\u003Cbrand>\u002F` before opening files. On re-invocation mid-session, skip files already in context.\n\nThis is the **one true stop** in the 12-Part flow. Nothing in Parts 6+ proceeds until this is signed off.\n\n## What this document is\n\nThe 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:\n\n- The finding itself\n- Evidence \u002F sources\n- Proposed implication if accepted\n- Three response options for the client: ACCEPT \u002F REJECT \u002F EDIT \u002F DEFER\n- (For REJECT or EDIT) — the client provides their corrected version and the rationale\n\nThe client's responses then feed the Decision Matrix in Part 6 to determine which v2 re-runs are needed.\n\n## What this document is NOT\n\n- **Not a Growth Plan.** This is research findings, not strategic recommendations dressed up. The Growth Plan is Part 8.\n- **Not exhaustive.** It includes only findings that have material strategic implications. Detail belongs in the source documents.\n- **Not a slide deck.** It is a written document the client reads carefully and responds to. Slides do not capture the rigor required.\n- **Not optional.** Every engagement runs Part 5. No shortcut to Part 6 without it.\n\n## Pre-conditions\n\nBefore running this skill:\n\n1. Parts 2, 3, 4 must be completed (or substantially complete with explicit acknowledgment that some research continues)\n2. The engagement state file `_engagement.json` must show Parts 3 and 4 as `completed`\n3. The Living Project Instruction File should be up to date with the v1 strategic facts\n\nIf pre-conditions fail, do NOT produce output. Instruct the user on what is missing.\n\n## Document Structure\n\nThe Client Validation Document is organised by category of finding. Each category has 3–8 findings; total document is typically 12–25 findings across categories.\n\n### Section 1: Executive Briefing\n\n**Length:** 1 page.\n\n**Content:**\n\n- Purpose of this document\n- How to read it (the ACCEPT \u002F REJECT \u002F EDIT \u002F DEFER framework)\n- What happens after the client responds (Part 6 v2 re-runs governed by the Decision Matrix)\n- Decision deadline (typically 7–14 days)\n\n### Section 2: Findings — by category\n\nEach category contains its findings as structured blocks. Categories:\n\n#### A. Business & SBU Findings (from 3.1)\n\nFindings about the business reality — SBU separation, unit economics, value chain, growth levers, constraints, risks. Typically 3–5 findings.\n\n#### B. Audience & Segmentation Findings (from 3.2 + 4.3)\n\nFindings about target groups, persona priority, decision-making units, MQL\u002FSQL definitions. Typically 3–5 findings.\n\n#### C. Positioning & Communications Findings (from 3.3)\n\nThe chosen positioning, messaging pillars, tone-of-voice, don't-say rules, sensitive-topic handling. Typically 3–5 findings.\n\n#### D. Channel & Budget Findings (from 3.4)\n\nChannel selections, in-market vs out-market split, budget allocation, channel sequencing. Typically 2–4 findings.\n\n#### E. Competitive Findings (from 4.1 + 4.2)\n\nCompetitor list, competitive positioning, Three-Question outputs (do well \u002F do poorly \u002F not doing). Typically 2–4 findings.\n\n#### F. Market & Customer Findings (from 4.3 + 4.4)\n\nMarket sizing, customer behaviour patterns, demand signals. Typically 2–4 findings.\n\n### Section 3: Open Questions\n\nQuestions that the unbiased research could not resolve and need client input. The client provides answers here.\n\n### Section 4: Response Mechanism\n\nHow the client returns their responses (typically a structured response file or a meeting walkthrough).\n\n## Finding Block Format\n\nEach finding follows this exact structure:\n\n```markdown\n### Finding {ID}: {Short title}\n\n**Category:** {A\u002FB\u002FC\u002FD\u002FE\u002FF}\n**Source:** {Document and step references — e.g., \"3.1 Step 4, 4.1 Three-Question Output\"}\n**Materiality:** {High \u002F Medium \u002F Low}\n\n**Finding:**\n{2–4 sentences stating the finding from the unbiased research}\n\n**Evidence:**\n- {Cited source 1 with specific data point}\n- {Cited source 2}\n- {Cited source 3}\n\n**Proposed implication if accepted:**\n{1–3 sentences on what this means for the strategy if the client accepts}\n\n**Client response:**\n\n- [ ] ACCEPT — finding is correct as stated\n- [ ] REJECT — finding is wrong; correction below\n- [ ] EDIT — finding is partially correct; amended version below\n- [ ] DEFER — needs further investigation; reason below\n\n**If REJECT or EDIT, client correction:**\n{Client fills in: what the correct finding is, with their evidence}\n\n**If DEFER, reason and follow-up plan:**\n{Client fills in: what additional research \u002F data is needed, who is accountable, deadline}\n```\n\n## Materiality Classification\n\nEach finding gets a Materiality rating that indicates how consequential the response is:\n\n- **High** — accepting vs rejecting would meaningfully change the channel mix, budget, positioning, or audience priority. Triggers v2 re-runs per Decision Matrix.\n- **Medium** — accepting vs rejecting would change tactical execution but not strategic direction. May or may not trigger re-runs.\n- **Low** — accepting vs rejecting changes phrasing or examples but not substance. No re-run triggered.\n\nThe client should focus most attention on High materiality findings; Medium and Low are still presented for completeness.\n\n## Response Categorisation for the Decision Matrix\n\nAfter the client provides responses, the responses are categorised into Decision Matrix triggers:\n\n| Client decision pattern | Decision Matrix trigger |\n|---|---|\n| Any competitor finding REJECTED or EDITED with new competitors | `competitors_changed` |\n| Any market sizing finding REJECTED or EDITED | `target_market_changed` |\n| Any segmentation finding REJECTED or EDITED with persona changes | `audiences_changed` |\n| Any positioning finding REJECTED or EDITED | `positioning_changed` |\n| Any budget \u002F scope finding REJECTED or EDITED | `budget_or_scope_changed` |\n| Any pricing or offering finding REJECTED or EDITED | `pricing_or_offering_changed` |\n| Any unit economics finding REJECTED or EDITED | `unit_economics_changed` |\n| Only Low-materiality EDITs \u002F minor wording corrections | `minor_corrections_only` |\n\nThe skill compiles the trigger list and runs:\n\n```bash\npython ${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fengagement-state.py decision-matrix \\\n  --brand {slug} --id {id} \\\n  --triggers \"{comma-separated-trigger-list}\"\n```\n\nThe output then feeds the Part 6 v2 re-run plan.\n\n## Production Steps\n\n1. **Verify pre-conditions** — Parts 2, 3, 4 completed.\n\n2. **Read the v1 source documents:**\n   - `part-03-four-core-documents\u002Fv1\u002F3.1-business-and-sbu-analysis.md`\n   - `part-03-four-core-documents\u002Fv1\u002F3.2-segmentation-framework.md`\n   - `part-03-four-core-documents\u002Fv1\u002F3.3-brand-positioning-and-communications.md`\n   - `part-03-four-core-documents\u002Fv1\u002F3.4-dmflow.md`\n   - `part-04-competitive-customer-market\u002Fv1\u002F4.1-competitor-ad-analysis.md`\n   - `part-04-competitive-customer-market\u002Fv1\u002F4.2-competitor-positioning.md`\n   - `part-04-competitive-customer-market\u002Fv1\u002F4.3-customer-analysis.md`\n   - `part-04-competitive-customer-market\u002Fv1\u002F4.4-market-analysis.md`\n\n3. **Extract 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.\n\n4. **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.\n\n5. **Add Open Questions section** drawn from the \"Open questions\" sections of each source document.\n\n6. **Add response mechanism section** — instruct the client how to return responses (recommended: produce a paired `client-validation-responses.json` file alongside the document).\n\n7. **Save the document** to:\n   ```\n   engagements\u002F{id}\u002Fpart-05-client-validation\u002Fclient-validation-document.md\n   ```\n\n8. **Generate the response template:**\n   ```\n   engagements\u002F{id}\u002Fpart-05-client-validation\u002Fclient-validation-responses.template.json\n   ```\n   Containing one entry per finding with empty decision\u002Fcorrection fields.\n\n9. **Mark Part 5 as `awaiting_input`** in `_engagement.json` (not `completed` — Part 5 is only complete when the client responses are recorded).\n\n10. **Brief the user** on the document, the response mechanism, and the typical 7–14 day decision window.\n\n## Recording Client Responses\n\nWhen the client returns responses (filled-in JSON file or verbal walkthrough captured in a meeting):\n\n1. Save the populated response file to:\n   ```\n   engagements\u002F{id}\u002Fpart-05-client-validation\u002Fclient-validation-responses.json\n   ```\n\n2. Run `engagement-state.py decision-matrix --validation-file \u003Cpath>` to determine the v2 re-run plan.\n\n3. Mark Part 5 as `completed`.\n\n4. Advance to Part 6 (v2 re-runs).\n\n## Quality Discipline\n\n1. **Plain client language.** No \"MQL\u002FSQL pipeline funnel architecture\" jargon. Translate to \"the way leads move from interested to ready-to-buy.\"\n2. **Each finding stands alone.** Client should not need to consult the source docs to understand the finding.\n3. **Evidence is cited explicitly.** Vague claims (\"market data shows...\") are unacceptable. Cite the specific source with the data point.\n4. **Materiality is honest.** Don't downgrade an uncomfortable finding to \"Low\" to make it easier to accept.\n5. **Open Questions are real questions.** Don't fabricate questions for the sake of having an Open Questions section.\n6. **The response mechanism is structured.** Free-form client emails are hard to translate into Decision Matrix triggers; the JSON response template makes the pattern unambiguous.\n\n## Examples\n\n### Example 1: Producing the document\n\n```\nUser: We've completed Parts 2, 3, 4 for Acme. Time to prepare the Client Validation Document.\n\nSkill response:\n1. Verify pre-conditions ✓\n2. Pull findings from the 8 source documents (4 from Part 3 + 4 from Part 4) using grep first to locate each category's section, then targeted Read with offset+limit — avoid bulk-Read on all 8 files up front or you'll blow the per-skill 5K-token budget\n3. Extract 18 material findings across categories A–F:\n   - 4 in Business & SBU\n   - 3 in Audience & Segmentation\n   - 4 in Positioning & Communications\n   - 3 in Channel & Budget\n   - 2 in Competitive\n   - 2 in Market & Customer\n4. 12 are High materiality, 5 Medium, 1 Low\n5. 4 Open Questions identified from source docs\n6. Save document at engagements\u002F2026-q2\u002Fpart-05-client-validation\u002Fclient-validation-document.md (~22 pages)\n7. Save response template at engagements\u002F2026-q2\u002Fpart-05-client-validation\u002Fclient-validation-responses.template.json\n8. Mark Part 5 as awaiting_input\n9. 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.\"\n```\n\n### Example 2: Recording client responses\n\n```\nUser: 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.\n\nSkill response:\n1. Read the populated client-validation-responses.json\n2. Categorise responses: 16 ACCEPT, 1 REJECT (positioning), 1 EDIT (competitor list)\n3. Determine triggers: positioning_changed + competitors_changed\n4. Run engagement-state.py decision-matrix --triggers \"positioning_changed,competitors_changed\"\n5. Output: triggered re-runs = 3.1, 3.2, 3.3, 3.4, 4.1, 4.2 (the union of both triggers' re-run sets)\n6. Estimate cost: ~85K tokens\n7. Mark Part 5 completed\n8. 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.\"\n```\n\n## Related skills\n\n- `engagement-workflow` — orchestrates the 12-Part flow\n- `four-core-documents` — produced the v1 docs being validated; will produce v2 re-runs after Part 5\n- Existing `competitor-analysis`, `audience-intelligence`, `market-intelligence` skills produced the Part 4 docs\n\n## Related references\n\n- [engagement-flow-methodology.md](..\u002Fcontext-engine\u002Fengagement-flow-methodology.md) — Part 5 in context\n- [decision-matrix-rerun.md](..\u002Fcontext-engine\u002Fdecision-matrix-rerun.md) — how responses translate to re-runs\n- [two-views-model.md](..\u002Fcontext-engine\u002Ftwo-views-model.md) — v1 + v2 architecture\n- [stone-vs-opinion.md](..\u002Fcontext-engine\u002Fstone-vs-opinion.md) — confidence tagging context\n",{"name":5,"triggers":24,"description":7,"allowed-tools":31,"user-invocable":32,"engagement-part":33,"view-preference":34},[25,26,27,28,29,30],"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","Read Write Edit Bash Glob Grep",true,"5","v1-only","main","4fd50b1281e8cd978866b6b4556242605cabf708","2_KNOWLEDGE\u002Fframeworks\u002Fdigital-marketing-pro\u002Fskills\u002Fclient-validation-document",1,"https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FSEOSONA-OS","https:\u002F\u002Fseosona-os.vercel.app","https:\u002F\u002Fgithub.com\u002FLongLeo287","https:\u002F\u002Fwww.facebook.com\u002FResourceRookie2023","2026-10-09 15:14:13",{"source":8,"skillName":5,"commands":45,"prompt":55,"zipAvailable":32},[46,49,52],{"tool":47,"command":48},"npx","npx skills add LongLeo287\u002FSEOSONA-OS --skill client-validation-document",{"tool":50,"command":51},"bunx","bunx skills add LongLeo287\u002FSEOSONA-OS --skill client-validation-document",{"tool":53,"command":54},"pnpm","pnpm dlx skills add LongLeo287\u002FSEOSONA-OS --skill client-validation-document","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FSEOSONA-OS\u002Fblob\u002Fmain\u002F2_KNOWLEDGE\u002Fframeworks\u002Fdigital-marketing-pro\u002Fskills\u002Fclient-validation-document\u002FSKILL.md",[],[58,65,72,79,86,93],{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":19},"01M75F0T3V3W7JQQ05X26NNN2T","web_crawler_katana","High-speed web crawling using Katana patterns for deep site mapping, URL discovery, and content extraction.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FSEOSONA-OS\u002Fblob\u002Fmain\u002F2_KNOWLEDGE\u002Fskills\u002Fseo_technical\u002Fweb_crawler_katana\u002FSKILL.md",[],[],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":19},"01M75F0Q2QJXDGAFKC7D84GT88","server_log_analyzer","Analyzes Nginx\u002FApache server logs to identify Googlebot crawl patterns, errors, and performance bottlenecks.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FSEOSONA-OS\u002Fblob\u002Fmain\u002F2_KNOWLEDGE\u002Fskills\u002Fseo_technical\u002Fserver_log_analyzer\u002FSKILL.md",[],[],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":19},"01M75F0KZP6D8R8XPN2YT35BAJ","schema_markup_generator","Auto-generates JSON-LD structured data for any page type (Article, Product, FAQ, LocalBusiness, etc.).","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FSEOSONA-OS\u002Fblob\u002Fmain\u002F2_KNOWLEDGE\u002Fskills\u002Fseo_technical\u002Fschema_markup_generator\u002FSKILL.md",[],[],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":19},"01M75F0G3KX4Y86AXJXTKXVEVA","internal_linking_optimizer","Analyzes and optimizes the internal link graph of a website for SEO authority distribution.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FSEOSONA-OS\u002Fblob\u002Fmain\u002F2_KNOWLEDGE\u002Fskills\u002Fseo_technical\u002Finternal_linking_optimizer\u002FSKILL.md",[],[],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":19},"01M75F0CS1RYX4YPJC7N6RAAQJ","google_trends_analyzer","Detects trending topics and seasonal patterns using Google Trends data for content planning and keyword strategy.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FSEOSONA-OS\u002Fblob\u002Fmain\u002F2_KNOWLEDGE\u002Fskills\u002Fseo_technical\u002Fgoogle_trends_analyzer\u002FSKILL.md",[],[],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":19},"01M75F0ASMQ1GKPFX82D19SRTN","brand_context_analyzer","Tracks brand mentions, sentiment, and online reputation across web sources.","https:\u002F\u002Fgithub.com\u002FLongLeo287\u002FSEOSONA-OS\u002Fblob\u002Fmain\u002F2_KNOWLEDGE\u002Fskills\u002Fseo_technical\u002Fbrand_context_analyzer\u002FSKILL.md",[],[]]