| name | kai-proof-builder |
| description | Build and maintain a provenance-clean proof library — inventory every real proof asset (analytics, reviews, permitted testimonials, case studies, press, certifications), categorize it, rewrite each cleared item in 3 lengths, fuse top assets with narrative, and gate everything through FTC testimonial rules before it can ship. Use when "proof library", "gather our proof", "authority builder", "collect testimonials", "social proof assets", "proof points for the sales page", "what results can we claim", or any request to assemble evidence for marketing claims. NEVER invents proof — missing proof is reported as a gap. |
Build a proof library where every asset has a source, a permission status, and a readiness verdict. The rule that makes this skill different from the viral "authority builder" prompt: proof is collected, never composed. If it can't be traced to a real source, it doesn't exist.
Phase 0: Load Product Context
Check if MARKETING.md exists in the project root (same directory as CLAUDE.md, README.md, package.json).
If it exists: Read it — skip product discovery questions. It has the product name, ICP, value prop, monetization, brand voice, current channels, and competitive landscape.
If it does NOT exist: Auto-explore the codebase to create it in the project root (next to CLAUDE.md). Do NOT ask the user what the product is. Read CLAUDE.md, README.md, PROJECT.md, package.json, landing pages, and any project files. Search for email/ad/analytics config. Then create MARKETING.md using the template from /kai-email-system. Present draft to user for confirmation.
Also load before starting:
harness/references/audit-data-provenance.md (data modes, source tiers, hard rules)knowledge/people/alex-hormozi-knowledge.md (Value Equation and proof mechanics — Phase 2 depends on it)memory/lessons.md (unsourced-claim history)
Phase 1: Proof Inventory Sweep
Enumerate real proof sources only. Ask the user which of these exist and where; check connected tools and the repo before asking.
| Source class | Where to look | Tier (per audit-data-provenance.md) |
|---|
| Analytics exports | GA4/GSC exports, dashboards, data/ files the client provides | 1 (connected) or 3 (user-provided) |
| Review platforms | Google reviews, G2, Trustpilot, app stores — captured via collector or screenshot | 1-2 |
| Testimonials | Emails, DMs, survey responses, call transcripts — written permission required to use with a name | 3 |
| Case studies | /kai-case-study output in workspace/ — hand off there if none exist yet | 3 |
| Press mentions | Live URLs, archived captures | 2 |
| Certifications / credentials | Certificates, license numbers, partner-program listings | 2-3 |
| Usage stats | The client's own systems: billing, CRM, product database queries they run | 1 or 3 |
Run the collector for anything public or quantitative (review counts, rankings, traffic, visible press):
python -m scripts.audit.collect --url https://<domain> --mode <sales_external|onboarding_connected> --workflow proof-builder --out workspace/proof-library/_data
Declare the mode before writing anything (sales_external by default; onboarding_connected only with confirmed access; internal_demo must be labeled sample data everywhere it appears). Read kai-data.json from the output folder.
Every item gets a provenance row in workspace/proof-library/_provenance.md:
| ID | Asset (one line) | Source class | Source location (file/URL/system + date) | Source tier | Permission status | Verification method | Readiness |
|---|
| P-001 | "Organic clicks up 42% in 90 days" | Analytics export | _data/kai-data.json §gsc, 2026-07-10 | 1 | n/a (own data) | Collector output | pending |
| P-002 | Testimonial — Jane D. | Testimonial | email 2026-05-02, forwarded by client | 3 | needs-permission | Written email on file? → verify | pending |
Hard rules for this phase:
- A quote without a locatable source (file, URL, transcript timestamp, email date) is not inventory — it is a gap.
- A number the user "remembers" is Tier 4 until they produce the export. Record it as a gap with a note of who can supply it.
- NEVER fill thin categories with plausible-sounding entries. Log every hole in
workspace/proof-library/_data-gaps.md with: what's missing, why it matters, who/what can supply it.
- Missing proof is itself a finding. "No usable transformation proof exists — recommend running
/kai-case-study with the two clients named in the CRM export" is a valid, useful output of this skill.
Phase 2: Categorize (Value Equation mapping)
Ground categories in what knowledge/people/alex-hormozi-knowledge.md actually says. Proof's job in the Value Equation is raising Perceived Likelihood of Achievement — the prospect's belief that they specifically will get the result ("not just 'this works' but 'this will work FOR ME'"). Third-party validation (reviews, case studies) is more credible than first-person claims. Sort every provenance row into one:
| Category | What it is | Value Equation lever |
|---|
| Quantitative | Measured numbers: metrics, review counts, usage stats | Perceived Likelihood — specific numbers beat adjectives |
| Qualitative | Testimonials and reviews in the customer's own words | Perceived Likelihood via similarity — prospect sees someone like them |
| Transformation | Before → after arcs (case studies, documented journeys) | Dream Outcome made concrete + Perceived Likelihood; Hormozi frames dream outcome as status elevation — how others will perceive the achievement |
| Authority | Credentials, certifications, press, expert standing | Perceived Likelihood via source credibility. FTC note: anyone presented as an expert must actually hold the relevant qualifications |
Two more Hormozi mechanics to apply while sorting:
- "Proof over claims." In the Give-Away-Everything model, demonstrated work is itself proof of competence — published frameworks, teardowns, and free tools belong in the Authority column when they exist. Don't claim expertise the library can demonstrate.
- The testimonial flywheel: premium clients → better results → testimonials that justify the premium (the virtuous cycle from the pricing philosophy section). Transformation assets are the highest-value category; if it's empty, say so in
_data-gaps.md and recommend the /kai-case-study pipeline.
Guarantees and risk reversal also raise Perceived Likelihood, but they are offer mechanics, not proof assets — hand off to /kai-offer-builder.
Phase 3: Rewrite in 3 Lengths (numbers and quotes frozen)
For each row marked Tier 1-3 with permission resolved, produce three renderings:
- Stat line (≤ 20 words) — for ads, headers, social proof bars
- Short blurb (40-80 words) — for landing page sections, email, sales decks
- Full story (200-400 words) — for case-study callouts, long-form pages
Non-negotiable rewrite rules:
- No number changes. Not rounded up, not "nearly," not annualized, not extrapolated. The number in the rendering must equal the number in the source.
- Direct quotes stay verbatim and attributed. Ellipses may shorten a quote only if the meaning is unchanged; never splice two quotes into one. Attribution matches the permission status (named / first-name / anonymized).
- No superlatives ("best," "#1," "fastest") unless a Tier 1-2 source substantiates that exact comparative claim.
- Each rendering carries its provenance ID in an HTML comment:
<!-- proof: P-001 -->.
Write to workspace/proof-library/<category>/<id>-<slug>.md (all three lengths in one file). Single-piece polish beyond this is /kai-write's job; distribution across channels is /kai-repurpose's.
Phase 4: Proof-Story Fusion (top assets only)
Pick the 3-5 strongest cleared assets (prefer Transformation and Quantitative with named permission). Pair each with narrative — logic + emotion, the case-study arc from /kai-case-study: before state in the customer's words → turning point → measured after state.
Fusion integrity rule — mark every sentence in the story as one of:
[S] sourced — traceable to the provenance row, transcript, or export[C] connective tissue — transitions and framing the writer added
[C] sentences may set scene and connect facts. They may NOT add events, feelings the customer never expressed, dialogue, or implied metrics. If the story only works because of an invented detail, the story is not ready — log what's missing (usually: a follow-up question for the customer) in _data-gaps.md.
Write to workspace/proof-library/fusion/<id>-story.md with the [S]/[C] markup in a review copy and a clean copy below it.
Phase 5: Compliance Gate (FTC testimonial/endorsement rules)
Load harness/references/advertising-compliance.md (§1 Endorsement & Disclosure Rules, §2 Truth in Advertising & Substantiation, §10 Fake Reviews Rule) and harness/references/creator-disclosure.md. Check every asset:
- Genuine and current — testimonials must reflect the endorser's genuine, current experience. Stale results (product changed, customer churned) get flagged for re-verification.
- Typical results — if a featured result is atypical, the rendering must disclose what typical consumers achieve. "Results not typical" alone is NOT sufficient — state the typical outcome, sourced from Tier 1-3 data. If no typical-results data exists, the atypical claim is blocked, not disclaimed around.
- Material connection disclosure — payment, free product, affiliate, employment, or family relationship with any endorser must be disclosed clearly and BEFORE or alongside the endorsement, never buried (16 CFR Part 255). Per-channel disclosure formats:
harness/references/creator-disclosure.md.
- No unsubstantiated superlatives — comparative and superiority claims need real substantiation; anecdotal/testimonial evidence is never sufficient substantiation for an objective product claim.
- Fake Reviews Rule — no purchased, incentivized-without-disclosure, insider, or AI-fabricated reviews anywhere in the library. If provenance can't rule this out for a review source, the asset is blocked.
- Expert framing — any asset presenting someone as an expert requires verified qualifications in the provenance row.
Then run the standard gates on every rendered file:
python scripts/quality_gates/four_us_score.py --file <file>
python scripts/quality_gates/banned_word_check.py --file <file>
Max 2 retry cycles, fixing only the named failure. After 2 failures, escalate to a human with specifics and log the diagnosis per memory/lessons.md doctrine.
Phase 6: Publish-Readiness Ledger
Set the Readiness column in _provenance.md for every row:
| Verdict | Meaning |
|---|
cleared | Source verified, permission on file, compliance gate passed — usable by other skills |
needs-permission | Real asset, but written permission (or typical-results data, or disclosure language) is outstanding — list exactly what's needed and from whom |
blocked | Unverifiable source, failed compliance, permission refused, or fabrication risk — do not use; state why |
Rules:
- Anything not
cleared NEVER ships. Downstream skills (/kai-landing-page, /kai-social, /kai-write, /kai-brief) may only pull assets marked cleared, referenced by provenance ID.
- End with a summary block: counts per verdict, top gaps from
_data-gaps.md, and the single highest-value next action (e.g., "get written permission from the P-002 customer — strongest transformation asset in the library").
- Approval doctrine: this skill builds a library; it does not publish. Any use of a cleared asset on a live channel goes through
/kai-gate and human approval first. Permission requests to customers are drafted for the human to send — never sent autonomously.
Output
workspace/proof-library/
├── _provenance.md # Ledger: every asset, source, tier, permission, verification, readiness
├── _data-gaps.md # Missing proof, unverifiable claims, outstanding permissions — never guessed
├── _data/ # Collector output (kai-data.json) from scripts.audit.collect
├── quantitative/ # <id>-<slug>.md — 3 lengths each
├── qualitative/
├── transformation/
├── authority/
├── fusion/ # Top-asset proof stories with [S]/[C] markup
└── _quality-report.md # Gate scores, compliance checklist results, retry log
Maintenance: re-run Phase 1 quarterly or after any product/pricing change; recheck cleared testimonials for currency (Phase 5 rule 1). New wins land here first, then feed /kai-case-study and knowledge/playbooks/what-works.md.
