Articles/Claude Code

⟐ Claude Code/2026-05-23Advanced

Skill, Subagents, and Rules in Claude Code: A One-Hour Implementation Loop That Fits a Solo Operator

Misaki Ito at SonicGarden wrote about wiring Claude Code's Skill, Subagents, and Rules to close a week's worth of low-priority work in one meeting. Here is how I adapted that pattern as a solo developer running a 50M-download app business.

Claude Code¹⁹⁸ Skill Subagents⁸ Rules Automation³⁹ Team Workflow MCP⁴⁵

✦ Premium Article

Low-priority work that keeps sliding past is the same shape of problem whether you are a solo developer or part of a team. I felt that strongly reading Misaki Ito at SonicGarden write up "Wiring an internal project with Claude Code Skill". The pattern is exactly the one I had been trying to assemble for my own setup.

What follows is a port of that pattern to a single-operator context, with a few small adjustments from my own decade-plus of running mobile apps independently. The portfolio crossed 50 million downloads a while back and I am the only one maintaining it, so "designing a loop that does not depend on willpower" is a load-bearing constraint, not a nice-to-have.

Why a Loop, Not Willpower

Low-priority work does not move because of willpower. Willpower is too dependent on context: today's focus, what else landed in your inbox, your sleep. Any one of these can break, and when they do, the low-priority list is the first thing sacrificed.

You are better off designing a loop that does not depend on willpower at all. SonicGarden's article describes one: after the weekly meeting ends, use the "follow-up" slot to run a Skill that fans out across multiple tasks and lands them in parallel. By the time the follow-up is over, the work is ready for review.

For a solo developer like me, "the follow-up slot" reads as "the one-hour weekly review block". I sit down, list the tasks I want to move, kick off the Skill, and by the time I am done thinking about higher-order things, the PRs exist.

How Skill, Subagents, and Rules Divide Responsibility

The three Claude Code primitives split cleanly by responsibility:

Primitive	Role	Lifetime
Skill	Workflow entry point — receives arguments, drives steps	Per-project to global
Subagents	One-task execution units, runnable in parallel	One task lifecycle
Rules	Per-environment operational rules, PROJECT_ID, MCP setup	Always in context

Holding this split in your head saves you from later asking "where does this piece live?" My layout follows the same shape SonicGarden used:

~/.claude/
├── skills/
│   └── start/
│       └── SKILL.md          ← entry point
├── rules/
│   ├── project.md            ← project management tool integration
│   └── tools.md              ← MCP, PROJECT_ID, etc.
└── agents/
    └── task-implementer.md   ← parallel execution subagent

I declare PROJECT_ID inside rules/tools.md and have the Skill say "if no argument is passed, use the value declared in Rules." That keeps the invocation slim — passing the ID every time gets tedious quickly.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦How Skill, Subagents, and Rules divide responsibility so 'low-priority' work stops slipping forever

✦A concrete file layout and prompts for fanning subagents out across a week's task list in one hour

✦Where I, running this as a solo operator on a 50M-download portfolio, keep human judgment in the loop

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

The Skill: Step Sequence with Explicit Stops

The entry-point SKILL.md is almost a process manual: a tight sequence of steps and the explicit places where I want the loop to pause for me.

---
description: From a weekly review summary, branch out into parallel implementation per worktree
argument-hint: <PROJECT_ID>
---
 
# Weekly Implementation Workflow
 
PROJECT_ID: $ARGUMENTS
 
Run the following in strict order. At every USER GATE, stop and wait
for explicit human approval.
 
## Step 0: Receive Review Summary
 
Ask the user to paste the task summary from this week's review.
Hold the returned text as "weekly summary". If empty, stop and ask again.
 
## Step 1: Candidate Extraction
 
Pull task data from the project management tool. Cross-reference against
the weekly summary. Narrow to 3–5 tasks to attempt this week.
 
[USER GATE 1: present candidate list, wait for approval]
 
## Step 2: Worktree Preparation
 
For each approved task, create a git worktree.
 
## Step 3: Fan-out
 
Launch task-implementer subagents in parallel against each worktree.
 
[USER GATE 2: wait for all subagents to report completion]
 
## Step 4: PR Creation and Status Updates
 
Each subagent opens a PR, sets the task status from "not started" to
"under review", and posts the PR URL into the project management tool
with the assignee mention.
 
## Step 5: Report
 
Report the PR URLs and statuses back to me.

$ARGUMENTS is Claude Code's built-in for what was passed at invocation; argument-hint tells the user what should be passed. The same structure SonicGarden documented.

The piece I added is the explicit USER GATE markers. Forcing the Skill to pause at named points keeps the AI from quietly fanning out and creating PRs I did not ask for. Ever since I started teaching myself the internet in 1997 I have kept a hard line between "this gets automated" and "this stays a decision", and I will not give that up here.

Rules: Where Per-Environment Truth Lives

Rules files are always in context, so they are the right home for everything you do not want to inline into the Skill itself.

# rules/tools.md
 
## Project management tool conventions
 
- PROJECT_ID per environment:
  - production: proj-prod-2026
  - staging:    proj-staging-2026
  - personal:   proj-personal-001
 
## MCP servers
 
- github: shares gh credentials
- linear: token at ~/.config/linear/token
- chrome-devtools-for-agents: for extension regression QA
 
## Default autonomy levels
 
- Read-only: always-proceed
- Write:     request-review
- Dangerous: strict

rules/project.md then holds the integration recipe for whichever PM tool you live in (Linear, Asana, GitHub Issues). Inlining that into the Skill itself bloats the Skill quickly.

My split rule is simple: anything that changes when the environment changes goes in Rules; anything that defines a workflow sequence stays in the Skill.

Subagents: Self-Contained Workers

Subagents are the units that the Skill fans out to. Each runs in its own worktree and is responsible for one task end-to-end.

---
name: task-implementer
description: Completes a single development task inside a worktree
tools: Read, Write, Edit, Bash, Grep, Glob, Skill
---
 
# Role
 
Inside the assigned worktree, implement the assigned task, add tests,
and open a PR. Follow the steps strictly.
 
## Procedure
 
1. From the worktree root, run `git status` and confirm a clean state
2. Read the task spec; use Grep / Glob to locate affected code
3. **Read the existing tests first**, and match their style
4. Implement using the smallest diff that satisfies the spec
5. Add tests; confirm `npm test` (or equivalent) passes
6. `git add` → `git commit` → `git push` → `gh pr create`
7. Return the PR URL and a one-line commit summary
 
## Constraints
 
- Do not propose framework changes
- If the diff exceeds 500 lines, propose a split via the Skill and stop
- Do not open a PR with failing tests

tools includes Skill so the subagent can call back into other skill workflows, which makes it more than "a thing that writes code" — it can follow your own design and test conventions through composed skills.

My two additions are "do not propose framework changes" and the 500-line split rule. The first one I have written about in other articles — give an AI room and it will rewrite the foundation in one go, and I would rather not let that happen. The second one is an operational safety valve: at 50M downloads, a 1,500-line PR is an unreviewable mess, and the AI's instinct is to keep stacking work into a single commit.

Parallel Fan-out: One Command, Whole Week

The real value of fan-out is breaking the dependency chain. SonicGarden makes this explicit: "if this task does not finish, the next one cannot start" is the death spiral of weekly throughput.

In a solo setup, "everyone's tasks" becomes "all of mine this week", but the structure stands. Three to five subagents in parallel changes the speed of the post-review session by a noticeable margin.

A small note on safety: Claude Code does not let subagents talk to each other unless you wire it up explicitly. That is the right default, but it means parallel subagents on tasks with hidden dependencies will collide later. I push the dependency check into Step 1 of the Skill — only tasks with no shared files go into the parallel batch.

The "Follow-up" Slot Turns Into a "Thinking" Slot

The point SonicGarden makes that lands hardest for me: once you have running artefacts as the basis for discussion, review time can be spent thinking, not running the code. Same shift, smaller team, in my case.

What "thinking time" looks like for me:

Choosing a refactoring direction without rushing
Architecture decisions that span the whole 50M-download portfolio
Trying a new MCP server and deciding whether to keep it in the rotation
Maintaining documentation and reviewing past judgement calls

Both of my grandfathers were carpenters of shrine architecture. They drew a clean line between the cutting — careful manual labour — and the assembly — matching drawings to the site. Mapping that onto Claude Code: subagent parallelism is the cutting, human judgement is the assembly. The mental model fits cleanly.

Real Production Pitfalls I Walked Into

After about a month of running this loop in earnest, here are the actual failure modes I hit. None of them were "the AI went rogue"; all of them were operator complacency.

Trap 1: parallel-launching tasks with hidden dependencies.

The Step 1 dependency check said the tasks were independent, but a merge conflict appeared mid-implementation. Two unrelated features had touched the same file. Grep-based dependency detection missed it. I added a heuristic: before creating worktrees, run git log --name-only over the last 30 commits, and refuse to parallel-launch any pair of tasks whose modified-file overlap exceeds 50%.

Trap 2: subagent forgets to add tests.

A subagent finished an implementation and went straight to PR without writing tests. This was not the AI being lazy — Step 5 of my Skill underweighted "add tests" relative to the surrounding steps. Promoting the test step to "stop if no tests were added" plus the constraint "do not open a PR with failing tests" closed the gap. In production this kind of slip is a direct incident, so a double guard is worth the cost.

Trap 3: MCP server token expiry, silently.

When the Linear or GitHub MCP token expires, the subagent reports "tool not responding" and stalls. I ignored that signal for a week before noticing. I now run an MCP smoke check in Step 0 of the Skill, so an expired token surfaces immediately.

Operational Tuning Notes

A few smaller observations from running the loop:

Keep the Skill to 5–7 steps. Past 10, maintenance gets painful
Cap USER GATEs at 2–3. Too many and the human burns out and stops running it
Write subagent constraints as comments. Models follow constraints that are presented as constraints
Split Rules into multiple files. One mega-file inflates the always-on context and slows responses
Cut PRs at a human-readable size. That is what the 500-line constraint is for
Keep failure logs. I write each Skill run into ~/.claude/logs/ and review them weekly

The last point — keep failure logs — maps onto the "this is where the real work starts" line in SonicGarden's article. I read the logs every week and decide which of the three layers (Skill, Subagents, Rules) to tune next.

Start Small

If you try to build the perfect loop from day one, you will give up before it lands. My recommendation: in week one, only run Step 0 and Step 1 of the Skill.

Narrowing a list to three to five tasks is itself a meaningful upgrade to weekly decisiveness. Add the parallel-implementation half once the candidate-extraction half has been stable for a couple of weeks. That is more than enough.

Since I saw the ring of light over Kichijoji Station in late 2019, I have kept the habit of standing still until intuition becomes certainty. Skill design works the same way. Run the early step on its own for a week or two. Once you are sure it stabilises, expand outward. The rails take half a day to lay; the work is in keeping them in service over the long term. That part is still a human job, and Claude Code's three-layer model is finally a tool that supports it well.

Thank You for Reading

Claude Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.