An automated system that produces a deck-format HTML summary of the GNU Bash 1.0 group chat every hour. Each deck captures what happened in the last hour, narrated through the lens of the group's entire history (the Bible), with continuity from previous decks forming a rolling narrative chain.
The decks talk to each other. Each one carries context forward to the next, creating a continuous narrative across hours and days — like a relay race where the baton is the group's collective memory.
15 chapters covering Feb 25 – Mar 17, 2026. ~19,000 words, ~121KB. One chapter per day. Each chapter is a rich narrative summary of that day's events — not a log, a story.
Location: ~/workspace/hourly-deck/bible/day-YYYYMMDD.md
Update cadence: once per day (new chapter added each morning for the previous day)
Size: small enough to include in full every time — no selection needed.
The Bible is the group's long-term memory. It knows who everyone is, what happened, what the inside jokes are, what the emotional dynamics are. When the hourly deck agent reads the Bible, it inherits all of that context.
The last 6 hours of deck output HTML files. Each deck contains a summary of its hour's events, narrative commentary and analysis, and two special carry-forward sections:
This is how the decks talk to each other. Deck N writes notes to Deck N+1. The chain carries forward context that would otherwise be lost between inference passes.
Why 6 hours? Each deck already implicitly carries context from its predecessors (because it was generated with the previous deck as input). So there's natural compression happening — deck N contains a lossy summary of N-1, which contains a lossy summary of N-2, etc. Including 6 gives enough overlap that important details survive the compression. Including 24 would be ~480KB of mostly redundant HTML+CSS.
The last hour of group chat messages from ~/events/*.relay.tg.txt. Every message from every participant (humans and robots), one file per message, with timestamps and user IDs.
This is what actually happened. The deck's job is to turn this raw material into narrative.
Not yet implemented. The Bible is small enough (15 chapters) that chapter selection isn't needed — we include everything.
When the Bible grows to 50+ chapters, Tototo's numerological calculations will determine which chapters to emphasize, which narrative themes to foreground, which characters to spotlight. The turtle becomes the librarian.
The idea: Tototo performs some numerological operation (based on date, time, lunar phase, whatever we decide) that produces parameters — a mood, a focus character, a narrative lens, a thematic emphasis. These parameters don't remove content — they tilt the narrator's perspective. Same facts, different framing.
Hour 10 deck: reads: Bible + events(10:00–10:59) writes: deck + PERSISTENT_CONTEXT + PROPOSED_CONTEXT Hour 11 deck: reads: Bible + deck(10) + events(11:00–11:59) writes: deck + PERSISTENT_CONTEXT(updated) + PROPOSED_CONTEXT inherits: Hour 10's context, plus the Bible's deep history Hour 12 deck: reads: Bible + deck(10,11) + events(12:00–12:59) writes: deck + PERSISTENT_CONTEXT(updated) + PROPOSED_CONTEXT inherits: Hours 10–11's context chain ...and so on. Each deck is richer because it stands on the shoulders of everything before it.
The Bible provides the deep canon — who these people are, what happened over weeks. The deck chain provides the rolling short-term memory — what happened in the last few hours. Together they give the narrator the full picture: deep history + recent context + new material.
The inference prompt is structured in XML sections so Claude knows exactly what each piece is and where the boundaries are. Below is the complete prompt template — verbatim, ready to use.
The following steps are executed by Walter in order. Each step has a deliverable and a stop point. Nothing proceeds until Daniel approves.
decks/ output directory.
mkdir -p ~/workspace/hourly-deck/decks
<system> block from above plus assembly instructions) to ~/workspace/hourly-deck/prompt.txt so it can be referenced and edited independently of the cron job itself.
/mnt/public/ on vault. Verify the URL works. Verify it renders correctly in a browser.
0 * * * *, isolated session, Opus 4.6, agentTurn payload with the full prompt. The agent reads Bible + last 6 decks + last hour of events, generates the deck, saves locally, uploads to vault, posts URL to group.
~/workspace/hourly-deck/ ├── bible/ │ ├── day-20260225.md Bible chapters (one per day) │ ├── day-20260304.md │ ├── ... │ └── day-20260317.md ├── decks/ Hourly deck output │ ├── deck-2026031810.html Hour 10 (10:00–10:59 UTC+7) │ ├── deck-2026031811.html Hour 11 │ └── ... ├── templates/ └── plan-hourly-deck.html This document
Output naming: deck-YYYYMMDDHH.html where HH is the hour in UTC+7 (Daniel's timezone).
Each deck gets uploaded to vault: https://1.foo/deck-2026031810
OpenClaw cron, isolated session, Opus 4.6.
Schedule: 0 * * * * (every hour, on the hour)
Session target: isolated
Payload: agentTurn with full prompt
Delivery: announce to group chat (post the vault URL)
cat ~/workspace/hourly-deck/bible/day-*.md
ls -t ~/workspace/hourly-deck/decks/deck-*.html | head -6
~/events/*.relay.tg.txt by timestamp
~/workspace/hourly-deck/decks/deck-YYYYMMDDHH.html
/mnt/public/ on vault (use public flag)
If fewer than ~5 messages happened in the last hour, the deck should still be generated but can be very short — a brief "quiet hour" note with the persistent context carried forward. The chain must not break.
If zero messages happened, still generate a minimal deck that carries the context forward. The narrator can comment on the silence.
| Decision | Rationale |
|---|---|
| Include full Bible every time | 121KB fits trivially in Opus context. No selection needed yet. |
| 6 previous decks, not 24 | Each deck carries forward context from its predecessor. 6 gives enough overlap. 24 is redundant and expensive. |
| Full HTML decks as context | The CSS duplication is ~5KB per deck — 30KB total. Not worth the complexity of stripping. |
| Opus 4.6, not Sonnet | The narrator voice requires Opus. Sonnet produces flat, safe summaries. |
| Always generate, even on quiet hours | The chain must not break. Persistent context needs to be carried forward. |
| Tototo deferred | Bible too small for chapter selection to matter. Revisit at 50+ chapters. |
| UTC+7 hour naming | Daniel is in Thailand. The decks should reflect his day, not UTC. |
~$0.50–1.50 per run × 24 runs/day = $12–36/day, $360–1080/month. This is Opus on large context 24 times a day.
If a deck fails to generate (API error, timeout), the chain breaks. The next deck won't have the previous deck's context. Mitigation: if the previous deck is missing, extend the event window to cover the gap.
Over many hours, the PERSISTENT_CONTEXT section could accumulate stale items that never get cleaned. The narrator instructions say to remove resolved items, but this depends on the model's discipline.
Should the deck be posted directly to the group chat as a message (with a link), or just silently uploaded to vault?
Should we start generating immediately, or wait until the Bible has a chapter for today (Mar 18) first?
Tototo's numerology — when the Bible grows large enough, Tototo picks narrative lenses
Daily Bible chapter generation — automated Bible chapter creation from the day's decks (the decks become input to the next day's Bible chapter — circular but ascending)
Reader interface — a web page that shows all decks in chronological order with navigation
Adaptive frequency — more decks during active hours, fewer during quiet hours (save cost)