Extract Completions For Log

Turn finished (or almost-finished) work into log blocks that the person would write themselves. The block is a memory aid — a signal trigger that makes them go "oh yeah, I built that yesterday" — not a status report and not documentation. It earns its place on their page only if it sounds like them.

Hard prerequisite — calibrate voice first

Before drafting any block, use the /how-to-talk-like-the-founder skill's voice-calibration step (it detects whether the person's own writing samples exist and, if not, offers to collect a few or use its opt-in example as a starting taste). Drafting blind and "fixing voice later" does not work — the voice has to be in the bones of the sentence. If you need more, /founder-voice-email-writing (if installed) has additional voice material, usable the same opt-in way.

This step is not optional. A block that doesn't sound like the person fails the skill regardless of how accurate the content is.

When to fire

• "Give me a daily log of what I got done"
• "End of week roundup"
• "What did I ship this week?"
• "Add this to my dashboard/vault"
• "Write up the completions from today's sessions"
• Anything that asks for a summary block of finished work that the person themselves will read

Example (opt-in starter — replace with your own)

This shows the shape a log entry can take. The specific words ("sesh," "fathom transcript") belong to one person's voice — the transferable part is the structure: verb-led heading, three short prose paragraphs, inline links, plain date. Once you have the person's own voice calibrated, their entries should read like them, not like this example.

### Transform Zoom Call Transcripts into Proposals

New tool created today for the client-facing AI-augmented-systems funnel which lets you grab a transcript and generate a proposal from it.

It attempts to move through many of the stages we are aiming for in [[link]], [[link]] and [[link]] and you can run it in debug mode right now.

Just drop a transcript into a Claude Code sesh and run `/prep-discovery-call` to run it. Add debug flag if you want it to stop and quality test its work.

Apr 28, 2026

Every block you produce takes this exact shape. Three short prose paragraphs, a date, nothing else.

The shape — decoded

Heading is verb-led. "Transform X into Y" / "Reverse-Engineer X" / "Crystallize X" / "Wire X to Y". Describes what the thing does, not its noun-name. Never ### New Tool: prep-discovery-call — that's a label, not an action.

Paragraph 1 — what it is + which initiative it sits inside. One casual sentence in the person's voice. The initiative is named in the sentence, not pinned as a label. Drop the sentence in front of them and they should already know which thread of work this belongs to.

Paragraph 2 — the nuance that makes it distinct, OR the state if it's not yet done. State is dissolved into word choice — "attempts to," "we are aiming for," "this is roughly there but" — never an all-caps STATE: tag. If the person keeps a linked notes vault (Obsidian or similar), cross-references to other initiatives appear as inline [[wikilinks]] to the related files. The links are part of the sentence, not a separate "Related" section. If they don't keep a linked vault, just name the related thread in prose instead.

Paragraph 3 — how to use it now, in the person's voice. Direct command, casual idiom matching how they actually talk. The actual slash-command (if any) appears inline as code: /prep-discovery-call. If the thing isn't usable yet, this paragraph is the literal move that would push it over the line, again in their voice.

Date stamp at the end, plain. Apr 28, 2026. No session-ID footer, no Generated by: line, no metadata trail. The date is the only metadata.

Rules

1. Verb-led headings only. "Transform / Reverse-Engineer / Crystallize / Wire / Open / Kill / Replace / Pry-Apart". Never noun-only headings.
2. Inline [[wikilinks]], if the person keeps a linked vault, to any related files — seeds, other initiatives, validators, evidence chains. Inline, in the sentence, never in a "Related links" block. If there's no vault, skip links and just name the thread in prose.
3. No bold field labels. Nothing like **The thing:**, **Why it exists:**, **State:**, **How to consume:**. The labels destroy the reading flow and make it look like an assistant wrote it.
4. No bullet lists for content. Bullets are only acceptable inside a closing "ranked moves" section if the larger log document has one. Inside individual completion blocks, bullets are forbidden.
5. For items that ARE done: focus on what makes this distinct from other attempts at the same thing — the nuance that matters. Do NOT hallucinate certainty about what it does. Do NOT fabricate claims about coverage, performance, or completeness. Stay in the realm of intent and the observable distinction.
6. For items NOT done: even shorter — what didn't land, the UX you'd get if it did, the literal move (in their voice) to push it over the line. Don't pad it.
7. Casual idiom is correct, if it matches how the person actually talks. Sanitizing a voice that is naturally casual into something formal is a failure mode; so is forcing casual idiom onto someone whose real voice is formal. Match the calibrated voice, not a stereotype of "casual."
8. Quote slash-commands inline as code. `/prep-discovery-call`. Never bare, never bolded.
9. Date stamp is plain. Apr 28, 2026. Not Date: Apr 28, 2026, not a metadata block, not a footer.

Failure modes — the exact mistakes that produced these rules

The "spreadsheet" failure. Bold field labels (**State:**, **How to use:**) plus bullet lists plus state tags turn the block into a tracking row. The person can't use it as a memory aid because it doesn't read like memory — it reads like a CSV. Prose only. No labels. No bullets.

The "agent narrator" failure. Writing about the person in second person — "you spent today building..." or "your team finished..." — instead of in their voice. The block must sound like they wrote it themselves, in their own register. If a sentence could come from a daily standup written by someone else about them, it fails.

The "hex ID" failure. Dumping session IDs like Session: 1f2d9f08 or compactionId: abc123def at the bottom of each block. Meaningless to a human reader, looks like agent debris. The date is the only footer.

The "hallucinated certainty" failure. Making confident claims about what the tool does ("automatically scores responses across 8 dimensions and routes to the highest-leverage path") when you only know intent. If you didn't observe it run, don't describe its output. Stay with intent and observable distinction. "Attempts to," "we are aiming for," "you can run it in debug mode right now" — these are honest. "Reliably produces a 9-stage proposal" — that's a claim you probably can't back.

Workflow

1. Calibrate voice — run /how-to-talk-like-the-founder's voice step first; use the person's own samples if on file, offer to collect a few if not, and offer the sample voice only as a clearly labelled opt-in taste.
2. Pull the source material — the session compaction, commit, completion log, or whatever evidence describes what got finished. Do not invent.
3. Identify the initiative — name the parent thread of work this completion sits inside. If you don't know, ask before drafting.
4. Find related files for [[wikilinks]], if the person keeps a linked vault — seeds, other initiatives, validators. Use real paths/files, not invented ones. If there's no vault, skip this.
5. Draft the three paragraphs in the calibrated voice. Verb-led heading. No labels. No bullets. Inline wikilinks where applicable. Inline code for slash-commands.
6. Stamp the date plainly at the bottom.
7. Self-check against the failure modes before handing it back. If it reads like a status report, restart.

Where the block goes — the consumption pattern

The block prepends to the top of ONE canonical rolling log file, not a new file per entry. Where that file lives depends on what the person has:

• If they keep a notes vault (Obsidian or similar) with an existing progress/dashboard log, use that file.
• If they named a specific log file already, use it.
• Otherwise, use the folder printed by alignment-harness records progress-log and keep a single file there (for example progress-log.md), and tell the person the path so they know where to find it.

Rules — read these before writing anything to disk:

1. One file. Not date-named files. The log is a single rolling document that grows over time. Never create a new file like 2026-04-28-progress-log.md — that breaks the pattern.
2. Newest at the top. Prepend the block above all existing content. Never append to the bottom, never overwrite, never insert in the middle.
3. Use horizontal rules (---) to separate blocks from existing content, matching the existing pattern in the file.
4. Each block takes the canonical shape described above (verb-led heading, prose paragraphs, plain date stamp at bottom). Three paragraphs is the upper bound, not a fixed target — if two paragraphs convey the signal without noise, ship two. The middle "nuance" paragraph is optional when the intro and the how-to-use bookends already carry the meaning.
5. When a new day rolls, an end-of-day meta reflection block can be added above that day's entries. Format: ### Meta Reflection for — YYYY-MM-DD followed by a one-paragraph summary in the person's voice and a Sessions touched: N. Initiatives below: N. line. The meta reflection is OPTIONAL during the day — individual completion blocks accumulate first, the meta reflection lands at end-of-day or the next morning.
6. If the person names a different path than the canonical log, do NOT create that file without checking first. The named path is most likely a slip — confirm the canonical log is what they meant before writing anywhere else. If they explicitly insist on a new file, ask why and surface the convention conflict.
7. If the canonical file does not exist yet, create it with the block as the first content at that exact path. Do not create date-named alternatives.

When in doubt

If you're not sure how the person would phrase a sentence, do not synthesize. Ask them for a short sample of how they'd describe the thing — that's faster and more precise than guessing.