Dude Superpowers has to be on here and not for just the build portion. But its systematic debugging skill is impressive
Open the batch installer for this collection and generate commands only when you need them.
por obra
requesting-code-review é um fluxo leve para acionar o subagente `superpowers:code-reviewer` com um git diff limpo, requisitos e um resumo das mudanças, ajudando a fazer o code review no momento certo e a gerar feedback acionável, classificado por severidade, antes do merge.
por obra
subagent-driven-development é uma skill para executar planos de implementação com um subagente novo por tarefa e depois revisar cada resultado em duas etapas: primeiro a aderência à especificação, depois a qualidade do código. Ela inclui templates de prompt para o implementador, o revisor de especificação e o revisor de qualidade de código.
por obra
systematic-debugging é uma skill de debugging orientada primeiro à causa raiz, indicada para bugs, testes instáveis, falhas de build e comportamentos inesperados. Entenda o fluxo de trabalho em quatro fases, os arquivos complementares e quando usá-la antes de propor correções.
por obra
Instale e use a skill test-driven-development para aplicar TDD rigoroso: escreva primeiro um teste que falha, confirme a falha, implemente o código mínimo e depois refatore com segurança.
por obra
using-git-worktrees ajuda a criar Git worktrees isolados para trabalhar em novas branches, com escolha de diretório, verificação de ignore e fluxos paralelos mais seguros sem mexer no checkout atual.
por obra
using-superpowers é uma skill de início de sessão do obra/superpowers que exige a consulta de skills antes de qualquer resposta, ajudando agentes a encontrar e ativar primeiro o fluxo de trabalho certo.
por obra
verification-before-completion é uma skill de checagem final que impede afirmações de conclusão sem respaldo. Veja quando usar, como instalar a partir de obra/superpowers e como vincular cada status informado a evidências recentes de verificação.
por obra
O writing-plans ajuda a transformar uma especificação ou documento de requisitos num plano de implementação detalhado, com orientação ao nível de ficheiros, sequência de tarefas, passos de teste e um prompt de revisão antes de começar a programar.
por obra
writing-skills é um guia de Skill Authoring para criar, editar e validar skills de agentes com um fluxo orientado por testes. Entenda os arquivos principais, os pré-requisitos e as etapas práticas para cenários de pressão, testes de linha de base e iteração concisa de `SKILL.md`.
por obra
brainstorming é uma skill de pré-implementação que explora o contexto, faz perguntas de esclarecimento uma por vez e exige aprovação do design antes de qualquer código. Inclui um companion visual opcional e forte suporte a planejamento de requisitos.
por obra
dispatching-parallel-agents é uma skill de orquestração de agentes para dividir tarefas realmente independentes entre agentes separados, com contexto isolado e resultados coordenados.
por obra
executing-plans ajuda agentes a seguir um plano de implementação por escrito: primeiro revisar, depois executar as tarefas em ordem, rodar as checagens indicadas, parar diante de bloqueios e fazer o handoff para um fluxo de finalização. É mais indicada para Project Management e outros contextos de entrega guiada por plano.
por obra
A skill finishing-a-development-branch ajuda a encerrar uma branch Git com segurança quando a implementação já foi concluída. Ela valida os testes, confere a branch base e depois apresenta quatro opções objetivas: fazer merge local, enviar para Pull Request, manter a branch ou descartar o trabalho.
por obra
receiving-code-review ajuda a validar feedback de PR antes de editar o código. Use para reformular comentários de review, conferir se eles fazem sentido no codebase, pedir esclarecimentos sobre pontos ambíguos e contestar sugestões que não se encaixam.
# How to Use Superpowers Skills Effectively Do not treat a task as “read the request and start coding.” Superpowers changes the default workflow: **check for relevant skills first, then let the skills determine how to work**. ## Core Rule Before responding, exploring files, asking clarifying questions, or implementing anything, first check whether a Superpowers skill applies. If a skill is relevant, use it first. User instructions define **what** to do. Skills define **how** to do it. --- ## Recommended Workflow ### 1. Start with `using-superpowers` Use this first for almost every task. Its job is to decide whether another skill should control the workflow. --- ### 2. Use `brainstorming` for new work or behavior changes Use it before: - building a feature - adding functionality - changing behavior - doing meaningful implementation work What to do: - understand the current context - ask clarifying questions one at a time - propose a few approaches with trade-offs - recommend one - get approval - write the design spec Do **not** code during brainstorming. --- ### 3. After approval, use `writing-plans` Turn the approved design into a concrete execution plan. The plan should include: - files to create or modify - small implementation steps - testing and verification steps A good plan should be clear enough for another agent to execute. --- ### 4. Use `using-git-worktrees` before implementation Prefer an isolated worktree instead of modifying the main workspace directly. This keeps feature work cleaner and safer. --- ### 5. Prefer `subagent-driven-development` for execution If subagents are available, use them to execute plan tasks one by one. Recommended pattern: - assign one focused task to one subagent - review for spec alignment - review for code quality - fix issues - mark the task complete --- ### 6. Use `executing-plans` if subagents are not available If you already have a written plan but are not using subagents, use `executing-plans`. Rules: - read the plan first - review it before starting - execute one task at a time - verify as you go - do not guess when blocked --- ## Supporting Skills ### `test-driven-development` Use when test-first implementation is appropriate: 1. write a failing test 2. confirm it fails 3. implement the minimum fix 4. run tests again --- ### `systematic-debugging` Use for bug fixing. Do not guess. Reproduce, narrow the problem, test hypotheses, find the root cause, then verify the fix. --- ### `requesting-code-review` / `receiving-code-review` Use review as a formal step, not an afterthought. --- ### `verification-before-completion` Before declaring work done, verify that: - tests pass - required commands succeed - the implementation matches the design and plan --- ### `finishing-a-development-branch` After implementation is complete: 1. verify tests 2. identify the base branch 3. present the completion options 4. clean up appropriately --- ## End-to-End Flow `using-superpowers` → `brainstorming` → `writing-plans` → `using-git-worktrees` → `subagent-driven-development` or `executing-plans` → supporting skills as needed → `verification-before-completion` → `finishing-a-development-branch` --- ## Operating Principle **User instructions define the goal. Skills define the method. Design before implementation. Plan before execution. Verify before completion.**
