Using Hyper

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.

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.

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

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

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

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

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]

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

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..."

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

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.)

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.

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

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

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)

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