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.
par obra
requesting-code-review propose un workflow léger pour déléguer le sous-agent `superpowers:code-reviewer` avec un diff git propre, des exigences et un résumé des changements, afin de lancer les revues au bon moment et d’obtenir avant le merge des retours actionnables, classés par sévérité.
par obra
subagent-driven-development est une skill conçue pour exécuter des plans d’implémentation avec un nouveau subagent par tâche, puis revoir chaque résultat en deux étapes : d’abord la conformité au spec, ensuite la qualité du code. Elle inclut des modèles de prompts pour l’implémenteur, le relecteur de conformité au spec et le relecteur de qualité du code.
par obra
systematic-debugging est une skill de débogage centrée d’abord sur la cause racine, conçue pour les bugs, les tests instables, les échecs de build et les comportements inattendus. Découvrez son workflow en quatre phases, ses fichiers d’accompagnement et les cas où l’utiliser avant de proposer des correctifs.
par obra
Installez et utilisez la skill test-driven-development pour appliquer un TDD strict : rédigez d’abord un test en échec, vérifiez l’échec, implémentez le minimum de code, puis refactorisez en toute sécurité.
par obra
using-git-worktrees aide à créer des Git worktrees isolés pour travailler sur de nouvelles branches, avec choix du répertoire, vérifications des fichiers ignorés et flux de travail parallèles plus sûrs, sans toucher à votre checkout actuel.
par obra
using-superpowers est une skill de démarrage de session du dépôt obra/superpowers qui impose une recherche de skills avant toute réponse, afin d’aider les agents à repérer et activer d’abord le bon workflow.
par obra
verification-before-completion est une skill de vérification finale qui empêche les affirmations de fin de tâche non étayées. Découvrez quand l’utiliser, comment l’installer depuis obra/superpowers, et comment associer chaque statut annoncé à une preuve de vérification récente.
par obra
writing-plans aide à transformer une spec ou un document d’exigences en un plan d’implémentation détaillé, avec des indications au niveau des fichiers, un séquencement des tâches, des étapes de test et une invite de relecture avant de commencer à coder.
par obra
writing-skills est un guide de Skill Authoring pour créer, modifier et valider des agent skills avec une approche pilotée par les tests. Découvrez les fichiers clés, les prérequis et les étapes concrètes pour les scénarios de pression, les tests de référence et l’itération concise de `SKILL.md`.
par obra
brainstorming est une compétence de pré-implémentation qui explore le contexte, pose des questions de clarification une par une et impose une validation du design avant tout code. Elle inclut un compagnon visuel optionnel et une prise en charge solide de la planification des exigences.
par obra
dispatching-parallel-agents est une skill d’orchestration d’agents conçue pour répartir des tâches réellement indépendantes entre plusieurs agents, avec contexte isolé et résultats coordonnés.
par obra
executing-plans aide les agents à suivre un plan d’implémentation écrit : le relire d’abord, exécuter les tâches dans l’ordre, lancer les vérifications prévues, s’arrêter en cas de blocage et passer la main à un workflow de finalisation. Idéal pour la gestion de projet et les livraisons pilotées par un plan.
par obra
La skill finishing-a-development-branch aide à clôturer proprement une branche Git une fois l’implémentation terminée. Elle vérifie les tests, contrôle la branche de base, puis propose quatre options claires : fusionner en local, pousser pour une Pull Request, conserver la branche ou abandonner le travail.
par obra
receiving-code-review vous aide à valider les retours de PR avant de modifier le code. Utilisez-la pour reformuler les commentaires de review, les confronter à la codebase, demander des précisions quand certains points sont ambigus et contester une suggestion lorsqu’elle ne convient pas.
# 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.**
