plan

Plan

Turn work into a task graph that maximizes throughput — what's independent, what genuinely depends on what, and how to structure agents around it.

This skill exists because planning drifts linear by default. A → B → C is the natural shape to write down even when B and C touch different files and share no state, and the result is correct but slower than it needs to be. So the question this skill keeps asking is: what is the minimal set of sequential constraints here?

Arguments

$ARGUMENTS

Pre-computed Context

Git root: !`git rev-parse --show-toplevel 2>/dev/null || echo "NOT A GIT REPO"`
Test suite: !`test -d test/ && echo "yes" || echo "no"`
CLAUDE.md exists: !`test -f CLAUDE.md && echo "yes" || echo "no"`

Constraints

• Call EnterPlanMode before designing the plan. This skill is plan-first.
• Never use git -C <path> — it rewrites the command prefix and breaks allowed-tools matching.

1. Enter plan mode

Call EnterPlanMode immediately. Everything below happens inside it.

2. Understand the work

If $ARGUMENTS carries context from /gather-context or /think, use it. Otherwise explore: what files change, what the current code does and why, what tests exist and what patterns they follow.

3. Decompose, then find the parallelism

Break the work into discrete tasks. For each, establish what must complete before it can start, what kind of agent suits it, whether it benefits from worktree isolation (it does if another task touches the same files), and whether a human should review before downstream work proceeds.

Then make a deliberate pass over dependencies, starting from the assumption that everything is independent. Group tasks by the files they touch — different groups are parallel candidates. For each pair, ask whether task B needs task A's output, or merely needs A to exist. Only the first is a real dependency. Add blockedBy only where that test fails, with a one-line reason.

Two rules of thumb worth applying: tests can often be written in parallel with implementation when they test the interface rather than the implementation, and review can start as soon as there's something to review rather than waiting for everything.