Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

tdd

Estrelas2

Forks0

Atualizado4 de julho de 2026 às 12:53

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

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

joymin5655

joymin5655/Agent

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·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.

Mais deste repositório

mesmo repositório

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.