Claude Code Ultraplan: Plan in the Cloud, Run Anywhere

• Claude Code Ultraplan drafts plans in the cloud, lets you review them in a web editor, then runs anywhere.

• The Monitor tool streams background events into chat in real time, so Claude reacts to logs as they happen.

• /autofix-pr flips on PR auto-fix from the terminal so Claude watches a pull request, applies fixes, and pushes commits.

• /team-onboarding packages your local Claude Code setup into a replayable ramp-up guide a teammate can run themselves.

• The triangle of Ultraplan, Monitor, and /autofix-pr changes how a small studio loops through planning and review.

I run a 15-repo studio and the part that always breaks is planning. The new Claude Code bundle, shipped in Week 15 and just hitting wider rollout, finally treats planning like its own first-class step.

Claude Code Ultraplan and where it actually fits

Ultraplan is the headline. From the CLI, you type /ultraplan and a plan starts drafting in the cloud. A web editor opens in the browser, you review the plan there, leave comments, and decide where to run it. Either it runs remotely on a cloud-spun environment, or you pull it back to your machine and run it locally with the same context.

The detail that sold me: the first run auto-creates a default cloud environment. Earlier previews forced you through manual web setup before you could even try the feature. That gate is gone. Type /ultraplan, get a working environment, see a plan in the browser inside a minute.

Why this matters for a solo studio. Plans usually live in three places: my head, a scratch file, and whatever Claude is holding in context. When I switch repos, all three drift. Ultraplan parks the plan somewhere persistent and renderable. I can read it on phone, leave a comment after dinner, then come back and run it Monday.

It is still early preview. The web editor sometimes takes a second pass to render long plans, the cloud env defaults are generic (Node, Python, basic CLI tools), and there is no team review flow yet. But for a one-person studio, the loop already works: draft cloud-side, review browser-side, run wherever makes sense.

Concrete example from this week. I asked Ultraplan to draft a refactor of my blog syndication engine across 15 platforms. Plan came back with phased steps, a risk callout for Medium rate limits, and a clear rollback path. I commented on two steps from the browser, then pulled the plan local and ran it on my own machine because the credentials live there. Took 12 minutes start to finish, half of which was me reading.

One small workflow win nobody talks about: the cloud plan persists across sessions. Close the laptop, open it the next morning, the plan is still there waiting. The old loop forced you to either finish in one sitting or rebuild context from scratch. Persistent cloud plans dissolve that constraint, which matters when you have 15 repos and your brain rotates through them on a four-day cycle.

Monitor tool and why streaming logs change the loop

The Monitor tool is the quiet workhorse. It streams background events into the conversation as they happen, instead of waiting for a process to exit. Claude can tail a log, watch a build, follow a deploy, and react live.

Before this, long-running commands were a black box. You ran the command, you waited, you checked the exit code. If something went sideways at minute three of a seven-minute build, Claude only saw it at minute seven. With Monitor, Claude sees the warning when it lands and can decide to abort, retry, or branch.

I pair this with Ultraplan. The plan executes step by step. Each step that touches a long process (test suite, build, deploy, syndication run) gets a Monitor wrapper. If the test suite starts flaking, Claude sees the first failure and rolls back to the previous step before wasting six more minutes.

Three real uses from my week:

1. Vercel deploy logs streaming back into chat. When a build flagged an env var miss, Claude caught it at the warning line, paused the plan, and asked me to add the var. Saved a failed deploy.

2. Tail of git log --follow during a refactor across the studio repo. Claude watched commits land in real time and adjusted the plan when an unrelated file showed up in the diff.

3. Background sync of 184 blog articles to Hashnode. Monitor caught a 429 rate limit on article 47, paused the loop, and resumed once the window opened. No manual babysitting.

The honest catch: Monitor needs a process that actually emits useful output. If your script logs nothing for five minutes, Monitor does nothing for five minutes. Logging discipline pays off here.

/autofix-pr and what changes when Claude babysits the PR

/autofix-pr is the third leg. From the terminal, you flip on PR auto-fix. Claude then watches the pull request, applies suggested fixes from review comments, and pushes commits back to the branch.

This is not a magic merge button. It is a way to close the loop on the boring half of code review, where the comment is "rename this variable" or "add a null check" or "this string should come from the locale file". Claude reads the comment, makes the edit, runs the tests, pushes the fix.

What this unlocks for a small studio. I review my own PRs because there is no one else. Half the time my review note is "I'll fix that tomorrow" and tomorrow becomes Friday. With /autofix-pr on, I leave the comment and walk away. By the time I open the PR again, the fix is in and the diff is smaller.

Limits, because they matter. /autofix-pr only handles fixes Claude can verify. If the comment is architectural (rewrite this whole module), it flags for human review and stops. If the test suite breaks after the fix, it reverts the commit and asks for guidance. The guardrails are sane.

Pairs nicely with the Claude Blueprint setups I keep at /pages/claude-blueprint. The hooks I ship there already enforce brand and spacing rules, so when /autofix-pr pushes a commit, the hooks catch any drift before the push lands.

A note on quota. PR auto-fix runs on the cloud-side environment, not your local machine. Long PRs with many comments will burn cloud minutes faster than you expect. I cap mine at 30 minutes of auto-fix per PR before it hands back to me.

The other thing worth knowing: /autofix-pr plays well with the Monitor tool. When the auto-fix push triggers a CI run, Monitor streams the result back into chat so Claude knows whether the fix held. If the fix breaks CI, Claude flags the regression instead of moving to the next comment. That feedback loop, fix and verify in one motion, is the part that actually saves time.

/team-onboarding when you finally hire someone

The fourth piece is /team-onboarding. It packages your local Claude Code setup, settings, hooks, slash commands, project memory, into a replayable ramp-up guide a new teammate can run.

I am one person today. But every contractor I have worked with in the last five years has spent the first half-day asking "where is the brand file" and "what are your spacing rules" and "do you commit lockfiles". A /team-onboarding bundle answers all of that without me typing anything.

What it actually exports. Your ~/.claude skills, your project .claude/settings.json, your hooks, your CLAUDE.md memory files, and a step-by-step shell script that installs the lot. The teammate runs the script, their Claude Code matches yours, and they hit the ground running with the same guardrails.

Use cases beyond hiring:

• Onboarding a contractor for a one-week project. They get my setup for the week, hand it back at the end.

• Sharing a setup with another solo studio for review or trade. I pass them my hooks, they pass me theirs.

• Spinning up a fresh laptop. /team-onboarding is also a personal backup. Nuke and pave a new machine in 15 minutes instead of two days.

Honest gap. The package does not include API keys, env vars, or anything in .env. That is correct, but it means the teammate still has to wire credentials by hand. Worth knowing before you assume the bundle is plug-and-play.

I see this becoming the default way to share working setups. Right now I write CLAUDE.md files by hand for new projects (the /blogs/lab registry has a few of these). With /team-onboarding, that work compounds across the studio.

Bottom Line

Ultraplan, Monitor, and /autofix-pr are three tools but they are really one workflow. Plan in the cloud while you do something else, run it on your machine when context demands it, watch real logs stream back, and let Claude clean up the PR comments after. The loop tightens by 40 percent in my measurement, and the work I dropped on the floor (because planning was friction) actually gets shipped now.

/team-onboarding is the long-tail bet. Solo today, packageable tomorrow.

If you want a working starting point that already plays with these new tools, the Claude Blueprint at https://raxxo.shop/pages/claude-blueprint ships with hooks, skills, and slash commands that drop into the new Ultraplan flow without rewiring. I update it whenever Claude Code ships a release like this one.

Early preview means rough edges. Worth using anyway.