Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

tdd

Estrellas2

Forks0

Actualizado29 de junio de 2026, 07:52

Test-driven development for one feature slice or bug fix. Use when Codex should work red-green-refactor, add behavior-focused tests, protect public interfaces, or turn a repro into a regression test during implementation.

Instalación

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.

Ejecutar en Manus

Fuente

HowAreAllWell

HowAreAllWell/code-workflow

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Analistas de garantía de calidad de software y probadoresOcupaciones informáticas y matemáticas·SOC 15-1253

Explorador de archivos

2 archivos

SKILL.md

readonly

name	tdd
description	Test-driven development for one feature slice or bug fix. Use when Codex should work red-green-refactor, add behavior-focused tests, protect public interfaces, or turn a repro into a regression test during implementation.

Test-Driven Development

Use TDD to build one behavior at a time through public interfaces.

Read docs/agents/domain.md and docs/agents/verification.md if they exist.

Principles

Test behavior, not implementation details.
Prefer integration-style seams that exercise real code paths.
Write one test, make it pass, then repeat.
Refactor only while tests are green.
Do not write a batch of imagined tests before seeing the implementation path.

Workflow

1. Choose The Seam

Pick the highest useful public interface:

UI workflow, HTTP endpoint, CLI command, public API, domain service, or fixture-based path.
Existing test style in the repo.
A seam that can also serve acceptance or regression evidence.

If no good seam exists, state the limitation and use the best command/manual verification available. Do not invent brittle tests just to appear test-first.

2. Red

Write one focused test for one observable behavior. It should fail for the right reason when practical.

3. Green

Implement the smallest change that passes the test. Avoid speculative interfaces or future options.

4. Refactor

Clean duplication or awkward design only after the test is green. Keep the public behavior unchanged and rerun the focused check after each meaningful refactor.

5. Repeat

Add the next behavior only after learning from the previous cycle. Stop when the work item's acceptance criteria are covered.

6. Record Evidence

For handoff and acceptance, record:

Tests added or changed.
The command that proves them.
Any broader regression command run.
Any behavior that remains manual or risky.

Test Quality Checklist

The test name uses project domain vocabulary.
The test would survive an internal refactor.
The test fails if the user-visible behavior is wrong.
Mocks are only used at true external boundaries.
The tested seam matches the acceptance criterion or bug repro.

Más de este repositorio

mismo repositorio

codebase-design

HowAreAllWell/code-workflow

Shared vocabulary and decision process for designing module interfaces and test seams. Use when Codex needs to decide where a seam belongs, judge whether a module is deep or shallow, design an interface that serves slicing and acceptance, or make code easier to test and navigate.

2026-07-072

domain-modeling

HowAreAllWell/code-workflow

Maintain a repository's domain vocabulary and architecture decision records. Use when Codex needs to sharpen terminology, resolve ambiguous domain concepts, update CONTEXT.md, create ADRs, or support grill-with-docs, triage, TDD, diagnosis, or architecture work with durable domain language.

2026-07-072

grill-with-docs

HowAreAllWell/code-workflow

Clarify a feature, refactor, architecture idea, or product plan against existing code and domain docs. Use when requirements, terminology, constraints, or success signals are unclear before to-prd, to-issues, triage, or implementation, and Codex should update CONTEXT.md or ADRs only when domain terms or decisions crystallize.

2026-07-072

improve-codebase-architecture

HowAreAllWell/code-workflow

Scan a codebase for architecture friction and deepening opportunities. Use when Codex needs to audit old code, find shallow modules, improve testability, identify seams before implementation, or report architecture blockers without directly changing product code.

2026-07-072

triage

HowAreAllWell/code-workflow

Move issues, external PRs, new ideas, manual test feedback, existing-codebase audits, and regression reports through workflow triage states. Use when Codex needs to classify work, verify claims, detect already-implemented behavior, ask for missing info, create agent-ready briefs, or route changes before implementation.

2026-06-292

acceptance

HowAreAllWell/code-workflow

Lightweight acceptance gate for completed slices, bug fixes, PRs, or implementation branches. Use when Codex needs to verify that work matches the originating issue or PRD, prove acceptance criteria and regression checks, decide pass/fail/blocked before handoff, or record acceptance evidence in GitHub, a PR, or local markdown.

2026-06-292

name	tdd
description	Test-driven development for one feature slice or bug fix. Use when Codex should work red-green-refactor, add behavior-focused tests, protect public interfaces, or turn a repro into a regression test during implementation.

Test-Driven Development

Use TDD to build one behavior at a time through public interfaces.

Read docs/agents/domain.md and docs/agents/verification.md if they exist.

Principles

Test behavior, not implementation details.
Prefer integration-style seams that exercise real code paths.
Write one test, make it pass, then repeat.
Refactor only while tests are green.
Do not write a batch of imagined tests before seeing the implementation path.

Workflow

1. Choose The Seam

Pick the highest useful public interface:

UI workflow, HTTP endpoint, CLI command, public API, domain service, or fixture-based path.
Existing test style in the repo.
A seam that can also serve acceptance or regression evidence.

If no good seam exists, state the limitation and use the best command/manual verification available. Do not invent brittle tests just to appear test-first.

2. Red

Write one focused test for one observable behavior. It should fail for the right reason when practical.

3. Green

Implement the smallest change that passes the test. Avoid speculative interfaces or future options.

4. Refactor

Clean duplication or awkward design only after the test is green. Keep the public behavior unchanged and rerun the focused check after each meaningful refactor.

5. Repeat

Add the next behavior only after learning from the previous cycle. Stop when the work item's acceptance criteria are covered.

6. Record Evidence

For handoff and acceptance, record:

Tests added or changed.
The command that proves them.
Any broader regression command run.
Any behavior that remains manual or risky.

Test Quality Checklist

The test name uses project domain vocabulary.
The test would survive an internal refactor.
The test fails if the user-visible behavior is wrong.
Mocks are only used at true external boundaries.
The tested seam matches the acceptance criterion or bug repro.