Superpowers Dev Workflow

Spec-first, TDD, subagent-driven software development workflow. Use when: (1) building any new feature or app — triggers brainstorm → plan → subagent executi...

Security Scan

The skill's instructions match a developer workflow, but there are mismatches between what it says it needs (exec + sessions_spawn, git/gh actions) and what the registry declares — it can run destructive git commands and spawn subagents without declaring required tools or credential needs.

Purpose & Capability

The skill's stated purpose (spec-first TDD, subagent-driven development) matches the instructions and reference files. However, SKILL.md explicitly says it requires an 'exec tool' and 'sessions_spawn' while the registry metadata lists no required binaries/tools. The workflow also assumes the ability to run git, test commands, and `gh pr create` — capabilities not declared in the metadata. This mismatch is disproportionate to the declared requirements.

Instruction Scope

Instructions direct the agent to read project files, run tests, run git commands (merge, push, delete branches), and call `gh pr create`. They also instruct spawning many subagents via `sessions_spawn`. Reading repository files and running test/git is coherent with the stated purpose, but the instructions permit destructive operations (branch deletion, pushing) and network actions (creating PRs) without documenting required approvals/credentials. The 'HARD GATE' language enforces behavior but is not enforced by code — it's an instruction to the agent which may be applied autonomously.

Install Mechanism

This is an instruction-only skill with no install spec and no code files — low install risk. There is nothing downloaded or written by an installer.

Credentials

The skill will likely need access to repository files, git credentials (SSH keys or HTTPS creds), and potentially GitHub CLI authentication to execute `gh pr create` or push branches, but requires.env and primary credential are empty in the registry. That omission is disproportionate: the runtime actions described require credentials and network push rights that are not declared or gated.

Persistence & Privilege

always:false and default model invocation settings are appropriate. However, the skill's heavy reliance on `sessions_spawn` means it will autonomously create subagents if invoked — increasing the blast radius if the agent has permission to run shell commands or push changes. This is not an immediate policy violation, but combine it with undeclared credential needs and destructive git commands raises caution.

What to consider before installing

This skill implements a strict developer workflow that will read the repo, run tests, commit, push, create PRs, and can delete branches — but the registry metadata does not declare the tools or credentials required. Before installing or enabling it: 1) Confirm the agent platform provides and documents the 'exec' capability and 'sessions_spawn' behavior and that you understand when/why subagents will be spawned. 2) Only enable subagent-driven execution if you trust the agent and want it to perform git pushes/PRs; consider using the 'manual execution' mode instead. 3) Ensure backups exist (don't let an automated skill delete branches without extra confirmation) and verify which credentials (SSH keys, GitHub token, gh CLI auth) the skill will need — ask the publisher to update metadata to list required tools and env vars. 4) If you need higher assurance, request the publisher to (a) declare required binaries/env vars, (b) add explicit confirmation steps before any destructive git operation, and (c) explain how sessions_spawn is authorized and limited. If the publisher cannot explain these points, treat the skill cautiously or avoid enabling autonomous execution.

Superpowers — OpenClaw Edition

Adapted from obra/superpowers. Mandatory workflow — not suggestions.

The Pipeline

Idea → Brainstorm → Plan → Subagent-Driven Build (TDD) → Code Review → Finish Branch

Every coding task follows this pipeline. "Too simple to need a design" is always wrong.

---

Phase 1: Brainstorming

Trigger: User wants to build something. Activate before touching any code.

See: references/brainstorming.md

Summary:

1. Explore project context (files, docs, recent commits)
2. Ask clarifying questions — one at a time, prefer multiple choice
3. Propose 2–3 approaches with trade-offs + recommendation
4. Present design in sections, get approval after each
5. Write design doc → docs/plans/YYYY-MM-DD-<topic>-design.md → commit
6. Hand off to Phase 2: Writing Plans

HARD GATE: Do NOT write any code until user approves design.

---

Phase 2: Writing Plans

Trigger: Design approved. Activated by brainstorming phase.

See: references/writing-plans.md

Summary:

• Write a detailed task-by-task implementation plan
• Each task = 2–5 minutes: write test → watch fail → implement → watch pass → commit
• Save to docs/plans/YYYY-MM-DD-<feature>.md
• Announce: "I'm using the writing-plans skill to create the implementation plan."
• After saving, offer two execution modes:
  • Subagent-driven (current session): sessions_spawn per task + two-stage review
  • Manual execution: User runs tasks themselves

---

Phase 3: Subagent-Driven Development

Trigger: Plan exists, user chooses subagent-driven execution.

See: references/subagent-development.md

Per-task loop (OpenClaw):

1. sessions_spawn an implementer subagent with task + full plan context
2. Wait for completion announcement
3. sessions_spawn a spec-reviewer subagent → must confirm code matches spec
4. sessions_spawn a code-quality reviewer subagent → must approve quality
5. Fix any issues, re-review if needed
6. Mark task done, move to next
7. Final: dispatch overall code reviewer → hand off to Phase 5

TDD is mandatory in every task. See references/tdd.md.

---

Phase 4: Systematic Debugging

Trigger: Bug, test failure, unexpected behaviour — any technical issue.

See: references/systematic-debugging.md

HARD GATE: No fixes without root cause investigation first.

Four phases:

1. Root Cause Investigation (read errors, reproduce, check recent changes, trace data flow)
2. Pattern Analysis (find working examples, compare, identify differences)
3. Hypothesis + Testing (one hypothesis at a time, test to prove/disprove)
4. Fix + Verification (fix at root, not symptom; verify fix doesn't break anything)

---

Phase 5: Finishing a Branch

Trigger: All tasks complete, all tests pass.

See: references/finishing-branch.md

Summary:

1. Verify all tests pass
2. Determine base branch
3. Present 4 options: merge locally / push + PR / keep / discard
4. Execute choice
5. Clean up

---

OpenClaw Subagent Dispatch Pattern

When dispatching implementer or reviewer subagents, use sessions_spawn:

Goal: [one sentence]
Context: [why it matters, which plan file]
Files: [exact paths]
Constraints: [what NOT to do — no scope creep, TDD only]
Verify: [how to confirm success — tests pass, specific command]
Task text: [paste full task from plan]

Run sessions_spawn with the task as a detailed prompt. The sub-agent announces results automatically.

---

Key Principles

• One question at a time during brainstorm
• TDD always — write failing test first, delete code written before tests
• YAGNI — remove unnecessary features from all designs
• DRY — no duplication
• Systematic over ad-hoc — follow the process especially under time pressure
• Evidence over claims — verify before declaring success
• Frequent commits — after each green test