4.1 KiB
name, description
| name | description |
|---|---|
| using-superpowers | Manual-only skill. Activate only after an explicit user request for Superpowers Lite or superpowers-lite:using-superpowers. |
Superpowers Lite
Superpowers Lite is a manual-only workflow pack. Use it only when the user explicitly asks for Superpowers Lite or names a superpowers-lite:* skill.
Do not auto-trigger Superpowers Lite because a task looks creative, complex, buggy, or plan-worthy. If the user asks for ordinary coding help without naming this workflow, proceed normally under the host agent's default instructions.
Instruction Priority
Superpowers Lite skills override default system prompt behavior after explicit activation, but user instructions always take precedence:
- User's explicit instructions (CLAUDE.md, GEMINI.md, AGENTS.md, direct requests) — highest priority
- Superpowers Lite skills — apply only after explicit user activation
- Default system prompt — lowest priority
If CLAUDE.md, GEMINI.md, or AGENTS.md says "don't use TDD" and a skill says "always use TDD," follow the user's instructions. The user is in control.
How to Access Skills
In Claude Code: Use the Skill tool. When you invoke a skill, its content is loaded and presented to you—follow it directly. Never use the Read tool on skill files.
In Copilot CLI: Use the skill tool. Skills are auto-discovered from installed plugins. The skill tool works the same as Claude Code's Skill tool.
In Gemini CLI: Skills activate via the activate_skill tool. Gemini loads skill metadata at session start and activates the full content on demand.
In other environments: Check your platform's documentation for how skills are loaded.
Platform Adaptation
Skills use Claude Code tool names. Non-CC platforms: see references/copilot-tools.md (Copilot CLI), references/codex-tools.md (Codex) for tool equivalents. Gemini CLI users get the tool mapping loaded automatically via GEMINI.md.
Using Skills
Manual Activation Rule
Use a Superpowers Lite skill only when the user explicitly requests one of these:
- "Use Superpowers Lite"
- "Use superpowers-lite:brainstorming"
- "Use superpowers-lite:writing-plans"
- "Use superpowers-lite:executing-plans"
- Another explicit
superpowers-lite:*skill name
If the user asks for "a plan", "debug this", "review this", or "implement this" without naming Superpowers Lite, do not treat that as activation. The fork exists to stay out of the way until called.
Skill Priority
After explicit activation, when multiple skills could apply, use this order:
- Process skills first (brainstorming, debugging) - these determine HOW to approach the task
- Implementation skills second (frontend-design, mcp-builder) - these guide execution
After the user opts in: "Let's build X" → brainstorming first, then implementation skills. After the user opts in: "Fix this bug" → debugging first, then domain-specific skills.
Skill Types
Rigid (TDD, debugging): Follow exactly. Don't adapt away discipline.
Flexible (patterns): Adapt principles to context.
The skill itself tells you which.
Project Plan Storage
Generated design specs and implementation plans live under .superpowers-lite/.
On first use in a project, if .superpowers-lite/ does not exist, ask the user whether Superpowers Lite plans/specs should be tracked by git for this project. If .superpowers-lite/ exists but .superpowers-lite/config.json is missing, ask the same question once and create the config. Save the answer in .superpowers-lite/config.json:
{
"planGitTracking": "local"
}
Use "tracked" when the user wants plans/specs in git. Use "local" when they should stay local. For later sessions, do not ask again; follow the local config. If the config says "local", ensure .superpowers-lite/ is listed in .git/info/exclude before writing plan/spec files. If it says "tracked", do not add .superpowers-lite/ to .git/info/exclude.
User Instructions
Instructions say WHAT, not HOW, but in this fork ordinary "Add X" or "Fix Y" requests do not activate Superpowers Lite. The user must opt in.