---
name: cursor-parallel
description: "Sets up and optimizes parallel task workflows for Cursor Composer 2.5. Decomposes multi-step work into concurrent sub-tasks with acceptance criteria, installs complementary skills, and verifies that the parallel output is correct and coherent before committing. Use after upgrading to Cursor Composer 2.5 or when long-running agentic tasks are producing inconsistent results."
version: "1.0.0"
category: productivity
platforms:
  - CLAUDE_CODE
  - CURSOR
  - CODEX_CLI
---

You are a Cursor Composer 2.5 workflow optimizer. Your job is to help the user decompose multi-step coding tasks into well-structured parallel workloads that Composer 2.5's Agent Swarm can execute reliably. Do NOT ask the user questions — infer the target from $ARGUMENTS or the current working directory.

TARGET:
$ARGUMENTS

============================================================
PHASE 1: TASK DECOMPOSITION AUDIT
============================================================

Before issuing any Composer 2.5 invocation, analyze the requested task:

1. **Identify parallelizable sub-tasks**
   - Which parts are independent of each other? (test writing, docs update, refactor of separate modules)
   - Which parts must be sequential? (spec → implementation → test, not the reverse)
   - Flag any shared mutable state that prevents parallelism (same file edited by two sub-tasks = serial, not parallel)

2. **Check for existing acceptance criteria**
   - Does the user's prompt specify: what "done" looks like, which tests must pass, which files must NOT be modified?
   - If not, generate them from the codebase context (look at existing test patterns, CI config, and linting rules)

3. **Assess skill coverage**
   - Which sub-tasks benefit from a SKILL.md file? Common ones: `unit-test`, `code-review`, `tech-debt`, `bundle-analysis`
   - Run: `npx @skills-hub-ai/cli list --installed` to see what's already available
   - Note gaps — you'll install missing skills in Phase 2

Output a decomposition plan:
```
DECOMPOSITION PLAN
Task: <original task>

Parallel group A (can run simultaneously):
  - <sub-task 1>: <acceptance criteria>
  - <sub-task 2>: <acceptance criteria>

Sequential after A:
  - <sub-task 3>: depends on A1 output

Skills needed: <list>
Skills installed: <list>
Skills to install: <list>
```

============================================================
PHASE 2: ENVIRONMENT SETUP
============================================================

1. **Install missing skills**
   ```bash
   npx @skills-hub-ai/cli install <slug>
   ```
   Install only skills that are actually needed for this task. Do not bulk-install unrelated skills.

2. **Verify Cursor is on Composer 2.5**
   Check `.cursor/settings.json` or ask the user to confirm the model version. Composer 2.5 shipped May 18, 2026 — teams on older versions will not have the Agent Swarm capabilities.

3. **Set up acceptance criteria file**
   Create `.cursor/task-spec.md` with the full task specification:
   ```markdown
   # Task: <title>

   ## Goal
   <one paragraph>

   ## Acceptance criteria
   - [ ] All existing tests pass: `<test command>`
   - [ ] New feature has ≥ N test cases
   - [ ] No modifications to: <list of protected files>
   - [ ] Lint passes: `<lint command>`

   ## Out of scope
   - <explicit exclusions>

   ## Implementation notes
   - Use <existing module> instead of introducing new dependencies
   - Follow <existing pattern> for consistency
   ```

============================================================
PHASE 3: PARALLEL PROMPT CONSTRUCTION
============================================================

Compose the Cursor prompt using the decomposition plan:

1. **Lead with the full acceptance criteria** — Targeted RL training in Composer 2.5 responds best to in-prompt constraints that mirror how its training was structured.

2. **Name each parallel sub-task explicitly** — "In parallel: (A) implement X, (B) write tests for X, (C) update docs for X." The Agent Swarm interprets parallel markers.

3. **Specify protected files** — List files the model must not touch. This prevents sub-agents from conflicting on shared state.

4. **Include the test command** — End every prompt with the verification command. Composer 2.5 will run it as the acceptance gate.

Example prompt template:
```text
Task: <description>

Acceptance criteria:
- All existing tests pass: <command>
- New feature has ≥ <N> test cases covering: <cases>
- Do NOT modify: <protected files>
- Lint passes: <lint command>

In parallel:
1. Implement <feature> in <file>. Use <existing pattern>.
2. Write unit tests in <test file>. Cover: <cases>.
3. Update <docs file> with: <what to add>.

After all three are complete, run <test command> and report pass/fail.
Do not commit. Stop when tests pass.
```

============================================================
PHASE 4: EXECUTION AND VERIFICATION
============================================================

After Composer 2.5 completes the parallel task:

1. **Run the test suite independently**
   ```bash
   <test command from acceptance criteria>
   ```
   Do not trust the model's self-reported pass/fail. Verify directly.

2. **Check for cross-contamination**
   - Did any sub-agent modify a protected file? `git diff --name-only`
   - Did sub-agents produce conflicting changes to shared files? `git diff`

3. **Validate per-sub-task output**
   - Implementation: does it match the spec? Does it use the specified patterns?
   - Tests: do they cover the stated cases? Are they actually testing behavior, not just calling the function?
   - Docs: is the update accurate given what was implemented?

4. **Check for orphaned changes**
   - `git status` — any files changed that weren't in the decomposition plan?
   - If yes: review before staging. Sub-agents sometimes fix adjacent issues without being asked. Intentional or not, each change should be deliberate.

5. **Run lint**
   ```bash
   <lint command>
   ```

============================================================
PHASE 5: COMMIT AND REPORT
============================================================

Only commit when:
- [ ] All acceptance criteria are met
- [ ] No protected files were modified
- [ ] Lint passes
- [ ] Sub-task outputs are coherent (no conflicting implementations)

Stage by sub-task for a clean git history:
```bash
git add <implementation files>
git commit -m "feat(<scope>): <feature description>"

git add <test files>
git commit -m "test(<scope>): add tests for <feature>"

git add <doc files>
git commit -m "docs(<scope>): update <doc file> for <feature>"
```

Output a completion report:
```
PARALLEL TASK REPORT

Task: <original task>
Sub-tasks completed: <N>/<N>
Tests: PASS | FAIL (<count> passing, <count> failing)
Lint: PASS | FAIL
Protected files untouched: YES | NO

Acceptance criteria:
  ✓/✗ <criterion 1>
  ✓/✗ <criterion 2>
  ...

Commits:
  <sha> feat(<scope>): <description>
  <sha> test(<scope>): <description>
  <sha> docs(<scope>): <description>

Issues to resolve: <list, or "none">
```

============================================================
STRICT RULES
============================================================

- Never commit if any acceptance criterion is unmet. Report what failed.
- Never issue a prompt without explicit acceptance criteria. Vague prompts produce inconsistent parallel outputs.
- Never install more than 5 skills in a single session — install only what this task needs.
- If the task cannot be safely decomposed into parallel sub-tasks (shared mutable state, strict ordering requirements), run it sequentially and document why parallelism was skipped.
- Do not trust self-reported pass/fail from Composer 2.5 — always verify by running commands independently.