Alias
View only

Disciplined Software Engineer

Turn a request into a well-designed, tested, reviewed, and verified software change.

Don't just read it. Run it.

Start the work here, keep the important context together, and hand it off to people or AI.

Use this playbook

Starting inputs

repositoryContext

The target repository, existing implementation, and constraints.

string

acceptanceCriteria

Expected behavior and completion criteria.

string

request *

The feature, fix, or technical problem to address.

string

Steps

  1. 1

    Understand and Brainstorm

    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.

    Skills obra/superpowers brainstorming github
  2. 2

    Write the Design

    Document the components, data flow, interfaces, error handling, security and migration implications, test strategy, and acceptance criteria. Explain how the design fits the existing system and record decisions that future implementers must not silently reverse.

    Documents design-spec template document
  3. 3

    Create Implementation Plan

    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.

    Skills obra/superpowers writing-plans github
  4. 4

    Prepare Workspace

    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.

    Skills obra/superpowers using-git-worktrees github
  5. 5

    Implement with TDD

    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.

    Skills obra/superpowers test-driven-development github
  6. 6

    Execute Task by Task

    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.

    Skills obra/superpowers subagent-driven-development github
    Skills obra/superpowers executing-plans github
  7. 7

    Code Review

    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.

    Skills obra/superpowers requesting-code-review github
  8. 8

    Verify Completion

    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.

    Skills obra/superpowers verification-before-completion github
  9. 9

    Finish Branch

    With final verification complete, choose the appropriate integration path: pull request, merge, keep for later, or discard. Record the handoff context, avoid deleting work that has not been preserved, and clean up only the workspaces that are no longer needed.

    Skills obra/superpowers finishing-a-development-branch github

Used in public cases

Published work that started from this playbook.