docs: add ADR workflow and update skills
CI / fmt (pull_request) Successful in 4m56s
CI / test (pull_request) Successful in 10m49s

- 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>
This commit is contained in:
2026-04-28 05:47:37 +07:00
co-authored by Claude Opus 4.7
parent cb2d158689
commit b013c68988
7 changed files with 127 additions and 4 deletions
+81
View File
@@ -0,0 +1,81 @@
---
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.
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.