Ward

---
name: ward
description: TDD engine and enforcer — red/green/refactor, one behavior at a time. Use while implementing any feature or bugfix, or to execute a specific blueprint task with TDD.
allowed-tools: Read, Grep, Glob
argument-hint: "[behavior to implement | task <N>]"
---

# /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, locale-code format) are still binding — apply them **as you write**, not after a reviewer flags them. See [lore/code-standards.md](../../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 (your model's deepest level — `xhigh`, or `max` where unsupported — only for a genuinely hard multi-layer one). See [lore/models.md](../../lore/models.md).

The failing test *is* the verification. Don't add a self-review step after green — re-reading your own diff to confirm it is redundant on current models. Let RED → GREEN → REFACTOR and [/certify](../certify/SKILL.md) carry the proof. See [lore/model-behavior.md](../../lore/model-behavior.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: don't stop to ask the owner between phases before reading `CLAUDE.md`/standards, searching, `kg query`/`blast`, running the tests, or read-only git (`git status`, diff). This skill pre-approves only Read/Grep/Glob, because TDD edits arbitrary source and no honest path limit exists: `kg` lookups, test runs, and edits go through Claude Code's normal permission prompt unless the user runs in auto mode or approves them. 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](../../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. (dispatched with no human present: return NEEDS_CONTEXT instead of waiting).

## 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](../../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.** But if you are running as a dispatched subagent with no human present to answer, do not wait — return a BLOCKED or NEEDS_CONTEXT Obstacles block (see below) naming the exact spec gap, and stop.

## 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](../../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]`).

## Obstacles

If this skill runs as a dispatched unit (under /orchestrate, /weave, /manifest, /transmute, or another skill) and hits something that blocks or degrades the work, do not wait for a human who is not there and do not silently ship a degraded result — return an Obstacles block to the caller, alongside whatever you did complete:

```
STATUS: BLOCKED | DEGRADED | NEEDS_CONTEXT
OBSTACLE: <one-line label of what blocked or degraded the task — the claim alone>
BLOCKER: <the specific, actionable cause — distilled, never a raw traceback or dumped log>
SEVERITY: Critical | High | Medium | Low
WORKAROUND: <what you did to proceed and what it leaves unverified; empty if still fully blocked>
RECURRENCE: First-seen | Recurring | Systemic
SCOPE: <this task only | likely hits sibling/downstream work too>
NEXT: <the action or decision the caller must make to clear it — retry with X, supply input Y, accept degraded, or escalate>
```

When invoked interactively by a human, surface the same obstacle in prose instead. Omit the block entirely on a clean run. See [lore/obstacles.md](../../lore/obstacles.md).

## Completion Signal

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