---
name: implement-task
description: Phase 2 skill. Use when issue scope is locked by Product Owner (Phase 1 done). Plan, implement, create PR, and own it until merged as Developer.
---

# Implement Task

**Phase:** 2 — Requirement Implementation
**Role:** Developer

## When to invoke

- User says: "implement issue #X", "/implement-task #X"
- Phase 1 is complete (issue has a "Final Requirements" comment from PO).

## Prerequisite

- Issue must have a **Final Requirements** comment locked by PO. If not found, stop and tell the user to run `/validate-issue` first.

## Workflow

1. **Load issue**
   - Read issue: `mcp__gitea__.issue_read` (`method: "get"`).
   - Read comments, find the **Final Requirements** comment: `mcp__gitea__.issue_read` (`method: "get_comments"`).
   - If Final Requirements not found → stop, tell user to validate issue first.
   - Read current Gitea user: `mcp__gitea__.get_me`.
   - If current user is not already in the issue assignee list, update the issue with `mcp__gitea__.issue_write` (`method: "update"`) and set `assignees` to the existing assignees plus the current username.

2. **Read codebase**
   - Use `mcp__gitea__.get_file_contents`, `mcp__gitea__.get_repository_tree` to understand current state.
   - Identify files and functions that need to change.

3. **Write plan and post on issue**
   - List implementation steps with verification criteria.
   - List files to change.
   - Flag risks or tradeoffs.
   - Post plan as comment: `mcp__gitea__.issue_write` (`method: "add_comment"`).
   - **Wait for "Approved" before coding.** Stop here.

4. **Implement** (only after plan is approved)
   - Create feature branch from `main`:
     ```
     git checkout main && git pull origin main
     git checkout -b feat/<short-description>
     ```
   - If currently on another branch, use worktree:
     ```
     git worktree add .worktrees/<branch-name> main
     ```
   - Implement following the plan (surgical changes only).
   - Run validation:
     ```
     gofmt -l .
     go vet ./...
     go test ./...
     ```

5. **Create PR**
   - Use `mcp__gitea__.pull_request_write` (`method: "create"`).
   - PR body must include:
     - Summary of changes
     - Test evidence (exact commands and output)
     - `Fixes #<issue-id>`
   - Add reviewer.

6. **Own the PR until merged**
   - Monitor for review feedback: `mcp__gitea__.pull_request_read` (`method: "get_reviews"`, `get_review_comments`).
   - When feedback arrives:
     - Checkout the PR branch (or use worktree if on another branch).
     - Fix code locally, commit, push.
     - Reply on PR: `mcp__gitea__.pull_request_review_write` (`method: "create"`, `state: "COMMENT"`) explaining what was fixed.
     - Never edit remote files directly via API.
   - After reviewer approves (APPROVED), merge the PR if user confirms.

## Rules
- Use Gitea MCP tools for all issue/PR operations.
- Preserve existing assignees when adding yourself unless the user explicitly asks to replace them.
- Never edit remote files directly — always work on local branch.
- Never claim completion without fresh verification output.
- Keep changes strictly scoped to the approved plan.
- If the change needs durable documentation, create/update `docs/adr/**`. Do not commit `docs/superpowers/**` planning artifacts.

## Next skill
After PR is created, the user invokes `/review-pr <pr-number>` on the Reviewer agent.