using-hyper

<EXTREMELY_IMPORTANT> 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>

<skill_overview> Skills are proven workflows; if one exists for your task, using it is mandatory, not optional. </skill_overview>

<rigidity_level> 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>

<quick_reference> 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>

<when_to_use> 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>

<the_process>

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>

<examples> <example> <scenario>User asks to implement a new feature</scenario> <code> 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>

<why_it_fails>

• 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>

<correction> **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> <example> <scenario>User reports a bug</scenario> <code> 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>

<why_it_fails>

• 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>

<correction> **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> <example> <scenario>User asks to refactor code</scenario> <code> 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>

<why_it_fails>

• 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>

<correction> **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>

<critical_rules>

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>

<understanding_rigidity>

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 <rigidity_level> section. </understanding_rigidity>

<instructions_vs_workflows>

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>

<verification_checklist> 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>

<integration> **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>

<resources> **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>