codebase-trio-mono

name	codebase-trio-mono
description	Single-conversation role-cycling variant of codebase-trio — one tmuxllm agent performs writer and reviewer roles in sequence, with role briefs loaded substrate-purely from roles/*.md
capabilities	["shell"]

Codebase Trio Mono

Single-tmuxllm-process counterpart to codebase-trio. Same task (one codebase journal entry), same context bundle (prepare_context.sh is shared), but ONE agent does both phases inside one conversation, loading its next role from the filesystem with cat.

What this exists to test

The substrate-purity claim says role specialisation can be done with nothing but cat $TMUXLLM_SKILL_DIR/roles/<role>.md. codebase-trio is the multi-process IPC version: two tmuxllm processes each get a fixed role via their goal prompt. This skill is the single-conversation version: one agent, two roles, switched by reading a role-lens file mid-session.

The empirical question — does in-conversation role cycling cost less or more than two-process IPC for the same task? — is what running this against codebase-trio via tools/skill_ab.py will answer.

Hypotheses, written before any data:

• For mono: no second-process startup tax (system prompt + tool schemas), no FIFO handoff, the reviewer has full context of how the writer arrived at the draft (could review more skeptically).
• For pair: isolation — the reviewer can't be biased by the writer's reasoning history. Two short conversations may compress better than one long one if cache reuse is asymmetric.

Procedure

1. Phase 0 (deterministic, no LLM): prepare_context.sh (shared with codebase-trio) emits $WS/context.md.
2. Phase 1 (one LLM session, two roles): start a single tmuxllm with a meta-goal that says: load roles/writer.md, do that part, then load roles/reviewer.md, do that part.
3. The orchestrator waits for the agent to exit. Final entry is at $WS/final.md; copied to $JOURNAL/$(date +%Y-%m-%d).md.

Run

tmuxllm-skill run codebase-trio-mono

Env vars (override defaults):

• TMUXLLM_PROFILE — provider profile (default: openrouter-gemini-3.1-flash-lite)
• REPO — codebase to analyse (default: $PWD)
• WS — workspace dir (default: /tmp/codebase-trio-mono)
• JOURNAL — journal output dir (default: $HOME/.local/share/tmuxllm/journal)

Channel

$TMUXLLM_SKILL_DIR/roles/writer.md     ← role lens, loaded by the agent via cat
$TMUXLLM_SKILL_DIR/roles/reviewer.md   ← role lens, loaded by the agent via cat
$WS/context.md                 ← prepare_context.sh output
$WS/draft.md                   ← writer's note (intermediate)
$WS/final.md                   ← reviewer's published entry

No FIFO. The agent transitions between roles by reading its next role brief from the filesystem.

What this exercises that codebase-trio doesn't

• Substrate-pure role specialisation. A role is a markdown file the agent literally cats when it's time to switch. No framework-side concept of "role." If the agent is competent, it can switch roles by reading a file.
• In-conversation role transition. The reviewer's review happens in the same LLM context as the writer's drafting. This may be cheaper (no re-priming) or worse (bias toward defending the draft); the A/B will tell us which.

Pitfalls specific to this design

• Bias toward self-validation. A single LLM that just wrote a claim may be reluctant to refute it as the reviewer. The reviewer role brief leans hard on "be skeptical, treat the draft as if a stranger wrote it."
• Conversation-length tax. Two roles in one conversation produces a longer context than either role alone. If the bundle + draft + reviewer's source-file lookups exceed cache-friendly sizes, mono may pay more than pair.
• Role transition discipline. If the agent doesn't actually cat the reviewer lens (or paraphrases it from memory), the transition is performative rather than real. The meta-goal explicitly tells the agent to read the file, not recall it.

Empirical comparison

python tools/skill_ab.py \
    --skill codebase-trio-mono \
    --scratch-goal "(same scratch goal as codebase-trio A/B)"

Then compare both arms' billable_tokens against codebase-trio's. The within-skill comparison (mono vs pair) is more informative than either arm's amortization ratio alone.