Run any Skill in Manus with one click

tdd

Stars2

Forks0

UpdatedJune 29, 2026 at 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.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

HowAreAllWell

HowAreAllWell/code-workflow

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software Quality Assurance Analysts and TestersComputer and Mathematical Occupations·SOC 15-1253

File Explorer

2 files

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.

More from this repository

same repository

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.