Use when you have a spec or requirements for a multi-step task, before touching code
Creates detailed, step-by-step implementation plans from specifications for developers unfamiliar with the codebase.
/plugin marketplace add oskar-dragon/claude-code/plugin install superpowers@claude-codeThis skill inherits all available tools. When active, it can use any tool Claude has access to.
You MUST NOT call ExitPlanMode at any point during this skill. This skill manages its own completion flow via AskUserQuestion. Calling ExitPlanMode breaks the workflow and skips the user's execution choice. If you feel the urge to call ExitPlanMode, STOP — that means you should be at the Execution Handoff section below.
Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
Announce at start: "I'm using the writing-plans skill to create the implementation plan."
Context: This should be run in a dedicated worktree (created by brainstorming skill).
Save plans to: docs/plans/<feature-name>/plan.md (or plan.local.md if non-committable)
BEFORE exploring code or writing the plan, you MUST:
TaskList to check for existing tasks from brainstorming (for awareness only)Do not proceed to exploration until TaskList has been called.
IMPORTANT: Do NOT call TaskCreate for PR-level tasks at plan time. PR tasks go into tasks.json only. The executing skill reads tasks.json to find the next PR to work on each session.
TaskList
Read the **Committable:** field from the design doc header. This was set during brainstorming.
true (or absent for backward compatibility): use .md extensions, commit planning docsfalse: use .local.md / .local.json extensions, skip git add/commit for planning docsFile extensions follow this table:
| Committable | Plan | Tasks |
|---|---|---|
true | plan.md | tasks.json |
false | plan.local.md | tasks.local.json |
Copy the **Committable:** field into the plan document header so downstream skills (executing-plans, subagent-driven-development) can read it without needing the design doc.
Three levels:
## PR N:) — a deployable increment; gets its own branch and pull request### Task N:) — an atomic commit unit within a PR; each task ends in verify + commit. Tasks are not independently deployable — they accumulate on the PR branch until the PR is opened.**Step N: ...**) — a single implementation detail within a task; bold named header with content belowA PR is deployable when:
Group tasks into a PR when they collectively deliver one independently deployable increment. A PR must not span unrelated concerns. When in doubt, split into more PRs.
Every plan MUST start with this header:
# [Feature Name] Implementation Plan
> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task.
**Goal:** [One sentence describing what this builds]
**Architecture:** [2-3 sentences about approach]
**Tech Stack:** [Key technologies/libraries]
**Committable:** [true/false — copied from design doc]
---
## Plan Structure
Plans use a 3-level hierarchy. All numbering starts at 1. Every task MUST end with a named Verify step then a named Commit step.
````markdown
## PR 1: [PR-worthy description]
### Task 1: [Component Name]
**Files:**
- Create: `exact/path/to/file.py`
- Modify: `exact/path/to/existing.py:123-145`
- Test: `tests/exact/path/to/test.py`
**Step 1: Write the failing test**
```python
def test_specific_behavior():
result = function(input)
assert result == expected
```
**Step 2: Run test to verify it fails**
Run: `pytest tests/path/test.py::test_name -v`
Expected: FAIL with "function not defined"
**Step 3: Write minimal implementation**
```python
def function(input):
return expected
```
**Step 4: Run test to verify it passes**
Run: `pytest tests/path/test.py::test_name -v`
Expected: PASS
**Step 5: Verify**
[any additional checks — read the file, grep for patterns, etc.]
**Step 6: Commit**
```bash
git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature"
```
**Acceptance Criteria:**
- [ ] Criterion from design
### Task 2: [Next component — another atomic commit in the same PR]
**Files:**
- Modify: `exact/path/to/existing.py`
**Step 1: [Action]**
[content]
**Step 2: Verify**
Run: `command`
Expected: output
**Step 3: Commit**
```bash
git add path/to/file
git commit -m "feat: add next component"
```
**Acceptance Criteria:**
- [ ] Criterion from design
→ Open PR: "feat: [pr description]"
````
**Rules:**
- Steps are bold named headers (`**Step N: Description**`) with content below — never a numbered list
- The `→ Open PR: "..."` line ends each PR section — the executing skill reads this for the PR title
- PR body is built from the task subjects and acceptance criteria in that PR
Your ONLY permitted next action is calling AskUserQuestion with this EXACT structure:
AskUserQuestion:
question: "Plan complete and saved to docs/plans/<feature-name>/plan.md. How would you like to execute it?"
header: "Execution"
options:
- label: "Subagent-Driven (this session)"
description: "I dispatch fresh subagent per task, review between tasks, fast iteration"
- label: "Parallel Session (separate)"
description: "Open new session in worktree with executing-plans, batch execution with checkpoints"
If you are about to call ExitPlanMode, STOP — call AskUserQuestion instead.
If Subagent-Driven chosen:
If Parallel Session chosen:
At plan completion, write the task persistence file to docs/plans/<feature-name>/tasks.json.
{
"planPath": "docs/plans/<feature-name>/plan.md",
"prs": [
{ "id": 1, "subject": "PR 1: ...", "status": "pending" },
{ "id": 2, "subject": "PR 2: ...", "status": "pending", "blockedBy": [1] }
],
"lastUpdated": "<timestamp>"
}
All artifacts (plan, design, tasks) must be co-located in docs/plans/<feature-name>/.
If committable: Commit both plan and tasks file:
git add docs/plans/<feature-name>/plan.md docs/plans/<feature-name>/tasks.json
git commit -m "plan: <feature-name>"
If non-committable: Files are plan.local.md and tasks.local.json. Do NOT commit.
Any new session can resume by running:
/superpowers:executing-plans <plan-path>
The skill reads the tasks.json file and continues from where it left off.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.