00 — START HERE: Kit Builder

This is the setup and orientation document for the Kit Builder. Read this to understand what it is, what it does, what files it needs, and how to use it.

What This Is

The Kit Builder takes a finished deliverable (the golden example) and produces a complete kit around it — ready to use for repeatable production. It reverse-engineers the structure, inputs, terminology, quality gates, and production instructions from the example you give it.

This kit produces other kits. The output is a new directory under content/frameworks/ containing the numbered files appropriate for the kit type.

Kit Types in the Vault

Not all kits are the same size. The kit builder must determine which type fits:

Decision rule: Start with the 6-file standard. Add files only when the kit's complexity demands it:

• Add a separate instructions file when the workflow has multiple multi-step processes that would bloat the output skill (e.g., CPM's 6-process workflow)
• Add an input manifest when inputs are complex enough to warrant separation from context/methodology (e.g., Master Plan)
• Add a consultant methodology file when the kit involves facilitating a human session, not just producing a deliverable (e.g., Change Communication, Recruiting kits)
• Add a full-document QC when the kit's output feeds downstream documents that need cross-validation (e.g., Master Plan → Project Plan → Blueprint)
• Add split golden examples (03a/03b) when the kit has distinct production tracks (e.g., consultant process vs. agent process in Recruiting kits)
• Stay lightweight when the deliverable is simple and the production rules fit in two files (e.g., Client Email)

Three Operating Modes

Mode 1 — Build Kit from Golden Example

The primary mode. You provide:

• A finished deliverable (the golden example)
• A brief description of what it is, who it's for, and when you'd run it
• Optionally, the inputs that were used to create it

Claude reverse-engineers the kit by analyzing the golden example to extract: structure, terminology, quality patterns, content rules, and production steps.

Mode 2 — Improve Existing Kit

The self-improvement loop. After running any kit:

1. QC flags issues → update the quality checklist to catch them, update the output skill to prevent them
2. You made manual changes to the output → update the golden example to reflect the better version, update the output skill to produce it that way next time
3. The system suggests improvements (via wrap-up or QC) → review suggestions, accept the good ones, update the relevant kit files

The rule: Every manual fix should become a kit fix. If you fixed it by hand, tell the kit builder to fix the kit so you never fix it by hand again.

Mode 3 — Convert Protocol to Kit

For written procedures that aren't yet in kit format (e.g., production protocols in khb-aos/skills/, SOPs, or documented workflows). Claude reads the procedure document and produces the 6-file kit structure from it.

This mode requires more human review because protocols are often informal and may not have a golden example. You may need to run the output skill once, tweak the result, and then loop back through Mode 2 to lock it in.

What This Does NOT Do

• Does not assume all kits are 6 files (kit type determines file count — see Kit Types above)
• Does not force a QC format (point-scored, pass/fail, binary gate, interactive HTML — match the kit's needs)

• Does not produce the deliverable itself (the kit produces the production system, not the product)
• Does not decide what should be a kit (Kathryn decides when something is worth repeating)
• Does not place kits outside content/frameworks/ (all kits live there)
• Does not duplicate logic from existing kits (if a kit already handles something, the new kit should reference it, not rewrite it)
• Does not create client-specific skills (those are Mode 3 of the new-client-kit, not this)

The Self-Improvement Loop

This is the cycle that makes kits compound in quality over time:

Run kit → Produce output → QC the output
    ↓
QC passes → Ship it. Done.
    ↓
QC fails OR you make manual changes → Mode 2
    ↓
Update golden example (if output changed)
Update output skill (if process needs to change)
Update quality checklist (if QC missed something)
    ↓
Next run is better.

After every kit run, ask:

1. Did I change anything in the output by hand? → If yes, Mode 2.
2. Did QC miss something I caught? → If yes, Mode 2.
3. Is there something the kit should do that it doesn't? → If yes, Mode 2.

If the answer to all three is no, the kit is working. Move on.

File Inventory

Total: 6 files.

Relationship to Other Kits

This kit is the meta-kit. It produces the other kits. It does not replace them or modify them directly — it produces the initial file set, and Mode 2 handles ongoing improvement.

Kit Builder (Mode 1) → Produces a new kit (file count fits the type)
    ↓
You run the new kit → Produce output
    ↓
Kit Builder (Mode 2) → Improves the kit based on what you learned
    ↓
Repeat. Kit compounds.

Every kit in the vault should eventually pass through the Kit Builder — either built by it (Mode 1), converted by it (Mode 3), or improved by it (Mode 2).

File Location

advisory-os-vault/content/frameworks/kit-builder/
    00-kit-builder-start-here.md          (this file)
    01-kit-builder-context.md
    02-kit-builder-terminology.md
    03-kit-builder-golden-example.md
    04-kit-builder-quality.md
    05-kit-builder-output-skill.md