implement

Full implementation mode - end-to-end feature implementation with parallel agent orchestration

$ Installieren

git clone https://github.com/thoreinstein/opencode-config /tmp/opencode-config && cp -r /tmp/opencode-config/skill/implement ~/.claude/skills/opencode-config

// tip: Run this command in your terminal to install the skill


name: implement description: Full implementation mode - end-to-end feature implementation with parallel agent orchestration

IMPLEMENTATION MODE

Current Time: !date Go Version: !go version

Execute a complete feature implementation using coordinated agent swarms.


MANDATORY: Roadmap Plugin Usage (NON-NEGOTIABLE)

You MUST use the roadmap plugin (createroadmap, readroadmap, updateroadmap) to:

  1. Define all phases BEFORE any implementation work begins
  2. Track phase status โ€” mark in_progress when starting, completed when done
  3. Gate phase transitions โ€” do NOT proceed to next phase until current phase is committed
  4. Archive roadmap โ€” delete/archive when implementation is complete

Phase Execution Loop (NON-NEGOTIABLE)

Every phase follows this exact sequence:

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚  PHASE EXECUTION LOOP                                       โ”‚
โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค
โ”‚                                                             โ”‚
โ”‚   1. PLAN     โ†’ Define work for this phase                  โ”‚
โ”‚                 Call: updateroadmap(status="in_progress")   โ”‚
โ”‚                                                             โ”‚
โ”‚   2. WORK     โ†’ Execute the phase work                      โ”‚
โ”‚                 Delegate to appropriate specialists         โ”‚
โ”‚                                                             โ”‚
โ”‚   3. VERIFY   โ†’ Run verification checklist                  โ”‚
โ”‚                 Tests pass, lints clean, build succeeds     โ”‚
โ”‚                                                             โ”‚
โ”‚   4. COMMIT   โ†’ Invoke commit skill                         โ”‚
โ”‚                 /commit (or load commit skill)              โ”‚
โ”‚                 Call: updateroadmap(status="completed")     โ”‚
โ”‚                                                             โ”‚
โ”‚   5. PROCEED  โ†’ Only after commit succeeds                  โ”‚
โ”‚                 Move to next phase                          โ”‚
โ”‚                                                             โ”‚
โ”‚   โš ๏ธ  DO NOT PROCEED TO NEXT PHASE UNTIL COMMIT SUCCEEDS    โ”‚
โ”‚                                                             โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

Implementation Protocol

Phase 1: Requirements Analysis

PLAN: Gather context and define scope.

  1. Gather Context
background_task(agent="explore", prompt="Find existing patterns for...")
background_task(agent="explore", prompt="Find related code that might be affected...")
background_task(agent="librarian", prompt="Research best practices for...")
  1. Clarify Requirements
  • What exactly needs to be built?
  • What are the acceptance criteria?
  • What constraints exist?
  • What patterns should be followed?
  1. Create Roadmap (MANDATORY)

Use createroadmap to define ALL phases with actions:

createroadmap(
  feature="Feature Name",
  spec="High-level specification...",
  features=[
    { number: "1", title: "Phase 1", description: "...", actions: [...] },
    { number: "2", title: "Phase 2", description: "...", actions: [...] },
    ...
  ]
)

Each phase MUST include a final action for commit:

{ number: "X.99", description: "Commit phase X changes via commit skill", status: "pending" }

WORK: N/A for this phase (planning only).

VERIFY: Roadmap created, requirements clear.

COMMIT: Use commit skill to commit any planning artifacts.

PROCEED: Only after commit succeeds.


Phase 2: Architecture Decision (If Needed)

PLAN: Mark phase in_progress via updateroadmap.

WORK: For significant features, consult:

@architect Design the architecture for:
- [Feature description]
- Constraints: [list]
- Expected scale: [numbers]

Or for simpler decisions:

@principal Quick architecture gut check:
- [Approach description]
- [Alternative considered]

VERIFY: Architecture documented, decisions recorded.

COMMIT: Use commit skill to commit architecture docs/decisions.

PROCEED: Only after commit succeeds.


Phase 3: Parallel Implementation

PLAN: Mark phase in_progress. Identify parallel work streams.

WORK: Deploy domain specialists in parallel where independent:

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚  PARALLEL IMPLEMENTATION SWARM                              โ”‚
โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค
โ”‚  BACKEND                     โ”‚  FRONTEND                    โ”‚
โ”‚  โ”œโ”€ @go (Go APIs/CLIs)       โ”‚  โ””โ”€ @frontend (UI)           โ”‚
โ”‚  โ”œโ”€ @postgres (schema)       โ”‚                              โ”‚
โ”‚  โ”œโ”€ @redis (redis)           โ”‚                              โ”‚
โ”‚  โ”œโ”€ @gcp-dev (google apis)   โ”‚                              โ”‚
โ”‚  โ””โ”€ @linux (shell scripts)   โ”‚                              โ”‚
โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ผโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค
โ”‚  INFRASTRUCTURE              โ”‚  QUALITY                     โ”‚
โ”‚  โ”œโ”€ @k8s (manifests)         โ”‚  โ”œโ”€ @testing (test strategy) โ”‚
โ”‚  โ”œโ”€ @terraform (IaC)         โ”‚  โ”œโ”€ @security (security)     โ”‚
โ”‚  โ”œโ”€ @cicd (pipelines)        โ”‚  โ”œโ”€ @perf (performance)      โ”‚
โ”‚  โ”œโ”€ @nix (Nix configs)       โ”‚  โ”œโ”€ @sre (reliability)       โ”‚
โ”‚  โ”œโ”€ @finops (architecture)   โ”‚  โ”œโ”€ @a11y (accessibility)    โ”‚
โ”‚  โ”œโ”€ @gcp-architect (gcp)     โ”‚  โ”œโ”€ @chaos (experiments)     โ”‚
โ”‚  โ””โ”€ @security (entsec)       โ”‚  โ”œโ”€ @o11y (observability)    โ”‚
โ”‚                              โ”‚  โ””โ”€ @e2e (end to end tests)  โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

VERIFY: All implementation work complete, tests written.

COMMIT: Use commit skill to commit all implementation changes.

PROCEED: Only after commit succeeds.


Phase 4: Integration

PLAN: Mark phase in_progress.

WORK:

  1. Integrate components
  2. Resolve any conflicts
  3. Ensure consistency across modules

VERIFY: Integration tests pass, no conflicts.

COMMIT: Use commit skill to commit integration changes.

PROCEED: Only after commit succeeds.


Phase 5: Verification

PLAN: Mark phase in_progress.

WORK: Run full verification checklist:

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚  VERIFICATION CHECKLIST                                     โ”‚
โ”œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ค
โ”‚  [ ] lsp_diagnostics clean on all changed files             โ”‚
โ”‚  [ ] Tests pass (go test / npm test / etc.)                 โ”‚
โ”‚  [ ] Linter passes (golangci-lint / eslint)                 โ”‚
โ”‚  [ ] Build succeeds                                         โ”‚
โ”‚  [ ] Security review if needed (@security)                  โ”‚
โ”‚  [ ] Performance acceptable                                 โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

VERIFY: All checks pass.

COMMIT: Use commit skill to commit any verification fixes.

PROCEED: Only after commit succeeds.


Phase 6: Documentation & Cleanup

PLAN: Mark phase in_progress.

WORK:

  • Update relevant documentation
  • Clean up TODO list
  • Cancel all background tasks
  • Summarize what was implemented

VERIFY: Documentation complete, no orphaned tasks.

COMMIT: Use commit skill to commit documentation.

CLEANUP (MANDATORY):

  • Archive or delete the roadmap file
  • Mark all roadmap actions as completed via updateroadmap
  • Confirm no uncommitted changes remain

Implementation Output

At completion, provide:

## Implementation Summary

### What Was Built

[Brief description of the feature]

### Files Changed

- `path/to/file.go` โ€” [what changed]
- `path/to/file.go` โ€” [what changed]

### Architecture Decisions

[Key decisions made and rationale]

### Testing

- [Tests added]
- [Coverage notes]

### Verification

- [ ] All diagnostics clean
- [ ] Tests passing
- [ ] Build succeeds

### Commits Made

- [Commit hash] โ€” [Phase X: description]
- [Commit hash] โ€” [Phase Y: description]

### Known Limitations

[Any constraints or future work]

### Next Steps

[Follow-up tasks if any]

Output

Write to Obsidian via obsidian_append_content at: $OBSIDIAN_PATH/Implementations/YYYY-MM-DD-feature-name.md

Note: $OBSIDIAN_PATH must be a vault-relative path (e.g., Projects/myapp), set per-project via direnv. The obsidian_append_content tool expects paths relative to the vault root.

Document Structure

Use this template for the Obsidian document:

@~/.config/opencode/templates/implementation-summary.md

Implement

$ARGUMENTS