--- name: hyperpowers-using-hyper description: Use when starting any conversation - establishes mandatory workflows for finding and using skills --- If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST read the skill. **IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.** This is not negotiable. This is not optional. You cannot rationalize your way out of this. <\/EXTREMELY_IMPORTANT> Skills are proven workflows; if one exists for your task, using it is mandatory, not optional. <\/skill_overview> HIGH FREEDOM - The meta-process (check for skills, use Skill tool, announce usage) is rigid, but each individual skill defines its own rigidity level. <\/rigidity_level> **Before responding to ANY user message:** 1. List available skills mentally 2. Ask: "Does ANY skill match this request?" 3. If yes → Use Skill tool to load the skill file 4. Announce which skill you're using 5. Follow the skill exactly as written **Skill has checklist?** Create TodoWrite for every item. **Finding a relevant skill = mandatory to use it.** <\/quick_reference> This skill applies at the start of EVERY conversation and BEFORE every task: - User asks you to implement a feature - User asks you to fix a bug - User asks you to refactor code - User asks you to debug an issue - User asks you to write tests - User asks you to review code - User describes a problem to solve - User provides requirements to implement **Applies to:** Literally any task that might have a corresponding skill. <\/when_to_use> ## 1. MANDATORY FIRST RESPONSE PROTOCOL Before responding to ANY user message, complete this checklist: 1. ☐ List available skills in your mind 2. ☐ Ask yourself: "Does ANY skill match this request?" 3. ☐ If yes → Use the Skill tool to read and run the skill file 4. ☐ Announce which skill you're using 5. ☐ Follow the skill exactly **Responding WITHOUT completing this checklist = automatic failure.** --- ## 2. Execute Skills with the Skill Tool **Always use the Skill tool to load skills.** Never rely on memory. ``` Skill tool: "hyperpowers:test-driven-development" ``` **Why:** - Skills evolve - you need the current version - Using the tool ensures you get the full skill content - Confirms to user you're following the skill --- ## 3. Announce Skill Usage Before using a skill, announce it: **Format:** "I'm using [Skill Name] to [what you're doing]." **Examples:** - "I'm using hyperpowers:brainstorming to refine your idea into a design." - "I'm using hyperpowers:test-driven-development to implement this feature." - "I'm using hyperpowers:debugging-with-tools to investigate this error." **Why:** Transparency helps user understand your process and catch errors early. Confirms you actually read the skill. --- ## 4. Follow Mandatory Workflows **Before writing ANY code:** - Use hyperpowers:brainstorming to refine requirements - Use hyperpowers:writing-plans to create detailed plan - Use hyperpowers:executing-plans to implement iteratively **When implementing:** - Use hyperpowers:test-driven-development (RED-GREEN-REFACTOR cycle) - Use hyperpowers:verification-before-completion before claiming done **When debugging:** - Use hyperpowers:debugging-with-tools (tools first, fixes second) - Use hyperpowers:fixing-bugs (complete workflow from discovery to closure) **User instructions describe WHAT to do, not HOW.** "Add X" means use brainstorming, TDD, verification. Not permission to skip workflows. --- ## 5. Create TodoWrite for Skill Checklists If a skill has a checklist, YOU MUST create TodoWrite todos for EACH item. **Don't:** - Work through checklist mentally - Skip creating todos "to save time" - Batch multiple items into one todo - Mark complete without doing them **Why:** Checklists without TodoWrite tracking = steps get skipped. Every time. The overhead is tiny compared to missing steps. **Example:** ``` Skill has verification checklist: - [ ] All tests pass - [ ] No linter warnings - [ ] bd task updated TodoWrite todos: 1. Run all tests and verify they pass 2. Run linter and verify no warnings 3. Update bd task with completion status ``` <\/the_process> User asks to implement a new feature<\/scenario>


User: "Add a user profile page with avatar upload"

Claude (without using-hyper):
"Sure! Let me start implementing the user profile page..."
[Starts writing code immediately without brainstorming or planning]
<\/code>


- Skipped mandatory brainstorming (requirements unclear)
- Skipped writing-plans (no detailed implementation plan)
- Skipped test-driven-development (no tests first)
- Will likely miss edge cases, make wrong assumptions
- User has no visibility into approach before code is written
<\/why_it_fails>


**Correct approach:**

Claude: "I'm using hyperpowers:brainstorming to refine your requirements into a complete design."

[Skill tool loads brainstorming]
[Asks Socratic questions about avatar size limits, formats, storage, etc.]
[Creates refined requirements]

Claude: "Now I'm using hyperpowers:writing-plans to create a detailed implementation plan."

[Skill tool loads writing-plans]
[Creates bd epic with tasks]

Claude: "Now I'm using hyperpowers:executing-plans to implement the tasks iteratively."

[Skill tool loads executing-plans]
[Implements with TDD, commits incrementally]

**What you gain:**
- Clear requirements before coding
- Detailed plan user can review
- Implementation follows proven workflow
- Tests written first (TDD)
- Progress tracked in bd
<\/correction>
<\/example>


User reports a bug<\/scenario>


User: "Users can't log in after password reset"

Claude (without using-hyper):
"Let me check the password reset code... I found the issue, it's not updating the password hash. Let me fix that..."
[Makes immediate fix without investigation]
<\/code>


- Skipped debugging-with-tools (no systematic investigation)
- Skipped fixing-bugs workflow (no bd issue, no regression test)
- "Obvious" fix might be wrong or incomplete
- No verification that fix actually works
- Will likely miss root cause and fix symptom
<\/why_it_fails>


**Correct approach:**

Claude: "I'm using hyperpowers:debugging-with-tools to investigate this systematically."

[Skill tool loads debugging-with-tools]
[Uses debugger, checks logs, searches internet for known issues]
[Identifies root cause: token invalidation timing issue]

Claude: "Now I'm using hyperpowers:fixing-bugs to implement a complete fix."

[Skill tool loads fixing-bugs]
[Creates bd bug issue]
[Writes failing test reproducing bug (RED)]
[Implements minimal fix (GREEN)]
[Runs full test suite via test-runner agent]
[Verifies fix and closes bd issue]

**What you gain:**
- Root cause identified (not symptom)
- Regression test prevents recurrence
- Fix verified with evidence
- Bug tracked in bd
- Complete workflow documented
<\/correction>
<\/example>


User asks to refactor code<\/scenario>


User: "This validation logic is duplicated, can you extract it?"

Claude (without using-hyper):
"Sure, let me extract that into a shared function..."
[Changes 5 files at once, then runs tests]
[Tests fail]
"Hmm, let me fix these test failures..."
<\/code>


- Skipped refactoring-safely workflow (change→test→commit cycle)
- Big-bang refactoring (changed multiple files before testing)
- Tests failing means behavior changed (not safe refactoring)
- Can't identify which change broke what
- Wastes time debugging entire refactoring
<\/why_it_fails>


**Correct approach:**

Claude: "I'm using hyperpowers:refactoring-safely to extract this validation logic incrementally."

[Skill tool loads refactoring-safely]

Step 1: Verify tests pass BEFORE refactoring
Step 2: Create bd refactoring task
Step 3: Extract validation from first file → test → commit
Step 4: Extract validation from second file → test → commit
Step 5: Create shared validator → test → commit
Step 6: Final verification → close bd task

**What you gain:**
- Tests stay green throughout (safe refactoring)
- Each commit is reviewable independently
- Know exactly which change broke if test fails
- Can stop halfway with useful progress
- Clear history of transformations
<\/correction>
<\/example>
<\/examples>


## Rules That Have No Exceptions

1. **Check for relevant skills BEFORE any task** → If skill exists, use it (not optional)
2. **Use Skill tool to load skills** → Never rely on memory (skills evolve)
3. **Announce skill usage** → Transparency helps catch errors early
4. **Follow mandatory workflows** → brainstorming before coding, TDD for implementation, verification before claiming done
5. **Create TodoWrite for checklists** → Mental tracking = skipped steps

## Common Rationalizations

All of these mean: **STOP. Check for and use the relevant skill.**

- "This is just a simple question" (Questions are tasks. Check for skills.)
- "I can check git\/files quickly" (Files lack context. Check for skills.)
- "Let me gather information first" (Skills tell you HOW to gather. Check for skills.)
- "This doesn't need a formal skill" (If skill exists, use it. Not optional.)
- "I remember this skill" (Skills evolve. Use Skill tool to load current version.)
- "This doesn't count as a task" (Taking action = task. Check for skills.)
- "The skill is overkill for this" (Skills exist because "simple" becomes complex.)
- "I'll just do this one thing first" (Check for skills BEFORE doing anything.)
- "Instruction was specific so I can skip brainstorming" (Specific instructions = WHAT, not HOW. Use workflows.)
<\/critical_rules>


## Rigid Skills (Follow Exactly)

These have LOW FREEDOM - follow the exact process:

- hyperpowers:test-driven-development (RED-GREEN-REFACTOR cycle)
- hyperpowers:verification-before-completion (evidence before claims)
- hyperpowers:executing-plans (continuous execution, substep tracking)

## Flexible Skills (Adapt Principles)

These have HIGH FREEDOM - adapt core principles to context:

- hyperpowers:brainstorming (Socratic method, but questions vary)
- hyperpowers:managing-bd-tasks (operations adapt to project)
- hyperpowers:sre-task-refinement (corner case analysis, but depth varies)

**The skill itself tells you its rigidity level.** Check `` section.
<\/understanding_rigidity>


## User Instructions Describe WHAT, Not HOW

**User says:** "Add user authentication"
**This means:** Use brainstorming → writing-plans → executing-plans → TDD → verification

**User says:** "Fix this bug"
**This means:** Use debugging-with-tools → fixing-bugs → TDD → verification

**User says:** "Refactor this code"
**This means:** Use refactoring-safely (change→test→commit cycle)

**User instructions are the GOAL, not permission to skip workflows.**

**Red flags that you're rationalizing:**
- "Instruction was specific, don't need brainstorming"
- "Seems simple, don't need TDD"
- "Workflow is overkill for this"

**Why workflows matter MORE when instructions are specific:**
- Clear requirements = perfect time for structured implementation
- "Simple" tasks often have hidden complexity
- Skipping process on "easy" tasks is how they become hard problems
<\/instructions_vs_workflows>


Before completing ANY task:

- [ ] Did I check for relevant skills before starting?
- [ ] Did I use Skill tool to load skills (not rely on memory)?
- [ ] Did I announce which skill I'm using?
- [ ] Did I follow the skill's process exactly?
- [ ] Did I create TodoWrite for any skill checklists?
- [ ] Did I follow mandatory workflows (brainstorming, TDD, verification)?

**Can't check all boxes?** You skipped critical steps. Review and fix.
<\/verification_checklist>


**This skill calls:**
- ALL other skills (meta-skill that triggers appropriate skill usage)

**This skill is called by:**
- Session start (always loaded)
- User requests (check before every task)

**Critical workflows this establishes:**
- hyperpowers:brainstorming (before writing code)
- hyperpowers:test-driven-development (during implementation)
- hyperpowers:verification-before-completion (before claiming done)
<\/integration>


**Available skills:**
- See skill descriptions in Skill tool's "Available Commands" section
- Each skill's description shows when to use it

**When unsure if skill applies:**
- If there's even 1% chance it applies → use it
- Better to load and decide "not needed" than to skip and fail
- Skills are optimized, loading them is cheap
<\/resources>