chief-of-staff-kit
One chief of staff for Claude Code and Codex. It is a single main loop that
plans the work, does the work and keeps the context. Your divisions and crafts are
skills it opens when it needs them, three helpers run in their own window
when a separate context changes the result, hooks hold the actions you never
want taken without a yes, and golden tasks, run for you in a test mode where
nothing is sent or changed, tell you whether a change helped. A short interview
fits all of it to your work. No two installs look the same.
Explore the live system
Open the live, read-only BluPlai whiteboard
to explore the native, editable release workflow from the private AIOS to the public
kit. It needs no BluPlai account, and changes to the board appear there live.
What you get
chief-of-staff ← the main loop: plans, does the work, keeps the context
│
loads a skill when needed ┼ calls a helper only when a separate context changes the result
│
division skills Business One · Business Two · … ← facts, people, voice, filing, open work
craft skills architecture · program-plan · problem-solving · decks · voice-scripts · growth
product-design · back-office · email · inbox · notes · memory-harvest
own-context skills web-build · video-edit · course-publish · content-engine ← run in their own context
helpers code-reviewer · verifier · researcher ← fresh window
hooks gates on your irreversible actions (a broken gate blocks too)
evals golden-tasks.md + golden.py: real tasks, run in test mode before and after any change
A division is whatever unit you run: a business, a department, a team, a
product line, a client book, or a person you manage. Each one becomes a skill:
the main loop sees a one-line summary and opens the full file (facts, people,
voice, filing, open work) only when the work touches it.
| Piece | What it is | Why it is that and not an agent |
|---|
| chief-of-staff | The main session (claude --agent chief-of-staff) | It holds the conversation from the first message to the result, so nothing is lost in a hand-off |
| Division skills | One per division, short, with referenced files | The division's knowledge is needed in the loop, not in a separate window |
| Craft skills | Twelve procedures: decks, email, back office, growth… | A procedure the main loop follows needs no context of its own |
| Own-context skills | Four tool-heavy jobs with context: fork | Their tool output (builds, renders, uploads) would flood the main window |
| code-reviewer | Fresh window, spec and diff only, effort: high | The builder's context would hurt: it shares the builder's blind spots |
| verifier | Drives the browser or app, knows only the user flow | Same reason: it checks what a user sees, not what was meant |
| researcher | Clean-window research helper | It needs nothing from the main loop, and its raw reading stays out |
| Hook gates | PreToolUse hooks with "onFailure": "block" | Hard rules in prose get forgotten; a hook runs every time |
| golden-tasks.md | Real tasks with "done" lines, run by golden.py in test mode | So "this is better" is a score, not an opinion |
Why one loop
Up to v0.5.0 this kit installed an org chart: a chief of staff that routed to a
lead per division, and leads that pulled in specialists. Every hop was a
hand-off, and hand-offs drop decisions. In the author's own use, the generic
helpers, forks and the code reviewer did almost all of the delegated work; the
named division leads were almost never called.
Anthropic's article Building agents: When to fold subagents into your main
agent loop
(22 October 2026) names the same failure modes in larger systems: context lost
at each hand-off, subagent sprawl, the "Frankenprompt" of conflicting rules,
evals that test one piece only, and latency (one customer's single loop ran
roughly twice as fast). Its rule is the one this kit now follows: fold a
subagent in, and keep it as a subagent only if the folded version scores worse.
The one question before any helper: does what the main loop already knows
help, hurt, or not matter?
- Helps → do it inline. This is the usual answer.
- Hurts → a fresh reviewer (
code-reviewer, verifier).
- Does not matter → a clean-window helper (
researcher).
- Several truly independent heavy jobs → forks in parallel; five or more
becomes a workflow.
Three recent Claude Code changes make this practical:
- Fork helpers (on by default in
-p, the SDK, desktop and VS Code from
2.1.302; in the terminal from 2.1.232). A fork inherits the whole
conversation and shares its prompt cache, but its tool calls stay out of the
main window. /subtask <task> starts one by hand.
- Skills survive compaction (2.1.304). The skill list is sent again after
compaction, so a long session keeps its divisions and crafts. Invoked skill
bodies are re-attached up to 5,000 tokens each and 25,000 in total, which is
why every skill here is short with detail in referenced files.
- Effort per helper (2.1.292). The main loop can run the reviewer at
high
and a quick lookup at low without a separate agent per effort level.
And hooks with "onFailure": "block" (2.1.295) mean a broken or slow gate
blocks the action instead of letting it through.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
