implement

What this skill does

# 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
- Identifies systemic gaps that enable vulnerability classes
- **Has authority to demand changes** - security issues should block or require explicit user approval

**Output**: Defense evaluation with severity levels (critical/high/low)

#### 5b. Refactoring Review (Conditional - Advisory)

**If non-trivial implementation (>50 lines changed, multiple files, or complex logic):**

**Spawn `swe-code-reviewer` agent:**
- Reviews implementation for code quality issues
- Identifies refactoring opportunities (DRY violations, dead code, complexity, etc.)
- Provides structured recommendations organized by priority
- Agent will report "No refactoring needed" if code is already clean

**Output**: Refactoring recommendations (advisory only)

#### 5c. Performance Review (Conditional - Advisory)

**If performance-critical code changed (hot paths, loops, database queries, API endpoints):**

**Spawn `swe-perf-reviewer` agent:**
- Reviews code for performance bottlenecks
- Identifies missing benchmarks and profiling gaps
- Provides optimization recommendations

**Output**: Performance metrics and recommendations (advisory only)

### 6. Implement Review Feedback

**Aggregate all review feedback from step 5 and provide to implementation agent.**

**If specialist was used in step 3 (swe-sme-golang, swe-sme-graphql, etc.):**
- Re-invoke the same specialist agent that did implementation
- Provide all review feedback (security, refactoring, performance)
- Specialist reviews all feedback and **uses own discretion** to implement
- **Security findings**: Must address or get explicit user approval to skip
- **Other feedback**: Advisory only - specialist has final authority
- Specialist may decline recommendations that conflict with language idioms
- Specialist implements accepted changes and commits

**If no specialist (general implementation):**
- Re-invoke the same agent that did implementation in step 3
- Provide all review feedback
- Agent addresses security issues and implements accepted recommendations
- Agent commits changes

**Note**: Security issues have authority to block; other feedback is advisory. Implementation agent makes final decisions on advisory feedback.

### 7. SME Peer Review (Conditional)

**Condition:** Non-trivial changes (>50 lines