spec-implement

Files (1)

• SKILL.md

SKILL.md (first lines)

# Spec Implement

Execute the approved Spec-backed Plan. Track progress when it uses tracked tasks. Report. Stop
when blocked.

**Announce at start:** "I'm using the spec-implement skill to execute this plan."

This skill does not make design decisions or change approved content. It may persist approved
content from the conversation when Plan Mode could not write the required artifact. If the plan
is wrong, go back to spec-plan. If the design is wrong, go back to spec-brainstorm.

## Prerequisites

Resolve required artifacts in order before starting product implementation:

1. If `docs/specs/YYYY-MM-DD-<feature>/design.md` is missing, write it from the approved design
   in the current conversation. Validate the file, report its path, and stop. Do not create
   `plan.json` or start implementation in the same invocation.
2. Otherwise, if `docs/specs/YYYY-MM-DD-<feature>/plan.json` is missing, write it from the
   approved plan in the current conversation. Validate it against the schema in `spec-plan`,
   report its path, and stop. Do not start implementation in the same invocation.
3. If the approved content needed for the next missing artifact is not available in the current
   conversation, stop and tell the human what content is unavailable. Do not ask the human to
   create the file.
4. When both artifacts exist, verify that any tracker entries selected during planning are
   available, along with `docs/agents/issue-tracker.md` when tracking is configured.
5. Verify that you are not on main/master without explicit user consent. Create a branch or use
   a git worktree first.

Each invocation creates at most one missing artifact. Only proceed to product implementation
when both approved artifacts existed at the start of the invocation.

---

## Step 1: Load and Review the Plan

Read plan.json critically before writing code. Look for:

- Unclear or ambiguous tasks
- Missing file paths or incomplete validation criteria
- Tasks that conflict with each other
- Dependencies that don't match what you see in the codebase
- Existing code or platform behavior that already satisfies a planned capability
- Duplicate IDs, parsers, errors, schemas, lifecycle handling, or test utilities
- Shared abstractions with fewer than two current consumers
- Tests whose only purpose is validating a new wrapper

If planned machinery fails these checks, stop before implementing it and return to
`spec-plan` with a smaller revision for human review. Preserve the approved behavior and scope;
do not force an unsupported structure through implementation.

For other concerns, **raise them with the human before starting**. Don't guess. Don't assume.
Don't force through blockers.

If no concerns, proceed. Use existing tracker entries when present.

---

## Step 2: Choose Execution Style

If the human has not specified an execution style, ask.

### Autonomous Mode

> "Implement it all. Don't stop until you're done."

- Execute all tasks in dependency order
- Track progress when the Spec-backed Plan has tracker entries
- Run type checking / linting continuously
- Only stop if blocked
- To run unattended to a draft PR, use **spec-loop**

### Batched Mode (default)

> "Do a few tasks at a time."

- Execute 3-5 tasks
- Stop and report: what was done, test output, anything unexpected
- Wait for human feedback before continuing

### Delegation (all modes)

In any mode, delegate a task to a fresh subagent when **the design is already settled and the
file just needs to be made**, as defined by the **code-subagents** "When to Use" criteria.

- Invoke **code-subagents** for eligibility, dispatch patterns, and the implementer template
- Paste the relevant design excerpt into the dispatch so the subagent makes no design decisions
- Select the agent explicitly (see Delegation in `atelier-orchestrator`)
- Keep coupled, exploratory, or design-sensitive tasks in the main thread
- The main agent runs the combined plan and code-quality review per completed batch, and the
  validation commands itself

### Subagent Mode

> "Use subagents."

Delegate every eligible task. Independent tasks dispatch in parallel, dependent tasks run
sequentially.

Default to batched if the human hasn't expressed a preference; delegation still applies per
task.

---

## Step 3: Execute the Plan

Preserve the approved behavior and scope. Treat the plan's proposed structure as a hypothesis
that must remain supported by repository evidence.

For each task, find the next unblocked task directly from `plan.json`. When tracker entries
exist, use `docs/agents/issue-tracker.md` to keep their execution state in sync; tracker state
never overrides the plan's dependency graph.

When a tracker exists, mark it in progress according to `docs/agents/issue-tracker.md`.

### For each task

Read the task's **inputs** and **description** first.

From martinffx/atelier, MIT.

More from martinffx/atelier