ward

/ward — TDD Engine

Enforce strict red → green → refactor discipline for all implementation work. (This skill absorbed the former /forge — general TDD and per-task blueprint execution are one engine.)

Match the project's conventions (read before you write)

Before implementing, discover and read the repo's own standards — CLAUDE.md, any code-review.md / CONTRIBUTING / STYLEGUIDE, and the linter/formatter config — and mirror the patterns already in the files you touch. Conventions a formatter can't enforce (async/await over .then, error-wrapping, naming, FR-CA vs FR) are still binding — apply them as you write, not after a reviewer flags them. See lore/code-standards.md.

Effort

Scale /effort to task size: low for a one-line fix, medium for normal work, high for a complex multi-behavior task. See lore/models.md.

Autonomy — approve the plan, then run

Once the spec is settled — the failing test you can write, or the plan task in .workspace/shared/plans/ — run the remaining phases (RED → GREEN → REFACTOR and the per-task steps) autonomously: reading CLAUDE.md/standards, searching, kg query/blast, running the tests, and read-only git (git status, diff) NEVER pause for permission between phases. Re-gate only on real side effects — the per-task git add/commit/push. Beyond that, pause only for genuine spec ambiguity (the "cannot write the test first" case below). See lore/autonomy.md.

Two modes

• Freeform (/ward <behavior>): drive TDD for whatever you're implementing now.
• Task mode (/ward task <N>): execute task N from the current blueprint plan in .workspace/shared/plans/. Read the task text from the plan file first; if the plan isn't clear from context, ask which plan file. End your turn and wait if you must ask.

The Law

1. RED — Write a failing test describing exactly one behavior. Run it and read the output: it must fail for the reason under test — your assertion, with a meaningful message, not a compile error, missing import, or typo. A failure for the wrong reason is a false RED → back to RED (fix the test, re-run), never forward to GREEN. If implementation code for this behavior already exists (written before its test), delete it and re-derive it from the test — code the test never drove is unproven.
2. GREEN — Write the minimum code to pass. Ugly is fine. Add no untested logic. Re-run the same test; RED→GREEN is proven by the two runs you watched — the real RED output, then GREEN — not by "it should pass" (lore/verification.md).
3. REFACTOR — Clean up implementation and tests. No behavior change. All tests stay green.
4. Repeat for the next behavior.

Vertical tracer bullets

Go end-to-end for one behavior before expanding: first test → first implementation → works → next behavior.

What counts as one behavior

One function doing one thing · one API endpoint with one response case · one UI component in one state. NOT "the whole auth system".

Test quality rules

• Test names describe behavior: test_returns_404_when_user_not_found
• Test observable behavior, not implementation internals
• No assertTrue(true) — always-pass tests are worse than none
• One assertion per concept

If you cannot write the test first

The spec is incomplete. Do not guess. Ask: "I can't write this test yet — the spec doesn't define what [behavior] should do. Clarify the expected input and output?" End your turn. Wait for clarification before writing code.

Per task (task mode only)

After the behavior(s) for the task are green and refactored:

1. Run the project's formatter + linter (the ones CI/review actually use) and type-check — fix style/lint before committing. A convention the reviewer or code-review.md would flag (e.g. async/await vs .then) is a failing gate, not a post-review fixup (lore/code-standards.md).
2. Run the full test suite — no regressions.
3. Commit with a conventional commit message.
4. Mark the task complete in the plan file (- [ ] → - [x]).

Completion Signal

• Freeform: "All behaviors covered. Run /certify."
• Task mode: "Task N complete. Next: /ward task N+1, or /certify if all tasks done."