Define the destination
- Describe the goal in plain language
- List acceptance criteria that decide when it's done
- Approve the plan, if you want a checkpoint
- Review the pull request and merge
New: configure every sub-agent's model & effort
New: per-agent model & effort
You set the destination.
You set the destination.
AI takes the wheel.
NH Wheel turns a goal and its acceptance criteria into a tested, reviewed pull request. Write tasks in NH Wheel or sync them from GitHub and GitLab. A team of AI agents plans the work, breaks it down, writes the code, tests it and opens the PR. You review and merge.
6stages from goal
to pull request
to pull request
3model tiers to mix
per agent role
per agent role
4effort levels,
low to max
low to max
2git providers:
GitHub & GitLab
GitHub & GitLab
0direct pushes to
protected branches
protected branches
// Product overview
A delivery pipeline that runs itself.
A delivery pipeline that runs itself.
You stay in charge of what “done” means.
Most AI coding tools still need someone at the keyboard. NH Wheel works on a different contract: you describe the outcome and how it will be judged, and agents handle everything between the ticket and the pull request.
Drive the whole way there
- Read the codebase and draft an implementation plan
- Break it into subtasks and assign them
- Write the code on an isolated branch
- Test it and verify every criterion with evidence
- Open a PR / MR with a clear summary
Stays under your control
- Agents only write to
wheel/branches - Every change arrives as a reviewable PR
- CI checks and approvals still gate the merge
- A full audit trail of who did what, and why
Tasks can start anywhere:
Created in NH Wheel
GitHub Issues
GitLab Issues
// How it works
From one sentence to one pull request
Follow a real task, WHL-231 · Add Apple Pay to checkout, through all six stages.
Say what you want, and how you'll judge it
Write the goal in plain language and list the acceptance criteria. Each criterion is typed (unit, end-to-end, performance or manual), so the agents know how to prove it. Attach designs, docs or links as context, or let a GitHub or GitLab issue become the task.
New task
Add Apple Pay to checkout
- C1Apple Pay button appears only on supported devicesUnit
- C2A successful payment creates an order with status PAIDE2E
- C3A declined payment shows an inline error and keeps the cartE2E
- C4p95 checkout API latency stays under 300 msPerf
The Orchestrator reads your code and writes a plan
The main agent (Opus, high effort by default) explores the repository, follows your project's conventions and proposes an implementation plan with risks and an estimate. Turn on plan approval to review it before any code is written.
Implementation planOrchestrator · Opus · High
- Add Apple Pay merchant config and the domain verification file
- Create
<ApplePayButton>with device feature detection - Extend
POST /api/checkoutto accept payment tokens - Map gateway decline codes to inline error messages
- Cover C1–C4 with unit, e2e and load tests
Approve planRequest changes
The plan becomes subtasks with owners
Each subtask gets an agent, its dependencies and the acceptance criteria it has to satisfy. Independent subtasks are scheduled in parallel, so two developers can work at the same time without stepping on each other.
WHL-231 · 5 subtasks2 parallel lanes
- 231.1Merchant config & domain fileDeveloper #1C1
- 231.2ApplePayButton componentDeveloper #1C1
- 231.3Checkout API: token supportDeveloper #2C2 · C4
- 231.4Decline mapping & inline errorsDeveloper #2C3
- 231.5Tests for C1–C4TesterC1–C4
Developers write the code on an isolated branch
Developer agents (Sonnet, medium effort by default) work on wheel/WHL-231-apple-pay, follow your lint rules and existing patterns, and commit in small, readable steps. Your protected branches are never touched.
wheel/WHL-231-apple-payDeveloper #1 · Sonnet
src/checkout/apple-pay-button.tsx +64 −0
12 export function ApplePayButton({ total }: Props) {
13+ const supported = useApplePaySupport();
14+ if (!supported) return null; // C1
15+
16+ return (
17+ <button className="apple-pay"
18+ onClick={() => startPayment(total)} />
19+ );
20 } Developer #2 is editing
api/checkout.ts…Tests prove every criterion, and failures fix themselves
The Tester writes and runs unit, end-to-end and load tests, and links evidence to each criterion. When something fails, the failure goes back to the right developer with full context and the loop repeats, up to the retry limit you set.
Tester · test run #2Sonnet · Medium
$ pnpm test --filter checkout
✓ ApplePayButton › hidden on unsupported devices 12 ms C1
✓ checkout.api › token creates a PAID order 48 ms C2
✓ e2e › declined card keeps cart, shows error 2.1 s C3
✗ load › p95 latency 342 ms > 300 ms C4
↻ sent back to Developer #2 · cache gateway session
✓ load › p95 latency 212 ms @ 500 rps C4
Acceptance criteria verified: 4 / 4
A pull request you can review in minutes
The Reviewer agent (Opus) checks the diff, then opens a PR or MR with a written summary, the test results and a checklist that maps each criterion to its evidence. You approve and merge, or comment and send it back.
acme/storefront-webOpen
feat(checkout): add Apple Pay #491
wheel/WHL-231-apple-pay → main · +318 −41 · 11 files
build
unit · 214
e2e · 18
lint
Acceptance criteria 4 / 4 verified with evidence
Approve & mergeRequest changes
// Product tour
Everything the agents do, in plain sight
Follow every task from goal to merged pull request: what the agents planned, what they changed and how they proved it.
01 / 09
Mission control for your backlog
See every task in flight, which agents are working on what, and what shipped this week.
- Live pipeline from queued to merged
- Running agents and what each one is doing
- Pass-rate and time-to-PR trends
// Sub-agents
Your AI team. Your rules.
Every role is a sub-agent you configure: choose the model, set the effort, decide how many run in parallel. Put Opus-level reasoning where it matters and Sonnet speed everywhere else. Try it below.
A common starting point
Opus where judgement matters: orchestrating, planning and reviewing.
Sonnet for high-volume coding and testing. Haiku for docs and chores.
Orchestrator
Owns the plan, delegates subtasks and enforces the acceptance criteria.
Model
Effort
Parallel instances
Reasoning depth
Speed
Relative cost
Team configuration
// Integrations
Lives where your code lives
Connect a GitHub organization or a GitLab group in a few clicks. Issues flow in as tasks, and finished work flows back as pull or merge requests, with CI checks, labels and links kept in sync.
GitHub
- Install as a GitHub App with scoped permissions
- Turn issues into tasks, by label or by hand
- Pull requests with checks and review status
GitLab
- gitlab.com groups and self-managed instances
- Issues sync into the shared task board
- Merge requests with pipeline status
- Least-privilege tokens you can review
- Writes only to
wheel/branches - Never pushes to protected branches
- Every agent action is logged
feat(checkout): add Apple Pay #491
nh-wheel[bot] wants to merge 7 commits into main from wheel/WHL-231-apple-pay
Summary
Adds Apple Pay as a payment method at checkout on supported devices. Other browsers keep the card form. Gateway sessions are cached to keep checkout latency under budget.
Acceptance criteria
- C1 · Button only on supported devices
apple-pay-button.spec.tsx - C2 · Successful payment creates a PAID order
checkout.e2e.ts - C3 · Declined card keeps cart, shows error
checkout.e2e.ts - C4 · p95 checkout latency < 300 ms
k6: 212 ms
All checks have passed
Merge pull request
// Features
Everything a team needs to let go of the keyboard
Criteria are the contract
A task isn't done until every acceptance criterion is verified, and each one links to the test or check that proves it.
Human-in-the-loop checkpoints
Require approval for the plan, the merge, or both. Or let trusted projects run fully on autopilot.
Isolated workspaces
Each task runs on its own branch and workspace, so parallel tasks never collide and nothing lands without review.
Self-healing test loop
Failing tests go back to the right developer agent with full context, up to a retry limit, before anyone is paged.
Live activity stream
Watch every plan, tool call, commit and test run as it happens. Pause or redirect a task at any time.
Cost & token tracking
Spend per task, per agent and per model, with budgets, alerts and hard stops that end runaway work.
Follows your conventions
Project instructions, lint rules and existing patterns guide every agent, so the code reads like your team wrote it.
Complete audit trail
Who approved what, which agent changed which file, and why. Every decision is kept for later review.
// Under the hood
AI at every step of the flow
One orchestrator, a team of specialist agents and the right model for each job. Here is how the AI turns your goal into a pull request, and where you stay in control.
Input
Your goal
A plain-language outcome and the acceptance criteria that define done
Main agent
AI Orchestrator
Opus · high effort
Reads the codebasePlans the workDelegates subtasksEnforces every criterion
Sub-agents
Specialist team
- PlannerOpus
- Developer ×3Sonnet
- TesterSonnet
- ReviewerOpus
Output
Pull request
Tested, reviewed and backed by evidence for each criterion, on GitHub or GitLab
You stay in the loop: approve the plan before coding starts, and review the PR before it merges.
The right model for each stepOpus reasons through plans and reviews. Sonnet writes and tests code at speed. Haiku handles docs and chores.
One shared contextEvery agent works from the same goal, criteria, plan and code, so nothing is lost between handoffs.
Evidence, not claimsAgents prove each criterion with a test, a load run or a check, and attach the result to the PR.
Autonomy within limitsBudgets, retry limits and approval checkpoints keep the agents inside the boundaries you set.
// Who it's for
Built for teams with more tickets than hands
Product teams
Clear the long tail of well-defined tickets without pulling engineers off roadmap work.
Tech leads
Delegate with precise acceptance criteria, then review outcomes instead of keystrokes.
Agencies & outsourcing teams
Deliver client tasks across many repositories with one consistent, auditable process.
// Roadmap
Where we're driving next
-
Phase 1 · Foundation
In progress
- Projects & native tasks
- GitHub & GitLab connection
- Pipeline: plan → PR
-
Phase 2 · Control
Next
- Sub-agent model & effort
- Plan approval checkpoints
- Usage & cost tracking
-
Phase 3 · Scale
Planned
- Parallel task execution
- Custom agent roles
- Slack / Teams notifications
-
Phase 4 · Enterprise
Exploring
- SSO & role-based access
- Self-hosted agent runners
- Jira & Linear import
// FAQ
Questions, answered
Short answers to the questions teams ask first.
Does NH Wheel push straight to my main branch?
No. Agents only write to branches prefixed with wheel/. Every change reaches your default branch through a pull request (GitHub) or merge request (GitLab) that you, your CI and your branch protection rules control.
Do I have to create tasks inside NH Wheel?
No. You can create tasks in NH Wheel, or connect a repository and turn GitHub or GitLab issues into tasks. Either way you add the goal and the acceptance criteria, and progress syncs back to the issue.
Which models can the agents use?
Each sub-agent can use Claude Opus, Sonnet or Haiku, with its own effort level from low to max. A common setup is Opus for the orchestrator and reviewer and Sonnet for developers and testers, but any mix works.
Can I review the plan before any code is written?
Yes. Turn on plan approval per project or per task. The orchestrator stops after planning and waits for you to approve or request changes.
What happens when tests fail?
The tester sends the failure and its context back to the developer who owns that subtask, and the loop repeats. If it still fails after the retry limit you set, the task pauses and you're notified.
How do I keep costs predictable?
Pick the model and effort per role, set a budget per task, and get alerts as spend approaches it. The usage dashboard shows tokens and cost by task, agent and model.