agentsclimarketplace

Tdd

Skill LuchoC-Dev/agent-kits/skills/tdd

AI-first workspace bootstrapper — installs skills, packs, agents, and disciplines into .agents/. Cross-compatible with Claude Code and OpenCode.

Install
npx -y skills add LuchoC-Dev/agent-kits --skill tdd

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Disciplina de ejecución Test-Driven Development — ciclo red → green → refactor. Escribir el test que falla antes que el código que lo hace pasar. Trigger cuando el proyecto tiene `tdd` en las disciplinas activas, o el usuario pide "hacer TDD", "test primero", "red green refactor", o está por implementar lógica con tests.

SKILL.md

3.7 KB, as published. Nobody here has run it

TDD — Test-Driven Development

Rol

Sos un practicante de TDD. Tu trabajo no es "agregar tests al final": es conducir la implementación con tests. Ningún código de producción se escribe sin un test que falle primero y lo justifique.

Naturaleza de esta skill

Es una skill de disciplina, no de diseño. No produce un documento-artefacto en docs/; produce código y tests y rige cómo se ejecuta el paso de implementación. Es agnóstica al flujo: el workflow decide en qué paso se aplica.

Cuándo se activa

Se aplica cuando tdd está en el campo disciplines de workspace.json. El workflow la invoca para envolver el paso de implementación. Si no está activa, el código se implementa sin esta disciplina.

La disciplina — el ciclo

Por cada unidad de comportamiento, repetir el ciclo corto:

🔴 Red — escribir un test que falle

  • Escribí un solo test que describa el próximo incremento de comportamiento deseado.
  • El test debe fallar por la razón correcta (comportamiento ausente), no por un error de compilación o de setup. Corré la suite y confirmá el fallo.
  • El test nombra el comportamiento, no la implementación: calcula_total_con_descuento, no llama_a_getDiscount.

🟢 Green — el mínimo código para pasar

  • Escribí lo mínimo que haga pasar el test. Está permitido hardcodear, duplicar o ser "feo" en este paso.
  • No agregues lógica que ningún test exija todavía. Si la querés, primero escribí su test (volvé a Red).
  • Corré la suite completa: todo en verde.

🔵 Refactor — limpiar con la red puesta

  • Con todos los tests en verde, mejorá el diseño: eliminá duplicación, renombrá, extraé funciones.
  • No cambies comportamiento. Si la suite se rompe, el refactor estuvo mal — revertí.
  • Refactorizá tanto el código como los tests.

Repetir hasta que la unidad de comportamiento esté completa.

Reglas de la disciplina

  • Un test que falla antes que cualquier código de producción. Sin excepción.
  • Pasos chicos. Si un ciclo se está volviendo largo, el incremento era demasiado grande — partilo.
  • Suite siempre verde al cerrar cada ciclo. Nunca dejar tests rojos "para después".
  • Test → razón de fallo correcta. Un test que pasa apenas se escribe no probó nada.

Integración con otras disciplinas

TDD es combinable; no es excluyente con ninguna otra disciplina:

  • Con bdd — los escenarios Gherkin definen el comportamiento de afuera; TDD conduce las unidades por dentro. Un escenario BDD se satisface con varios ciclos red-green-refactor. BDD da el "qué"; TDD el "cómo, en chico".
  • Con contract-first — el contrato congelado es la fuente de verdad de los tests de borde (request/response, errores). Los primeros tests rojos verifican conformidad con el contrato.
  • Con trunk-based — cada ciclo verde es un punto seguro para un commit chico. El ritmo de TDD alimenta naturalmente la cadencia de commits de trunk-based.

Reglas duras

  • No escribir código de producción sin un test rojo que lo pida.
  • No avanzar de Green a un nuevo Red sin pasar por Refactor (aunque el refactor sea "nada que limpiar").
  • No mezclar refactor con cambio de comportamiento en el mismo paso.
  • La cobertura es consecuencia, no objetivo: no escribir tests sin comportamiento que los motive.

Gives 4 of the 12 instructions most tdd skills give

Counted across 439 of the 443 authors here whose files we hold, read 2026-08-06

  • write minimal code to pass the testhere, and in 302 of 439, across 218 files
  • write a failing test firstin 176 of 439, across 112 files
  • refactor code only after tests passin 171 of 439, across 101 files
  • watch the test fail before writing codehere, and in 142 of 439, across 93 files
  • test one behavior per testin 106 of 439, across 44 files
  • refactor code while keeping tests greenhere, and in 99 of 439, across 86 files
  • delete code written before testsin 98 of 439, across 54 files
  • run tests after each refactor stepin 85 of 439, across 54 files
  • Use real code instead of mocks unless unavoidablein 64 of 439, across 21 files
  • confirm the test fails for the right reasonhere, and in 64 of 439, across 60 files
  • reproduce bugs with a test before fixingin 53 of 439, across 36 files
  • write tests before implementationin 48 of 439, across 39 files

Said here and by no other author read

  • do not add logic that no test demands
  • run the full suite before finishing a step
  • keep the suite green at the end of each cycle
  • take small steps

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.