Issue → Implementation

Overview

Take a finalized GitHub issue (the durable what/why spec produced by brainstorming-to-issue) and drive it to merged code — without a committed plan document and without a human approval gate on the plan. Plan generation is delegated wholesale to superpowers:writing-plans; only its persistence (where the plan lives) and its handoff (who decides how to execute) are overridden.

Core principle: the issue is the durable spec; the plan is ephemeral how. So the plan lives in per-run scratch and is mirrored into the PR description at the end — never committed under docs/. Execution auto-hands to superpowers:subagent-driven-development; there is no "which approach?" question.

This is the exact inverse of brainstorming-to-issue: that skill reuses brainstorming's dialogue but diverts its docs/ + writing-plans tail into an issue; this skill reuses writing-plans' generation but diverts its docs/ + human-choice tail into scratch + auto-SDD.

When to Use

• A finalized (non-[DRAFT]) issue exists and you're ready to build it now.
• The work is more than one test-and-commit: multiple files, or two-plus independently reviewable deliverables, or interfaces between units.

When NOT to use:

• The issue is still [DRAFT] or the spec isn't settled → use superpowers:brainstorming / brainstorming-to-issue first.
• The change is trivial (see the gate below) → skip planning entirely and go straight to superpowers:test-driven-development.