Plan+

plan+ — Disciplined Planning

Wraps superpowers:writing-plans. Requires superpowers to be installed.

Before You Begin

This skill runs after brain+ has produced a validated design. It creates the implementation plan with testing discipline baked into every task.

Procedure

Phase A: Load Context

1. Read the design output from brain+ (from the current session or saved spec).

1. When you need to explore the codebase (verify file paths, check dependencies, find related modules), use the scout agent:

`` Agent(subagent_type="scout", prompt="Map the codebase structure for [area]. Focus on: dependencies, test files, and related modules.") ``

1. Load active enforcement rules from session context (see session-start output). If active enforcement rules are configured, add a Constitutional Compliance section to the plan:

``` ## Constitutional Rules for This Plan [List active enforcement rules from session-start output — these are configurable via .harness.yaml]

• Use real [database/payment/logger] connections in stack/E2E tests — mocks are appropriate in unit tests
• Show command output before claiming done
• Every source file change requires corresponding test changes
• Full-loop assertions: verify primary + second-order + third-order effects

```

1. Identify the mock policy for this plan based on active enforcement rules:

`` ## Mock Policy Stack/E2E (real deps): [list from active enforcement rules] Unit tests (mocks ok): [all components] / External without sandbox: [third-party services] ``

Phase B: Create Plan (delegate to superpowers:writing-plans)

1. Invoke superpowers:writing-plans with the enriched context.

1. For each task in the plan, ensure it includes:

• Test strategy: which tests cover this task's requirements
• Mock check: does this task need to interact with protected components (per active enforcement rules)?
• Evidence criteria: what output proves this task is done

1. Every task must follow the pattern:

``` ### Task N: [Name] Files: [exact paths] Test strategy: [which tests, scoped to this task] Mock check: [are protected components involved?]

• [ ] Step 1: Write failing test
• [ ] Step 2: Verify it fails
• [ ] Step 3: Write minimal implementation
• [ ] Step 4: Verify it passes
• [ ] Step 5: Commit

```

1. If the design includes a loop/signal-stack section (see

references/agent-loops.md): order the plan signal-stack-first — harness tasks (golden tests, contract probes, calibration harness, dry-run rig, telemetry store) come before or alongside the features they gate, because the assembly process uses the stack to verify itself as it builds. Then:

• Each task names its gating signal (which layer's signal proves it done)
• The maintainer deployment is a late task, after the primary system's

acceptance criteria pass

• Rollout gates (credentials, schedule enablement, live writes) are

explicitly reserved to the user — never automated in any task

1. Independence contract (consumed by sdd+ team mode): every task's

**Files:** list must be exhaustive — include shared test files a task extends (a tests file touched by several tasks makes them dependent). Where ordering matters even without file overlap, add an explicit Depends on: Task N line under the task header. A pair of tasks is parallelizable only when their Files lists are disjoint AND neither depends on the other.

Phase C: Validate Plan

1. Confirm the plan:

• [ ] Every task has a test strategy
• [ ] No task mocks a protected component
• [ ] Plan references exact file paths (no TBDs)
• [ ] Evidence criteria defined for each task
• [ ] Active enforcement rules section present (if rules are configured)

Output

Save the plan to docs/plans/ and feed into tdd+ for implementation.

Skill Chain

After completing plan+, the next step is:

• Invoke /tdd+ to implement the plan task-by-task with RED-GREEN-REFACTOR
• Or invoke /sdd+ to execute the plan via typed subagents (implementer → spec-reviewer → code-reviewer) — best for plans with independent tasks

Completion

Report one of these states when the skill finishes:

• DONE — Plan saved to docs/plans/, all validation checklist items in Phase C confirmed.
• DONEWITHCONCERNS — Plan complete but has open questions or tasks needing refinement.
• BLOCKED — Cannot proceed (missing design from brain+, unclear requirements).
• NEEDS_CONTEXT — Need user input to resolve a task scope or dependency question.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: franklywatson
• Source: franklywatson/claude-rig
• License: MIT

Install and usage instructions live in the source repository linked above.