superpowers-writing-plans

Convert written specs into structured implementation plans with tasks and principles.

1|Updated Apr 9, 2026
One-click install
npx skills add https://github.com/rohit-vc26/claude-power-kit --skill superpowers-writing-plans-rohit-vc26
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: superpowers-writing-plans
Source: https://github.com/rohit-vc26/claude-power-kit/tree/main/skills/superpowers-writing-plans
Command: npx skills add https://github.com/rohit-vc26/claude-power-kit --skill superpowers-writing-plans-rohit-vc26

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Helps engineers turn a vague spec into a complete, executable implementation plan.

Core Features & Use Cases

  • Produces a thorough plan detailing required files, code changes, testing, and verification steps.
  • Ensures adherence to DRY, YAGNI, and TDD principles.
  • Useful when specs cover multiple subsystems or complex workflows; yields one plan per subsystem that can be implemented and tested independently.

Quick Start

Provide a complete, bite-sized plan for the given spec, listing tasks in order from setup to verification.

Frequently Asked Questions about superpowers-writing-plans

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I break down a complex spec into an actionable implementation plan?

To break down a complex spec, you structure it into a detailed plan with a clear goal, architecture, tech stack, and a task-by-task breakdown. This ensures multi-step features are executable and independently testable across subsystems.

What is the best way to apply TDD and YAGNI principles when planning a feature?

The best way to apply TDD and YAGNI during feature planning is to enforce these principles directly within the task breakdown. The plan outputs bite-sized tasks ordered from setup to verification, ensuring test-driven development and avoiding unnecessary features.

How do I plan cross-subsystem changes so each part can be tested independently?

Planning cross-subsystem changes involves generating one structured plan per subsystem. This approach lists required files, code changes, and verification steps for each subsystem, allowing them to be implemented and tested independently.

When do I need upfront planning for a non-trivial software implementation?

Upfront planning is needed for non-trivial software implementations involving multi-step features or complex workflows. It transforms a vague written spec into a complete, executable plan detailing required files, testing, and verification steps.

Does this spec breakdown approach work for multi-step features spanning multiple subsystems?

Yes, spec breakdown works effectively for multi-step features spanning multiple subsystems. It produces a thorough plan detailing required code changes and yields one plan per subsystem that can be implemented and tested independently.