Files
thuanleandClaude Opus 4.7 b013c68988
CI / fmt (pull_request) Successful in 4m56s
CI / test (pull_request) Successful in 10m49s
docs: add ADR workflow and update skills
- Add docs/adr/README.md with ADR format, rules, and index
- Add ADR-0001: IMAP thread resolution via In-Reply-To + References
- Add Documentation Rules section to AGENT.md
- Update validate-issue skill: flag ADR-requiring changes
- Rename do-task → implement-task for clearer semantics
- Update review-pr skill: accept docs/adr/, reject agent artifacts

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-04-28 05:47:37 +07:00

3.0 KiB

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