What landed recently

The pace Claude Code has been shipping at means a lesson written a few months ago is already incomplete. This one is a current-docs refresh — a pass over the features that have landed recently, in the rough order of how much they change day-to-day work. Nothing here replaces the earlier lessons; think of it as "what you didn't know to ask about yet."

Forks: a subagent that shares your context

The earlier subagents lesson made the case for delegation: run an investigation in a separate window, keep the raw file reads out of your conversation, get back a conclusion. It also named the shape of problem subagents are bad at: the ones that depend on what you and Claude just worked out together. A subagent starts fresh; your twenty turns of context don't come with it.

Forks close that gap. A fork is a subagent spawned with subagent_type: "fork" — it inherits your full conversation context, runs in the background, and shares your prompt cache (so it's cheap). The tool output stays in the fork's window; the answer comes back to yours.

Reach for a fork when:

• You want to delegate a research question that's grounded in the conversation. "What's left to ship on this branch?" "Are we on track to hit the perf budget?" "Which of these three implementations is closest to shipping?"
• The investigation would read many files and the output would balloon your context, but the answer itself is a paragraph.
• You want to keep talking to the main conversation while the fork works — the notification arrives in a later turn.

A few rules that save pain:

• Don't peek. The tool result includes an output file path for the fork's transcript; don't read it mid-flight. The point was to keep that output out of your context.
• Don't race. You know nothing about the fork's findings until the notification arrives. Don't predict the result; if the user asks, say the fork is still running.
• Write the prompt as a directive, not a briefing. The fork already has the context. Tell it what to do; don't re-explain what the situation is.

Workflow: deterministic orchestration

The Workflow tool runs a JavaScript workflow script that orchestrates multiple subagents in a specific shape — parallel, pipelined, phased. A workflow is a .js-shaped program with its own API (agent(), parallel(), pipeline(), phase()), runs in the background, and the harness notifies you when it's done.

The canonical use is "fan out, verify, fan in":

export const meta = {
  name: "review-changes",
  description: "Review changed files across dimensions, verify each finding",
  phases: [{ title: "Review" }, { title: "Verify" }],
};
 
const DIMENSIONS = [
  { key: "bugs", prompt: "Review for correctness bugs." },
  { key: "perf", prompt: "Review for performance issues." },
  { key: "style", prompt: "Review for readability." },
];
 
const results = await pipeline(
  DIMENSIONS,
  (d) => agent(d.prompt, { label: `review:${d.key}`, phase: "Review" }),
  (review) =>
    parallel(
      review.findings.map((f) => () =>
        agent(`Adversarially verify: ${f.title}`, {
          label: `verify:${f.file}`,
          phase: "Verify",
        }),
      ),
    ),
);
 
return { confirmed: results.flat().filter((f) => f.verdict?.isReal) };

The point isn't that this is more agents — it's that the shape is deterministic. You know every finding gets a verification pass; you know the three dimensions run in parallel (not serially); the pipeline operator means a dimension's findings start verifying as soon as that dimension's review returns, without waiting for the other dimensions.

Workflows are the right reach when the problem has real structure and you'd otherwise be hand-orchestrating a half-dozen Agent calls. For a single investigation, a plain Agent call (or a fork) is still simpler.

Monitor: streaming background output

If you've started a long-running process (npm run build --watch, a dev server, a test runner, a CI-like loop) with Bash({ run_in_background: true }), the question is how to stay aware of its output without blocking the main conversation on it.

The Monitor tool streams the process's stdout to Claude as it arrives. Every new line becomes a user-role message; Claude sees it the way it'd see any other notification. For "wait until this succeeds or fails," Monitor also supports an until-loop (until <check>; do sleep 2; done) that fires a single notification when the loop exits.

In short: Monitor turns polling into subscribing. The harness becomes event-driven. You keep talking; interesting output interrupts you.

Worktree isolation

An isolation: "worktree" option on an Agent call creates a temporary git worktree on a branch of its own and runs the agent against that isolated copy of the repository. If the agent made no changes, the worktree is cleaned up automatically; if it did, the path and branch are returned so you can review and merge the diff on your terms.

This is the cheap version of "try two directions in parallel":

• Spawn two worktree agents with different approaches to the same refactor; diff them when both return; pick one.
• Let an agent make broad edits for review, without those edits landing in your working tree until you've looked at them.
• Keep working in the main worktree on something else while the agent iterates.

The subagent still runs in your usual session; the filesystem is what's isolated.

Scheduling and coordination you might not know about

Three features that are quietly load-bearing once you know they exist:

• /schedule — set up a recurring cloud agent (a "routine") that runs on a cron schedule on Anthropic's infrastructure. Useful for "every morning, open my morning brief as an artifact" or "every Monday, triage open PRs."
• /loop — run a prompt on a recurring interval, or dynamically paced (the model decides when to come back). Good for "check the deploy every 5 minutes until it's green," "babysit this PR queue until I say stop." Dynamic mode uses ScheduleWakeup to pick its own cadence.
• Addressing other sessions — ListAgents returns the set of sessions you can SendMessage to: other local Claude sessions on this machine, cloud sessions you own, and (with Remote Control) your account's other sessions on other machines. Means an agent can coordinate another agent across devices or environments, not just within one process.

The useful mental shift is that "the agent" isn't necessarily a single process on your laptop. It's a set of addressable sessions, some on your machine, some in the cloud, some scheduled, and they can talk to each other.

Artifacts, plugins, and the smaller niceties

Some that are worth knowing exist without a dedicated lesson:

• Artifacts — publishable HTML pages with optional live capabilities (data, memory, chat callback, media). The artifact-design, artifact-diagramming, and artifact-capabilities skills cover the design rules; load them before authoring any artifact.
• Plugins — mods to Claude's own interface or behaviour (a panel, a band, a status line, a hook on tool calls). Authoring guide: plugin-authoring skill. Publish via PublishPlugin.
• Keybindings — customise ~/.claude/keybindings.json via the keybindings-help skill.
• Fewer permission prompts — the fewer-permission-prompts skill scans your transcripts, identifies the common safe tool calls you've been approving, and writes a tailored allowlist to .claude/settings.json.
• Project-scoped skills — skills can be scoped to a directory (apps/web:deploy); when both scoped and unscoped variants of a name exist, the one whose directory contains your current file wins.

None of these change the day-to-day shape of a conversation. They make the edges smoother, and they're easy to miss because they don't come up unless you go looking.

What to remember

• Forks (subagent_type: "fork") inherit your full context, run in the background, share your prompt cache, and hide the fork's tool output from your window. The fix for subagents' "starts fresh" limitation when the task depends on the current session.
• Workflow runs a deterministic multi-agent script (agent(), parallel(), pipeline(), phase()) in the background. Reach for it when the problem has real structure (fan-out + fan-in, dimensional reviews, pipelines). For a single investigation, a plain Agent call is simpler.
• Monitor streams a background process's stdout as notifications — turns polling into subscribing. Pair with Bash({ run_in_background: true }) for long-running work.
• isolation: "worktree" on an Agent call runs the subagent against a temporary git worktree. Cheap parallelism; review-gated changes; no cross-contamination with your working tree.
• The agent is not one process on your laptop. /schedule, /loop, ListAgents, SendMessage, Remote Control, and cloud sessions all mean "the agent" is a set of addressable sessions, some scheduled, some remote, that can coordinate.
• Smaller niceties: artifacts (with the three design skills), plugin authoring and publishing, custom keybindings, fewer-permission-prompts for taming settings, directory-scoped skills.