Implement

Execute a less-structured 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, report a four-state status per implicit task, and emit a single immutable implementation report record on the way out. By default, do not pause for clarifying questions at each step or ask before committing — but honor an invocation that asks you to check in or work through the tasks interactively; 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 SEVEN input forms. Detect which form was passed before deriving implicit tasks:

1. A spec artifact path under a thread's specs/ folder. The spec's semantic-contract elements (intended outcome, expected behavior, constraints, acceptance guidance) drive the implicit task list directly. If the spec has acceptance guidance, every implicit task should trace to a piece of it; if a piece of acceptance has no implicit task covering it, that is a coverage gap to surface.
2. A proposal artifact path under a thread's proposals/ folder. The proposal's rough shape becomes the implicit task list; the proposal's open questions become either tasks the implementation resolves or DONE_WITH_CONCERNS / NEEDS_CONTEXT flags in the four-state report.
3. A decision-log artifact path under a spine node's discussions/ folder. The log carries one or more settled decisions. Each settled decision may map to an implicit task (or constrain one); cite the source log by path and decision identifier in the task report where the decision is operative.
4. A GitHub issue URL or identifier. Accepted forms include a full URL (https://github.com/<owner>/<repo>/issues/<NNN>) or the short owner/repo#NNN form. The issue body becomes the input; treat the issue title and labels as additional framing.
5. A seed artifact path under a thread's seed/ folder (seed/seed.md). The seed is the thread's genesis record; its trigger narrative names the intended outcome and the body sketches the work. A seed input typically means tier-1 work — read the thread's ledger.md to confirm the tier before deriving tasks.
6. A code context reference — a file path, directory, or git ref. The implementer reads the referenced context and derives implicit tasks from the observed state (e.g., "remove dead code in src/legacy/", "fix the import order in src/foo.ts"). This input form fits requests where the user's intent is "look at this and do the obvious thing" rather than a written input.
7. A raw user prompt. When no artifact or code reference is passed, the user's prompt is itself the input. Derive implicit tasks directly from the prompt's stated intent.

If the input is ambiguous — a thread contains multiple lineages of the named type (e.g. specs/001-api/ and specs/002-cli/) and "the spec" has no clear referent, the issue identifier is incomplete, the prompt references an artifact with no clear referent, the code context reference points at a directory containing multiple in-progress changes — ASK the user which input is intended. There is no global "latest input" algorithm. Do not silently pick by recency, and do not pick "highest NNN".