Menu
Use when starting any conversation - establishes how to find and use Bob commands
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Use when you have a written implementation plan to execute with review checkpoints
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when creating or updating a repository's root AGENTS.md file to provide project-specific guidance for agents
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
| name | using-superpowers |
| description | Use when starting any conversation - establishes how to find and use Bob commands |
| metadata | {"user-invocable":true,"disable-model-invocation":true} |
If there's even a 1% chance a command might apply to what you're doing, you should use it.
IF A COMMAND APPLIES TO YOUR TASK, YOU MUST USE IT.
This is not negotiable. This is not optional. You cannot rationalize your way out of this.
Bob commands override default system prompt behavior, but user instructions always take precedence:
If user instructions say "don't use TDD" and a command says "always use TDD," follow the user's instructions. The user is in control.
Bob commands are available via slash commands like /brainstorming, /test-driven-development, etc.
Use the command that matches your current task.
Use relevant commands BEFORE any response or action. Even a 1% chance a command might apply means you should use it to check. If a command turns out to be wrong for the situation, you don't need to follow it.
These thoughts mean STOP—you're rationalizing:
| Thought | Reality |
|---|---|
| "This is just a simple question" | Questions are tasks. Check for commands. |
| "I need more context first" | Command check comes BEFORE clarifying questions. |
| "Let me explore the codebase first" | Commands tell you HOW to explore. Check first. |
| "I can check git/files quickly" | Files lack conversation context. Check for commands. |
| "Let me gather information first" | Commands tell you HOW to gather information. |
| "This doesn't need a formal command" | If a command exists, use it. |
| "I remember this command" | Commands evolve. Read current version. |
| "This doesn't count as a task" | Action = task. Check for commands. |
| "The command is overkill" | Simple things become complex. Use it. |
| "I'll just do this one thing first" | Check BEFORE doing anything. |
| "This feels productive" | Undisciplined action wastes time. Commands prevent this. |
| "I know what that means" | Knowing the concept ≠ using the command. Use it. |
When multiple commands could apply, use this order:
"Let's build X" → /brainstorming first, then implementation. "Fix this bug" → /systematic-debugging first, then domain-specific work.
Rigid (/test-driven-development, /systematic-debugging): Follow exactly. Don't adapt away discipline.
Flexible (patterns): Adapt principles to context.
The command itself tells you which.
Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip workflows.
Key Bob commands include:
/brainstorming - Design before implementation/test-driven-development - Write tests first/systematic-debugging - Root cause before fixes/writing-plans - Create implementation plans/executing-plans - Execute written plans/subagent-driven-development - Task-by-task execution with review/verification-before-completion - Verify before claiming success/requesting-code-review - Get code reviewed/receiving-code-review - Handle review feedback/finishing-a-development-branch - Complete and integrate work/using-git-worktrees - Set up isolated workspaces/dispatching-parallel-agents - Parallel independent tasks/writing-skills - Create new skills/commandsUse the command that matches your current need.