274cf1617b
Condense the injected bootstrap without dropping behavior-shaping content: replace the graphviz flowchart with prose (1% rule, plan-mode->brainstorm gate, announce + checklist->todos), fold Instruction-Priority into User Instructions, and drop the per-platform skill-loading section. Keep the full Red Flags rationalization table (all 12), the platform tool-mapping pointer (now a skill-relative path list), skill priority framed as a category (process before implementation, not just the two named skills), and user-instruction precedence plus the WHAT/HOW guard. Snapshot on a local branch for review — NOT final, NOT for dev. Open items: the dropped "Skill Types" (rigid/flexible) section, and evals for user preferences overriding skills. Clean Docker evals show the more-aggressive g-minimal preserves load-bearing triggering across opus/sonnet/haiku/codex/ gemini/kimi; this variant keeps more content. Claude-Session: https://claude.ai/code/session_01Hz32pBE7kiqr78DY6PWmZN
3.3 KiB
name, description
| name | description |
|---|---|
| using-superpowers | Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions |
IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
This is not negotiable. You cannot rationalize your way out of this.
The Rule
Invoke relevant or requested skills BEFORE any response or action — including clarifying questions, exploring the codebase, or checking files. Even a 1% chance a skill applies means you invoke it to check. If it turns out wrong for the situation, you don't have to use it.
Before entering plan mode: if you haven't already brainstormed, invoke the brainstorming skill first.
Then announce "Using [skill] to [purpose]" and follow the skill exactly. If it has a checklist, create a todo per item.
Skill Priority
When multiple skills apply, process skills come first — they set the approach, then implementation skills (frontend-design, etc.) carry it out. Brainstorming and systematic-debugging are the most common process skills, but the rule holds for any of them.
- "Let's build X" → brainstorming first, then implementation skills.
- "Fix this bug" → systematic-debugging first, then domain skills.
Red Flags
These thoughts mean STOP—you're rationalizing:
| Thought | Reality |
|---|---|
| "This is just a simple question" | Questions are tasks. Check for skills. |
| "I need more context first" | Skill check comes BEFORE clarifying questions. |
| "Let me explore the codebase first" | Skills tell you HOW to explore. Check first. |
| "I can check git/files quickly" | Files lack conversation context. Check for skills. |
| "Let me gather information first" | Skills tell you HOW to gather information. |
| "This doesn't need a formal skill" | If a skill exists, use it. |
| "I remember this skill" | Skills evolve. Read current version. |
| "This doesn't count as a task" | Action = task. Check for skills. |
| "The skill 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. Skills prevent this. |
| "I know what that means" | Knowing the concept ≠ using the skill. Invoke it. |
Platform Adaptation
Skills name actions ("dispatch a subagent", "create a todo", "read a file"), not any one runtime's tools. For your harness's tool equivalents and instructions-file conventions, read the matching file:
- Claude Code:
references/claude-code-tools.md - Codex:
references/codex-tools.md - Copilot CLI:
references/copilot-tools.md - Gemini CLI:
references/gemini-tools.md(also auto-loaded via GEMINI.md) - Pi:
references/pi-tools.md - Antigravity:
references/antigravity-tools.md
User Instructions
User instructions (CLAUDE.md, GEMINI.md, AGENTS.md, direct requests) take precedence over skills, which in turn override default system behavior. But they set WHAT to do, not HOW — "Add X" or "Fix Y" is not permission to skip the workflow a skill prescribes.