Executing Plans
Batch-executes an already-written implementation plan with human checkpoints, for sessions without subagent support
Provides a useful, structured execution workflow for coding agents that already have a written implementation plan, including review checkpoints and blocker handling. Its boundaries are reasonably clear: it is not the planning, TDD, or branch-finishing skill. However, it does not define a plan-file format, supported project scope, or limits for complex plans.
Requires per-task status updates, exact plan execution, and the plan's specified verifications; it also stops on blockers, failures, or ambiguity instead of guessing. This supports procedural consistency. Reliability is reduced by dependencies on writing-plans, using-git-worktrees, and finishing-a-development-branch, plus the absence of concrete recovery behavior, persisted state semantics, retry limits, or standardized verification criteria.
The skill includes critical plan review, human confirmation, stop-and-ask behavior, and an explicit prohibition on starting implementation on main/master without consent. Requiring worktrees can also reduce workspace contamination. It does not specify permission boundaries for file edits, command execution, network access, credentials, or sensitive data, and it lacks a clear rollback or recovery procedure for partial changes.
The selected skill provides a coherent process description but no skill-specific behavioral tests, execution records, success metrics, or independent corroboration. Repository-level references to broader tests and evaluation tooling do not establish that this selected skill works as described. This is static review only, so no test execution is claimed; the skill-level evidence gap is substantial.
The steps and stop conditions are understandable, and fixed announcement text is supplied for start and completion. Inputs are only loosely described as a plan file; outputs, todo-tool requirements, checkpoint interaction, platform compatibility, cost, installation prerequisites, and troubleshooting are underspecified. Required companion skills are referenced but not operationally summarized here.
The repository supplies an MIT license, a package version, and general update information, and the skill references related repository skills. Publisher provenance is not verified by the FollowSkills curated enterprise registry, so it cannot support governance or quality claims. The skill lacks its own version constraints, changelog, named maintainer, release responsibility, and explicit update path, leaving maintenance evidence limited.
- This workflow directs an agent to modify code and run verifications; confirm the host platform, tool permissions, plan provenance, and human authorization boundaries before adoption.
- The required companion skills may be unavailable or incompatible; prepare explicit rollback and recovery procedures for missing skills, failed verification, and partial completion.
- Do not treat repository-wide tests, README claims, or the unverified publisher identity as independent evidence that this selected skill has been validated.
What it does & when to use it
The lightweight alternative to subagent-driven-development: when you already have an implementation plan from writing-plans but the current environment doesn't support subagents (or you deliberately want a fresh session to run it), this skill works through the plan task by task, verifying each step, and stops to ask when blocked rather than guessing. The doc itself is short (about 70 lines) — the core value is a clear set of stop conditions.
Reads the plan file and reviews it critically first, raising concerns before starting; creates a todo per plan item; for each task, marks it in-progress, follows the steps exactly, runs the specified verification command, and marks it complete; once every task is done, hands off to finishing-a-development-branch for wrap-up (run tests, decide merge/PR/keep/discard). Stops immediately and asks for help on any blocker — missing dependency, failing test, unclear instruction, repeated verification failure — instead of guessing through it.
- Run an existing implementation plan on a harness that has no subagent support (some pure-CLI tools)
- Deliberately execute a plan in a fresh session to avoid carrying brainstorming-phase chat history into implementation
- Hit a mid-execution problem with the plan itself and need to stop for human input rather than silently patching the plan
Pros & cons
- The stop conditions are concrete (blockers, critical plan gaps, unclear instructions, repeated verification failures), reducing the risk of silently improvising missing instructions
- The doc itself is minimal (~70 lines), cheap to read and understand — unlike some of the other Superpowers skills that run several hundred lines
- Clean integration with finishing-a-development-branch, using-git-worktrees, and writing-plans forms an actual pipeline instead of an isolated document
- Only reliably self-enforcing on harnesses that actually read and follow SKILL.md instructions (Claude Code, Codex CLI, etc.) — in a plain chat interface it's just a document a human has to apply by hand.
- It's a deliberate fallback for environments without subagent support — functionally less rigorous than subagent-driven-development's two-stage review
- The granularity of "batch execute, checkpoint review" depends heavily on how well the plan itself is written — this skill only executes the plan, it doesn't vouch for the plan's quality
How to install
Installed as part of the obra/superpowers plugin — individual skills can't be installed standalone:
- Claude Code: official marketplace
/plugin install superpowers@claude-plugins-official; or register the community marketplace with/plugin marketplace add obra/superpowers-marketplacethen/plugin install superpowers@superpowers-marketplace - Also supports Antigravity, Codex App/CLI, Cursor, Factory Droid, GitHub Copilot CLI, Kimi Code, OpenCode, and Pi — see the repo README for the exact command per harness
Once installed, this skill activates alongside the other 13 Superpowers skills, auto-triggered by using-superpowers based on context — there's no separate invocation step.
How to use
Triggers when you already have a plan file from writing-plans and want it executed in the current or a new session. Typical flow: load the plan → work through tasks in order → run the verification command for each step → hand off to finishing-a-development-branch once everything's done.
Compared to similar skills
Versus subagent-driven-development: that skill dispatches a fresh subagent per task within the same session and runs two-stage review (spec compliance + code quality) — faster iteration and stricter, but needs subagent support. executing-plans is the fallback path when subagents aren't available, or when you deliberately want a clean new session — not meant to be used alongside subagent-driven-development on the same plan.