Run any Skill in Manus with one click

tdd

Stars2

Forks0

UpdatedJuly 4, 2026 at 12:53

Enforce Red-Green-Refactor cycle for a feature. Write the failing test first, then minimal implementation, then refactor with tests green.

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

joymin5655

joymin5655/Agent

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

SKILL.md

readonly

name	tdd
description	Enforce Red-Green-Refactor cycle for a feature. Write the failing test first, then minimal implementation, then refactor with tests green.
when_to_use	User starts a new feature, fixes a non-trivial bug, or invokes `/tdd`.
tools	Read, Write, Edit, Bash, Grep, Glob

/tdd

Goal

Force the discipline of writing the test before the code. Three phases: Red (failing test) → Green (minimal impl) → Refactor (with tests green).

Phase 1 — Red

Understand the feature/bug.
- One observable behavior, named.
- Acceptance criteria from rules/policy/strong-goal-template.md.
Write the failing test.
- One test per observable behavior. Don't pack multiple assertions into one test unless they're the same behavior.
- AAA pattern: Arrange, Act, Assert.
- Name the test so it documents the intent (when_input_is_empty__should_return_error).
Run the test. Confirm it fails for the expected reason.
- Failure message must match what the spec demands (e.g., AssertionError: expected ValueError, not ModuleNotFoundError: foo).
- If the failure is unrelated (import error, syntax error), fix that first and re-run before moving on.

Phase 2 — Green

Write the minimum code that makes the test pass.
- No extra features. No optimisation. No abstraction.
- "Make it work, then make it right."
Run the test. Confirm green.
- If still red, the impl is wrong. Don't change the test to match.
Run the full test suite for that module.
- Make sure you didn't break anything else.

Phase 3 — Refactor

With tests green, refactor for clarity / dedup / structure.
- Each refactor step: small change, run tests, confirm green.
- If a refactor breaks tests, the design is wrong — back out and reconsider.
Final check: full test suite green, lint green, type-check green.

Output

Phase: Red    | Test added: <path>:<test-name> | Status: FAIL (expected)
Phase: Green  | Impl: <path>:<function>        | Status: PASS
Phase: Refactor | Changes: <bullet list>      | Status: PASS

Suite: <command> → <PASS/FAIL>
Coverage: <% if available>

Hard rules

No green-without-red. If you wrote the impl first, throw it away and start over.
No "I'll add tests later". The test is the spec; without it you don't know what "done" means.
No relaxing assertions to make a test pass. The test failure describes the bug — fix the code.
No commented-out tests in the codebase.

Anti-patterns

Anti-pattern	Fix
Writing all tests, then all code	Write one test, then one impl, then loop.
Tests that test the implementation, not the behavior	Test inputs → outputs. Don't assert internal state.
Mocking everything	Integration tests with real deps catch real bugs. Mock at the system boundary, not internally.
One test, multiple assertions for different cases	Split. One behavior per test.

More from this repository

same repository

supervise

joymin5655/Agent

Dispatch a multi-wave plan to specialist agents with audit + risk-area abort. Supports --auto-push, --auto-merge, --goal-mode for budgeted runs. NOT for writing the plan itself (that is /spec), and NOT for a single small edit with no waves — just make the edit.

2026-07-112

verify-completion

joymin5655/Agent

Independently re-verify a completion claim in a separate context — mechanical evidence (files/tests/assertions) plus a refute-by-default semantic judge — before a wave or task is allowed to be called "done". Emits the shared verdict schema. NOT for code-style review (that is a reviewer's lane) and NOT for verifying work you authored in the same context — the verifier must be a fresh spawn.

2026-07-112

harness-help

joymin5655/Agent

Router over the harness skills — which skill fits your situation, and the main flow through them. NOT for performing the routed work itself — it only points; invoke the skill it names.

2026-07-112

spec

joymin5655/Agent

Upstream planning-discipline — brainstorm a feature into spec.md + plan.md under .agent/plans/<slug>/, then route to plan approval. Enforced by the spec-gate tool boundary, not prompt coercion. NOT for trivial/test/doc-only edits (the gate scopes those out), and NOT for executing an already-approved plan (that is /supervise).

2026-07-112

wrap

joymin5655/Agent

Commits staged changes and opens a PR. Runs gitleaks + risk-area guards before committing. Push is user-confirmed by default; --auto-push and --auto-merge are opt-in. NOT for review or verification (run those before wrapping), and NOT when nothing has changed yet — there is nothing to commit.

2026-07-112

harness-audit

joymin5655/Agent

Agent-driven, read-only self-audit of the harness — run the machine integrity layer once as a dry-run, present a per-check pass/fail table, cite the P1-1 doc-reality result, and for any failure give root-cause + fix + backlog follow-up. Consumes the machine gates; it does not reimplement them. NOT for auditing a consumer project's own codebase (use that project's test suite), and NOT for applying fixes — this skill observes and reports only.

2026-07-092

/tdd

Goal

Force the discipline of writing the test before the code. Three phases: Red (failing test) → Green (minimal impl) → Refactor (with tests green).

Phase 1 — Red

Understand the feature/bug.

One observable behavior, named.
Acceptance criteria from rules/policy/strong-goal-template.md.

Write the failing test.

One test per observable behavior. Don't pack multiple assertions into one test unless they're the same behavior.
AAA pattern: Arrange, Act, Assert.
Name the test so it documents the intent (when_input_is_empty__should_return_error).

Run the test. Confirm it fails for the expected reason.

Failure message must match what the spec demands (e.g., AssertionError: expected ValueError, not ModuleNotFoundError: foo).
If the failure is unrelated (import error, syntax error), fix that first and re-run before moving on.

Phase 2 — Green

Write the minimum code that makes the test pass.

No extra features. No optimisation. No abstraction.
"Make it work, then make it right."

Run the test. Confirm green.

If still red, the impl is wrong. Don't change the test to match.

Run the full test suite for that module.

Make sure you didn't break anything else.

Phase 3 — Refactor

With tests green, refactor for clarity / dedup / structure.

Each refactor step: small change, run tests, confirm green.
If a refactor breaks tests, the design is wrong — back out and reconsider.

Final check: full test suite green, lint green, type-check green.

Output

Hard rules

No green-without-red. If you wrote the impl first, throw it away and start over.

No "I'll add tests later". The test is the spec; without it you don't know what "done" means.

No relaxing assertions to make a test pass. The test failure describes the bug — fix the code.

No commented-out tests in the codebase.

Anti-patterns

Anti-pattern

Fix

Writing all tests, then all code

Write one test, then one impl, then loop.

Tests that test the implementation, not the behavior

Test inputs → outputs. Don't assert internal state.

Mocking everything

Integration tests with real deps catch real bugs. Mock at the system boundary, not internally.

One test, multiple assertions for different cases

Split. One behavior per test.