/implement

name: implement
description: Iterative development workflow that coordinates implementation, refactoring, QA, and documentation agents to complete features systematically. Use when the user wants a full development workflow with quality checks.
model: opus

Implement - Automated Development Workflow

Coordinates specialist agents through a complete development cycle: requirements -> planning -> implementation -> refactoring -> QA -> documentation.

Workflow

1. Receive and clarify requirements

**Gather requirements from user:**

• What feature/bug/change is being requested?
• What are the acceptance criteria?
• Any constraints or preferences?

**Ask clarifying questions if needed:**

• Ambiguous requirements
• Missing information
• Multiple valid approaches

Loop back to user until requirements are clear.

2. Planning (Conditional)

**Assess task complexity:**

After requirements are clear, assess whether planning is warranted:

**Invoke `swe-planner` agent for complex tasks:**

• Large architectural changes (refactoring entire subsystems, technology migrations)
• Cross-cutting concerns (multi-tenancy, i18n, audit logging)
• Features touching many modules with unclear implementation path
• Changes requiring database migrations and backward compatibility
• Multiple valid approaches with significant trade-offs
• Tasks where diving straight into implementation risks going down wrong path

**Skip planning for simple tasks:**

• Single-file changes or small bug fixes
• Straightforward CRUD operations
• Simple refactorings (rename, extract method, remove duplication)
• Clear, well-defined changes with obvious implementation path
• Tasks that can be completed in <100 lines of code

**Note:** `swe-planner` has a safety valve to exit early if invoked for a task simpler than assessed. If planner reports "planning not needed," proceed directly to implementation with planner's brief recommendation.

**If planning invoked:**

• `swe-planner` will produce implementation plan with ordered sub-tasks
• Each sub-task includes: What/Why/How/Verify/Risks
• Plan identifies risk areas (prototyping needs, user decisions, performance/security concerns)
• Plan applies YAGNI, emphasizes starting small and working incrementally

**Use plan to guide implementation:**

• Implementation agent should follow plan's sequencing
• Implement one sub-task at a time
• Verify each sub-task before moving to next
• If plan identifies prototyping needs, create scratch repos in `/tmp` first

3. Implementation

**Detect project language/framework:**

• Check for language-specific files (go.mod, package.json, Cargo.toml, Dockerfile, Makefile, etc.)
• Determine which specialist agent to use

**Spawn appropriate implementation agent:**

• If Dockerfile changes: spawn `swe-sme-docker` agent
• If Makefile changes: spawn `swe-sme-makefile` agent
• If Golang project: spawn `swe-sme-golang` agent
• If GraphQL schema/resolvers: spawn `swe-sme-graphql` agent
• If Ansible playbooks/roles: spawn `swe-sme-ansible` agent
• If Zig project: spawn `swe-sme-zig` agent
• If TypeScript project (`.ts` files, `tsconfig.json`): spawn `swe-sme-typescript` agent
• If vanilla JavaScript (`.js` files, no TypeScript): spawn `swe-sme-javascript` agent
• If HTML/markup changes: spawn `swe-sme-html` agent
• If CSS/styling changes: spawn `swe-sme-css` agent
• Otherwise: implement directly with general best practices

**Pass plan to implementation agent if planning was done:**

• Implementation agent should follow plan's sequencing
• Work incrementally through sub-tasks
• Verify each step as specified in plan

**Implementation agent responsibilities:**

• Write code following language idioms
• Follow project conventions
• Handle edge cases and errors
• Write unit tests for pure functions as part of TDD (encouraged, not just QA's job)
• If following plan: implement sub-tasks sequentially, verify each before proceeding

4. Quality Assurance - Verify Acceptance Criteria (CRITICAL GATE)

**Spawn `qa-engineer` agent:**

• Pass original requirements and acceptance criteria to the agent
• The agent infers its mode from context: presence of acceptance criteria triggers acceptance verification
• Agent performs **practical verification first** - actually running/using the feature to confirm it works
• This means: executing CLI commands, spawning subagents to test MCP tools, making API calls, etc.
• Only AFTER practical verification confirms the feature works does the agent write unit tests
• This prevents the failure mode of "passing unit tests for broken code"

**Practical verification by feature type:**

• CLI tools: Run commands in subshell (skip destructive operations)
• MCP servers/Claude skills: Spawn subagent to actually use the feature
• API integrations: Make actual calls (with caution for dangerous operations)
• Libraries: Quick sanity checks, then unit tests

**This is a CRITICAL GATE:**

• Implementation must demonstrably work (practical test) AND have tests to proceed
• If practical verification fails: return to step 3 (implementation) immediately
• If verification passes but tests fail: debug tests, not implementation
• Track iteration count (max 3 attempts before escalating to user)

**Expected output:** Practical verification results, integration test recommendations, pass/fail determination with specific findings about each acceptance criterion.

5. Code Review (Conditional)

**Only proceed to code review if acceptance verification passed.** Don't review broken code.

Conditionally invoke specialized reviewers based on code changes and complexity. All reviewers provide feedback; implementation agent responds to all feedback in step 6.

5a. Security Review (Conditional - Has Authority)

**If security-sensitive code changed (auth, crypto, input validation, data access):**

**Spawn `sec-blue-teamer` agent:**

• Evaluates defensive security posture of changed code
• Checks control consistency, defense-in-depth, and configuration
• Iden