The full stack, assembled

The shift the whole series has been building: from asking Claude things to operating a system where context, methods and jobs each live in the right layer.

Notice what's not on the list: effort. Your hours move up the stack, into briefing and reviewing, and the doing increasingly happens below you. That's the whole trade.

When work is a list of similar items, don't process it; parallelise it. One instruction into Dispatch becomes one child task per item, all running at once (guide 06, section 07).

The recognition skill is spotting list-shaped work. It hides in plain sight:

1. A sweep: "go through my email and Slack; everything I've committed to, with deadlines, cross-checked against my calendar" (the cross-tool pattern, guide 04).
2. A batch: six shortlisted companies, one research brief each, ranked summary at the end.
3. A chore: a folder of accumulated mess, filed by the rules in your folder instructions.

Notice the play's dependencies: connectors granted (04), folder rules written (06), house templates encoded as Skills (05). A fan-out spends capital that setup deposited; without the setup, it just parallelises confusion.

Delegated work comes back through you, on purpose. Every fan-out gets a review pass, and dependent work is chained through your approval rather than left to run blind. This isn't overhead; it's the job now.

• Read the reports, open one deliverable per batch and actually look (guide 06's spot-check rule).
• Corrections go into the child task, where its context lives, not as fresh top-level instructions.
• Chain the next step by naming the source: "take the ranking from the summary task; draft outreach for the top two, using the outreach skill".
• Promote the durable stuff. The ranking that will matter in a month goes into the client project's knowledge base (guide 03: chats are where things happen; the knowledge base is where things live).

No deliverable starts cold. Before writing a word, the play is choosing where to write it, because the location does half the briefing for you.

• A proposal starts inside the client's project, so it opens knowing the brief, the contacts, and the never-promise-dates rule (03). The proposals Skill supplies structure and boilerplate (05). Your job shrinks to the judgement calls, which is the correct size for it.
• A deck starts on the design system, briefed art-director style with the destination named: "edited in PowerPoint by the sales team" (guide 08). On-brand from slide one, exportable by design.
• Everything ships through an adversarial pass: "be the procurement director looking for reasons to say no" (guide 02, section 06). Thirty seconds; catches what your optimism can't.

Big mechanical jobs get a checkable definition of done, then run unattended. That's Claude Code territory: precision, scale, and a finish line a machine can verify.

• The shape of the job: hundreds of files to a naming scheme, the same edit across dozens of documents, a folder tree reorganised with an index. Big, boring, rule-based.
• The play: plan mode first (blast radius), then a /goal with a checkable condition: every file matched, index complete, nothing deleted, stop after 25 turns (guide 07, section 11).
• Sized honestly: a swarm or ultracode is for when coverage is the metric (audits, reviews); a tidy /goal is for when the job is big but mechanical. Resist the urge to use the fun tool.

The third time you run the same job, it stops being yours. Recurring work with a stable recipe becomes a Routine (guide 07, section 11): it reads the inputs, applies the Skill that holds your format, files the output, on infrastructure that doesn't need your laptop open.

• Classic hand-offs: the weekly status report, the monthly numbers summary, the inbox-to-actions sweep that Play 1 proved out.
• Your remaining job is reading the output, plus the one human paragraph at the top that no automation should write.
• The promotion rule applies to automations too: anything in the output that changes a plan goes into the relevant project's knowledge base, or the next fan-out won't know about it.

The plays are moves; combos are where it gets absurd. These are real working combinations, not thought experiments, and each one exists because the layers compose: any agent can use any Skill, any surface can reach any connector, and Dispatch can drive all of it from a phone.

The walking deploy

Ship a real change to a live app without touching a computer. From your phone, mid-walk:

1. Dispatch spawns a Claude Code session pointed at the app's repo. First instruction: read the codebase and the part we're changing, report back, change nothing (guide 07's read-only opener).
2. You discuss the change conversationally, walking. The session has the code in front of it; you have opinions. This is a design meeting where one attendee can also do the work.
3. Approve the plan; it implements, tests, and deploys through the project's own tooling — the deploy CLI it found in the repo, the checks in CLAUDE.md, the allowlisted commands you granted back on setup day (07, section 06).
4. You come home to a shipped change and a transcript of exactly what happened.

What makes it possible isn't magic in the moment; it's that the repo carries a CLAUDE.md, the permissions were pre-granted, and the machine was awake. The walk is the payoff of the setup.

The pyramid

One message, an organisation of agents. Dispatch fans out four Claude Code tasks (Play 1); each task then spawns its own swarm of teammates or subagents for its job (07, section 10). You're now three layers up: you brief one orchestrator, it briefs four leads, they each run a team. The rules that keep it from being an expensive mess:

• Pyramid only what's independent. The four tasks must not need each other's output; anything dependent goes through the relay (Play 2) instead.
• Every layer needs a finish line. Tasks with /goal-style checkable conditions finish; tasks with vibes multiply the vibes by the number of agents.
• Count the tokens honestly. A pyramid can burn a week's allowance in an afternoon. It's for the day the backlog genuinely is four parallel jobs deep, not for feeling powerful.

The evidence pipeline

Research to boardroom without the middle being you: a Deep Research run with a proper brief (guide 02, section 09) lands in the client project's knowledge base (Play 3's promotion rule); the deck is then built inside that project on the design system (guide 08), so every slide can cite the evidence base it sits on; the adversarial pass interrogates it; PowerPoint export ships it. Four guides, one flow, and the humans only touched the judgement calls.

The self-briefing meeting

A Routine runs before your weekly client call: sweeps email, Slack and the tracker via connectors (guide 04), builds the one-page brief from your meeting-prep Skill (guide 05), files it where your phone can open it. You walk in current; nobody prepared.

Twenty minutes, monthly, calendar-blocked. The play that keeps the other five compounding instead of rotting, because stale context is the only real failure mode of everything above.

1. Memory: open it, prune what's no longer true (03).
2. Connectors: remove what you haven't used (04).
3. Projects: retire superseded documents; update the "current focus" line in instructions (03).
4. Skills: fold in this month's corrections; the second time you fixed the same thing by hand was the signal (05).
5. Design system: same rule, visual edition (08).

The series in ten lines. Print this one.

1. Upload, don't describe; show, don't adjective. (01, 02)
2. Context in projects, methods in Skills, reach through connectors. Narrowest layer that's true. (03, 04, 05)
3. Supervise the first run of anything; dispatch the tenth. (06)
4. Fan out the list-shaped, relay the dependent, spot-check every batch. (06)
5. Big mechanical jobs get a /goal with a checkable finish line. (07)
6. Design from a system, brief like an art director, name the destination. (08)
7. Adversarial pass before anything ships. (02)
8. Stack the plays: encoded context + pre-granted reach + a checkable finish line composes into combos nobody has to supervise. (this guide)
9. Promote durable outcomes; chats are events, knowledge bases are records. (03)
10. Audit monthly. Corrections become rules; the system compounds. (this guide)