Alex' Gardenアレックスの庭

5 min read

fetch-monologue

Replaces the old external-transcription pipeline. Voice memos now live in Monologue (cloud app); this skill pulls transcripts only (not summaries — Monologue’s summary style isn’t what the vault wants) into 0_Inbox/transcripts/ so the rest of the wiki workflow can treat them like any other inbox transcript.

When to use

  • User runs /fetch-monologue, or asks to “sync monologue”, “pull monologue notes”, “fetch new voice memos”.
  • Phase 0 of process-inbox — runs automatically before draining.
  • Daily routine (if scheduled).

Prerequisites

  • Monologue MCP server is connected. Tools:

    • mcp__a166b90c-2d77-4a11-99ae-3bd0e1d9e7e8__list_recent_notes
    • mcp__a166b90c-2d77-4a11-99ae-3bd0e1d9e7e8__get_note
    • mcp__a166b90c-2d77-4a11-99ae-3bd0e1d9e7e8__search_notes

    These are loaded via ToolSearch if they aren’t visible at session start (select:mcp__a166b90c-...__list_recent_notes,mcp__a166b90c-...__get_note).

  • If the MCP server isn’t connected, stop. Append an action item to 7_Agent/notifications.md asking the user to wire up the connector, and exit. Do not try to install a CLI or use the API directly.

Workflow

1. Read the processed log

Read monologue-processed. This is the source of truth for “which Monologue notes have already been pulled into the inbox” — keyed by note_id (Monologue’s stable UUID). A note appears in this log exactly once, the first time it’s fetched. It stays in the log forever, even after process-inbox deletes the resulting transcript.

If the file doesn’t exist, treat the set as empty and create it as you go.

2. List recent notes

Call list_recent_notes with limit: 20 (raise to 50–100 if the user says it’s been more than a few days since last sync). Result has items[] (note_id, title, summary, created_at, updated_at) and next_cursor.

Walk newest → oldest. For each item:

  • If note_id is in the processed log → stop walking. Everything older is already pulled.
  • Otherwise → mark for fetch.

If you walk the full page without hitting a known note_id, paginate with next_cursor and continue. Safety cap: stop after 5 pages (500 notes) and surface a warning — something is wrong if the gap is that wide.

3. Fetch each new transcript

For each new note_id (oldest → newest, so the log appends chronologically):

  1. Call get_note with note_id and include_transcript: true.

  2. Extract transcript (the body), title, created_at, summary (kept only for the log, not written into the note — the user dislikes Monologue’s summaries).

  3. Build the filename: <YYYY-MM-DD> <sanitized-title>.md where the date is created_at (UTC date) and the title has filesystem-illegal chars (/ \ : * ? " < > |) replaced with -, collapsed whitespace, trimmed to ~80 chars. Preserve case and umlauts.

  4. Write to 0_Inbox/transcripts/<filename> with this shape:

    ---
created: 2026-05-13
lang: de
tags: [voice-memo]
source: monologue
monologue_id: f8803a34-39f2-4df5-a441-bf6ea289910f
monologue_created_at: 2026-05-13T14:00:33.572188Z
monologue_title: "Schönheit an hässlichen Orten"
---
 
<transcript body verbatim>
    • lang: — quick detection from the transcript: de, en, ja, or mixed. If the title is in one language and the body in another, mixed. If unsure, pick the dominant one.
    • monologue_title: — preserves the original title for provenance, since the filename is sanitized.
    • Body is the transcript verbatim. Do not clean, summarize, or reformat. process-inbox and downstream skills handle structuring; this skill is a pure fetch.

  5. Append to the processed log (monologue-processed):

    - 2026-05-15 — f8803a34-39f2-4df5-a441-bf6ea289910f — "Schönheit an hässlichen Orten"

    The leading date is today’s date (when fetched), not created_at. The format is one bullet per note, under the ## Processed heading. Append in fetch order.

  6. If a write collides with an existing filename (same date + title from a previous fetch that hasn’t been routed yet, edge case), append (2), (3), … before .md.

4. Report

After the batch, output a short summary:

  • n notes fetched (with titles).
  • 0_Inbox/transcripts/ count after the run.
  • If invoked as Phase 0 of process-inbox, return control silently — process-inbox will report on the full inbox drain.
  • If invoked standalone, mention next step: “Run /process-inbox to route these into PARA.”

Rules

  • Transcripts only. Never write Monologue’s summary into a note. The user finds its style off-key. Summaries can go into the processed-log entry for human reference, nothing more.
  • Verbatim body. Don’t clean the transcript here. The voice-memo cleanup conventions in audio-inbox applied to a separate transcription pipeline; Monologue’s transcripts are already high quality and the user wants them raw.
  • No PARA routing. Always write to 0_Inbox/transcripts/. process-inbox decides where each note lands — including whether it’s a work note that belongs in 6_Private/Work/.
  • The log is append-only. Never remove entries, even if the corresponding inbox transcript was deleted by process-inbox or by the user. The log is the dedup oracle.
  • Read-only against Monologue. The MCP server is read-only by design. Do not attempt writes.

The user may dictate work-related thoughts (e.g., about employers like 10ten, current or past). These end up in Monologue indistinguishably from personal memos.

This skill does not classify — it dumps everything into 0_Inbox/transcripts/. process-inbox reads the transcript body and routes work content to 6_Private/Work/ (the umbrella for work-related material not tied to a specific employer) or to an employer-specific subfolder like 6_Private/10ten/ if one already exists. See Privacy Classification.

Blocked cases

  • MCP server not connected — notify the user (action item in 7_Agent/notifications.md) and exit. Do not improvise an alternative path (e.g., shelling out to a CLI).
  • Empty transcript — Monologue returned a note with no transcript text. Write the note anyway with an empty body and tags: [voice-memo, empty-transcript]. Log it. Let the user decide on cleanup.
  • MCP call fails / network error — retry once. If still failing, log to 7_Agent/log.md under ## [YYYY-MM-DD] fetch-monologue | error, leave the processed log untouched (so the next run retries), and exit.

Verification

  • Every fetched note_id appears exactly once in monologue-processed.
  • Every fetched note has a corresponding file at 0_Inbox/transcripts/<filename>.md (until process-inbox routes it).
  • No file in 0_Inbox/transcripts/ was overwritten.
  • No Monologue summaries were written into note bodies.

Graph View

Backlinks