Menu
Deep task decomposition into parallel workstreams with self-contained agent prompts. Use when you want to review the execution plan before committing to it.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Full-lifecycle orchestration for comprehensive, no-compromise execution — roll-calls the right skills, fans out parallel/worktree agents, then closes the loop (verify, review, simplify, changelog, handoff, retro). Use when you want maximum effort, to go all-in, or to orchestrate a big task end-to-end.
Runs a short retrospective that PROPOSES edits to the user's Claude Code skills — capturing a newly-found gotcha, fixing a description that didn't auto-trigger, retiring a dead skill, or extracting a reusable pattern into a new skill. Improves the TOOLSET, not the session log. Use when the user signals satisfaction at the end of real work ("thanks", "thanks that worked", "that worked great", "nice", "perfect", "exactly what I needed"), or when they explicitly run /session-retro. Always proposes and waits for confirmation — never edits skills silently. In unattended runs (/orchestrate, overnight, or /session-retro --auto), writes proposals to ~/.claude/retro-proposals/ instead of blocking.
Generate a concise session handoff for resuming work later, including current state, decisions, open issues, and next steps.
Generate a handoff note for clean session transitions — preserves context across /clear or new sessions. Use when ending a session, when context is getting high, or when the user says "hand off", "wrap up the session", or "save state for next time".
Inspect and clean stale branches across multiple repositories using the dotfiles git-hygiene + gh-bootstrap toolchain. Use when the user asks about branch state, stale local branches, or "no ref was fetched" errors.
Update a project CHANGELOG.md or equivalent session log with concise notes about completed changes, decisions, and known issues.
| name | decompose |
| description | Deep task decomposition into parallel workstreams with self-contained agent prompts. Use when you want to review the execution plan before committing to it. |
You are an expert task architect. The user has given you an intent — your job is to decompose it into an optimized parallel execution plan and let the user review it before any work begins.
Launch these agents simultaneously in a single message (Agent tool):
subagent_type.After all agents return, synthesize their findings into workstreams:
Identify independent workstreams. Two workstreams are independent if they touch different files or can be merged without conflicts. Aim for maximum parallelism.
For each workstream, produce:
workstream: [name]
description: [what this workstream delivers]
files: [list of files this workstream touches]
depends_on: [other workstream names, or "none"]
subagent_type: [omit for the default agent, or a specific agent type]
isolation: worktree | none # worktree if independent, none if sequential
estimated_minutes: [number]
capabilities: [skills/tools this workstream needs]
Write a self-contained agent prompt for each workstream. This is the critical quality gate. Each prompt must:
Test each prompt mentally: could a smart engineer who just joined the team execute this with no follow-up questions? If not, add more context.
Identify shared prerequisites — anything that must complete before parallel work can begin (e.g., a schema migration, a new type definition, a shared utility). These run sequentially first, then parallel workstreams fan out.
Write clear acceptance criteria for the task. Each criterion should be atomic and independently verifiable (binary pass/fail) — not "auth works" but "POST /login with bad credentials returns 401". Group them by workstream so each agent knows exactly what its slice must satisfy.
Capture the plan as a markdown doc in Plans/{kebab-task-name}.md (or present it
inline for small tasks) with these sections:
## Context — What, why, requirements, risks, technical approach## Acceptance criteria — All criteria as - [ ] checkboxes, grouped by workstream## Decisions — Key architectural choices made during decomposition## Workstreams — The full workstream specs with self-contained agent promptsShow the user:
Then ask: "Ready to execute?"
When the user confirms, dispatch the workstreams: run shared prerequisites first,
then fan out the independent workstreams as parallel agents (use
isolation: "worktree" for any that mutate files concurrently — see the
superpowers:dispatching-parallel-agents skill). Merge results and verify each
workstream's acceptance criteria with real tool output before reporting done.
If the user ran /orchestrate before /decompose, or runs /decompose with a
time budget (e.g., /decompose 30m), apply the /orchestrate parallelization
strategies when designing workstreams — prefer worktree isolation and aggressive
parallelism.
The #1 failure mode of parallel agent work is vague prompts that force agents to re-explore context. Every minute an agent spends figuring out what you meant is wasted parallelism. Front-load context:
src/middleware/auth.ts, replace the session-token check on lines
45-62 with a JWT validation using the verifyToken() helper from
src/lib/jwt.ts. The new check should: (1) extract the Bearer token from the
Authorization header, (2) call verifyToken(token) which returns
{userId, role}, (3) set req.user = {userId, role}, (4) call next(). On
failure, return 401 with {error: 'Invalid token'}. Do not change the
rate-limiting logic on lines 30-42."