Claude Code subagents: my workflow from idea to merge

Short answer: I use Claude Code subagents to implement Rydger stories while Opus coordinates dependencies. Sonnet handles much of the implementation, Haiku gets simpler tasks, and Fable is available for difficult decisions. The useful part is being able to step away for hours because each assignment says what can start, which branch it needs and what evidence must come back.

The Android first-ride check in Rydger has an iOS story blocking it. The Swift implementation has to produce first-ride-check-cases.json before Kotlin can run those cases against the port. Putting two platform names on a plan hasn’t made the work independent.

The project is Rydger, my maintenance and running-cost app for motorcycles and cars. It started on iOS; I’ve also built an Android version.

I now spend more time deciding what the product should achieve. I still care about implementation details, but I don’t want every decision about who edits which file to need me at the keyboard.

I’ve left agents writing and running tests, including UI checks in the iOS and Android simulators, while I worked on other things or left the computer. I haven’t measured hours saved, but I no longer need to direct every implementation step.

OpenSpec held the implementation plan; the objective came first

My earlier routine was to prepare an OpenSpec change, then implement it. That still has a job. What needed more space was the conversation before the specification: is this idea worth building, and what would success look like?

I work through that with Opus 5.5. We discuss the idea until it becomes a business objective, split that into epics, then turn an epic into stories. I approve the work before execution starts.

The hierarchy is familiar project management. What changes is who can act on it. A dependency written into a story is something the orchestrator can check without asking me to remember it.

GitHub holds the objective, epics and vertical stories. OpenSpec’s tasks.md holds the engineering checklist. A story that changes app behaviour links the OpenSpec change and the tasks it covers.

Completing the checklist doesn’t tell me whether the business objective worked; that needs its own evidence.

The project’s /epics, /stories and /pickup skills connect those steps. They are local instructions I’ve put around Claude Code, not built-in commands everyone gets after installation.

The Android story needed a Swift test fixture first

One actual epic is about activation on the first ride: help someone set up automatic mileage, confirm that the first ride recorded, and show what to fix when it didn’t.

Two stories inside it carry the important dependency:

The iOS story produces first-ride-check-cases.json. Kotlin runs the same cases in the Android story. That gives the port a concrete reference instead of asking a second agent to invent its own definition of a recorded first ride.

Some integration details must differ. The iOS checklist includes a manual Shortcuts check; Android has Bluetooth and notification permissions to handle. Shared rule cases don’t prove those platform integrations behave identically.

The Android issue explicitly depends on the iOS issue. Running them together would mean implementing against a moving input. Different platforms do not automatically mean independent work.

Opus holds the queue; the executors get bounded assignments

I start the main agent, then let Claude choose how to delegate within the agreed scope. My current arrangement is Opus coordinating, Sonnet implementing, and Haiku doing easier work. That’s a description of my setup, not a model comparison.

Exploration comes before implementation. The worker needs enough context to understand the assigned slice, including the decisions that affect it. I can’t assume it knows everything I discussed with the main agent.

Anthropic documents the separate context and configuration in its subagent guide.

For difficult decisions, .claude/agents/advisor.md uses Fable. The advisor inspects the repo and returns a concrete recommendation for the executor. Its instructions say read-only, but its tools include Bash: that instruction alone is not a technical restriction on every possible write.

Starting the orchestrator also doesn’t authorize every later action. The project’s written default leaves merges to me; when I ask an agent to merge, that is a specific delegation. Store submissions and steps marked founder-action remain mine to carry out.

A separate worktree still owes you an integration

Each implementation works in a different worktree. The directories stay separate while the agents edit. Incompatible changes can still meet later.

I’ve had agents expect to touch different things, then collide in a shared file. The conflict gets resolved while integrating into the parent or epic branch.

It hasn’t been a reason to abandon the setup. It is work the setup still leaves someone to do.

The first-ride Android PR records a less obvious collision. Regenerating translations removed strings from earlier work because those strings had been added directly to strings.xml. They needed to go into the manifest that feeds the generator.

Git could accept the changes and the next regeneration could still erase them.

That is why an assignment needs a base branch and an account of the artifacts it produces. With Claude Code’s automatic worktree isolation, also check which branch the new worktree starts from; don’t assume it is your epic branch.

The worktree workflow explains the mechanism. You still need an integration order.

Green tests have a scope, including after a merge

There’s an obvious objection: the same agents can write an implementation and tests that agree on the wrong behaviour.

They can. Acceptance criteria and shared fixtures give this port a reference, but they aren’t proof that every device integration works. The PRs record different kinds of evidence, and those distinctions matter.

The iOS PR records an initial failure in the new UI test, followed by passing reruns after the fix. The Android PR records unit tests and a manual emulator check; it explicitly says that this area added no instrumented tests.

A road test using the real iOS Shortcut remains separate. Calling all of that automated end-to-end coverage would be generous in exactly the wrong direction.

The rule I’d copy is to ask for the executed command, its result and what remains unverified. Repeat the affected checks after integration.

A worker’s report that everything looks fine isn’t a substitute for execution evidence. That’s the generate-and-check boundary I wrote about in the harness article.

Give one worker a story it can finish without guessing

I’d start with one assignment. Before launching a second context, write down this much:

Observable result and acceptance criteria:
Dependencies and evidence they are already integrated:
Base branch and assigned worktree:
Owned files or area; source of generated artifacts:
Checks to execute and evidence to return:
Open decisions and the condition for stopping to ask me:
PR destination; who may approve and integrate:

The downloadable kit contains that worksheet in both languages, an orchestrator brief and an advisor restricted to reading tools. It is an adaptation for this article, not Rydger’s private repository or an installed scheduler.

A prompt requests behaviour; it doesn’t enforce every instruction.

Run one story and inspect the evidence it returns. Then add an independent story. If both need the same generated file, you’ve found a coordination decision worth making before parallel execution.

Keep an eye on usage too: workers consume it even when you discard their output. Giving some tasks to Sonnet or Haiku doesn’t establish that the whole process costs less: repeated exploration and retries count.

Anthropic’s cost guide covers that side. I can stand behind the autonomy I’ve gained, but I don’t yet have a savings figure to put beside it.

Before the next session you leave running, write down the result it must bring back and the decision that should make it stop and ask you. Test that assignment first.

Sources

• Anthropic: custom subagents, parallel sessions with worktrees, and usage management, checked October 21, 2026.
• My Rydger delivery workflow and skills, epic #166, stories #192 and #193, and PRs #247 and #250. The repository is private. Those PR records describe their own verification runs; I haven’t rerun the app suites for this article.

Related reading: the skills behind my coding workflow and how I connect that process with loops.

P.S. Where has parallel agent work cost you more effort: assigning the stories or integrating what comes back? Tell me on Twitter/X.