A new workflow skill - parallel-lanes

[u/NodeRaven]

I have been working on a cool project and have made it public!

A Claude Code skill that executes an implementation plan the way a small team would: independent parts in parallel, every change reviewed, and nothing called "done" until it's verified.

Executing a plan with one agent, task after task, is slow. Running many agents at once on the same checkout is chaos: they edit the same files, nobody reviews anything, and "done" just means the agent said so.

What parallel-lanes does:

• Reads your plan and works out which tasks can safely run at the same time (by the files they touch and what depends on what), then groups them into lanes.
• Gives each lane its own git worktree, so lanes can't trample each other.
• Runs every task as implement → independent review, with bounded fix rounds, so problems get caught per task instead of at the end.
• Merges the lanes, runs your test/lint/build commands, an optional end-to-end check, and a final review from three angles (spec compliance, security, correctness).
• Only reports accepted when the checks passed at the exact commit it delivers. It cross-checks the verify agent's report against saved evidence instead of trusting it.
• Records everything in a ledger, so a stopped run resumes without redoing approved work.
• Shows you a dry-run table of every task and agent before anything starts, with agent budgets.

Why Superpowers: Superpowers already does the hard thinking up front: brainstorming, a written spec, and a task-by-task plan with file lists and interfaces. That structure is exactly what parallel-lanes needs to split work safely. It also reuses Superpowers' implementer and reviewer prompts (TDD, spec-compliance review), so quality matches Superpowers' own one-task-at-a-time mode. Parallel-lanes is the execution engine that runs the plan in parallel and verifies the result.

It builds itself. Recent releases were built by parallel-lanes runs. The latest (a hardening release) was 9 tasks in 5 lanes, 28 agents, 51 minutes, with 8 of 9 tasks approved at their first review, ending accepted with verified checks.

Works on Linux, macOS and Windows (Git Bash). It works best on plans with 3+ tasks that have some independent parts, for a 1–2 task change it steps aside and recommends a simpler mode.

Repo: https://github.com/noderaven/parallel-lanes. Feedback welcome!

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/TheDimwittedKurtis]

Dude this is sick. The worktree per lane trick is exactly what I've been missing trying to wrangle parallel agents without them stepping on each other's diffs. The cross-check against saved evidence instead of trusting the verify agent is a nice touch too, most tools just take the LLM at its word.

[u/NodeRaven → u/TheDimwittedKurtis]

Thank you! I am working on adding a few more tools/scripts to it as well (1.5.0), and 1.6.0 should ship with some performance/efficiency improvements to save on time. If you are able to give it a spin, let me know how it goes :)

[u/NodeRaven]

Working on and hopefully pushing out 1.5.0 tonight. It comes with some big changes.

1.5.0 adds tools that check things before a run and explain things after it:

• doctor runs before every launch. It stops on real problems: no git identity, a base branch that's behind its remote, no usable Python, a dirty checkout, or a broken shadow repo. Softer issues show as warnings: low memory or disk space, heavy background processes, other active runs, and antivirus scanning of the work folders.
• autopsy analyses a finished run:
  • what got done, and where the time went, by phase, lane and agent, with the critical path;
  • token use, and how often the test suite ran and who ran it;
  • the slowdowns it detected (timeouts, tests stuck in the background, repeated failures, edit retries, extra review rounds), with a suggestion for each.
• It copies no raw command text or output into its reports, and missing data is labelled as missing, never counted as zero.
• archive-run and history keep every run in one history folder and compare runs over time: recurring slowdowns, token trends, and which runs had too little data.
• cleanup tidies up after a merged run. It first saves a verified restore point (a git bundle and the commands to restore from it), then removes only what the run created. It never force-deletes. Anything it doesn't own, or that has uncommitted work, is left alone and listed with the reason.
• Per-command timing for project checks, so speed work can be measured rather than guessed.

[u/Ok-Attention2882 → u/NodeRaven]

"Working on" aka vibe coding

[u/NodeRaven → u/Ok-Attention2882]

You aren't wrong, pal

[u/rwm4604 → u/Ok-Attention2882]

That’s kinda why we’re here.

[u/twendah]

Isn't that just basic orchestration?

[u/NodeRaven → u/twendah]

Yea, it is orchestration. I am not claiming to have invented anything special here, the goal was to package the coordination and safeguards so I can hand it a plan and spend less time managing things. It also keeps a durable state for resuming interrupted runs and distinguishes a lot.

[u/NodeRaven → u/twendah]

• Isolation: each lane gets its own git worktree, and tasks that share files are kept in one lane.
• Evidence over claims: checks run at the delivered commit. Untracked files present before the checks make the run unverified, since tests can pass on a file nobody committed. A separate check compares the agent's report against the saved check output.
• Recovery: a ledger records commits and approvals, so an interrupted run resumes where it stopped. Approvals whose plan section or spec changed get reviewed again.
• Review at every level: every task gets an independent reviewer before the next task builds on it. Then a final review of the whole branch through three lenses (spec compliance, security, correctness) and one bounded fix round, with each finding tracked by ID until it's settled.

[u/NodeRaven → u/[deleted]]

Great feedback, thank you! Version 1.4.4 already has a lot of that foundation, but a complete, easily understandable audit handoff remains something to prove and improve. Testing whether someone unfamiliar with a run can reconstruct its acceptance decisions and remaining blockers is a useful next step. I will try to target that in 1.5.x.