Supercharging AI: Getting Started with Superpowers Skill

If you've used AI to write code, you've probably encountered this situation:

You lay out a long list of requirements, the AI excitedly says, "Okay, I'm done," and then you run it—it doesn't work at all, or fixing one bug creates three new ones. AI looks smart, but always gives the feeling: Strong skills, sloppy attitude.

Superpowers is specifically designed to cure AI's "undisciplined genius" problem.

What is Superpowers? Not a code library, but an "AI Employee Handbook"

Many people initially think Superpowers is a framework or toolkit, but it's not.
It's more like an "employee handbook" written for an AI Agent, telling it: at different stages, you must follow a specific process.

• It's on GitHub, with a separate skills repository superpowers-skills, which contains individual Markdown documents.

• Each document is called a Skill, describing "what you (the AI) must do in a certain scenario."

• Paired with Claude Code's plugin, these rules are integrated into the AI's daily conversation and coding workflow.

In one sentence:

Superpowers uses a set of skills to train AI from a "code-writing intern" into a "professional engineer."

Core concept: Use 15 Skills to control the AI's development process

The author breaks down the entire software development process into a series of skills: from "clarifying requirements first" to "finally merging branches," each step has a corresponding skill to constrain the AI.

Imagine a typical process looks something like this:

1. brainstorming: First clarify requirements and design a solution.

2. writing-plans: Write an execution plan that even a fool can follow.

3. test-driven-development: Strict TDD—write tests first, then code.

4. systematic-debugging: When bugs appear, no guessing—only step-by-step root cause analysis.

5. subagent-driven-development: Hand off writing code to sub-agents plus double code review.

6. verification-before-completion: Before any "it's done" claim, verification must be run.

7. receiving-code-review, writing-skills: rules for handling reviews and writing new skills.

Below, I'll pick a few of the most interesting and non-engineer-friendly skills to explain.

Skill Example 1: brainstorming — AI first becomes a good questioner

Pain point:
AI loves to "start writing before finishing questions," resulting in wrong directions, endless revisions, and you might as well have written it yourself.

brainstorming skill forces AI to first use "Socratic questioning" to clarify requirements before taking action:

• Ask only one question at a time—no fire ten at once.

• Use multiple-choice questions instead of open-ended ones when possible.

• Write the design plan in sections, and after each section ask you "Is this right?" before continuing.

Imagine a conversation:

You: I want to build a small tool for "auto meeting minutes."

AI (using brainstorming skill):

1. What tool do you usually use for meeting recordings? (Zoom recording / audio file upload / text transcript)

2. Do you want output as "bullet points" or a "full summary"?

3. Will this tool be used by you alone or by the whole team?

4. …

After a round of questions, it writes a mini design document (200-300 words), and finally asks:

"Is the above understanding correct? If not, please point it out and I will revise the design."

This step seems slow, but it actually saves you a lot of rework from "doing it wrong from the start."

Skill Example 2: writing-plans — Assume the executor knows nothing

writing-plans is the skill many people see and exclaim "That's so verbose!"

It has a brutal assumption:

Assume the person executing this plan:

• knows nothing about the project

• has average taste

• doesn't like writing tests
  So the plan must be written such that even such a person won't mess up.

What does such a plan look like? Something like this:

• Each step does only one thing, takes 2-5 minutes to complete.

• No writing "add appropriate tests," instead write the full test code and file paths.

• No writing "run the tests," instead write the exact command (e.g., npm test) and what the expected output should look like.

A minimalist example (real skill is more detailed):

1. In src/meeting_summary.ts, add a summarizeTranscript function with the following content:…code…

2. In tests/meeting_summary.test.ts, add a test with the following content:…code…

3. Run npm test meeting_summary.test.ts in the terminal, confirm 1 new test passes, 0 failures.

Such a plan is somewhat like:

"Put all the tacit experience in a senior engineer's head into a document."

The benefit: you can confidently hand a task to "an unknown subagent" or "a new AI session next time," and it won't get lost following the plan.

Skill Example 3: test-driven-development — No failing test, no code allowed

The most "strict" rule in Superpowers is test-driven-development.
It's very blunt:

"No writing production code before writing a test."

And it pre-emptively blocks all common excuses, for example:

• "The feature is too simple, I don't want to write tests"? — Simple code can also have bugs; writing a test takes seconds.

• "I'll test it manually first"? — Manual testing has no record and can't be re-run.

• "I already wrote the code, I'll add tests later"? — Sorry, delete that code, pretend it didn't happen, and start over.

Behind this is the classic TDD cycle:

1. Write a test that fails (Red).

2. Run to confirm it really fails.

3. Write the minimal code to pass the test (Green).

4. Then refactor to clean up the code.

What can you learn from this?
Even if you're not an engineer, you can take away one idea:

Before "doing it," first clarify "how will I verify this is successful."

You can apply this method to: writing course outlines, designing workshops, or even launching a new product—first think clearly, what is the verification criteria for success.

Skill Example 4: systematic-debugging — No guessing, only systematic investigation

When a system has a bug, many AI enter "wild guess mode"—change one line and try, if it doesn't work change the next, wasting a lot of time.

systematic-debugging skill stipulates: debugging must follow four stages, no skipping:

1. Root cause investigation:

• Read the error message thoroughly, not just a glance.

• Find a way to reliably reproduce the problem; don't fix it if it can't be reproduced.

• Check recent code diffs for suspicious changes.

1. Pattern analysis:

• Find similar code that works correctly and compare it with the problematic area.

1. Hypothesis and test:

• Propose a specific hypothesis, change only one point at a time to verify.

1. Fix and defense:

• Write a test to reproduce the issue, then fix it. If you can't fix it after many attempts, suspect the architecture itself.

This process effectively converts an engineer's debugging experience into a "standard operating procedure" that AI can follow.

You don't have to use it all, but you can borrow Superpowers' approach to write your own "debugging checklist."

Skill Example 5: verification-before-completion — Show evidence before saying "done"

Many AI have a bad habit:

"Should be fine," "Looks OK," "I'm confident this time"... but actually no checks were run at all.

verification-before-completion skill says directly:

"Claiming completion without verification evidence is not efficient; it's dishonest."

It requires the AI:

• Before saying "all tests passed," actually run the tests and check the output, confirm 0 failures.

• Before saying "build succeeded," check that the exit code of the command is 0.

• Before saying "the bug is fixed," re-run the reproduction steps to confirm the problem is gone.

And it provides a "self-check list":

1. What command proves this claim?

2. Was it fully run just now?

3. Did you carefully check the output?

4. Does the result really support your conclusion?

This applies to us humans too:
After writing an article, finishing a video, or launching a new page, ask yourself: "Have I really verified it?"

Fun Skill: How to handle code review, and teaching AI to use a "secret code"

There's a widely discussed skill called receiving-code-review, which specifically teaches AI: how to respond professionally when receiving code review comments.

It explicitly bans common polite-but-shallow responses:

• "You're absolutely right!"

• "Great suggestion!"

• "I'll do it right away!" (but without verification)

In this rule:

Politeness is not the point; "does it make technical sense" is the point.

The correct approach:

• First, restate the reviewer's technical requirement in your own words to confirm understanding.

• Use code and tests to verify whether the suggestion fits the current project.

• If you believe the reviewer is wrong, push back with technical reasons, not because you feel awkward.

More interestingly:
To prevent AI from directly confronting humans in sensitive or politically delicate situations, the document even includes a secret code sentence:

"Strange things are afoot at the Circle K"

This sentence comes from an old movie and is unlikely to appear naturally in technical conversations, so when it appears, it should be understood as:

"I (the AI) sense something wrong here, but I can't say it directly right now. Please double-check carefully."

Few technical documents teach AI how to handle human relationships, which is what makes Superpowers so interesting to many people.

Skill Example 6: writing-skills — Even writing a Skill follows TDD

Superpowers doesn't just manage "writing code"; there's also a dedicated skill for "how to write new skills": writing-skills.

It proposes:

Writing a skill itself is a form of "doing TDD on the process."

The process roughly:

1. First, design a high-stress scenario where a subagent executes a task without this skill, and observe what mistakes it makes.

2. Based on the real problems that occurred, write the skill document.

3. Then test the same scenario again, this time loading the skill, and see if the AI follows it.

4. If the AI still circumvents the rule, continue patching holes and retest.

It even maps this process directly to traditional TDD:

TDD concept in SuperpowersTest casePressure scenario designed by subagentProduction codeSkill document (SKILL.md)Test fails (Red)Without skill, AI messes upTest passes (Green)With skill, AI follows the rulesRefactorPatch holes and rewrite skill without breaking the rules

This highlights a key point:
Superpowers is not a set of rules invented out of thin air; it is refined from real AI behavior, through repeated cycles of "see it fail → write rules → test again."

What makes it great? And what are its limitations?

Several interesting design decisions

• Use "must" instead of "should"
  Most guides write "You should..."; Superpowers writes "You must..." and even says "violating the literal meaning of the rule is violating the spirit of the rule," blocking AI from slacking off with "I understand the spirit."

• Extensive tables of "common excuses vs. reality"
  Each rule is followed by a list of possible AI excuses, each countered—effectively blocking AI's ways to find loopholes.

• Every step requires verification
  Not only must the final result be verified, but even the test itself must first be confirmed to "fail" and then to "pass after fix."

These practices make Superpowers more than a "set of best practices"; it's more like "behavioral training specifically for AI thinking gaps."

Real-world limitations

Of course, it's not a silver bullet:

• Entirely depends on AI's "self-discipline"
  These are just documents with no hard technical constraints; the AI can choose to ignore them.

• High cost
  For example, subagent-driven-development may launch 3 subagents for a single task, burning tokens and time quickly.

• Overkill for small tasks
  Fixing a typo or changing one line of configuration—going through the full brainstorming, plan, TDD, review cycle—would be very heavy.

The author also admits:
This system is better suited for projects that need high quality and long-term maintenance, not for quick experimental scripts.

How you can use this approach

Even if you don't directly install Superpowers, it's worth doing three things:

1. Treat it as a "how to command AI to write code" textbook—read it once, and you'll better understand how to write instructions and require verification.

2. Pick a few processes that best fit your workflow, simplify them into your own team's standards, for example:

• Always require "first write the test, then let AI implement."

• Require AI to paste the full command and output before saying "done."

1. If you're onboarding new people, consider adapting the "excuses vs. reality" tables from the docs for both newcomers and AI to read together.

Final thoughts

The real value of Superpowers is not "copy all its rules," but the systematic framework for thinking about AI workflows it provides:

Write experience into text, turn text into habits, and let AI and humans follow them together.