softpowers

Softpowers

Softpowers is a human-led software development workflow for coding agents. It uses LLMs for exploration, specifications, planning, research, review, and verification, while keeping implementation close to the developer by default.

Softpowers is a fork of Superpowers. The goal is to stay technically compatible with upstream where practical while taking a different product stance: agents should help humans think and ship better software, not silently become the default implementer.

How it works

It starts from the moment you fire up your coding agent. When a task is tiny or clearly scoped, it can just handle it directly. When the task looks bigger, riskier, or fuzzier, it can slow down and ask whether you want direct execution, light guidance, or the full Softpowers flow.

If you choose the full flow, the agent helps tease a spec out of the conversation, then shows it to you in chunks short enough to actually read and digest.

After you've signed off on the design, your agent helps put together an implementation plan with clear phases, concrete verification steps, and enough context for a developer to execute without guessing. It emphasizes true red/green TDD, YAGNI (You Aren't Gonna Need It), DRY, and maintaining the developer's mental model of the code.

Next up, the recommended path is Softassist: you stay the primary implementer while the agent guides one step at a time, fetches documentation, reviews diffs, runs verification, and takes on agreed mechanical chores when useful. Fully delegated implementation is still available, but it is an explicit choice rather than the default.

There's a bunch more to it, but that's the core of the system. The heavy workflows are available when you want them, instead of being forced onto every tiny request.

Why Softpowers?

LLMs are excellent collaborators for exploring ideas, surfacing trade-offs, drafting specifications, decomposing plans, finding documentation, reviewing changes, and running verification loops.

But implementation is not just typing. Writing, debugging, and refactoring code are how developers build and maintain their mental model of a system. If agents silently take over that work by default, the developer can lose the very cognitive skill needed to supervise those agents well.

Softpowers keeps the human in the implementation loop by default. The agent helps you think, plan, verify, and review. It can also take on boring or mechanical work when explicitly delegated. But the default workflow is human-led, not agent-led.

Use the ship's computer, not an autopilot you no longer understand.

About this fork

This fork carries bnema-specific experiments on top of obra/superpowers and is being repositioned as Softpowers. Use upstream/obra for the canonical Superpowers project and origin/bnema for these custom changes.

Notable differences in this fork:

• OpenCode and Pi install/update docs point at github.com/bnema/softpowers.
• Pi support is experimental, including .pi/agents/ setup for subagent-based workflows.
• Heavy workflows are opt-in: small or clearly scoped tasks can stay in direct execution.
• Plan execution recommends softassist, where the human stays the primary implementer and the agent provides guidance, research, review, verification, and explicitly delegated mechanical help.
• Fully delegated implementation remains available for cases where the human deliberately wants the agent to implement phases or sub-tasks.
• Both specs and implementation plans can be saved as either Simple Markdown or Enriched HTML. The workflow asks which output to use before creating the final artifact:
  • brainstorming produces spec documents.
  • writing-plans produces implementation playbooks with phases, tasks, and concrete verification steps.
  • softassist reads the approved spec and plan, then guides step-by-step.
  • Document storage resolves paths as follows:
    • When PROJECTS_DOCS_PATH is set, files go under $PROJECTS_DOCS_PATH/{repoName}/plans or $PROJECTS_DOCS_PATH/{repoName}/specs.
    • Otherwise, docs/softpowers/ in the repo is used.
    • Resolve the env variable explicitly with printenv PROJECTS_DOCS_PATH.
    • Derive {repoName} from the git top-level directory basename when possible.
    • Do not create a second repo-local copy when the resolved docs path lives outside the project repo.