AI field guide · Design — a full working day
← All guides
Guide 03 · full day

Lead and scale the work

Decide what Claude may access, where people approve, how work is checked and how the team recovers when something goes wrong.

~6 hours hands-on Bring 3 real recurring tasks Best after guides 1 and 2 Design your own workflow

A ~6-hour, hands-on day for someone who's done the first two guides and now wants to design their own workflows, connect Claude to the tools they already use, debug it when it drifts, and teach their team. Still framed for someone who will never write code by hand. Come prepared: bring three real, recurring tasks from your own week. You'll build real automation on these and leave with at least one running.

The day starts with your working rules, moves into live tools and automation, then finishes with review and team adoption. Once work runs without you watching every step, the controls become part of the job.

The four decisions a leader owns
  1. Access: which files and systems may Claude read or change?
  2. Approval: where must a person say yes before work moves?
  3. Evidence: what proof makes an output safe to use?
  4. Recovery: who owns a failure, and how does the team roll back?
One principle over the whole dayFrom Anthropic's Building Effective Agents: "build the right system for your needs." Sophistication is a cost. A workflow runs fixed steps you defined (the skill you'll build); an agent picks its own steps toward a goal. Almost everything today should be a workflow — predictable, easy to trust. And whichever you build, ground every step in real numbers and tool results, never its own assumptions.
Barry Zhang's test — workflow or open-ended agent?
◀ Workflow
steps you can map out · predictable · cheap · you stay in control
Open-ended agent ▶
ambiguous · high-value · worth the tokens · errors are catchable
1Complexity. Can you map the whole decision tree? Then just build it — a checklist beats an agent.
2Value. Exploration burns tokens. A 2-min reformat doesn't justify it; a quarter-end rebuild might.
3No blocking gaps. Can it do the hard part? If not — reduce scope, simplify, try again.
4Cost of a mistake. High-stakes & hard to spot? Short leash: read-only, or you in the loop.

Morning · make it yours ≈ 2 hrs

Morning · 2 hours

M1 · Persistent working rules (CLAUDE.md) (30 min). Past "ten tight lines." Two layers: ~/.claude/CLAUDE.md (global: "Explain technical choices in business terms; reconcile every revenue number to plan") and ./CLAUDE.md per project (the data quirks, the fiscal calendar, the output formats). Keep the main file short; pull in detail on demand with @path — e.g. See @fiscal-calendar.md for period definitions. Prune ruthlessly; a long CLAUDE.md is worse than a short one.

M2 · Saved methods (skills) (35 min). A skill turns a brief that works into a method you can run again with one command. It lives in a small text file inside .claude/skills/:

.claude/skills/week-readout/SKILL.md
---
name: week-readout
description: Turn a folder of deal-review notes into a structured weekly readout
---
Read every note in the current folder and produce week-readout.md with:
1. a 3-bullet summary per rep,
2. a table of every commitment (who/what/due),
3. the top 3 ranked risks.
Show me the commitments table for sanity-check before writing the file.

Now /week-readout runs your whole workflow. For a workflow with side effects you want to trigger manually, mark it so Claude only runs it when you ask.

The real reason skills matter — they're how Claude gets your expertiseBarry Zhang's framing: who do you want doing your taxes, the 300-IQ genius working it out from scratch, or the experienced accountant? A raw model is the genius — brilliant, but it doesn't know your fiscal calendar or comp rules, and won't learn them on its own. A skill is where you write that down once. Their goal: "Claude on day 30 of working with you is a lot better than Claude on day 1" — which only happens if you keep turning what you learn into skills. When you catch Claude redoing the same fiddly steps, tell it to save that as a skill for its future self (a skill can hold a small script as a tool, so the repeatable bit runs the same way every time).
Why a skill beats a saved note: it's dual-useAnthropic builds slash commands and skills for both you and the model — "everything is dual use." Write /week-readout and you get a one-click command and Claude now knows that's your standard way to do a readout, so it reaches for the same steps even when you ask in passing. A note helps you; a skill upgrades you and the tool at once.

M3 · Permissions and the risk model (30 min). Automation means Claude acts without asking each time, so you decide how much rope it gets — "diligence" made concrete. Default asks before edits and shell commands. Auto-accept edits / auto mode = fewer interruptions, a classifier blocks the risky stuff. Allowlists permit specific safe commands. Sandboxing gives OS-level isolation. The rule: loosen permissions in proportion to how reversible the work is. Drafting a doc? Let it run. Writing to a real system? Stay in the loop.

Before lunch — 10 minutes
  1. Pick the brief you reuse most.
  2. Save it as .claude/skills/<name>/SKILL.md.
  3. Run the slash command once on real files.

Your first skill exists and runs before the afternoon builds on it.

Midday · connect it to your real tools ≈ 2.5 hrs

Midday · 2.5 hours

D1 · Reliable save points (Git) (30 min). Git is a system that records versions of a folder, so you can return to an earlier version after an experiment. Save a version before you experiment, so you can always get back. Claude handles the Git commands for you — "commit this with a message", "what changed?", "undo the last change."

Two kinds of undoClaude Code has its own checkpoints — /rewind or Esc Esc — but those only track Claude's own edits, not a real backup. Git is the real one.

D2 · Connect to live systems (MCP) (50 min). Model Context Protocol, or MCP, is a standard way to connect Claude to tools such as Notion, Slack, a database or Google Drive. It lets Claude work on live data instead of hand-exported files. You add a connector with one command pattern, claude mcp add … (the exact line comes from that tool's MCP setup page). Then you just ask:

pull this quarter's closed-won from the CRM and reconcile it against the board number in
our Notion finance page. flag any region that's off by more than 5%.

The honest framing: MCP is the highest-payoff and the fiddliest part of the day. Setup varies per tool — budget patience; once a connector's in, it stays.

Use the simplest connection availableA command-line tool is a small program controlled by typed instructions. When a reliable one already exists, it may be simpler than adding an MCP connector. GitHub is a clean example: its gh tool already gives Claude what it needs. A CRM or Notion may need an MCP connector instead.

Two rules that keep connectors from biting you — both from Ruben Hassid, who lives in this setup daily:

Read-only first, and toggle them like a kitchen tap"Read-only first. Watch how Claude uses it for a week." Give a new connector permission to look, not to write, until you trust what it does with your live data. And don't leave every connector on at once — each one it can see eats working memory. Turn on the two or three you need for this task and leave the rest off, the way you don't run every tap in the house at once. The stack he gets the most from is a trio that compounds: meeting notes + email + team chat = the context layer for almost any revenue question.

Once a connector's in, the prompts are the same plain English — now pointed at live systems instead of a stale export:

from the CRM, list every deal in stage "Proposal Sent" that hasn't moved in 7+ days.
for each: owner, amount, days stuck. sort by amount.

That one query — Ruben's, lightly adapted — is a Monday-morning pipeline review you used to build by hand, now a sentence.

D3 · Automatic checks (hooks) (25 min). Saved instructions guide Claude; a hook runs a fixed check at a set moment. A useful example is a quality gate: after any file with revenue numbers is written, automatically run a reconciliation check; or log every output to an audit trail. You don't write the script — ask Claude to, then /hooks to see what's configured. The sharper version the Claude Code team uses is a stop hook that won't let a run finish until a condition's met — their line is "if the tests don't pass, keep going." Yours: don't call this done until the numbers reconcile to plan. The check stops being something you remember and becomes something the workflow can't skip.

D4 · Build automation on your second real task (25 min). Put M2 + D1–D3 together: build your second task as a skill, put its workspace under git, wire one check. Run it. This is the template you'll copy for everything else.

Afternoon · scale, debug, make it a team thing ≈ 2 hrs

Afternoon · 2 hours

A1 · Context economics and model choice (25 min). Tokens cost money and attention — long sessions are slower, pricier, worse. /clear between tasks, /compact <focus> and /btw for asides are now a cost lever, not just a quality one. Match the model to the job (/model to switch) — a data clean-up doesn't need the horsepower of designing a comp plan. Think of it like staffing: you don't put your most expensive strategist on data entry.

A2 · Debugging — what to do when Claude goes wrong (30 min). It will drift; the skill is catching it fast. Interrupt early (Esc the moment it heads wrong). The two-strike rule: corrected the same thing twice? Stop, /clear, rewrite the brief. Make it show its work. A clean answer with no evidence is a red flag, not a result. Rewind (/rewind) to roll back and try a different approach. Ask Claude to understand Claude: when a skill or brief keeps misfiring, paste it back and ask "is anything here ambiguous? why did you do X? what would help you get this right?" (Barry Zhang's team debugs their own prompts this way). And think like your agent: most "why did it do that?!" moments dissolve once you remember it only knows what's in its context window. Missing context causes most failures. Know the five failure patterns and name them: kitchen-sink session, correcting-over-and-over, over-specified CLAUDE.md, trust-then-verify gap, infinite exploration. Naming the failure tells you the fix.

A3 · Parallel helpers (sub-agents) (30 min). A sub-agent is a helper Claude starts with its own clean working memory; it does a chunk of work and reports back just the result, so your main session never fills with detail. That one property is what makes the patterns below work — the people who built Claude Code use them constantly. Steal them by name:

Writer / reviewer
builderfresh reviewer
One session builds the comp model; a fresh one reviews it for holes.
Clean eyes catch what the builder rationalised. Anthropic runs this in their own code review.
Finders → checkers
flag gapsdrop false +
One pass flags every region whose number won't reconcile; a second pass throws out the ones that aren't real.
Real exceptions, no drowning in false alarms.
Opposition
rep's casecompany's
Two sub-agents argue opposite sides of a discount exception or quota appeal; you read the fight.
The disagreement is the analysis. (Anthropic's example: filing expenses.)
Fan-out
task×40
The same task across many files at once — re-format 40 regional exports in one go.
Test on two first, then run the batch.
Low-tech parallelismWant two Claudes running at once without a fancy setup? Cal Rueb's trick: have one write a handoff to ticket.md, then open a second and tell it "read ticket.md, another analyst left you this." A shared file is all the coordination you need — Anthropic engineers run up to four at once this way.

A4 · Make it a team capability (20 min). Where to start: your noisiest workflow — the heuristic from Anthropic's own engineering leadership. Pick the weekly grind everyone groans about, and ask whether it still serves its purpose before you automate it. The win is obvious there and the team buys in.

  • Check ./CLAUDE.md and .claude/skills/ into git. A new hire inherits the context and the best workflows on day one.
  • Ship a settings.json that pre-allows the safe commands and blocks the dangerous ones, so everyone gets a working setup without permission fatigue.
  • Delegate the spread too: master one workflow, teach it with a short Loom plus the skill file, then hand it over.
  • Measure cycle time, escape rate, and whether people actually like using it. Raw velocity flatters the wrong thing.

Retrain for judgment. Cat Wu (head of Claude Code product): "as code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write." The failure mode she names: delegating the check to a sub-agent and never checking the sub-agent. (The Legal / Growth / Data-science wins at the top of this page are the proof to show a skeptical team.)

Capstone — ship one workflow you'll use Monday (40 min)
  1. Take your third prepared task.
  2. Build it as a skill, in a git-backed workspace, with one real check (hook or prompt-level).
  3. Connect it to one real tool via MCP if access allows, or run it on real exported data.
  4. Run it end to end and write a 5-line README so a colleague could run it too.
The honest limits — don't skip this
  • MCP setup is the rough edge. It varies by tool and can fight you. Budget extra time and don't feel bad about it.
  • Automation amplifies mistakes. An unwatched workflow with a bad check ships bad numbers at scale. The checks and the reviewer pass are the point.
  • The tool moves fast. Re-check code.claude.com/docs before you teach this to others.
  • The judgment stays yours. Claude does the work; you own the call.