con un clic
tdd
Use when implementing or fixing production code with tests.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Menú
Use when implementing or fixing production code with tests.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Use at ship time to merge the spec into the living documentation, delete the staging spec and plan, and ask how to finish.
Use when taking over an existing codebase that has no living document. Produces a factual record of what already exists.
Use when all plan tasks are done and green to review, archive planning artifacts, and ask how to finish.
Use for standard or complex new work before coding or planning. Also handles vague goals — clarifies before designing.
Use at session start to learn how Praxis skills are invoked and why triage runs before every task.
Use when the goal is vague or vision-level and can't be defined well enough for design questions.
| name | tdd |
| description | Use when implementing or fixing production code with tests. |
No production code without a failing test first. Wrote code before the test? Delete it. Rewrite from the test. Exception — ask user first: prototypes, generated code, throwaway scripts.
RED (fail for the right reason) -> GREEN (minimum to pass) -> refactor -> sync docs -> commit -> edit docs/staging/plans/YYYY-MM-DD-<topic>.md and change this task's - [ ] to - [x]. Do not start the next task without this edit.
Sync docs means:
docs/staging/specs/*.md): update it to match code reality.All tasks - [x] and green -> ship.
Passing tests are not a quality bar.
<gate> Before committing: evaluate the implementation against SOLID principles, design patterns, and clean code. State what you assessed and what (if anything) you improved — or why no changes were needed. </gate>