jiglisted

# Jig — Test-Driven Implementation (A jig is the guide that constrains the workpiece so it comes out right. Tests written first are the jig; the implementation is shaped against them.) Read `${CLAUDE_PLUGIN_ROOT}/references/creed.md`, `${CLAUDE_PLUGIN_ROOT}/references/memory.md`, and `${CLAUDE_PLUGIN_ROOT}/references/dispatch.md` first. Log: `bash ${CLAUDE_PLUGIN_ROOT}/scripts/ledger.sh append forge <slug> jig STARTED -` ## When jig vs plain forge | Situation | Path | |---|---| | Behavior is specifiable as tests up front (functions, APIs, parsers, business logic) | **jig** — TDD pays for itself | | Exploratory/visual work where the assertion isn't knowable first (UI layout, design spikes) | plain forge, tests after via `/smithy:ring-test` | | Bug fixes | **jig always** — the regression test IS the failing test (RED = reproduce) | | Config/docs/mechanical changes with nothing to assert | plain forge | The choice is per-job (or per-task when tasks differ in nature). It is controlled by `implementation.tdd` in the effective config: - `"always"` — every forge task dispatches the jigsmith - `"never"` — every forge task dispatches the plain forger - `"ask"` (default) — forge asks the user ONCE per job, at the first task, with a recommendation derived from the table above ## The three TDD dials Read all three with `config.sh get` (it merges defaults → global → project; reading a config file directly silently misses the user's global default): ```bash bash ${CLAUDE_PLUGIN_R