Implement-code (FP-first, no UI)

Execute exactly one phase of a plan for non-UI code (backend services, libraries, CLIs, scripts, infra, data pipelines, etc.). Output is real production code plus an implementation report. The skill leaves the working tree on a clean series of atomic commits — one per acceptance criterion — and never amends.

Inputs and outputs

• Code output: edits to project source.
• Report output: <cwd>/.plans/<feature>/implementations/code/{feat,fix,refactor}/<phase_number>.md — what was built, decisions made (FP choices, complexity), and any deviations from the plan. Subdirectory choice (feat / fix / refactor) follows the dominant intent of the phase: new behaviour → feat, bug-fix → fix, internal restructure with no behaviour change → refactor. If mixed, default to feat.

This skill does not read <cwd>/.plans/DESIGN.md and does not invoke any other skill. If the chosen phase touches a UI surface, hard-stop and tell the user to use a UI-oriented implementation skill instead — one that reads .plans/DESIGN.md and .plans/UI-RULES.md.

Modes

Two modes — default and TDD. Pick once at the start of the invocation; do not switch mid-phase.

• Default mode — write code, then run the narrowest automated check that proves the AC, then commit. One commit per AC.
• TDD mode — strict red → green → refactor per AC. Activated when the user's prompt contains "tdd", "use tdd", "tdd mode", or "test-first", or when (during preconditions) the user explicitly opts in. In TDD mode, each AC produces 2–3 commits ([red] failing test, [green] passing code, optional refactor). Full discipline in TDD.md.

If the prompt contains a near-trigger that doesn't match the list exactly (e.g. "write tests as you go", "test everything"), ask once with AskUserQuestion during preconditions; default to non-TDD if they decline to choose. Do not ask when no trigger phrase appeared — silence means default mode.