Menu
Use before writing or changing any feature or bugfix code, to drive the change with a failing test first. Red, green, refactor. The discipline that proves the code does what was asked and keeps it proven as the project grows.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Use when several pieces of work are genuinely independent and can run at once, to fan them out across parallel agents instead of doing them in sequence. Cuts wall-clock time and keeps each strand in its own clean context.
Use when a written plan exists and you are about to build it in the current session, to work it task by task with a checkpoint after each. Keeps execution honest against the plan instead of drifting into a freehand build.
Use when work needs its own isolated checkout — parallel strands that would fight over files, or a risky change you want quarantined from the main tree. Gives each strand a real working directory on its own branch without re-cloning.
Use whenever the user says "use slipstream", "use superpowers", or starts any task in a project that has slipstream. A hard, always-on discipline that forces scoped reads over whole-file reads to save tokens, recalls memory before acting, and records what is durable every turn so memory grows constantly.
Use when a site needs to look designed rather than defaulted, before building sections: establish a cohesive design system of type scale, spacing, colour, radius and shadow tokens so every component shares one premium visual language.
Use when building the top of a landing page, to produce a high-impact hero with confident display type, a clear single call to action and balanced composition, the kind of opening a polished marketing site leads with.
| name | test-driven-development |
| description | Use before writing or changing any feature or bugfix code, to drive the change with a failing test first. Red, green, refactor. The discipline that proves the code does what was asked and keeps it proven as the project grows. |
| slipstream | {"category":"context","requires":[],"tags":["testing","discipline","correctness"]} |
Code written before a test tends to test nothing and prove nothing. Writing the test first forces you to state the behaviour in concrete terms, gives you a definition of done you cannot fudge, and leaves a regression guard behind for free. This is a rigid discipline: do not write implementation before a failing test exists, and do not claim the work is done until the test passes for the right reason.
Run the project's test command and confirm the new test passes and the rest of the suite still passes. Paste the actual passing count. A claim of done without a green run is not done.
