← Vault Index
Source: frameworks/kit-builder/03-kit-builder-golden-example.md

03 — GOLDEN EXAMPLE: Kit Builder

The golden example for the Kit Builder is the full population of existing vault kits. This file annotates patterns observed across all of them — what's universal, what varies, and what each kit type does well.


Reference Kits by Type

Standard 6-File Kits

KitFilesQC FormatGolden Example FormatWhat It Does Well
Blueprint6100-point, 90 thresholdHTML (fully populated)Content filtering (in vs. out), forbidden terms, component-level templates
Project Plan6100-point, 90 thresholdHTML (fully populated)Status progressions, 10-step ordered update sequence, deploy chain terminology
New Client Kit6Multi-phase gate (Mode 1/2/3)Structural reference (points to live repos)Mode-specific inputs, gold standard references to real repos, coordinator pattern

Extended Kits (7-9 Files)

KitFilesExtra FilesQC FormatWhat It Does Well
CPM9Instructions, separate HTML output skill100-point, 90 threshold + reject triggersDirection Gate, Unknown status, behavioral modifier, conflict resolution matrix
Master Plan9Full-document QC, input manifestMulti-phase (create + update + content quality)Immutable history rule, GPS history tracking, cross-document QC
Change Communication7Consultant methodologyPass/fail with blocking failuresTwo-beat conditional model, team filter gate, anti-pattern focus, voice authenticity
Recruiting kits (x5)9 eachConsultant methodology, process agent, split golden examplesBinary Gate 1 + 100-point Gate 2Gap protocol, extraction interview as primary source, two-track model

Narrative & Marketing Kits

KitFilesQC FormatWhat It Does Well
AOS Interactive Narrative6Checklist (no points) + mandatory copy QC passHTML (fully populated)7-decision intake, mechanism naming, interactive emotional design, CTA versioning
Standard Interactive Narrative5Checklist (no points)HTML referenceSimplified version of AOS narrative — same patterns, lighter documentation
Offer Page8Interactive HTML (weighted)HTML (fully populated)13-section fixed architecture, pre-build validation gate, external reference file dependencies

Lightweight Kits (2-4 Files)

KitFilesQC FormatWhat It Does Well
Client Email28-point checklist with ship criteriaGolden examples in client repo (not in kit)Menu-based assembly (not rigid template), AI tell scan, comparison check against prior emails
Session Recap46-point checklist with ship criteriaGolden examples in client repoDual output (email + Relay app extraction), owner taxonomy, date-from-filename rule

Universal Patterns (Present in Every Kit)

These patterns appear in every kit regardless of type or size. The kit builder must include all of them:

  1. Start-here defines scope AND anti-scope. Every kit says what it does AND what it does not do.
  2. Terminology locks words. Every kit has at minimum: terms that are used (with precise definitions) and terms that are forbidden (with why).
  3. Output skill is standalone-readable. Restates scope and inputs — never says "see file 01." Someone reading only the output skill can produce the deliverable.
  4. Quality checks are specific and testable. "Zero internal jargon: no constraint, CPM, upstream, downstream, GPS, Mode" — not "Appropriate language."
  5. Golden example is never a template. If it has {{PLACEHOLDER}} tags, it belongs in the output skill. File 03 is a finished deliverable or a structural reference to one.
  6. Content rules are numbered. Not prose paragraphs — numbered, enforceable rules that can be checked one by one.
  7. Delivery/ship checklist exists. Every kit has a final gate before the output is presented — either in the output skill or the quality file.

Patterns That Vary (Kit Builder Must Decide)

These patterns appear in some kits but not all. The kit builder must determine which apply:

PatternWhen to IncludeExamples
Content filtering (in vs. out)When the kit transforms one document into anotherBlueprint (project plan → client dashboard), CPM (transcripts → diagnostic)
Forbidden termsWhen the output has a different audience than the source materialBlueprint (no internal jargon), Change Communication (no AI writing patterns)
Gap protocol (binary gate before build)When missing inputs would produce a fundamentally flawed outputAll recruiting kits, Offer Page
Two-gate QC (binary + weighted)When some errors are disqualifying and others are gradedRecruiting kits (Gate 1 blocks, Gate 2 scores)
Blocking failuresWhen certain errors cannot be offset by high scores elsewhereChange Communication, Recruiting kits, Offer Page
External QC dependenciesWhen the kit's output needs voice/copy validation beyond its own checklistAOS Narrative (copy-qc.md, sentence-editor.md), Offer Page (copy-qc.md), Client Email (AI tell scan)
Consultant methodology fileWhen the kit involves facilitating a conversation, not just producing an artifactChange Communication, all Recruiting kits
Cross-document QCWhen the kit's output must stay consistent with upstream/downstream documentsMaster Plan (covers Project Plan + Blueprint too)
Split golden examplesWhen distinct production tracks existRecruiting kits (03a consultant, 03b agent)
CTA versioningWhen the same output ships with different calls-to-action over timeAOS Narrative (launch, product, evergreen versions)
Comparison checkWhen the output should be measured against the prior version sent to the same audienceClient Email, Session Recap

What Makes a Kit "Complete"

A kit is complete when every applicable item is addressed:

Core (every kit):

  1. [ ] Start-here answers: What is this? Who is it for? What format? What modes? What files? What it does NOT do?
  2. [ ] Context answers: What inputs? What validation rules? What priority when inputs conflict?
  3. [ ] Terminology answers: What terms are locked? What terms are forbidden?
  4. [ ] Golden example exists — fully populated deliverable, structural reference, or explicit placeholder awaiting first deployment
  5. [ ] Quality gate exists — format matches the kit's needs (points, pass/fail, checklist, or interactive)
  6. [ ] Output skill is standalone-readable with scope, inputs, content rules, and delivery checklist
  7. [ ] Self-improvement loop is built in — Mode 2 in start-here, failure modes in quality, change log convention

Extended (if applicable):

  1. [ ] Consultant methodology covers how to facilitate the human session
  2. [ ] Gap protocol defines what blocks the build
  3. [ ] Cross-document QC validates downstream consistency
  4. [ ] External QC dependencies are documented (which files, when to run them)
  5. [ ] Split golden examples cover each production track