obra/superpowers

Do not implement immediately. Inspect existing behavior and constraints, clarify requirements and edge cases, compare viable designs, and select an approach with explicit trade-offs. Stop for human approval whenever a product or architectural decision remains materially ambiguous.

Break the design into small, independently verifiable tasks. For every task, name the files or interfaces affected, the behavior to add or change, the test that proves it, dependencies, and its completion criteria. Order tasks to reduce risk and preserve a working system.

Work in an isolated workspace when the change needs protection from the main checkout. Inspect existing changes first, run the narrowest useful baseline checks, and distinguish pre-existing failures from failures caused by this work before modifying production code.

For each behavioral change, first write a test that fails for the intended reason. Implement only enough to make it pass, then refactor without changing behavior. Keep the Red, Green, Refactor evidence and do not rely on an unobserved test failure as proof of coverage.

Execute the approved plan one task at a time. After each task, verify the specified behavior and assess whether the task remains aligned with the design. Use separate implementer and reviewer agents when available; otherwise perform the same independent review checkpoint yourself.

Review correctness, requirements compliance, design fit, tests, maintainability, security, and operational behavior. Treat findings as concrete work: fix required issues, rerun affected checks, and do not advance while a release-blocking concern remains unresolved.

Before claiming completion, run the relevant tests, lint, build, static analysis, and required manual checks against the final state. Read every result, verify the acceptance criteria, and report the actual evidence rather than an expectation that the change should work.