← Vault Index
frameworks / kit-1on1-recap / 05-1on1-recap-output-skill.md
Source: frameworks/kit-1on1-recap/05-1on1-recap-output-skill.md

05 — OUTPUT SKILL: 1:1 Recap Workflow

Scope

Produces: Gmail draft (recap email) + .md file (full personal notes) + Gmail draft (prep email for next session) Consumer: Kathryn (sends the email, keeps the .md as private reference) Lifecycle: Runs after every paid 1:1 session that isn't AOS DFY or TPC mastermind group

Required Inputs

  1. Session transcript — .txt or .vtt. Blocking — do not proceed without it.
  2. Member reference data — cyp/tpc/members/[name]/[name]-reference-data.md. Blocking — read first.
  3. Cohort reference data (TPC members) — cyp/tpc/tpc-reference-data.md. Blocking — locked cadence vocabulary lives here.
  4. Prior recap email — Gmail sent folder or session repo. Voice reference.
  5. Member file — cyp/tpc/members/[name]/[name].md. Engagement context.

RULE 0 — build from the transcript, never from memory (ported from the AOS recap-email gate, 6/17)

Every reporting line in the recap email must trace to a moment in the transcript (or to Kathryn's explicit confirmation). You may NOT write a sentence from what you "expect" happened, from build files, from the prior recap, or from a CPM. Keep the transcript open and pin each claim to it as you write. This is the failure that produced overstated recaps — "SharePoint turned on" when it was gated behind client IT; "you're over the hump" stated as a win — and it is the thing the claim gate (Step 5B) exists to stop.

The ledger (Step 5) already enforces this for commitments and decisions. Step 5.6 + Step 5B extend the same discipline to wins and status claims — the category that was previously ungated, and where overstating lives.

Step 0 — Mode 2: learn from what was actually SENT (do this FIRST)

Kathryn edits almost every recap before sending — the draft is not the final. Input #4 already pulls the prior sent recap as a voice reference; this step makes it learn from it.

  1. Pull the most recent recap Kathryn actually sent to this member/client from Gmail Sent (by their address; newest; note its session date).
  2. Pull the prior draft for that session (the prior Gmail draft to Kathryn).
  3. Diff sent vs. draft. Ignore wording/synonym tweaks (noise). Note any structural change — a section removed, an obligation softened to an offer, jargon stripped, the close changed, a personal line cut.
  4. If a structural change looks like a repeatable pattern (not a one-off taste tweak), run kit Mode 2 — update the golden-example pointer to the sent version + the relevant output-skill instruction. If unsure it will recur, don't harden it into a rule — flag it for confirmation next run.
  5. If no prior sent recap exists, or nothing structural changed, move on — don't invent a lesson.

This replaces the old "did Kathryn change anything by hand?" self-report (file 00, Mode 2): the kit now reads what landed instead of asking.

Structural principle

This kit treats writing as a two-phase act: extract first, compose second. Steps 1–5 produce structured artifacts (transcript notes, calendar facts, the Commitments / Decisions / Specifics Ledger). Steps 6–8 compose prose that draws only from those artifacts. Every assertion in the email must trace to a row in the ledger or a value in reference data — never to model judgment at the sentence level.

When errors surface in QC (Step 7), the fix is upstream: a missing ledger row, a stale reference data entry, a wrong cadence vocabulary lookup. Don't patch the prose; fix the input that produced the prose.

Step 0.5 — Triage: does this call earn the cascade? (REQUIRED — first gate)

Before running anything else, classify the session. Not every 1:1 earns the full cascade — running heavy machinery on a thin call costs Kathryn more time than it saves. (Failure this gate exists to stop: Meryl 6/19 — a 30-minute, cut-short check-in produced 10 artifacts and an hour of rework on a note she could have written in two minutes.)

Skim the transcript and classify:

  1. A short note to the member — the reschedule and any direct answers actually given, in the member's voice. No section headers, no agenda, no manufactured structure.
  2. A one-line board touch on the TPC Member Pipeline card (Last touch + any signal note). Then a 3-line .md stub (date · what it was · next session) and stop. No CPM, no claims gate over an empty ledger, no lessons, no cascade report.

The test for every output, every step: would this save Kathryn time versus writing it herself? If not, don't produce it.

Step 1: Read Reference Data

Before anything else. Every team member's correct name. Every tool. Every transcript override. Cohort reference data is part of this read — load locked cadence vocabulary (e.g., for TPC: Monday = Momentum Monday, Thursday = co-working) and forbidden-term table (file 02) into working memory. Keep open mentally for the whole run.

Also at Step 1 — detect the engagement sub-type and load the stance invariant (file 01). Which of the three is this: a TPC member 1:1, a team-and-one (member + their staff in the room), or a one-off advisory consult? Detect from the attendees + where the member lives (cyp/tpc/members/ = TPC member). Load file 01's stance invariant: Kathryn does no between-session build work in this kit; a member's build / tooling / infrastructure need routes to the signal (file 07) or a note — never a Kathryn deliverable. The stance is identical for all three sub-types and governs every composition step; the sub-type only changes the recap's shape (see file 01's shape table).

Step 2: Read the Transcript

If the transcript came from Otter (or any non-local source), save it to cyp/tpc/transcripts/ first — the claim gate (Step 5B) reads a file, not a chat.

Cover to cover. Note (don't yet structure):

Cross-check every proper noun against reference data as you read.

The structured extraction happens in Step 5 (Ledger). For now: read with attention, surface things to verify.

Step 3: Check Calendar for Next Session (REQUIRED — blocking)

This is a fact-source step, not a compliance check. The calendar tells you when the next session is, on what day, and the cadence pattern. That information feeds the close (Step 6), the prep email send date (Step 12), and the calendar event creation (Step 13). Without it, those downstream artifacts fabricate or fail.

Use mcpclaudeaiGoogleCalendarlistevents with fullText: "[FirstName]" and a date range starting from today + 90 days forward. Pull:

Write these facts into your working notes for the run. They're inputs to Step 5 (Ledger) under the "Calendar / next-session facts" category.

Step 4: Read the Prior Recap

If one exists in Gmail or sessions/. Match the voice — opening style, level of warmth, sentence cadence, close pattern. The new recap should feel like the next email in the sequence.

Step 5: Build the Commitments / Decisions / Specifics Ledger (REQUIRED — blocking)

The ledger is the structural protection that prevents the kit's most common failure: stating undecided things as decided, fabricating commitments, and inventing closing-line specifics. Every assertion in the email must trace to a ledger row.

Write the ledger directly into the working .md (it lives there permanently — useful audit trail). Five categories:

5.1 Commitments

Things that were said about future action. Tag each row's confidence explicitly:

StatementSpeakerTranscript line/timestampConfidence

Confidence values:

Recommendations Kathryn made that the client didn't accept (e.g., "you should X" → silence or "huh, interesting") are tagged hedged. Kathryn's recommendation is not the client's commitment.

Live-and-executable screen (REQUIRED for every explicit member commitment before it earns a spot in the email). A commitment can be verbally explicit in the transcript and still NOT belong in the member's Action Items. After tagging explicit, screen each member commitment against two gates — it must pass BOTH:

  1. Still outstanding? Did something in the session (or Kathryn's own follow-through) already close it? If Kathryn sent the invite, made the booking, or handled it on her end, the member's "I need to do X" is moot — drop it from the email (note in .md as done).
  2. Known-how? Was the member actually shown how to do it, or do they already know? If the session never covered the how (e.g., "invite Natalie to Claude" when inviting was never walked through), assigning it sets the member up to flounder on a step they weren't equipped for. Drop it from the email — it belongs in the next session's hands-on work (and the .md/agenda), not as written homework.

A member commitment that fails either gate is real in the transcript but is not a valid Action Item. Member action items are welcome — they just have to be live and executable. This is the extension of the Citation Test: explicit is necessary but not sufficient; the item must also be outstanding AND something the member can actually do.

5.2 Decisions

Things stated as resolved during the call:

StatementTypeTranscript lineStatus

Status values:

If a sentence in the draft asserts that something was decided, the corresponding row must be tagged made. If discussed or recommendation_open, the prose must say "we discussed" or "we talked through" — never "we decided."

5.3 Closing-eligible specifics

Things from the transcript that are factually verifiable AND personal-specific — eligible to anchor the warm close. Examples: "show this weekend," "surgery Monday," "finish strong" (a phrase from the call), "good luck with [specific thing]."

SpecificTranscript lineNotes

This list is allowed to be empty. If empty, Step 6's close defaults to the locked sign-off (Talk soon, Kathryn) only — no warm close line. Never generate a close from outside this list. Closes like "safe travels" or "enjoy the weekend" without a transcript-rooted source are fabrications.

5.4 New proper nouns / engagement context surfaced this session

Anything in the transcript that's NOT in the current member or cohort reference data:

ItemType (name / tool / role / engagement field)Source lineAction

This list is the input to Step 11 (apply to reference data). It also means Step 6's draft uses the new names correctly because they're in the working set.

5.5 Calendar / next-session facts

Pulled from Step 3:

FactValue
Next session date[YYYY-MM-DD]
Next session time[HH:MM TZ]
Recurrence pattern[e.g., monthly Wed 10am ET]
Next session purpose/type[regular 1:1 / makeup-catch-up / staff onboarding / kickoff — what is this session actually FOR]
Booking note[if any, verbatim]

These feed the close (only the next session date is a candidate cadence reference), the prep email send date, and Step 13's calendar events.

Capture the next session's PURPOSE, not just its date. The next session is not always a forward-planning 1:1 — it may be a makeup/catch-up (work that slid), a staff onboarding, or a kickoff. The Proposed Agenda (Step 6) must match what the session actually is. A makeup session's agenda is the thing being made up — not an aspirational roadmap. Read the calendar event's title/description for the purpose; if ambiguous, infer from the transcript (what did they agree the next session would do).

Ledger discipline:

5.6 Reporting-line claims (quotes-first — feeds the gate)

Before composing any prose, convert every fact-asserting reporting line the cascade will produce — in ANY artifact, not just the email — into a typed claim. The ledger is the single gated source: the recap email, the .md, the CPM, the drafted action items, and the agenda are all projections of it. So each Wins bullet, each What We Covered line, each Action Item, each Proposed Agenda item, AND each fact a downstream artifact will assert (a CPM constraint's evidence, a draft's content) becomes a claim here. Write them to cyp/tpc/members/[name]/sessions/[name]-claims-[YYYY-MM-DD].json:

{
  "artifact": "[name] recap email [YYYY-MM-DD]",
  "transcript": "../../../transcripts/[transcript file].txt",
  "claims": [
    {"id": "win1", "type": "fact", "text": "[the claim as it will read]", "evidence": "[VERBATIM transcript quote, >=4 words]"},
    {"id": "cov1", "type": "advisor-confirmed", "text": "...", "evidence": "Kathryn affirms; transcript silent"},
    {"id": "agenda1", "type": "judgment", "text": "[proposed next step]", "evidence": ""}
  ]
}

Claim types (same as the AOS gate):

This maps onto the ledger you already built: ledger 5.1 explicit and 5.2 made rows become fact claims (carry their transcript line as the evidence quote); proposed-agenda items become judgment.

Step 5B: Run the Claim Gate at the SOURCE (fail-closed — BLOCKING)

This gate sits at the source — the ledger — and protects the WHOLE cascade, not just the email (6/16 spec R4: gate the extraction every artifact draws from). BLOCKED stops everything — no artifact (email, .md, CPM, drafts, agenda) composes until it prints CLEAR. Fabrication does damage the moment it enters any artifact Kathryn relies on, not only when something is sent (Rob 6/17: the SharePoint overstatement had already propagated into the CPM, open-actions, and a drafted deliverable before it was caught in the recap).

Run the same gate the AOS cascade uses:

⚠️ On Windows, bare python/python3 is a dead stub — use py. If it errors instead of printing CLEAR or BLOCKED, the gate did NOT run, and a gate that didn't run is not a pass. Fix the invocation and re-run.

If it prints BLOCKED, fix or cut the failing lines — a fact whose quote isn't in the transcript is either mis-cited or overstated. Do not draft (Step 6) until it prints CLEAR.

The gate certifies sourcing, not interpretation — it catches fabrication, not overstatement of degree. The win-rule in Step 6 and Kathryn's review cover interpretation.

Single gated source → the ripple. Every artifact traces to gated ledger rows, so correcting a ledger row and regenerating propagates the fix to every artifact that drew from it. This is the mechanism behind Kathryn's operating loop: when she edits the recap and says "go check it out," trace each edit to its ledger row(s), update the ledger, and regenerate every downstream artifact that drew from those rows — not just the email (see Step 8's correction/ripple path).

Step 5C — Confirm load-bearing facts before drafting client copy (REQUIRED when the email hinges on a fact you're unsure of)

If the email's content depends on a fact about the member's setup or situation that the transcript doesn't fully nail down — which tool/account/plan they're on, what they've already set up, what they've decided — surface those 2–3 facts to Kathryn and confirm before drafting. Drafting polished client copy on an assumed fact and correcting it afterward is the multi-redraft failure (Meryl 6/19: the AI-account line churned business → consumer → opted-out → Plus → no-Team across four redrafts). Confirm once, draft once.

Step 6: Draft the Email

The draft is a select-from-ledger operation, not a generate-from-transcript operation. Every line in the email maps to ledger content or reference data.

The email is a client-facing projection of the record — not a copy of it. The full record (the .md, the complete ledger, everything discussed and what it relates to) stays exhaustive; that's where completeness lives. The email carries only what was explicitly relevant to the conversation — no backstory, no internal threads, no program/cohort context, no how-to. Filtering content out of the email does not mean deleting it; it stays in the .md. Keep the record complete; send the client the relevant slice.

Subject

Meeting recap - [M-DD-YYYY]

Composition rules

No section is composed from "what feels right." Every section has a defined source in the ledger or reference data. If the source is empty, the section is empty.

Non-duplication rule (hard) — Wins and What We Covered may never say the same thing (ported from the AOS recap-email skill, where it's a hard rule). Wins & Progress = what moved forward (completed outcomes). What We Covered = what was discussed without a finished outcome. If a topic produced an outcome, the outcome goes in Wins and the topic is not repeated in Covered. For a hands-on session most topics become wins — that correctly shrinks What We Covered to the few things discussed-but-not-done (a 2-line Covered is fine; a Covered that restates the Wins is a failure). The claim gate (Step 5B) does NOT catch this — it certifies sourcing, not composition. Read the finished email as the recipient and compare Wins vs. Covered by eye before drafting the Gmail draft.

Multi-recipient & shared-transcript recaps (from Rob 6/17 Mode 2):

Body Format

Rich text (HTML via htmlBody). Section headers bold. Lists as real