Other Sessions Brief the Chief

The Gap

The chief of staff coordinates the portfolio; it does not execute inside ventures. So the actual work — a company’s bookkeeping, a negotiation, a codebase — happens in other sessions, in other folders, with their own context. Those sessions learn facts the chief of staff should hold: a balance, a deadline, an open decision, a person who now matters. And for months they had no contract for handing them over. The first hand-off was ad hoc — a file dropped in the inbox by a session that happened to know where the inbox was — and it worked, which is how the gap became visible.

The Contract: Session-Brief

A global skill — installed at the user level, not inside any one project — that any session can invoke: /cos-inbox. It writes a structured capture into the chief of staff’s Efforts/inbox/:

---
handoff_kind: session-brief
source: <the session's folder or venture>
date: <YYYY-MM-DD>
---
## Facts learned
- …
## Decisions the owner still has to make
- …
## Deadlines and dates
- …
## People who now matter
- …
## Open questions for the chief of staff
- …

It is a capture like any other. The inbox triager does not touch it — session-briefs are handled by the chief of staff itself in the first phase of triage, because they routinely contain structural facts (a new person, a new project, a decision) that need the vault-writing authority only the chief of staff has. Each fact lands in the right note with provenance pointing at the brief; each decision becomes a concrete-action task; each question gets answered or surfaced.

Why Not Let the Other Session Write to the Vault Directly

Because then two agents write, and traceability collapses — the same reason curators do not write. The outside session knows its own work; it does not know the vault’s conventions, the current decision log, or that the person it met is already a note under a different spelling. The chief of staff does. The hand-off is a capture; the write is the chief of staff’s.

The Corollary: Skills Every Session Needs Live outside the Vault

A companion decision, learned from a different pain. A meeting-processing skill — transcribe a recording, diarise the speakers, extract the slides — lived inside the vault, so only a chief-of-staff session could discover it. But every actual producer of a recording is an outside session: the one that just sat through the call. That session would transcribe by hand, badly, for an hour, not knowing the skill existed.

So the skill moved out whole, to the user-level skills directory, self-contained, depending on nothing in the vault. The vault keeps a reference only: a decision record and a one-page note saying where the skill lives, what is in it, and how to change it. No copy of the code — a second copy would drift silently and the wrong one would get edited.

The test for where a skill lives: who invokes it? If the answer is “any session on this machine”, it lives globally and the vault points at it. If the answer is “only the chief of staff”, it lives in the vault.

What Flows the Other Way

Sessions also ask the chief of staff for things — “what’s the status of X?”, “who is Y?” — and the honest answer today is that they read the vault directly, read-only, because it is plain files. A more disciplined future has a small read-only query surface. Until then: plain files are the API, and that is most of why the vault is plain files.

Getting Started

Write the session-brief template into a global skill today; it is twenty lines. The first time an outside session finishes a piece of work, invoke it. Then watch the next triage: if the chief of staff filed every fact with provenance and turned every decision into a task, the contract works. If it created a bare task with no note behind it, that is a feedback-log entry.

#handoff · #skills · #sessions · #architecture