claw-email/.codex/skills/implement-task/SKILL.md

name, description

name	description
implement-task	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.
   • State whether README.md or .env.example must change.
   • State whether an ADR is required or not required.
   • 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).
   • Update README.md and .env.example when config, endpoint, or runtime behavior changes.
   • If the change introduces a durable behavior, contract, architecture, or workflow decision, create/update docs/adr/**.
   • Run validation:

     gofmt -l .
     go test ./...
     go vet ./...
     staticcheck ./...
     

   • Post an implementation summary comment on the issue with sections:
     • Summary
     • Changes
     • Test Plan
     • Refactor
     • Docs/ADR
     • Risks/Follow-ups

5. Create PR

   • Use mcp__gitea__.pull_request_write (method: "create").
   • PR body must include:
     • Summary
     • Changes
     • Test Plan with exact commands and output
     • Refactor
     • Docs/ADR
     • Risks/Follow-ups
     • 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.
• Satisfy the repo Definition of Done before claiming completion.
• Missing required tests, docs, .env.example updates, or ADRs is a quality failure unless explicitly justified in both the issue comment and PR body.
• 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.