chief-of-staff turns one long session into the manager of a long-running goal. It tells the agent it is a chief of staff and the Directly Responsible Individual for that goal: the one who owns it.
It thinks on two tracks at once:
Tactical: how do I finish the task in front of me?
Strategic: how do I change the environment so the next task goes better?
It does no work itself. All work goes to subagents, helper agents that each start with a fresh context window. They run in the background, so the session stays free to talk with you. Messages to them are short and carry context pointers, such as research notes, earlier commits and wiki pages, instead of pasted copies.
Its memory lives in a wiki: a folder of linked Markdown pages that outlives the session.
When to use it
You have one goal that will take a long time, with no Spec or Ticket list yet.
You want to stay in conversation with one session while helpers do the work.
You want the agents' environment to get better as you go: tighter APIs, lint rules, written coding standards.
You start it yourself by typing /chief-of-staff. The agent never picks it on its own.
When not to use it
When the goal is a Spec already split into Tickets, use its look-alike implement-spec. That treats the Tickets as a task graph and finishes with the whole Spec on one integration branch. chief-of-staff pursues a long-running goal, with no task graph and no integration branch.
When you want to supervise workers with blocking questions and tracked results, that's Orca's orchestration Skill, not this one.
What it needs to start
A long-running goal you can describe.
A place for the wiki. If the goal has no wiki yet, it agrees the location with you before writing to it.
A harness that can run background subagents. Schedules are suggested only where the harness allows them.
What it creates
Whatever the subagents build.
The wiki: an index.md listing every page with a one-line summary, and one page per thing, such as a decision, a recurring problem or a user preference. Every claim is dated, and a claim about code cites the commit it was true at.
Suggested recurring schedules, including a regular check of the wiki.
Changes to the environment that make the next task easier.
Going deeper
5 min read · Going deeper not read
Why it exists
Matt added chief-of-staff on 2026-10-05, in a commit he titled "Added experimental chief-of-staff skill". It still sits in his in-progress folder at the pin commit (2026-10-29). That folder's README calls its Skills "Beta" and says they "can change or disappear without warning". In-progress Skills also "get no docs pages". The README's own list leaves chief-of-staff out, so the folder listing is where it shows.
Matt framed it in its opening line on 2026-10-05: the session "will run for a long time, accruing tribal knowledge and helping you make long-term strategic decisions."
How it works underneath
The wiki is borrowed from Andrej Karpathy. His LLM wiki gist, llm-wiki.md (2026-04-04), starts from a complaint about chatting with documents: the model "is rediscovering knowledge from scratch on every question. There's no accumulation." His fix is a set of Markdown pages the model writes and keeps up, so "the wiki is a persistent, compounding artifact." Its index.md is "a catalog of everything in the wiki".
Matt's pull request #1304 (merged 2026-10-19, its text written with Claude Code) brought the idea in. It added the line "Tribal knowledge that lives only in your context is lost at compaction; the wiki is how it reaches the next session." It says "Matt asked for to keep its state in an LLM wiki, based on Karpathy's gist but without ." It kept as the catalogue, and the ingest, query and lint operations. It left out , the gist's schema layer, tooling such as Obsidian, and a fixed wiki location.
#1304's addition is "Write history, not the present". The wiki "never claims to describe how things are now, because it cannot keep up with the code." So the Skill bans writing "currently", "now" or "is" about code without a date or commit. Its lint step looks for "claims newer sources have overtaken".
The strategic track is an old idea too. The Skill says agents "thrive in the pit of success". Jeff Atwood's 2007 post credits Rico Mariani with the phrase. Atwood puts it this way: "a well-designed system makes it easy to do the right things and annoying (but not impossible) to do the wrong things". It's the same idea as Fix the environment, not just the code.
Fresh subagents are the newest part. Pull request #1341 (merged 2026-10-29) added "Start every subagent with a fresh context window." It explains: some Codex models fork the parent conversation, and "The fork inherits the parent's context window, which throws away the reason for using a subagent". That's Context hygiene applied to helpers.
A real example
On 2026-10-13 a user filed issue #1263 with numbers from a real run. They had used "a locally adapted copy of this skill in Codex", with background agents in Herdr. The chief of staff "kept polling and reporting no change even though coordinator events were already arriving."
Their log compared two equal windows of 714.5 seconds:
Before their patch, the model issued 10 waits on the same worker, across 10 turns.
All 10 came back empty.
It spent 550.1 seconds inside those waits.
After the patch, all three numbers were 0.
They were careful to call it "not a controlled benchmark of unmodified upstream".
Where it goes wrong
Polling instead of waiting for news. That's #1263 above. The Skill only says messages should be sparse. The issue asked it to set up callbacks. It was closed as not planned the same day. The reply, marked "generated by AI during triage", isn't Matt's own words. It said the Skill "is harness-neutral text", and that the reader's own copy or AGENTS.md is "the right home" for that plumbing.
Subagents that aren't fresh. Before #1341, none of the eight Skills it changed said "what context a subagent should start with". On a harness that forks, each helper would get the chief's whole long history. On Claude Code, which starts subagents fresh by default, "nothing changes".
The Skill itself moving. It's beta. The wiki section is ten days older than the pin, and the fresh-context line is the pin day's own change. Read the current SKILL.md before trusting any older note, this one included.
Try it
In your practice project (set it up first with keeping-track's Try it step if you haven't), install it on its own, since the plugin doesn't ship in-progress Skills: npx skills@latest add mattpocock/skills --skill=chief-of-staff.
Then, in the yoga-studio repo, type /chief-of-staff with a goal such as "keep the booking API's CI fast and green", and put the wiki at docs/wiki/ when it asks. After one session, open docs/wiki/index.md and the pages it lists, and check that each claim is dated and each claim about code cites a commit.
From snapshot/skills/chief-of-staff/SKILL.md, lines 53–55: “- API's and functions which are extremely constrained and limited - Lint rules which force correctness - CODING_STANDARDS.md files which let code reviewers enforce best practices”
From snapshot/skills/implement-spec/SKILL.md, line 11: “The goal is the entire spec implemented on a single integration branch, with every ticket resolved the way the issue tracker closes work.”
From snapshot/web/github.com/mattpocock-skills-issues-1263.md, line 82: “I used a locally adapted copy of this skill in Codex (GPT-6-Astra), with background agents in Herdr. CoS kept polling and reporting no change even though coordinator events were already arriving.”