Implement

Execute an input end-to-end on the current working tree. Read the input, derive implicit tasks if the input does not already enumerate them, implement each task, self-review, auto-commit per implicit task or per explicit Git instruction the user passes through, record a factual progress block per implicit task, and update the thread's singleton implementation report on the way out. Do not pause for clarifying questions at each step and do not ask before committing; the execution posture is identical whether or not a person is present. Do not rewrite history.

This skill is single-agent: the current session is the implementer and runs the self-review pass after each implicit task. No subagents are spawned.

Inputs

This skill accepts ONE of the following input forms. Detect which form was passed before deriving implicit tasks:

1. The thread-root plan.md — a brief plan whose numbered steps ARE the implementation steps. Treat each numbered step as an implicit task, in order; you have the freedom to derive the obvious substeps a step implies. This is the most structured input this skill takes.
2. The thread's seed.md plus decisions.md — when no plan exists, the seed's trigger narrative names the intended outcome and decisions.md carries the settled decisions that constrain it. Derive the implicit task list from the two together; a settled decision may map to an implicit task or constrain one.
3. An explicit code or issue reference — a file path, directory, or git ref, or a GitHub issue (full URL, or the short owner/repo#NNN form). For a code reference, read the referenced context and derive implicit tasks from the observed state ("look at this and do the obvious thing"). For an issue, the body becomes the input and the title and labels are additional framing.
4. A raw user prompt — when no artifact or reference is passed, the user's prompt is itself the input; derive implicit tasks directly from its stated intent.

If which input is meant is ambiguous — an incomplete issue identifier, a code reference pointing at a directory with multiple in-progress changes, or a prompt naming an artifact with no clear referent — that is a preflight failure, not an in-run decision: refuse before deriving tasks, name the ambiguous reference and how to disambiguate it, write nothing, and end with Outcome: REFUSED — <the ambiguity and how to re-invoke>. Never silently pick by recency; there is no global "latest input" algorithm. (Which thread is meant is resolved the same way — an unresolvable or ambiguous thread also refuses in preflight.)

Factual progress records