05 — OUTPUT SKILL: Knowledge Transfer

How to produce a capture document. Standalone-readable — you can run this without reading 00–02 first.

Scope

Produces: a .docx capture document — the tacit knowledge of one person/process, structured, gaps flagged, gate-passed. Audience: internal (advisor + the successor who inherits the work). Filename: - Capture .docx (the engine sets this; bump STAMP in build.py per version). Lifecycle: living — created once, updated as the successor runs it.

Required Inputs

1. Source recording/transcript — the expert narrating the work as they do it (Educate & Delegate). This is the spine. No source → no capture (see Gap Protocol, 01).
2. Prior doc (optional) — an old SOP, partial blueprint, or notes. Supplementary; the recording wins on conflict.
3. Template — engine/template.json. Use the general structure as-is, or adapt the section headings/fields to the domain (see "Adapting the template").
4. Subject + header facts — who/what is being captured, the operator, system/tools, cadence, owner.

Content Rules

1. Substantiate every line. Each entry traces to the source recording or the prior doc. If it isn't in a source, it isn't in the capture.
2. Flag, don't guess. Anything missing, unconfirmed, or empty becomes a FILL:: marker — it renders as a yellow-highlighted "Fill this out — ." Never invent a plausible value to fill a blank.
3. Capture the judgment, not just the steps. The watch-outs section is the point — the calls a successor can't guess ("this client always…", "don't close X before Y lands"). A capture that's only steps has missed the knowledge.
4. Flag live risks. A single-point-of-failure or an undocumented method that must be captured before a deadline becomes a FLAG:: RISK — (renders highlighted).
5. Alphabetize the Rules and Standing-notes lists (fast scanning for a non-expert).
6. Plain language. Write what the operator would say. No internal jargon, no AI-team names, no builder-speak.
7. Anonymize for the vault. Golden examples and any vault-visible capture use fictional names/data — never a real client, person, or account.

How To Run (Create)

1. Confirm understanding (per 00): state the subject, the source, the template. Get the go.
2. Mine the source into a content file (engine/-content.json), following the structure of engine/example-content.json:

• Fill each section only from what the source says.
• Mark gaps as FILL:: ; mark live risks as FLAG:: RISK — .

1. Generate: py engine/build.py engine/template.json engine/-content.json
2. Gate: py engine/qc.py "/ - Capture v1.docx" — must exit 0. (Gate 1 is mechanical; then run Gate 2, the judgment checklist in 04.)
3. Human review before it ships. The advisor is the final gate.

Update: edit the content file, re-run build.py. The engine is deterministic — only the section you changed moves. Then re-gate.

The Template (single source of truth)

The structure lives in engine/template.json — the engine renders from it, this skill documents it. Edit the JSON, not prose copies. The general capture structure:

Adapting the template: to fit a domain, change a section's heading/hint in the template JSON (e.g., for bookkeeping, "Rules" → "Vendor rules"). Keep the pattern — standing facts · recurring rules/sequence · judgment · exchanges · outputs. Add a section only if the domain truly needs one.

Two capture shapes — pick the template that matches (surfaced by the first production run):

• Process / method — how someone does a recurring task (a sequence + judgment, e.g. a review method). Use engine/template-process.json; the middle section is "Sequence — run in order" (ordered, not alphabetized). Example content: engine/monthly-close-review-content.json.
• Standing config — the standing facts/rules of an account or role. Use engine/template.json; the middle section is "Rules — alphabetized," and you may split it per domain (bookkeeping → "Vendor rules" + "Recurring entries"). Example content: engine/example-content.json (golden example 03).

Same five-part spine either way — only the middle section's framing changes.

Content file shape (engine/-content.json)

{
  "subject": "<subject name>",
  "header": {"Operator": "...", "System / tools": "...", "Cadence": "...", "Owner / contact": "..."},
  "set": [{"label": "Standing setup", "value": "..."}, {"label": "How the work comes in", "value": "..."}],
  "rules": ["X → Y.", "FILL:: add rules as each cycle surfaces them"],
  "watch_outs": ["This always… <judgment>.", "FLAG:: RISK — <single point of failure to capture>"],
  "exchanges": ["Send: ...", "Receive: ..."],
  "outputs": "The deliverables · what 'done' looks like."
}

• Any value may carry a FILL:: or FLAG:: marker.
• An empty/omitted section auto-renders a flagged gap (so nothing silently goes blank).

Delivery Checklist (pre-ship gate)

1. [ ] Confirmed the subject + source before running (no 10-minute wrong run).
2. [ ] Every line traces to a source — nothing invented.
3. [ ] Gaps are FILL:: flags, risks are FLAG:: flags — none left as bare brackets or blanks.
4. [ ] The watch-outs section carries real judgment, not restated steps.
5. [ ] engine/qc.py exited 0 (Gate 1).
6. [ ] Gate 2 (judgment checklist, 04) passed — tone plain, jargon stripped, anonymized if vault-visible.
7. [ ] First run was not interrupted mid-build — let it finish, then fix the kit, not just the output.
8. [ ] Advisor reviewed. She is the final gate, not the QC pass.

Self-Improvement

If you changed the output by hand → update 03-golden-example.docx (regenerate) + this skill. If QC missed something → add the check to engine/qc.py and 04. If a new term needs locking → 02. Every hand-fix becomes a kit-fix so it never recurs.