Using Superpowers
Install this as the default ritual so your coding agent always loads the right SKILL.md before planning, coding, or answering—instead of guessing from chat alone.
Overview
Using Superpowers is a journey-wide agent skill that enforces mandatory SKILL.md invocation before you commit to plans or code—usable whenever a solo builder needs disciplined agent workflows instead of ad-hoc chat.
Install
npx skills add https://github.com/obra/superpowers --skill using-superpowersWhat is this skill?
- Forces a Skill-tool lookup and invocation whenever a workflow might apply—even at low confidence—before normal replies o
- Blocks common failure modes: skipping skills, rationalizing shortcuts, and proceeding without reading bundled checklists
- Maps Codex/Cursor equivalents (spawn_agent, update_plan) so the same superpowers discipline works outside Claude Code.
Adoption & trust: 134k installs on skills.sh; 221k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent answers and codes from general knowledge even when a curated skill already defines the right process, so you repeat mistakes and skip proven checklists.
Who is it for?
Solo builders who installed obra/superpowers (or any large skill pack) and want the agent to actually run those skills at conversation start and before non-trivial work.
Skip if: One-off questions with no skills installed, or teams that intentionally disable skill tools and want fully free-form chat only.
When should I use this skill?
Use when starting any conversation or whenever there is even a small chance a skill applies—before planning, implementation, debugging, or other non-trivial responses.
What do I get? / Deliverables
You get a repeatable invoke-first workflow where the agent loads and follows the matching skill (and its sub-skills) before implementation, with clear platform mappings for Codex and peers.
- Announced skill invocation and adherence to the chosen SKILL.md procedure
- Documented sub-skill chain when the primary skill routes to follow-on skills
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Before committing to a product direction, invoke brainstorming or research skills instead of letting the agent pick a stack in the first reply.
When scoping an MVP, run planning-oriented superpowers skills so scope docs follow a checklist rather than a single chat paragraph.
Before editing APIs, load the implementation skill chain so file changes follow the pack’s TDD or review substeps.
Prior to merge, invoke review or testing skills so the agent does not rubber-stamp its own diff.
When production breaks, reach for systematic debugging skills first instead of random log grepping in chat.
How it compares
Use as a process gate on top of your skill library—not as a replacement for domain skills or MCP servers that connect to external APIs.
Common Questions / FAQ
Who is using-superpowers for?
It is for indie and solo developers using agentic IDEs who rely on SKILL.md packages and need a strict habit of invoking those skills instead of letting the model freestyle.
When should I use using-superpowers?
Use it at the start of any session and before planning or executing work whenever a skill might fit—including idea brainstorming, validation scoping, build implementation, ship review, launch copy passes, growth analytics setup, and operate debugging.
Is using-superpowers safe to install?
It is instructional metadata about when to call other skills; review the Security Audits panel on this Prism page and read any skill you invoke before granting shell, network, or secret access.
SKILL.md
READMESKILL.md - Using Superpowers
# Codex Tool Mapping Skills use Claude Code tool names. When you encounter these in a skill, use your platform equivalent: | Skill references | Codex equivalent | |-----------------|------------------| | `Task` tool (dispatch subagent) | `spawn_agent` (see [Subagent dispatch requires multi-agent support](#subagent-dispatch-requires-multi-agent-support)) | | Multiple `Task` calls (parallel) | Multiple `spawn_agent` calls | | Task returns result | `wait_agent` | | Task completes automatically | `close_agent` to free slot | | `TodoWrite` (task tracking) | `update_plan` | | `Skill` tool (invoke a skill) | Skills load natively — just follow the instructions | | `Read`, `Write`, `Edit` (files) | Use your native file tools | | `Bash` (run commands) | Use your native shell tools | ## Subagent dispatch requires multi-agent support Add to your Codex config (`~/.codex/config.toml`): ```toml [features] multi_agent = true ``` This enables `spawn_agent`, `wait_agent`, and `close_agent` for skills like `dispatching-parallel-agents` and `subagent-driven-development`. Legacy note: Codex builds before `rust-v0.115.0` exposed spawned-agent waiting as `wait`. Current Codex uses `wait_agent` for spawned agents. The `wait` name now belongs to code-mode `exec/wait`, which resumes a yielded exec cell by `cell_id`; it is not the spawned-agent result tool. ## Environment Detection Skills that create worktrees or finish branches should detect their environment with read-only git commands before proceeding: ```bash GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P) GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P) BRANCH=$(git branch --show-current) ``` - `GIT_DIR != GIT_COMMON` → already in a linked worktree (skip creation) - `BRANCH` empty → detached HEAD (cannot branch/push/PR from sandbox) See `using-git-worktrees` Step 0 and `finishing-a-development-branch` Step 1 for how each skill uses these signals. ## Codex App Finishing When the sandbox blocks branch/push operations (detached HEAD in an externally managed worktree), the agent commits all work and informs the user to use the App's native controls: - **"Create branch"** — names the branch, then commit/push/PR via App UI - **"Hand off to local"** — transfers work to the user's local checkout The agent can still run tests, stage files, and output suggested branch names, commit messages, and PR descriptions for the user to copy. # Copilot CLI Tool Mapping Skills use Claude Code tool names. When you encounter these in a skill, use your platform equivalent: | Skill references | Copilot CLI equivalent | |-----------------|----------------------| | `Read` (file reading) | `view` | | `Write` (file creation) | `create` | | `Edit` (file editing) | `edit` | | `Bash` (run commands) | `bash` | | `Grep` (search file content) | `grep` | | `Glob` (search files by name) | `glob` | | `Skill` tool (invoke a skill) | `skill` | | `WebFetch` | `web_fetch` | | `Task` tool (dispatch subagent) | `task` with `agent_type: "general-purpose"` or `"explore"` | | Multiple `Task` calls (parallel) | Multiple `task` calls | | Task status/output | `read_agent`, `list_agents` | | `TodoWrite` (task tracking) | `sql` with built-in `todos` table | | `WebSearch` | No equivalent — use `web_fetch` with a search engine URL | | `EnterPlanMode` / `ExitPlanMode` | No equivalent — stay in the main session | ## Async shell sessions Copilot CLI supports persistent async shell sessions, which have no direct Claude Code equivalent: | Tool | Purpose | |------|---------| | `bash` with `async: true` | Start a long-running command in the background | | `write_bash` | Send input to a running async session | | `read_bash` | Read output from an async session | | `stop_bash` | Terminate an async session | | `list_bash` | List all active shell sessions | ## Additional Copilot CLI tools | Tool | Purpose | |------|---------| | `store_memory` | Persist facts about the codebase for future session