CODEZ ORIGINAL SELECTION ANALYSIS / 02
Choosing Superpowers workflow skills: intent, verification and skill authoring
Skills in the same Agent workflows category can serve different stages. Start by identifying whether your task needs clearer intent, verifiable results or reusable process instructions. Three real sources illustrate how to choose by task.
Sources checked:
Project facts come from original SKILL.md files at a fixed commit. Selection advice, cost judgments and scenarios are CODEZ editorial analysis. These third-party skills were not executed for this article. Scenarios and the trial template are illustrative; no measured success rates or performance rankings are claimed.
Choose by the output you need now
All three entries belong to obra/superpowers and display the same repository Star count. Stars cannot choose between them; triggers and deliverables are more useful distinctions.
Our selection method starts with the task gap: unresolved intent needs alignment, delivery needs evidence, and a reusable agent capability needs instructions whose effect can be examined.
| Current need | Candidate skill | Expected output | Process cost to consider |
|---|---|---|---|
| Clarify goals, scope and design | brainstorming | An understanding and design basis the user can confirm | Discussion and approval, proportional to task complexity |
| Establish that work is complete or fixed | verification-before-completion | Verification commands, results and limits for the current change | Run checks and read complete output |
| Create or improve a reusable skill | writing-skills | Maintainable instructions and scenario records | Design scenarios, observe a baseline, revise and recheck |
Unclear requirements: inspect brainstorming
The source organizes collaboration around intent, context, requirements and design approval, with paths for different task complexity. We categorize it as an Agent workflow because these steps govern how work progresses and is confirmed; consult the original for its scope.
A useful selection signal is being able to name the product you want without yet defining its audience, success criteria or operation scope. Expect a short understanding record and check which parts reflect your request and which are assumptions.
When inputs, outputs and acceptance criteria are already clear, observe whether the process uses that information and whether additional discussion resolves a real ambiguity. More questions are not a quality metric.
Before delivery: inspect verification-before-completion
The source requires identifying a verification method, running checks and reading complete output before claiming completion. It governs delivery judgments rather than supplying project-specific test tools.
List the conclusion you want to establish and the corresponding check. For example, checking four required CSV column names can support that specific output requirement. One local check rarely establishes that an entire system is correct.
A passed code check does not automatically establish correct functionality, deployment and user flows. Look for a clear correspondence between claims and evidence, with uncovered areas retained explicitly.
verification-before-completion: original file at a fixed commit ↗
Maintain a reusable capability: inspect writing-skills
The source covers creating and editing skills and relates process-documentation validation to scenario testing, including observing behavior without instructions and after revision. Its focus is a reusable agent capability.
This investment is useful to consider when a task recurs and existing instructions still produce a describable failure. Write the failure and acceptance criteria first; they are easier to examine than a large expansion of rules.
Scenario validation adds time and execution cost, and clients may support different execution methods. For a one-off task, decide whether a new maintained skill is necessary. Check valid format and effective behavior separately.
Illustrative scenario: fixing input validation
This is an editorial selection scenario, not a report of using the three skills. Suppose the reproducing input, expected error message and regression-check command are already defined for a bounded repair.
Delivery evidence is a direct need here. Add requirements clarification if reproducing conditions or expected behavior remain ambiguous. Consider skill authoring when the team repeatedly misses the same check and plans to maintain it as a reusable capability.
The criterion is stage and output, rather than using every workflow in a repository on every task. When combining candidates, check whether their triggers, approval steps and operation scope conflict.
Record a trial in your own environment
Compare candidates using the same input and acceptance criteria, recording the client, repository commit and file path. Until an actual trial is completed, use public-source conclusions only for candidate selection.
| Record | What to enter |
|---|---|
| Task and input | What needs clarification, verification or authoring; retain identical input |
| Client and version | Agent client, required tools and execution environment |
| Candidate source | Repository, fixed commit and SKILL.md path |
| Expected output | Understanding, evidence record or instructions and scenarios |
| Actual result | Real artifacts, commands and errors after completion |
| Cost and limits | Additional discussion, execution steps and uncovered areas |