---
name: thermograph-voice-summaries
description: The periodic job that digests NoteCat's voice transcripts into the docs. Read this when running the loop, or setting it up.
---

# Voice-transcript digest

A transcription bot (**NoteCat**) posts voice-to-text into a Discord transcript
channel. Raw transcript is high-volume and perishable — nobody re-reads an hour
of it, and it scrolls out of the channel. This job turns each window of it into
a durable summary in the docs repo. It is meant to run **every few hours**, and
to be safe to run again if a run is missed or repeated.

## What the loop does, each run

1. **Find the window.** Read the most recent `summaries/` file with
   `summaries_list` + `docs_read`. The last timestamped section header tells you
   where the previous run stopped. If there is no file for today, start from the
   beginning of the day.

2. **Pull the transcript.** Read the transcript channel with the Discord tools
   (`discord_get_messages` on the channel NoteCat posts to — its id is in
   `community_channels` under the `transcripts` role, or `CENTRALIS_TRANSCRIPT_CHANNEL`).
   Take only messages newer than where the last run stopped. If nothing is new,
   **stop — do not write an empty summary.**

3. **Digest.** Write a summary that someone who was not on the call can read:
   - What was discussed and, more importantly, **what was decided**.
   - Action items, with who owns them if it is clear.
   - Open questions left unresolved.
   - Drop the filler. A summary is a claim about what happened, not a transcript.
   - Keep the grade-language rule: never call a percentile "hot" or "cold".

4. **Write it.** `summaries_write` with a `heading` naming the window
   (e.g. `war-room 14:00–16:20 UTC`). It appends a timestamped section to
   `summaries/YYYY-MM-DD.md` and commits straight to main. Do not open a PR —
   this runs too often for that, and the direct-commit path exists for exactly
   this.

5. **Surface it.** Post a short version into **#voice-summaries** (Owners
   category) with the Discord tools, linking the committed file, so owners see it
   without opening the repo. The full digest lives in the docs file; the channel
   post is the headline plus decisions and action items.

## Turning transcript into a decision record

The pipeline is **voice → transcript → summary → doc**. This job owns the middle
arrow. When a summary contains a decision that should outlive the day — an
architecture choice, a commitment — promote it: a `notes_write`, or a
`docs_write` into `architecture/` as a proper decision record. The summary is
the raw material; the decision record is the publication.

## Idempotency and safety

- **Anchor on the last section's timestamp**, never on wall-clock assumptions —
  that is what makes a re-run harmless and a missed run self-healing.
- **Never invent content.** If the transcript is garbled or thin, say so briefly
  and summarize what is legible. A confident summary of a bad transcript is
  worse than a short honest one.
- **Only the transcript channel.** Do not pull from other channels; this is a
  voice digest, and the transcript channel is where consent was given.
- If `CENTRALIS_TRANSCRIPT_CHANNEL` / the `transcripts` role has no id yet, there
  is nothing to do — report that the source is not configured and stop.

## Scheduling it

Runs on a cron routine every few hours (see `deploy/routines/voice-summaries.md`).
The routine is just "load this skill and do it"; all the logic lives here, so
changing the behavior is editing this file, not the schedule.