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

name, description

name	description
do-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.

Do Task

Phase: 2 — Requirement Implementation Role: Developer

When to invoke

• User says: "implement issue #X", "/do-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.

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.
• 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.

Next skill

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