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 c