104 lines
4.3 KiB
Markdown
104 lines
4.3 KiB
Markdown
---
|
|
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.
|
|
- State whether `README.md` or `.env.example` must change.
|
|
- State whether an ADR is required or not required.
|
|
- If ADR is required or recommended, invoke `create-adr` before finalizing the implementation summary and PR body.
|
|
- 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, use `create-adr` and 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, use `create-adr` and 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.
|