Build a new feature in an existing codebase

Explore before designing, design before building, and stay skeptical of the design once it exists — the ordering that keeps the most common development task from becoming ad hoc.

Also usessuperpowersclaude-plugins-official

Building a new feature is the most common development task, and the easiest to let slide into ad hoc work. feature-dev:code-explorer and feature-dev:code-architect keep exploration and design as separate, sequential steps; code-modernization:architecture-critic is cheapest to apply against a blueprint that has not yet become a branch. Tests come from superpowers' test-driven-development before the feature exists to test, and andon:andon-verify checks the new feature's integration with existing stages as a wire, not a formality.

Start here

One prompt to start

I want to build this new feature -- trace how the existing code around it actually works before we design anything, turn that into a concrete blueprint naming the files and build order, review the blueprint adversarially before any branch exists, write the tests from the specification rather than the finished code, and prove the new feature's integration with andon-verify rather than trusting a green suite.

Needsfeature-dev, code-modernization, superpowers, andon

Beats

Run these in order. Each prompt is copy-pasteable straight into Claude Code.

1. feature-dev:code-explorer

   Traces execution paths and maps layers while the design is still negotiable; its tools grant has no Write/Edit, so it cannot drift into building before the design is settled.

   Run this beat on its own

   before we design anything, trace how the existing code around this feature actually works — layers, data flow, the abstractions already in play

2. feature-dev:code-architect

   Produces the blueprint naming specific files to create/modify and the build sequence — a blueprint written after the first file exists is a rationalization, not a plan.

   Run this beat on its own

   now give me a concrete blueprint: which files to create or modify, the component design, and the order to build them in

3. code-modernization:architecture-criticalso in 1 other recipe

   • Decide an architecture that will not force a rewrite

   Its default stance is skeptical — looks for over-engineering and simpler alternatives. Cheapest to apply against a blueprint, worthless once the branch is already built.

   Run this beat on its own

   review this blueprint adversarially before I start — where is this over-engineered, and what's the simpler alternative?

4. superpowers:test-driven-developmentalso in 3 other recipes

   • Root-cause a bugfix from a tracked issue
   • Collapse duplication hand-synced across N sites
   • Refactor for maintainability

   Tests written after the feature exists test the feature that got built, not the one that was specified.

5. andon:andon-verifyalso in 13 other recipes

   • Audit supply-chain pinning and dependencies
   • Finish and integrate a development branch
   • Investigate a job that reports success but changed nothing
   • Investigate a fix that did not stick
   • Investigate tests that pass while the code is broken
   • Root-cause a bugfix from a tracked issue
   • Collapse duplication hand-synced across N sites
   • Execute a written plan across parallel workstreams
   • Migrate a return shape or type representation
   • Propagate a vendored artifact to N copies
   • Audit your own agent and skill definitions for loop-reliability defects
   • Do oracle engineering and numerical V&V
   • Whole-branch review without re-trusting the branch's own self-assessment

   The new feature's integration with existing stages is a wire, not a formality; a green test suite is not by itself evidence that wire holds.

Worked example

Grounded in — why this beat order is trustworthy

Adding a subcommand to tools/werkstoff-cli/src/werkstoff/ — cli.py and core.py split the surface, and tests/__snapshots__/test_cli.ambr will re-record silently if the feature lands before the snapshot is read, which is exactly the kind of integration wire andon-verify exists to check rather than assume.

Do / Don't

• ✓Trace the existing execution paths and layers before designing anything -- done with an explorer that has no Write/Edit access, so it cannot drift into building ahead of the design.
• ✓Write the blueprint naming specific files and a build order before the first file exists -- a blueprint written after is a rationalization, not a plan.
• ✓Review the blueprint adversarially while it's still just a blueprint -- architecture-critic is cheapest against a blueprint and worthless once the branch is built.
• ✓Write tests from the specification, before the feature exists to test.
• ✓Prove the new feature's integration with existing stages with andon-verify -- a green suite alone is not evidence that the wire holds.

• ×Don't design before tracing how the existing code actually works -- exploration and design are separate, sequential steps.
• ×Don't write the blueprint after the first file already exists -- that produces a rationalization, not a plan.
• ×Don't skip the adversarial review once a branch already exists -- by then it's too late to be cheap.
• ×Don't write tests after the feature already exists -- they'll test the feature that got built, not the one that was specified.