How it works: CoCo Manager

The system at a glance

Three rhythms (a daily session loop, meetings, and a weekly cycle) all write into the same four note stores. Skills that capture feed the stores; skills that brief you read back from them. You learn them in that order; you don't need all of them on day one.

Because every skill writes as it works, the stores double as an audit trail: each decision, dead end, and result the agent captured is there to inspect, question, or correct, so the agent can do the work while you stay able to verify what it did and why, rather than taking its output on faith.

How you and the agent split the work

You decidethe calls that shape the work: scope, direction, methodology, the key design decisions, and when it's good enough. The agent doesn't settle any of these on its own, and you're the one who catches the blind spots.

The agent proposesplans, approaches, design decisions, and trade-offs, laid out for you to accept or redirect before the work starts.

The agent does the workthe building, drafting, and documenting, recording each decision in the trail as it's made.

The agent verifies as it goeschecking claims against evidence rather than just asserting them, and double-checking its work before it's acted on, so mistakes surface early instead of compounding. /audit turns this into an explicit, separate pass when it matters.

The agent flagsits own soft spots (a claim it couldn't verify, a check it skipped, two findings that disagree) instead of quietly papering over them.

Running a session with /co-work puts this division in place: Claude adopts the collaborator role for the rest of the session (decomposing the task across subagents, reviewing and verifying as it goes) and logs the work in a sublog under the day's worklog, while you set scope and direction.

Capture skills (left) write into your notes; briefing skills (right) read back from them. /end-session and /process-meeting also file decisions and tasks into state/ and planning/; /build-week plans from the indices.

Two note types, one design principle

state/: what you know

Atomic items for durable facts: decisions, findings, open questions, hypotheses, assumptions. One fact per file. A generated INDEX.md lists them all so you (or Claude) can scan at a glance, then drill into just the one you need.

planning/: what you do

Atomic backlog items (tasks, experiments, chores) with status, priority, and horizon. Same shape: one item per file, one generated INDEX.md for a fast prioritization scan.

Why atomic + index? The LLM never has to read every note to answer "what's open?" It scans the small INDEX.md and opens only the items that matter. That's what keeps context manageable as the project grows. (More in Deep dive → Concepts.)