Implement-with-instructions

Execute the user's instructions as a list of acceptance criteria (ACs) — small, end-to-end behaviours that each compile, run, and demonstrate an observable signal. Output is real production code committed atomically. No plan file, no UI rulebook, no design tokens file required.

Inputs and outputs

• Input: the user's freeform instructions in the conversation. Optional: pasted sketches, file pointers, screenshots.
• Code output: edits to project source.
• Commits: one atomic commit per AC (or per red/green/refactor step in TDD mode).
• Report output: <cwd>/.plans/<slug>/implementations/with-instructions/{feat,fix,refactor}/run.md — what was built, decisions made (FP choices, complexity), and any open follow-ups. Subdirectory choice (feat / fix / refactor) follows the dominant intent of the work: new behaviour → feat, bug-fix → fix, internal restructure with no behaviour change → refactor. If mixed, default to feat. If run.md already exists at that path, write run-2.md, run-3.md, etc. — never overwrite.

What an AC means

An acceptance criterion (AC) is the smallest end-to-end piece that is observable — something a caller, a test, or a user can run and see. Examples: an HTTP endpoint returning a hardcoded response; a pure function plus the test that pins its first behaviour; a button that opens a modal with placeholder content; a migration plus the model field it backs.

ACs are not "create the file", "add the import", "write the docstring". If a unit cannot be exercised on its own, fold it into the next observable step.

Source of ACs. Dynamic — if the user's instructions already enumerate acceptance criteria (numbered list, checklist, pasted plan content), take those verbatim. Otherwise, derive the AC list from the freeform instructions during preconditions step 1.