dmi-superpowers

Plugin dmi-superpowers from marketplace dmi-marketplace in HundredBillion/dmi_superpowers. Commands read from the repo's manifest — 18 days ago.

Skills (30)

• brainstorming

  You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

• codebase-design

  Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

• creating-a-pull-request

  Use when opening, creating, or writing a pull request, pushing a branch for review, or running gh pr create - covers the PR title, body, and evidence so the description reads for both a non-developer and a developer.

• dispatching-parallel-agents

  Use when facing 2+ independent tasks with no shared state or ordering between them and no written plan to work from — ad-hoc fan-out. When the tasks come from a TSP, use subagent-driven-development instead.

• domain-modeling

  Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.

• executing-plans

  Use when executing an approved written TSP inline, when your human partner chose this session as the implementer, or when subagents are unavailable

• finishing-a-development-branch

  Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

• grill-with-docs

  Use when stress-testing a PRD or TSP that should leave documentation behind — the interview also records decisions as ADRs and keeps the CONTEXT.md glossary current. For an interview with no doc side effects, use grilling instead.

• grilling

  Use when the user wants to stress-test a plan or design before building, or says grill. For a grilling session that should also write ADRs and update the glossary, use grill-with-docs instead.

• improve-codebase-architecture

  Use when a debugging post-mortem concludes the root cause was architectural (no test seam, tangled callers, hidden coupling), or when the user asks for an architecture review, a deepening pass, or wants to find over-engineering to cut. Writes an HTML report to a temp directory and opens it.

• migrating-safely

  Use when replacing or removing a database shape, public API, event contract, dependency, service, or feature that active consumers must leave without downtime or data loss

• ponytail

  Forces the laziest solution that actually works, simplest, shortest, most minimal. Channels a senior dev who has seen everything: question whether the task needs to exist at all (YAGNI), reach for the standard library before custom code, native platform features before dependencies, one line before

• property-based-testing

  Use when a parser, serializer, normalizer, comparator, reversible transformation, numeric operation, or state transition should be tested over an input domain rather than only hand-picked examples

• prototype

  Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

• receiving-code-review

  Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

• requesting-code-review

  Use when completing tasks, implementing major features, or before merging to verify work meets requirements

• resolving-merge-conflicts

  Use when you need to resolve an in-progress git merge/rebase conflict.

• say

  Use when reporting a finding about code to the user during grilling, grill-with-docs, or systematic-debugging, and when drafting or rewriting prose for a human reader (Slack, Jira, PR, email). Pairs plain-language meaning with exact technical anchors so a non-developer can follow and the developer c

• source-grounded-development

  Use when implementation correctness depends on a framework, library, platform, protocol, or tool whose APIs and recommended patterns vary by version

• subagent-driven-development

  Use when executing a written implementation plan (TSP) whose tasks are independent, in the current session. For ad-hoc fan-out with no plan behind it, use dispatching-parallel-agents instead.

• systematic-debugging

  Use when encountering any bug, test failure, unexpected behavior, or performance regression, before proposing fixes — a disciplined diagnosis loop (orient → build a feedback loop → reproduce + minimise → hypothesise → instrument → fix + regression-test → cleanup). Triggers when the user says "diagno

• test-driven-development

  Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

• to-prd

  Turn the current conversation into a PRD and write it to docs/PRDs/ — no interview, just synthesis of what you've already discussed.

• using-git-worktrees

  Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback

• using-superpowers

  Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions

• variant-analysis

  Use when a confirmed bug, vulnerability, or unsafe pattern may have sibling instances elsewhere in a codebase, especially when asked whether the same defect occurs in other paths

• verification-before-completion

  Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

• writing-code-comments

  Use when writing or editing code and adding a comment, note, TODO, or docstring — including when the change comes from a ticket, PR, or review thread whose ID could leak into the note.

• writing-plans

  Use when you have a PRD or requirements for a multi-step task, before touching code

• writing-skills

  Use when creating new skills, editing existing skills, or verifying skills work before deployment

Hooks (3)

• SessionStart

  "${CLAUDE_PLUGIN_ROOT}/hooks/run-hook.cmd" session-start

• UserPromptSubmit

  command -v node >/dev/null 2>&1 && node "${CLAUDE_PLUGIN_ROOT}/hooks/ponytail-mode-tracker.js" || exit 0

• PreToolUse

  "${CLAUDE_PLUGIN_ROOT}/hooks/run-hook.cmd" pretooluse-pr-reminder

Similar plugins