Read Superpowers as a process design

The name SuperPower refers here to obra/superpowers.

Suggested learning time: 45 minutes.

1. 1Observed failure
2. 2Debugging hypothesis
3. 3One check
4. 4Reproduction or revised hypothesis

Original learning map: arrows show the reading or decision sequence, not a measured execution trace.

Prerequisites

• Read catalogs by purpose rather than popularity

Evidence and exercise status

This chapter is an editorial learning guide. Reading sources is distinct from executing a Skill and measuring its effect. Exercise status: not-run. No experiment logs or model outputs exist.

Learning goals

• Distinguish a single Skill from a framework.
• Measure methodological adherence separately from outcome improvements.

Roles in the work

• Learner: define hypotheses and grading criteria.
• AI: assist with reading and deliverable creation within the authorized scope.
• Reviewer: inspect outcomes and logs separately.

Inputs

• The input examples specified in this chapter.
• The official material and versions to verify.

More than one powerful prompt

obra/superpowers is a software-development methodology combining multiple Skills and installation instructions. Its README describes a sequence of clarifying requirements, designing, creating an implementation plan, and proceeding through implementation and review. Enabling Superpowers in a comparison may therefore change task decomposition and hooks as well as add text. Design that comparison as the effect of an entire workflow, rather than the effect of one Skill.

obra/superpowers

What to look for in systematic-debugging

This Skill strongly calls for investigating causes before rushing to a fix, checking reproduction conditions and differences, and testing small hypotheses. Focus on the behavior it aims to change rather than the force of its wording. Evaluation examples in this course observe the number of unsupported changes, clarity of reproduction steps, and presence of regression tests. Do not award points merely for a long explanation of the procedure; use actual logs and deliverables as evidence.

Superpowers systematic-debugging: 固定版

What to look for in test-driven-development

This Skill emphasizes writing a test first, observing it fail for the intended reason, passing it with a minimal implementation, and then cleaning up. Evaluation checks logs for an observed failure before implementation, rather than just the existence of a test file. The independent outcome criteria proposed by this course are correct behavior for unseen inputs, preservation of existing features, and understandable changes. Keep process adherence and defect rates in separate columns.

Superpowers test-driven-development: 固定版

Methodologies have costs and boundaries

Design checks may help medium-size development with ambiguous requirements, while confirmation and decomposition may impose substantial fixed overhead on small learning changes. These are hypotheses in this course, not measured results. Strong instructions to delete files or make large changes do not authorize exceeding the user's scope or safety checks. Record automatic hooks, nested Skills, and subagent counts in comparisons, and do not confuse evaluations of an individual Skill with those of the whole workflow.

Workflow

1. Prepare practice code with a known small bug and a request that does not reveal the answer.
2. Define only the difference between systematic-debugging alone and the disabled condition.
3. Score evidence of the cause, the fix, and regression tests independently.

Outputs

• A comparison plan that has not been executed.

Quality checklist

• You identify the target as obra/superpowers.
• You do not cite promotional claims for the methodology as results.
• You distinguish pinned versions from rolling references.

Failure diagnosis

• Symptom: Recording success without observing the effect.
• Cause: Confusing expected judgments with actual outputs.
• Fix: Keep unexecuted work as not-run, clear measurement fields, and obtain raw outputs and logs before scoring.

Exercise: Design a debugging comparison

Follow the workflow above in order and create the stated deliverable.

Completion criteria: Distinguish enabling the complete framework from loading an individual Skill.

Status: not-run.

Source scope

Sources support feature descriptions and distributor statements in the text and catalog. They are not evidence of measured effects or popularity ranks. Verification dates record reading public sources, rather than publication or update dates. Rolling references such as main are not pinned experimental versions.

Offline experiment worksheet