메뉴
Implements a feature based on a provided technical specification, ensuring build stability and strict adherence to the spec through a sub-agent code review. Creates a feature branch, commits changes, and raises a PR on completion.
| name | implement-spec |
| description | Implements a feature based on a provided technical specification, ensuring build stability and strict adherence to the spec through a sub-agent code review. Creates a feature branch, commits changes, and raises a PR on completion. |
All paths are relative to the skill's base directory provided when you load the skill.
This skill guides you through implementing a feature defined in a Technical Specification file (usually in specs/). It mandates a strict workflow of Worktree Setup -> Analysis & Planning -> Implementation -> Verification -> Code Review -> QA Validation -> PR Creation.
Invoke the /setup-worktree skill to create an isolated worktree for this task. After the worktree is created, proceed to Analysis & Planning.
Read the Spec: Use the tool available to you for reading files to read the target technical specification artifact (e.g., specs/feature-name.md).
Understand Guardrails: Pay close attention to the "Goals", "Non-Goals", and "API Design" sections. These are your acceptance criteria.
Determine implementation approach:
These are not mutually exclusive — a full-stack change follows both, each for its part of the work.
After reading the spec, use whatever task/todo tool you have available to create todos combining skill workflow steps and feature work items. Create every todo before writing any code. They must cover both:
Only frontend work is suitable for parallelisation. Backend work (services, repositories, modules) must be implemented sequentially by the main agent following the TDD workflow.
Before writing any code, read the spec and identify independent work streams — frontend components, pages, hooks that don't depend on each other at compile time.
Shared dependencies first: any file that other streams will import (DTOs, types, base components, constants) must be implemented in the main session before parallel work begins.
Once shared dependencies exist, delegate frontend streams to subagents — up to a maximum of 2. Do not always spin up 2; use as many as the work genuinely calls for. Parallelise only if there are 2+ independent frontend work streams. If unsure or the spec is small, stick with sequential implementation.
For each subagent, provide:
Do not commit during subagent work. Subagents implement and return results. Review their output, apply any corrections, then commit everything together after verification.
Before moving to Step 3, confirm:
references/tdd.mdreferences/figma-to-code.mdCRITICAL: You must ensure the application builds successfully after your changes.
package.json scripts first. Look for build, type-check, or typecheck in that order. Use the first one found. Only fall back to running tsc directly if none exist.npm lint --fix or similar automation. This ensures only files in the spec are touched.Before communicating completion to the user, delegate code reviews to two sub-agents in parallel — one for feature correctness, one for code quality. Using sub-agents avoids bias from the implementing agent reviewing its own work.
Pass both sub-agents the list of files changed and the spec content. They return reports. Using the combined reports, ask yourself:
If you find discrepancies: Fix them now. Do not ask the user for permission to fix bugs you introduced. Once fixes are applied, send changes back to the sub-agent that flagged them — independently. Do not send correctness fixes to the code quality reviewer or vice versa. Use the same sub-agent instance, not a new one. If issues persist after this second pass, escalate to the user rather than looping further.
Determine which QA agents to spawn based on what the spec contains:
| Spec contains | Agent to spawn | Mode |
|---|---|---|
| Figma References section | UI validation sub-agent | UI validation only |
| QA Test Plan section | Test plan execution sub-agent | Test plan execution only |
| Both | Both sub-agents | In parallel |
| Neither | — | Skip this step entirely, go to PR Creation |
If neither condition is met, skip this step and proceed directly to PR Creation.
Provide:
/tmp/<feature-slug>/)Provide:
Review each agent's report:
If fixes require a second round of code review: only send the changed files back to the relevant code review sub-agent — not a full re-run of all agents.
Only once the build is clean, the code review passes, and QA validation passes (or was skipped):
Commit following Conventional Commits format. The type must match the branch prefix:
git add -A
git commit -m "<type>: <short imperative description>"
Examples: feat: add contractor onboarding flow, fix: correct invoice rounding logic
Push branch:
git push -u origin <branch-name>
Check if a PR already exists for this branch:
gh pr view <branch-name> --json url -q .url
gh pr create \
--base <base-branch> \
--title "<type>(<optional scope>): <short description>" \
--body "$(cat <<'EOF'
## Summary
<Goals from the spec>
## Changes Made
<Bullet list of files/modules touched>
## Code Review Report
<Combined output from both code review sub-agents>
## Test Plan
<From the spec's verification section, if present>
EOF
)"
Examples of PR titles: feat(onboarding): add contractor onboarding flow, fix(invoice): correct invoice rounding logic, docs: update API usage guide
Capture the PR URL from the output.
Fallback: If gh CLI is not available, warn the user, skip PR creation, and provide the branch name so they can open a PR manually.
Only when you are confident that:
gh is unavailable).Then notify the user with:
React composition patterns that scale. Use when refactoring components with boolean prop proliferation, building flexible component libraries, or designing reusable APIs. Triggers on tasks involving compound components, render props, context providers, or component architecture. Includes React 19 API changes.
Reviews code changes for correctness, quality, security, and rule compliance. Works on local files or a GitHub PR. Produces a structured report with severity levels and a pass/fail verdict.
Generates a technical specification document for a new feature or product.
QA skill for browser-based UI validation and functional test plan execution. Handles authentication and routes to the appropriate reference based on the task.
Sets up a Git worktree for a task or feature. Derives a branch name from the task description, creates an isolated worktree directory, copies env files, and installs dependencies. Use when starting work on a new feature or task in isolation.
Autonomously plans, specs, implements, and raises a PR for a task — without requiring the human to be present for the planning phase. Use this skill when the user hands off a task and asks you to handle it end-to-end, or when phrases like "auto-implement", "handle this autonomously", "fire and forget", or "work on this without me" appear. Also use when the user provides a task description and signals they want to review the output rather than participate in the planning.
