implement

name	implement
description	Build a piece of work (ticket, spec, or free-form request) through a tunable pipeline — test-first, verify, review, and track — where every phase can be skipped or tuned. Use when the user wants to actually build something, from a throwaway prototype to a CCB-gated feature.
codex-short-description	Build through a tunable pipeline (every phase skippable)
disable-model-invocation	true
compatibility	claude-code codex opencode

Implement

Build the work — but first agree how much process it deserves. A throwaway prototype and a production feature run the same skill; they differ only in which phases are on. The run plan is proposed once, tuned by the user, then executed predictably.

The Jira project / Confluence space keys come from memory when tracking is on; read them, don't ask (reference_jira_default_project.md, reference_confluence_default_space.md).

The pipeline

Five phases. Each can be on, off, or tuned:

1. Source — where the work is defined: a Jira ticket, a /plan-to-spec page, or free-form from the conversation.
2. Test-first — drive /tdd (red → green) at pre-agreed seams. Off = build directly, no tests.
3. Verify — typecheck + run tests (single files during, full suite at end). Off = no test/type setup to run.
4. Review — /code-review (Standards + Spec axes) of the working diff. Off = skip review.
5. Track — commit; open an MR; move the ticket. Tunable down to commit only, or nothing (prototype).

Step 1 — Propose the run plan

Before building anything, detect a preset from the context and present the run plan as an editable list. The user edits any line or names a preset; you don't build until they approve.

Presets:

Preset	Test-first	Verify	Review	Track
prototype	off	off	off	nothing (or commit only)
standard	at key seams	typecheck + tests	code-review	commit + MR
full	TDD throughout	typecheck + full suite	code-review	commit + MR + move ticket

Auto-detect the starting preset:

• No test tooling in the repo, a spike/scratch/prototype path or explicit "quick/throwaway" → prototype.
• A Jira key or spec as the source, in a repo with tests + CI → full.
• Otherwise → standard.

Present it like this, and invite edits:

Run plan (auto-detected: standard — edit any line, or say a preset):
- Source:     PRJ-1490 (Jira ticket)
- Test-first: TDD at the ExportService seam
- Verify:     typecheck + test suite
- Review:     code-review (Standards + Spec)
- Track:      commit + MR   (not moving the ticket)

Confirm seams here if Test-first is on (that's /tdd's pre-agreement, pulled forward). Once approved, the plan is fixed for the run — state it back in one line and proceed.

Step 2 — Execute the enabled phases

Run only the on phases, in order, honouring each tuning:

• Test-first on → work in vertical slices via /tdd: one seam, one failing test, minimal code to pass, repeat. Off → build the slice directly.
• Verify on → typecheck and run single test files as you go; run the full suite once at the end. Off → skip (and don't invent a test command that doesn't exist).
• Review on → run /code-review against the branch point once the build is green. Off → skip.
• Track → per the tuning: commit only stops at a commit on the current branch; MR also drafts one (delegate to /mr-draft if installed); move ticket transitions the Jira issue. nothing leaves the work uncommitted for the user to inspect.

Refactoring belongs to the Review phase, not the build loop (per /tdd).

Step 3 — Close out

Report what ran and what was skipped, explicitly — a skipped phase is a stated outcome, not a silent omission:

Done — ran: TDD (3 slices), verify (suite green), code-review.
Skipped: MR (track = commit only, per run plan).
Committed a1b2c3d on feature/csv-export-v2.

If Review surfaced findings, list them before the close-out so the user decides what to address now vs. later.

Rules

• Agree the plan before building. The run plan is the one mandatory checkpoint; never start Phase 2 before the user approves Phase 1.
• A skipped phase is reported, never hidden. The close-out names every off phase so "no tests" is a visible decision, not an accident.
• Don't fabricate a phase's tooling. Verify off means there's nothing to run; don't invent a test command. Track = nothing means don't commit.
• One preset is a starting point, not a cage. The user can tune any single line without leaving the preset.
• Reuse, don't reimplement. Test-first is /tdd; review is /code-review; MR drafting is /mr-draft. This skill orchestrates them.

Host portability: tool names follow Claude Code conventions; on other hosts map by intent — see PORTABILITY.md.

Self-Evolve Loop

This skill learns across invocations — the full contract is SELF-EVOLVE.md. Start: read the learnings journal — ~/.ink-and-agency/learnings/implement.md and/or the workspace-local .ink-and-agency/learnings/implement.md — if present, and apply its guidance. End: self-evaluate the results; optionally ask the user for feedback (never block on it); append signal-bearing learnings to the journal (user-global when the sandbox allows writing there, workspace-local otherwise); route skill-improvement ideas per the contract's tiers — edit the canonical source when one is present, never the plugin cache.