Skip to content

Daily Agenda + Context-Entry Optimization, Design Spec โ€‹

Date: 2026-08-19 Status: DRAFT / living (operator co-edits). Scoped via the planning skill. Plan: ../plans/2026-08-19-daily-agenda-and-context-entry.mdRelated design: 2026-07-13-agents-config-hierarchy-design.md (the .agents/ compiler and the personal context home this builds on)

Two changes that arrived together because they are the same idea at two scales: put each thing in the one place it belongs, and route to it from a short index. Part 1 does it for the operator's day. Part 2 does it for what every agent loads on every turn.


Consolidation (rule 13) โ€‹

Already tracked, and this work extends rather than duplicates:

ExistingStateRelationship
sync the per-user context home across machines (#834)openThe agenda lives in that home. Verified today: boards/pm/*.md are tracked and pushed to the private lantern_context repo, so the agenda syncs with no new work.
sync model, dated files for volatile state, a generated index, and how memories converge (#862)open, parts 3-4Established dated append-only files as the pattern for volatile state. The agenda IS that pattern, applied properly.
Context layer: flip Claude memory subtree to context-canonical (#654)open*/memories is gitignored and still symlinks to live Claude memory, so memories do NOT cross machines. Deliberately out of scope (operator decision, 2026-08-19).
lantern board, print the PM board + today's live PR ledger in the terminal (#856)openBecomes lantern agenda once the file format is fixed.
lantern next, ranked next-task list from board + registered live plans + scored issues (#859)openReads the agenda's task list as one of its inputs.
skill for keeping the timeline docs current as work is planned, prioritized, and finished (#853)openAdjacent. The agenda's work log is the daily grain; the timeline is the release grain.

The decay this fixes. Dated board files exist for 2026-08-13 and 2026-08-14 and then stop. Four working days (08-15 through 08-18) have no dated record; the published html page became the record instead. The practice lapsed because nothing named a single artifact that had to exist by end of day.


Part 1: The daily agenda โ€‹

Problem โ€‹

The PM board is a running log written for the PM. It answers "what happened" and does not answer "what is on my plate, and what would I hand an agent to do it." The operator's own tasks live scattered across Need-from-you blocks in chat messages she cannot scroll back to. Nothing carries deferred work to the next day except memory.

Goals โ€‹

  • One dated file per day that holds the whole day: her tasks and the agents' tasks together.
  • Every task carries enough to be dispatched without re-derivation: description, skills to invoke, and a copy-pasteable handoff prompt.
  • Deferred work survives the night in a named place, not in an agent's head.
  • A close-of-day report that is written because the day ended, not because someone asked.

Non-goals โ€‹

  • Not a replacement for GitHub issues. Issues track units of work across days; the agenda tracks one day.
  • Not a project tracker. The alpha north star and the issue backlog stay where they are.
  • Not synced memory. Memories stay out of scope (#654).

Design โ€‹

Location: ~/.agents/context/lantern_app/agenda/<YYYY-MM-DD>.md

New folder, her word. boards/pm/ freezes with its two historical files intact; nothing is deleted.

One dated file per day, one stable page to look at. agenda/agenda.html becomes the single reference: it keeps the existing artifact URL forever and always renders TODAY's dated file. The markdown files are the append-only record; the page is the view onto whichever one is current. That way there is exactly one link to bookmark, one link to send, and it never rots (operator decision, 2026-08-19).

Dated and append-only, per #862: two machines' snapshots of "now" cannot merge, so there is never a mutable agenda.md.

Structure, the five sections she specified, in order:

markdown
# Agenda: 2026-08-19 (Wed)

## 1. Task list          One line per task. Owner, status, link. Hers and the agents' in one list.
## 2. Work log           Append-only, timestamped, written as it happens.
## 3. Task detail        One block per task: description, skills to use, handoff prompt.
## 4. Parked             Not today. Each with why it parked and what would unpark it.
## 5. Report             Written at close: what shipped, what did not, what carries to tomorrow.

The handoff prompt is the new artifact. Today a dispatch is a chat message that evaporates. In the agenda each task's detail block ends with a fenced prompt block carrying: the worktree and theme, the branch, the scope edges, the skills to invoke, whether any permission-sensitive step is authorized, the one-line ack requirement, and the wrap-up self-improve instruction. That is exactly the day-plan dispatch content, made durable and re-sendable.

Lifecycle. Sections 1 and 3 are written at dispatch. Section 2 is appended all day at every material event. Items move to 4 when deferred, with the reason. Section 5 is written at close. Tomorrow's PM opens yesterday's file and reads sections 4 and 5 before writing anything.

Write-through stays as it is today: commit and push the context home at every material write, not only at the bookends, because sessions drop off mid-day and pushes there are free.

Key decision: agenda replaces the board file โ€‹

Operator decision, 2026-08-19. Two dated files covering one day would drift against each other, and the board's own content is already a subset of the agenda's sections 1, 2, and 5.

Decisions (operator, 2026-08-19) โ€‹

  1. A handoff prompt is written by hand and links its issue. Not generated from the issue. The prompt carries scope edges and permission state that no issue body holds.
  2. The close-of-day report lives in the dated file. The page stays a live view of today. One link that always shows current state; past days are read from their files.
  3. A carried-over task gets a fresh detail block each day. She never has to open yesterday's file to know what a task is. The duplication is the point.

Part 2: Context-entry optimization โ€‹

Problem, measured โ€‹

Static context loaded into every session, on every turn:

SourceApprox tokens
AGENTS.md19,548
MEMORY.md index3,715
Operator Voice output style1,976
CLAUDE.md (project)831
CLAUDE.md (global)384
Total26,454

Two specific findings inside that:

The voice rule loads twice. 28 of the 30 non-blank lines of the AGENTS.md Communication Style section appear verbatim in the generated Operator Voice output style. Both load every turn. Roughly 1,900 tokens of pure duplication.

AGENTS.md accumulated rationale it forbids. Its own Communication rule says documentation states what IS, not why, and that rationale belongs in the plan, the issue, or git history. AGENTS.md itself carries incident narratives, worked examples, and dated post-mortems inline. The Non-Negotiable Rules section is 1,987 words for 21 rules. That is the single largest compressible block, and compressing it enforces a rule the operator already set.

Goal โ€‹

AGENTS.md becomes the contextual overview and the router (operator direction, 2026-08-19). It orients an agent and points at where the detail lives. Long procedural content moves into skills, which load only when invoked.

Measured: how skills actually load (2026-08-19) โ€‹

Scanned 13 session transcripts, 1,186 real operator turns. Counting only turns where a skill invocation was the model's FIRST tool call, so the routing decision is attributable to that message:

  • 42 turns opened with a skill invocation.
  • 19 of those, the operator had named the skill.
  • 23 of those, she had not. Clean examples: "Lets build it" loaded script-wiring; "Why did u open a PR when it isn't 6pm yet?" loaded self-improve; "I agree with the structural reco, greenlit" loaded decision-log; "Lets try the fix" loaded pr-workbench.

The router is the description block: every skill's description is always in context (approx 3,462 tokens for 29 repo skills) while the bodies are not (approx 51,755 tokens if all were loaded). Descriptions are 6.7% of the weight, which is the whole reason this trade works.

What this does NOT prove, stated plainly. Autoload is model judgment. The measurement shows skills DO load unprompted; it cannot show how often one is MISSED, and the miss rate is the only number that matters for a rule whose violation is expensive. So there are three tiers of reach, not two:

TierMechanismFires
1AGENTS.md, CLAUDE.md, output style, hooksalways, no judgment
2Skillson description match, observed 23 of 23 attributable turns
3Slash commandsonly when typed

Tier 1 is the only guaranteed one, and a hook is the only tier-1 mechanism that can also BLOCK rather than merely inform.

The deciding test (the core of this spec) โ€‹

A rule can move into a skill only if an agent cannot violate it without knowing it is in that domain.

  • "How to add a Cloud Run service" is safe to move. You cannot add one by accident, so a router line plus the cloud-service skill is sufficient.
  • "Never write a CI-skip directive in a commit message" is NOT safe to move. An agent writing a commit message may never invoke a skill, and the violation happens inside an action it does not recognize as specialized. It stays in AGENTS.md in full.

And the tier-1 corollary: a rule that both must always apply AND is mechanically checkable does not belong in prose at all. It belongs in a hook or a CI gate, with a one-line AGENTS.md pointer for the agents hooks do not reach. The branch guard and the PR-ready guard are already this shape; the migration should look for others rather than settling for a longer paragraph.

Everything else follows from that one question. The corollary: what stays in AGENTS.md stays as the rule text only. The incident that motivated it moves to the linked skill, issue, or git history, exactly as the doc-messaging rule requires.

Proposed disposition โ€‹

Measured current sizes, with a target. STAY means always-on. MOVE means a router line in AGENTS.md plus the body in a skill.

SectionWords nowDisposition
Non-Negotiable Rules1,987STAY, compressed to rule text; narratives to skills and issues
Architecture1,465MOVE to a new repo-map skill
Communication Style1,350DELETE, duplicate of the output style; one router line
Operator Preferences949STAY, compressed; rationale to the decision log
Key Conventions761SPLIT: em-dash and doc pattern stay, rest moves
Helping a New Contributor636MOVE to a skill
Testing574MOVE to a skill
Relay authorizing rules by QUOTATION488MOVE to a new authorization skill
Local Dev Ports476MOVE to repo-map
Linter Organization406MOVE to a skill
UI Conventions (Admin Portal)394MOVE, the design skill already owns this
A permission is real, current, scoped367MOVE to authorization
Relayed Decisions Between Sessions351MOVE to authorization
Common Commands273MOVE to repo-map
Never Bypass a Codified Rule259STAY, compressed
Project Overview173STAY
Naming Origins157STAY, compressed
Product and Privacy Axioms145STAY
Skills142STAY and GROW, this becomes the router table

Target: roughly 11,400 words down to under 3,000, so about 19.5k tokens down to about 5k. Combined with dropping the duplicated voice block, roughly 16k tokens returned on every turn of every session.

The mechanism: one source, two emissions โ€‹

Do not hand-maintain a summary next to a body; that is the drift the whole .agents/ compiler exists to prevent. Instead npm run sync:agents gains a frontmatter key so one rule source emits both forms:

yaml
agentsMd: router          # full | router | none
skill: authorization      # where the body goes when agentsMd is not full
  • full renders the whole body into AGENTS.md, as today.
  • router renders only the one-line router: sentence. AGENTS.md already carries a hand-authored heading above each marker pair, so the block must not emit its own.

Shipped as full and router only. none and skill: are NOT implemented: parseRule rejects an unknown agentsMd, and no rule body is auto-written to a skill. The two skills this work created were hand-authored, which is why they read better than a generated dump would. Corrected after /code-review max found this section describing both as decided, 2026-08-19.

The existing sync:agents --check gate in npm run validate and CI keeps it honest in both directions.

Risks, named โ€‹

RiskWhy it is realMitigation
A moved rule stops firingSkills load on invocation; a rule in a skill is silent until thenThe deciding test above. Anything violable-without-knowing stays full.
The router line is too weak to trigger the skillAn agent reads "see the X skill" and does notRouter lines name the TRIGGER, not the topic: "before writing any commit message, load X"
Compression deletes a hard-won lessonThe narratives record real incidentsNothing is deleted. Every narrative lands in the skill, the issue, or stays in git history, and the migration is diffed section by section.
Non-Claude tools lose a ruleAGENTS.md feeds Gemini tooVerified: Copilot and Cursor already receive every rule as its own path-scoped file, independent of AGENTS.md. Gemini reads AGENTS.md, so Gemini sees the router. Accepted.

Decisions (operator, 2026-08-19) โ€‹

  1. Architecture keeps a short map, roughly 10 lines, and the detail moves to a skill. An agent stays oriented instantly; the breakdown loads when someone is actually working in it. Saves about 1,300 words per turn.
  2. Operator Preferences stay full, with the backstory trimmed. Every preference survives verbatim. The paragraphs naming which incident produced each one move to the issues and git history, which is what the doc-messaging rule already requires. Roughly halves the section without losing a rule.
  3. The MEMORY.md index moves to #927, where the rest of the memory corpus is being decided. Not this spec's call.

No open questions remain. The spec is decided.

Built with VitePress