How does it stop my agents from colliding?

Every task gets an explicit list of files it may change. Shared files like routers, migrations, lockfiles and root reducers get one owner at a time, usually a short setup task first or an integration task last. The bundled validator then checks every pair of tasks that can run at the same time and flags overlapping paths before any agent starts.

Which agents and tools does it work with?

Any agent that reads SKILL.md, including Claude Code, Codex CLI, Cursor, Copilot and Gemini CLI. It hands off as Claude Code subagent briefs, per-task prompts for git worktrees, a MultiClaude plan_dag payload, or a Markdown plan you can paste into an issue tracker.

Does it run the agents or write the code?

No. It surveys your repo, writes and validates the plan, and stops for your approval. You or your orchestrator run the tasks; each brief is self-contained so a fresh agent can pick it up without the planning conversation.

What do I need installed?

Just Python 3 for the plan validator. It uses only the standard library: no packages, no network access. Plans work best with git worktrees or one branch per task, so each agent has its own copy of the repo.

How is this different from just asking an AI to break the work into tasks?

Plain task lists usually let parallel tasks share files by naming 'edit only function X' zones, which still conflict at merge. In blind-graded tests on four real codebases, the same model without this skill let concurrent tasks share files in 6 of 12 plans; with the skill, 0 of 12. The skill also splits out shared interfaces first so more work runs in parallel, and checks the result with a validator instead of trusting the plan.

Works with the AI Agents you already use

+22 more

+18 agents

Parallel Task Planner

Splits big features into tasks parallel agents can build at once: file ownership per task, run order, critical path, and a merge-conflict check.

$24

Secure checkout via Stripe

Money-back guarantee

Converts to your local currency at checkout

Security scanned

Parallel Task Planner

Example session with this skill installed

React + Redux frontend in this repo. I want: (1) a dark-mode toggle in the header, persisted in localStorage; (2) bookmarks UI: bookmark button on article previews and article pages plus a 'My bookmarks' page (the backend already has GET /user/bookmarks and POST/DELETE /articles/:slug/bookmark); (3) a notifications bell in the header that polls GET /notifications every 30s and shows unread items. Break it down for a few Cursor agents running in parallel.

Read your context and instructions
Compiled the parallel task planner

Dark mode, bookmarks and notifications: 5 tasks · 3 waves · max 3 in parallel · ~1.8x faster than sequential
Critical path: groundwork → bookmarks → integrate-and-verify (~125 of 220 min)

Wave 1: groundwork (standard/high): API methods, action types, stub components wired into Header/App/root reducer, setupTests.js, committed lockfile
Wave 2: dark-mode (standard/high) · bookmarks (standard/high) · notifications-bell (standard/xhigh), one Cursor agent each
Wave 3: integrate-and-verify (standard/high): full suite and build, cross-feature smoke test, README
Conflict check: clean. Each shared file (agent.js, actionTypes.js, reducer.js, Header.js, App.js) is edited once, in groundwork.

The wave 2 agents replace the stubs groundwork leaves and edit only files they own.

What I found in the repo and how the plan handles it

All three features need `Header.js` (toggle, bell, Bookmarks link). Groundwork puts empty `ThemeToggle` and `NotificationsBell` components into it, so no feature agent edits the header.

There's no lockfile. Three worktrees each running `npm install` can end up with three different lockfiles. Groundwork commits one, and every other agent runs `npm ci`.

The toolchain is CRA 1 / Jest 20. I checked this in a scratch install on Node 22. jsdom here has no `localStorage` or `matchMedia`, and `jest.advanceTimersByTime` doesn't exist (`runTimersToTime` does). Groundwork adds a localStorage shim and the briefs cover the rest. `CI=true npm run build` has zero warnings today, so every task uses it as the lint check.

Polling doesn't go through the promise middleware. The middleware drops responses after a page change, throws on network errors, and sets `settings.inProgress` on every request.

Dark mode for the bell dropdown: the notifications agent writes those styles in its own CSS file, keyed on html[data-theme="dark"]. The dark-mode agent sets that attribute, so the two agents never share a file.

Assumptions (overrule any):

Confirm this one: the bookmark endpoints work like favorites. Toggling returns { article } with bookmarked, and article payloads include bookmarked. If they don't, buttons outside /bookmarks start in the wrong state and the bookmarks task needs a bookmarked-slugs slice instead.

/user/bookmarks takes limit/offset and returns { articles, articlesCount }.
/notifications returns { notifications: [{ id, message, createdAt, read, link? }] }. There's no mark-as-read, so the bell only lists unread items.
Polling runs only while logged in, every 30s, and fails silently.
Dark mode follows the OS setting until the user toggles it. The choice is stored as theme in localStorage and applied before first paint by an inline script in the app's HTML entry page.
Bookmark UI shows only when logged in. No new dependencies, and API_ROOT is unchanged.

Plan files: plan.json (source of truth) and plan.md (readable plan with every brief).

After approval: I'll export one self-contained brief per task. With Cursor, give each task its own branch or worktree:

Run groundwork and merge it.
Start the three wave 2 agents from the updated base, one brief each, and merge them in any order.
Run integrate-and-verify last.

Proceed, or revise?

Connects securely to your tools. The creator never sees your data.

About this skill

Running several coding agents at once is easy. Getting them to finish without colliding is not. Parallel fan-out fails in three predictable ways: two agents edit the same file and their branches conflict, a worker starts with a fresh context and guesses what the planner meant, or false dependencies serialize the plan so eight agents finish no faster than one.

Parallel Task Planner is the planning layer from MultiClaude, an open-source orchestrator for parallel Claude Code workers, extracted into a standalone skill that works with any agent that reads SKILL.md.

What it does

Surveys your repo read-only and finds the hot files (route tables, barrel exports, manifests, lockfiles, migrations) where parallel plans collide
Breaks the work into agent-sized tasks and a dependency graph (DAG), each task with an explicit list of files it may change, files to read, a contract, and runnable acceptance checks
Splits out contract tasks (types, API shapes, interfaces) so dependent work can run in parallel instead of in sequence
Assigns a model tier and reasoning effort per task (fast/standard/strong/frontier × low…max)
Follows each new status, flag or tool to every dashboard, doc and prompt that needs to know about it, so nothing ships half-wired
Validates the plan with a bundled script: cycles, unknown or duplicate IDs, redundant edges, oversized tasks, thin briefs, catch-all "fix anything" scopes, and every pair of concurrently runnable tasks that would write the same path
Shows waves, critical path, max parallelism and estimated speedup, then asks you to approve before anything runs

Hands off to what you already use

Claude Code subagents or any prompt-driven agent: one self-contained brief per task, numbered by wave
Git worktrees with Claude Code, Codex, Cursor or Aider sessions
MultiClaude: exports the plan_dag payload directly
Issue trackers: a Markdown plan with a Mermaid graph you can paste into an epic

Includes

SKILL.md with the decomposition and dependency rules
scripts/plan.py (Python 3 standard library only; no network, no subprocesses)
Pattern library: full-stack feature, framework swap, schema migration, cross-cutting change, issue batch, greenfield service, refactor, spikes
Hot-file catalog for JS/TS, Python/Django/Alembic, Rails, Go, JVM, Prisma, iOS/Android
A complete worked example plan

Tested, not just written

Blind-graded on 4 real codebases (Django, FastAPI, React/Redux, and MultiClaude), 3 runs each, with and without the skill. With the skill, tasks that could run at the same time never wrote the same file (12 of 12 plans). Without it, the same model let parallel tasks share files in 6 of 12. Overall the skill scored 94% on a 9-point plan-safety checklist, against 81% without it.
Fixed, then re-tested. All of the skill's misses came from one cause, which is fixed in this version. On 8 follow-up runs it passed every check (72/72).
Built end to end: parallel agents built two plans for the same three MultiClaude features, one written with the skill and one without. Both merged with zero conflicts and all tests green. The skill's plan finished about 30% sooner on the clock and used 46% fewer agent tokens.

Built by Marcus Chandradasa, author of MultiClaude (github.com/dushshantha/multiclaude).

How to use

Skills on Agensi run inside your AI agent. Copy the prompt, paste it into your agent, and it connects to Agensi and installs this skill for you. If a payment is needed, your agent shows it to you first.

Reviews

No reviews yet

Be one of the first to try it. Every listed skill passes our trust checks below.

Security scanned

Passed our 8-point scan before listing

Fresh listing

Recently published to Agensi

Money-back guarantee

Doesn't do what its page promises? You get your money back.

Trust & safety

Security scanned

Verified clean 2 days ago

Passed all security checks, Safe to install

Requires

Python 3 (standard library only)

Python

tsc

Node.js

Git

Listed2 days ago

Parallel Task Planner

Parallel Task Planner

What I found in the repo and how the plan handles it

All three features need `Header.js` (toggle, bell, Bookmarks link). Groundwork puts empty `ThemeToggle` and `NotificationsBell` components into it, so no feature agent edits the header.

There's no lockfile. Three worktrees each running `npm install` can end up with three different lockfiles. Groundwork commits one, and every other agent runs `npm ci`.