/implement-spec

description: 'Deliver an approved plan or OpenSpec change through controlled implementation.'
argument-hint: '[openspec-change]'
model: 'inherit'
agent: 'plinth-tech-lead'
tools:
  - 'Read'
  - 'Write'
  - 'Edit'
  - 'Bash'

implement-spec

Deliver an approved implementation plan or validated OpenSpec task list through controlled implementation.

Usage

/implement-spec <approved-plan|openspec-change> [task-or-group] [constraints]

Accepted inputs

• An approved implementation plan (`*.plan.md`)
• An OpenSpec change containing a validated `tasks.md`
• Optional task or group selection, branch/worktree context, and implementation constraints

A bare issue is context, not an execution contract. When repository policy requires structured planning and neither executable artifact exists, stop and direct the user to provide an approved implementation plan or run `/create-spec`.

Owner and delegation

• Owner: `@plinth-tech-lead`
• Delegation targets: `@plinth-java-coder`, `@plinth-java-spring-boot-coder`, `@plinth-java-quarkus-coder`, `@plinth-java-micronaut-coder`, or `@plinth-no-java`
• The tech lead coordinates delivery and MUST NOT implement application code directly.

Mandatory execution contract

• If the command runner is not `@plinth-tech-lead`, immediately delegate the whole command execution to `@plinth-tech-lead` and wait for its result.
• `@plinth-tech-lead` MUST invoke the selected implementation agent for implementation, test, and verification work; naming an agent in the response is not delegation.
• If agent invocation is unavailable in the current environment, stop and report that `/implement-spec` cannot proceed instead of implementing directly.
• For OpenSpec inputs, pass the **OpenSpec readiness gate** below before skill discovery, Git-location changes, or implementation delegation.
• Before any implementation agent starts, pass the branch/worktree gate below and report the selected isolation strategy.
• Before any implementation agent starts, `@plinth-tech-lead` MUST publish a **Skill discovery brief** and pass an ordered **candidate skills to read** list in every implementation handoff.

OpenSpec readiness gate

• After loading and structurally validating the selected change, determine the **selected execution scope** from the requested task or group, or all incomplete tasks when no narrower scope is supplied.
• Require **bidirectional traceability**: every selected behavior-changing implementation task has one or more concrete scenarios in `specs/**/spec.md`, and every scenario applicable to the selected scope has an actionable implementation or verification task. Repository validation tasks must map to an explicit quality, safeguard, or verification obligation.
• A concrete scenario defines its trigger, required preconditions, and observable outcome without unresolved placeholders. An actionable task names a specific remaining implementation or verification outcome; completed-only tasks do not provide executable work.
• Treat evidence as not ready when it is **absent, ambiguous, placeholder, completed-only, partial, or divergent** from the selected change requirements or safeguards.
• When the gate fails, stop and report **each unsupported scenario or task**, identify the owning OpenSpec artifact, and instruct the contributor to **update the OpenSpec change and rerun `/implement-spec`**.
• The command must not invent acceptance criteria or tasks. A failed readiness gate stops **before skill discovery, Git-location changes, or implementation delegation**.
• Do not require unrelated future task groups to be implementation-complete when a narrower task or group was explicitly selected.

Branch/worktree gate

• After the OpenSpec readiness gate passes, inspect the workspace with `git status --short` before resolving or changing an implementation location.
• If the workspace is dirty, stop immediately and report the changed/untracked paths. Do not create a feature branch, create a worktree, delegate implementation, or ask for approval to continue in the dirty checkout.
• Continue only after the user cleans, commits, or stashes the workspace and reruns `/implement-spec`.
• The dirty-workspace stop remains non-bypassable.

Implementation location precedence

• Resolve location only after readiness and workspace cleanliness checks pass; invocation constraints take precedence over any artifact location.
• If invocation constraints omit location, read an exact `## Implementation Location` section from the selected change's `design.md` using this canonical form:

## Implementation Location

- Strategy: `main` | `feature-branch` | `worktree`
- Reference: `<branch-name-or-worktree-path>`

• `Strategy` is required. `Reference` is optional for `main` and may be omitted for a new feature branch or worktree that the existing creation command will name and report.
• Treat a missing, blank, or unsupported `Strategy` as unresolved. Unless invocation constraints already resolved the conflict, ask the contributor to choose `main`, a feature branch, or a worktree and wait for the answer before creating or selecting a location.
• Do not silently guess a strategy and do not delegate implementation until the location is confirmed.
• If the confirmed strategy is a feature branch or worktree, apply the existing creation and conflict safeguards below and report the isolation strategy.
• Report the selected feature branch or worktree paths before delegating implementation.
• If the work is serial and the current checkout is not already a safe, suitable feature branch, execute `/create-feature-branch` before delegating implementation.
• If independent groups can run in parallel or need isolation, execute `/create-worktree` for each independent branch/worktree before delegating implementation.
• If the confirmed strategy is `main` or the repository default branch, warn about direct implementation there and require **separate explicit approval**