Extract Completions For Log

---
name: extract-completions-for-log
description: Use when the user asks for a daily progress log, end-of-week roundup, "what did I get done", Obsidian dashboard entry, or any summary block describing recent work that the user will read. Produces signal-trigger blocks written in the user's own voice — verb-led headings, short prose paragraphs, inline obsidian wikilinks, plain date stamp. Read the `how-to-talk-like-the-founder` skill voice samples BEFORE drafting any block — non-negotiable.
---

# Extract Completions For Log

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

## Hard prerequisite — read voice samples first

Before drafting any block, open `${CLAUDE_PLUGIN_ROOT}/skills/how-to-talk-like-the-founder/SKILL.md` and read at least **2 voice samples** in full. Drafting blind and "fixing voice later" does not work — the voice has to be in the bones of the sentence. If the samples there feel insufficient for the work at hand, also open the `founder-voice-email-writing` skill.

This step is not optional. A block that doesn't sound like the user 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 Obsidian dashboard"
- "Write up the completions from today's sessions"
- Anything that asks for a summary block of finished work that the user themselves will read

## The canonical example (memorize this shape)

```
### Transform Zoom Call Transcripts into Proposals

New Tool created today for the Funnel Enabling AI Augmented Systems to serve clients 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 fathom transcript into 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 user's voice. The initiative is named in the sentence (e.g. "the Funnel Enabling AI Augmented Systems to serve clients"), not pinned as a label. Drop the sentence in front of the user and the user 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. Cross-references to other initiatives appear as inline `[[obsidian-links]]` to the related Obsidian files in the intent vault. The links are part of the sentence, not a separate "Related" section.

**Paragraph 3 — how to use it now, in the user's voice.** Direct command, casual idiom — "sesh," "fathom," casual profanity if the moment calls for it. The actual slash-command 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 the user's 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]]`** to any related files in the intent vault — seeds, other initiatives, validators, evidence chains. Inline, in the sentence, never in a "Related links" block.
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 the user's voice) to push it over the line. Don't pad it.
7. **Casual idiom is correct.** "sesh," "drop it in," "fathom transcript," "wire it up," casual profanity if it sounds natural. Sanitizing the voice is a failure mode.
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 "Google spreadsheet" failure.** Bold field labels (`**State:**`, `**How to use:**`) plus bullet lists plus state tags turn the block into a tracking row. The user 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 user in second person — "you spent today building..." or "your team finished..." — instead of in the user's voice. The block must sound like the user wrote it themselves, in the same casual register the user speaks in. If a sentence could come from a daily standup written by someone else *about* the user, 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. **Read voice samples** — open `how-to-talk-like-the-founder` and read at least 2 verbatim samples.
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 in the intent vault** for `[[wikilinks]]` — seeds, other initiatives, validators. Use real paths/files, not invented ones.
5. **Draft the three paragraphs** in the user's voice. Verb-led heading. No labels. No bullets. Inline wikilinks. 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:

`$(alignment-harness records progress-log)/Substantive Progress Log.md`

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 user'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 user names a different path** (e.g. `2026-04-28-progress-log.md`), do NOT create that file. 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 for some reason**, 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 user would phrase a sentence, do not synthesize. Ask the user for a 3-sentence sample of how the user would describe the thing — that's faster and more precise than guessing.