I Built a Skill That Turns Claude Into a Project Manager
Table of contents
The Problem
I kept doing the same thing every time I wanted Claude to build something non-trivial. Write a plan. Break it into tasks. Spin up agents. Babysit them. Merge the branches. Run tests. Clean up worktrees. Repeat for the next phase.
So I wrote a skill that does all of it. One command: /buildthis. Give it a plan file, a PRD, a scope folder, a URL, or just type what you want inline. It handles the rest.
The skill is on GitHub. This post walks through what it does, how I designed it, and the patterns that make multi-agent orchestration actually reliable.
What Happens When You Run /buildthis
You type something like:
/buildthis add OAuth login with Google and GitHubOr point it at a file:
/buildthis project_plan.mdOr a whole scope folder:
/buildthis Docs/scope/From there, the skill runs an eight-stage pipeline:
- Intake classifies your input (file, folder, URL, or inline text) and normalizes it into a canonical plan source.
- Assessment reads the plan and the repo, flags risks, detects the environment, identifies gaps in the spec that would produce generic output.
- Onboarding asks you targeted questions: budget tier, parallelism, target environment, and steering questions for every gap the assessment found.
- Decomposition breaks the plan into phases and tasks, each with acceptance criteria, test parameters, and blockers.
- Build loop dispatches sub-agents, one per task, each in its own isolated git worktree. They run in parallel up to your chosen limit.
- Phase gate runs QA on every completed task, merges passing work, cleans up worktrees, and verifies zero artifacts remain.
- Master review scores the build across five dimensions with itemized deductions and runs a final fix pass.
- Report generates a self-contained tabbed HTML file and opens it in your browser.
The Architecture That Makes It Work
Worktree Isolation
The biggest problem with multi-agent builds is collision. Two agents editing the same file on the same branch will produce conflicts that are painful to resolve and easy to miss.
The solution: every concurrent task gets its own git worktree. Each worktree is a separate checkout of the repo with its own branch, so agents can work in parallel without ever touching each other's files.
When a task passes QA, the orchestrator merges its branch into the feature branch, removes the worktree, and prunes. At the end of every phase, it verifies the working tree is clean: no orphaned worktrees, no stray branches, no temp files.
For simpler work, there is a Lite Mode that skips worktrees entirely and works sequentially on a single branch.
The State Machine
Every task in the build follows a strict state machine:
| From | To | Trigger |
|---|---|---|
| pending | ready | blockers resolved |
| ready | in_progress | agent dispatched |
| in_progress | in_review | agent reports done |
| in_progress | blocked | agent stuck |
| blocked | escalated | sent to Advisor |
| escalated | in_progress | fix applied, retry |
| escalated | ready | needs dependency first |
| in_review | passed | QA passes |
| in_review | failed | QA fails |
| failed | ready | queued for rework |
| passed | done | merged and cleaned |
The orchestrator is the sole writer of state. Sub-agents propose transitions by returning a status in their report. The orchestrator validates the transition against the state machine, reconciles with git ground truth, and persists after every change.
This matters because sessions drop. Context windows fill up. If the orchestrator crashes mid-build, the next session can pick up from Build/tasks.json and resume without re-doing completed work.
The Escalation Pattern
When a build agent gets stuck, it does not retry in a loop. It returns blocked with a description of the obstacle. The orchestrator then dispatches an Advisor agent with a structured problem statement:
- What was the task?
- What did the agent try?
- What exact error or blocker did it hit?
- What files and context are relevant?
The Advisor diagnoses the root cause, optionally does web research (official docs, changelogs, issue trackers), and returns a concrete fix plan. The orchestrator injects that fix into a fresh build agent and re-dispatches. After three failed attempts on one task, it stops and asks you.
This three-tier model (builder, advisor, orchestrator) is more reliable than letting a single agent retry with increasing desperation.
Budget Tiers
Not every build needs the same model. The skill offers three tiers:
| Tier | Planning | Build | Advisor |
|---|---|---|---|
| Economy | Opus 5 @ medium | Sonnet 5 @ low | Opus 5 @ high |
| Business | Fable @ medium | Opus 5 @ low | Fable @ high |
| First Class | Fable Ultracode | Opus 5 @ medium | Fable Ultracode |
The split is intentional. Planning and escalation benefit from stronger reasoning. Build tasks are more mechanical and can run on cheaper models. This keeps costs down on large builds without sacrificing quality where it counts.
The Design Bar
One thing I got tired of: AI-generated UIs that look like default Tailwind templates. Functional but generic. So the skill enforces what I call the Awwwards-premium bar by default.
Every steering option the skill offers during onboarding is a premium design direction, not a quality level. The user picks which direction, never whether to aim high. The assessment phase identifies design gaps early. If you ask for a website but have no design tokens, style guide, or brand direction, the skill flags it and asks targeted questions with curated options inferred from your project's domain and audience.
During QA, output that reads as a default template or generic AI build is a fail, even if it works correctly. The build agent gets sent back to rework it.
Sensitivity Profiles
The skill adjusts its caution level based on the target environment:
Standard (dev): Worktrees per task, commit and merge, lighter confirmations.
Elevated (stage): Everything from Standard plus mandatory PR and review pass before each merge.
Maximum (production): Everything from Elevated plus explicit user confirmation before any merge that could reach a protected branch. Mandatory clean-state verification. Halt-and-ask on any anomaly. And the hard rule: no smoke tests against production, ever.
Cost Tracking
Every sub-agent's token usage gets recorded in Build/cost.json per phase. The final report includes a cost tab showing tokens and estimated USD per phase. These estimates are indicative, based on API pricing, and do not reflect subscription plan usage. They should not be taken as definitive cost figures. On large builds, this visibility matters. You can see roughly which phase consumed the most resources and why.
The Report
The final output is a self-contained HTML file with tabbed navigation:
- Overview of what was built
- Architecture and flow (pages, functions, logic)
- Tasks with every ID, type, and final state
- Tests and verification results
- Confidence scores across five dimensions with itemized deductions
- Cost breakdown per phase
It opens automatically in your browser. No server needed. No dependencies. One HTML file with inline Tailwind and JS.
Optional: Production Readiness Review
After the build completes, the skill offers a production-readiness audit. It fetches a review rubric, splits the sections across sub-agents, and generates a second HTML report with findings grouped by severity and a prioritized remediation list.
Blocker and high-severity findings can be turned into a follow-up fix pass using the same build mechanics.
How to Install It
The skill is a single Markdown file. No dependencies, no setup.
Quick install (per project):
git clone https://github.com/imielvisser/buildthis_Claude_Skill.git
cp buildthis_Claude_Skill/SKILL.md .claude/commands/buildthis.mdGlobal install (all projects):
cp buildthis_Claude_Skill/SKILL.md ~/.claude/commands/buildthis.mdAs an auto-triggering skill:
mkdir -p .claude/skills/buildthis
cp buildthis_Claude_Skill/SKILL.md .claude/skills/buildthis/SKILL.mdAfter installing, restart your Claude session to activate the skill.
Get the skill on GitHub — star the repo, clone it, and you are up and running.
Why This Pattern Matters
The interesting thing about /buildthis is not the skill itself. It is the pattern.
Multi-agent orchestration is fragile when you treat it casually. Agents collide on files. State gets lost between sessions. Failed tasks retry endlessly. Nobody tracks costs. The output looks generic because nobody specified what "good" means.
The pattern that makes it work: a strict state machine that survives session drops, worktree isolation that prevents collisions, an escalation tier that separates diagnosis from execution, and a design bar that treats "it works" as necessary but not sufficient.
These are not AI-specific ideas. They are project management fundamentals encoded as a prompt. The state machine is a Kanban board. The escalation pattern is "ask your tech lead." The phase gate is a sprint review. The design bar is a creative director who sends things back.
The difference is that the prompt runs them automatically, at the speed of inference, across parallel agents that do not get tired or skip steps.
That is what makes skills interesting. They are not just instructions. They are operational systems compressed into a file.