thomas gaume

Tammy How-Tos

These are the how-tos that took me the longest to figure out. Not because they’re complicated, but because the obvious approaches don’t work and the right approaches aren’t obvious.


Token Trim: shrinking your instruction files

After a few months of use, your CLAUDE.md and other instruction files get fat. Every rule you add, every new section, every process note accumulates. The files stay functional but they start consuming a meaningful chunk of your context window on every session start.

The solution is mechanical compression. The AI does not care about your formatting. It parses meaning from text. All the markdown structure, the bold markers, the horizontal rules, the blank lines between list items: those are for human readers. The AI doesn’t need them.

There are five rules:

Strip markdown formatting. Remove bold markers, horizontal rules, backticks around non-code terms. The content survives; the formatting overhead doesn’t.

Remove blank lines between list items. A blank line between list items is visual breathing room for humans. To the AI it’s just whitespace. Collapse it.

Use shorthand notation. Instead of “The following rule applies to all dispatch operations:” just write the rule. Drop the preamble.

Collapse bulleted lists into inline text. “Tasks include: research, drafting, and fact-checking” takes fewer tokens than a three-item bulleted list.

Remove redundant context. If the file says something twice, say it once. If a section restates what was already established in CLAUDE.md, cut it.

My documented result when I ran this on my own files: 7 files, 139KB down to 65KB. 53% reduction. Individual files ranged from 25% to 74% reduction depending on how prose-heavy they were.

Important limits: this is only for AI-read instruction files. Not for human-facing documentation. Not for code files, where formatting carries semantic meaning.

The process: ask Claude to compress a file, read what it produced against the original, verify the behavior holds, then save. Do one file at a time. Don’t batch them.


The todo list

The todo system is a single text file. That’s it.

You say “todo: follow up on the vendor quote” and Claude appends this to assistant/todo.md:

2026-03-02 -- Follow up on the vendor quote

You ask “anything on the todo list?” and Claude reads the file and reports back.

It works because files persist between sessions. Claude’s memory inside a session is temporary. When the thread closes, it’s gone. But a file on disk survives. That’s the whole architecture.

The rules in CLAUDE.md that make this work:

  • Capture: append items in format YYYY-MM-DD -- [item]
  • Assess urgency; if it can wait, keep working and don’t interrupt
  • Recall: when asked about the list, read and report all items
  • Offer to act on, clear, or defer items after recall

There’s also a priority system I added over time. “note 1: [message]” means handle immediately and stop what you’re doing. “note 2: [message]” means high priority at the next natural break. “note 3: [message]” is informational, acknowledge silently. These are live messages, not todo items. They don’t go in the file.

The optional enhancement mentioned on the site is an HTML web board with radio buttons for Done, Do This, and Park, rendered via Node.js and deployed for mobile access. I have this but I don’t use it often. The text file is usually enough.


Video production pipeline

This one took the most iteration to get right. The pipeline turns a published article into a narrated video with AI-generated slides and a music bed, without manual editing or timing adjustments.

Six stages:

Stage 1: Newscast script. A script agent rewrites the article for broadcast delivery. Print writing is contextual; broadcast is action-first. The agent restructures the content into shorter sentences, active voice, and spoken transitions. It’s calibrated to target video duration, usually 5-7 minutes for a standard article.

Stage 2: TTS narration. A text-to-speech engine converts the script to audio. I use specific voice parameters matched to the publication’s tone. There’s a separate voice for mid-roll promotional content so I can rotate evergreen promos across multiple videos without them sounding identical.

Stage 3: Word-level timestamps. The narration audio gets processed to extract precise timing data for each word. This is what makes automated slide transitions work without manual intervention. The slides advance based on what’s being said, not on fixed intervals.

Stage 4: Slide generation. An AI image API generates slides from the script descriptions. The critical detail: slides render text natively as part of the generated image. No post-production text overlays. This keeps the visual consistent.

Stage 5: FFmpeg assembly. The pipeline combines slide images, narration audio, timestamp-driven transitions, and the music bed into a finished MP4. The xfade filtergraph handles transitions. The Remotion approach was retired after repeated failures. FFmpeg xfade is the locked-down method.

Stage 6: Output. The video integrates with the article canvas, giving readers a video option alongside the text version.

A few rules that came from hard experience:

The concat demuxer is banned. Every time I tried it I got sync failures. Use xfade filtergraph. This rule is in the agent instructions and the memory server.

The music bed runs at -16 LUFS loudness normalization. Get this wrong and the audio either drowns the narration or sounds like a phone call.

Every slide gets the publication URL. Not optional. It’s a hard rule.

The pipeline uses an agent orchestrator that queries the memory server for production rules before each run. Sub-agents cannot access memory directly. The orchestrator injects rules as a RULES block into each dispatch prompt. That’s the bridge.


How the system grows

The general principle across all three of these: when you repeat the same multi-step task twice, it becomes a skill. You describe it to Claude, it writes the skill file, you review it, you deploy it.

The system detects repeated patterns and surfaces them at session start as skill candidates. Some of those candidates become skills. Most get deferred. The ones that become skills are the ones where the manual process was fragile or time-consuming enough that formalizing it paid off.

The changelog on the Tammy site covers the full development arc from February 2026 through today. The system went from a simple CLAUDE.md file to a 26-agent framework through about three months of continuous iteration. None of it was planned upfront. It grew from what the work actually required.

That’s the honest picture of how this gets built. You start simple, you use it, you fix what breaks, you formalize what works.