Superpowers for Coding Agents: Branching Makes Sense

Adityo Guni WaluyoOctober 10, 202618:03

Adopting the superpowers framework turns a branching naming convention into a real isolation requirement. One worktree per task, enforced by the workflow itself.

#claude-code #superpowers #git-worktree #ai-agents

TL;DR

The superpowers framework chains coding agents through mandatory stages—brainstorming, git worktrees, planning, TDD, code review—enforced by skills. Worktrees give each task an isolated directory and branch, making the one-branch-per-task rule functional rather than ritual. The overhead pays off only in long autonomous runs; disable telemetry if your data policies are strict.

The workflow chain that lights up on its own

The first time I ran a coding agent on a city portal project, not a single line of code had been written. What showed up instead was a log saying the brainstorming stage had started automatically, followed by the creation of a fresh git worktree. I initially assumed our branching rule was just a naming convention to keep the Git history tidy.

Wrong. The one-branch-per-task rule is not bureaucracy; it exists because worktrees work through physical isolation. The superpowers framework enforces the flow through skills, while Git enforces the isolation through worktrees. That combination is what makes agent discipline survive long autonomous runs.

The framework is a composable skills-based software development methodology, popularized by Jesse Vincent and released under an MIT license. On harnesses like Hermes, installation is one command:

hermes plugins install obra/superpowers --enable

Once active, the agent follows a mandatory chain: brainstorming, then using-git-worktrees, writing-plans, subagent-driven-development or executing-plans, test-driven-development with the RED-GREEN-REFACTOR cycle, requesting-code-review, and finally finishing-a-development-branch. The trigger is sensitive: a skill with even minimal relevance to the task must be invoked, not skipped. Notably, user instructions in CLAUDE.md or AGENTS.md still outrank bundled skills, so framework defaults can be overridden without forking anything.

Worktree: one directory, one branch

A git worktree is a separate working directory with its own branch that still shares the same repository history. Two sessions can run in parallel, one building a feature while another fixes a bug, without overwriting each other's files. This is where the branching rule finds its reason to exist: one branch per task is not about aesthetics, it is the precondition for worktree isolation to mean anything.

One detail gets missed often: a worktree is a fresh checkout, so dependencies and files like .env do not carry over. If a "module not found" error appears the moment the agent switches tasks, that is the sign the new worktree's environment was never initialized. A .worktreeinclude file can carry Gitignored files into every new worktree automatically.

One more thing to know before adopting: telemetry is on by default. For environments with strict data policies, disable it through the SUPERPOWERS_DISABLE_TELEMETRY environment variable before running the agent.

When the discipline pays for itself

For a small project with a five-line change, the chain feels excessive; a direct prompt is faster. The hard boundaries only show their value when an agent runs hundreds of steps alone. That is when forced brainstorming prevents features built on a wrong understanding, forced TDD prevents code that merely looks like it works, and worktrees keep two experiments from wrecking each other. Tool-enforced discipline becomes a stability guarantee, and the branching rule that once sounded like ritual finally makes sense: it exists so the isolation actually happens.