/implement

name: implement
description: End-to-end workflow for taking MCP work items from backlog to merged PR. Handles git branching, schema-driven planning, implementation, independent review, and PR creation. Composes spec-quality, review-quality, and schema-workflow skills into a single pipeline. Use when a user says "implement this", "work on this item", "fix these bugs", "pick up the next task", "create a PR for this", "go through the backlog", or references specific MCP item IDs for implementation.
user-invocable: true

Implement

End-to-end workflow for taking MCP work items from queue to PR. This skill composes the schema-driven planning (spec-quality), implementation, review (review-quality), and git/PR workflow into a single pipeline.

**Usage:**

• `/implement <item-id>` — work on a specific item
• `/implement` — with context about what to work on
• Can process single items or multiple items in batch

---

Step 1 — Assess the Work

Load the item(s) and determine the execution tier and interaction mode.

For each item, call `get_context(itemId=...)` to understand:

• Current role and gate status
• Schema tag (feature-implementation, bug-fix, etc.)
• Existing notes already filled
• Dependencies and blocked status

When the user or an item references a PR or commit as already landed, verify its merge state before relying on it — `gh pr view <n> --json state,mergeCommit` plus `git log origin/main` — and confirm the working tree is current (Step 2, base-freshness precondition) before any pass that checks whether a change is present in the codebase.

**Execution tier** — classify by this table (canonical source shared with the `task-orchestrator:orchestrate` skill; edit the fragment, not this copy):

<!-- BEGIN GENERATED:tier-classification | source: claude-plugins/task-orchestrator/_fragments/tier-classification.md · regen: node claude-plugins/task-orchestrator/_fragments/generate.mjs --> | Criteria | Tier | Pipeline | |----------|------|----------| | 1-2 files, known fix, no migration/new API | **Direct** | Orchestrator edits, tests, reviews inline | | 3-10 files, single logical unit, clear or explorable scope | **Delegated** | Single subagent, separate review agent | | 11+ files, multiple independent work streams, dependency edges | **Parallel** | Worktree agents, full pipeline |

**Force-UP signals** (bump tier regardless of file count):

• Database migration → min Delegated
• New public API surface → min Delegated
• Multiple independent work streams → Parallel
• User says "let's plan" / collaborative language → min Delegated

**Force-DOWN signals:**

• User says "just fix it" / "quick" → Direct (unless complexity contradicts)
• Schema tag is `default` or absent → eligible for Direct

<!-- END GENERATED:tier-classification -->

Delegated with ≥2 ready items, or Parallel → run `/task-orchestrator:run-wave`.

If the item has no schema tag, apply `quick-fix` for Direct tier or leave untagged for Delegated/Parallel (the `default` schema catches these).

**Trait application on classification.** When the tier resolves to Delegated or Parallel and the workspace defines a `delegated` trait (it appears in `availableTraits` on create responses), apply it before any dispatch — `traits: "delegated"` at item creation, or `manage_items(operation="update", items=[{itemId: "<uuid>", traits: "delegated"}])` for an existing item. This makes the orchestrator-filled `delegation-metadata` note schema-visible instead of convention-only. Direct tier: do not apply it — nothing is delegated.

**Model-selection traits.** Seat dispatch defaults come from the `delegated` trait (planner `opus`, implementer `sonnet`, test-author `sonnet`, reviewer `opus`). Override them per item, at the same point:

• `complex-implementation` — implementer on `opus`. Apply for architecture-heavy or multi-file

synthesis work: new public API, cross-layer seams, subtle state machines or concurrency.

• `high-stakes` — planner and reviewer on `fable`. Apply sparingly, where a wrong plan or a missed

review finding is expensive: security predicates, auth, data-loss paths, hard-to-reverse design decisions. Fable draws on its own usage bucket, so it is never a default. `needs-security-review` does NOT imply it.

Read the resolved per-seat profile from `get_context` / `query_items(operation="schema")` (`dispatchBySeat`) and pass its `model` explicitly on the dispatch.

**Test-author trigger rule.** `bug-fix.default_traits` already includes `needs-test-author` — no action needed, it applies automatically. For `feature-task` items, apply `needs-test-author` per item (`manage_items(operation="update", items=[{itemId: "<uuid>", traits: "needs-test-author"}])`) when acceptance criteria involve a predicate, algorithm, parser, validator, or state transition, or when any force-ON signal is present: new public API surface, a database migration, a security predicate, or a prior vacuous-test finding in this item's area. Other schema tags (`feature-implementation`, `plugin-change`, `quick-fix`, and the global floor) do not carry the trait. Direct tier: apply the trait only in its **temporal-only degraded mode**, and only on bug-fixes — the `test-plan` gate and red-first rule still apply, `test-manifest` declares a single actor, and there is no separate test-author dispatch. Other Direct-tier items are exempt regardless of the criteria above — the tier is too small to separate authorship into a second dispatch.

**Interaction mode** — orthogonal to tier:

| Signal | Mode | |--------|------| | User says "work with me on", "let's plan", or similar collaborative language | **Collaborative** — user participates in planning and key decisions | | Scope is clear, no user participation needed | **Autonomous** — agent handles the pipeline | | Unclear scope or ambiguous complexity | **Ask the user** |

When processing multiple items, evaluate whether related items (e.g., bugs in the same module, fixes that touch the same files) should be grouped into