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>
This commit is contained in:
Claude Opus 4.7
@@ -0,0 +1,53 @@
|
||||
---
|
||||
name: do-task
|
||||
description: Use when handling a Gitea issue/task end-to-end, including validation, planning, implementation, PR creation, and review-feedback iteration.
|
||||
---
|
||||
|
||||
# Do Task
|
||||
|
||||
## Overview
|
||||
Process a single Gitea issue from analysis to merge-ready PR with explicit decision gates. Prefer Gitea MCP tools for all issue/PR actions.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Load issue**
|
||||
- Read issue by ID from Gitea.
|
||||
- Extract: problem, expected behavior, impact, acceptance checks.
|
||||
|
||||
2. **Validate technical correctness**
|
||||
- Verify against current code/docs/tests.
|
||||
- Decide:
|
||||
- **Valid issue** -> continue to planning.
|
||||
- **Not valid / out of scope** -> comment rationale on issue and stop.
|
||||
|
||||
3. **If valid: plan and comment**
|
||||
- Create implementation plan using Superpowers planning flow.
|
||||
- Post summary plan to the issue before coding.
|
||||
|
||||
4. **Implement**
|
||||
- Use Superpowers execution flow (TDD + verification before completion).
|
||||
- Keep changes scoped strictly to issue requirements.
|
||||
|
||||
5. **Create PR**
|
||||
- Open PR from feature branch.
|
||||
- PR description must include:
|
||||
- Summary of changes
|
||||
- Test evidence (exact commands)
|
||||
- `Fixes #<issue-id>` (or `Closes #<issue-id>`)
|
||||
- Add reviewer: `codex`.
|
||||
|
||||
6. **Review feedback loop**
|
||||
- Read all feedback.
|
||||
- For each item:
|
||||
- If technically valid -> implement + re-test + reply.
|
||||
- If not valid -> reply with concise technical reasoning.
|
||||
- Do not blindly accept external feedback without verification.
|
||||
|
||||
## Required Rules
|
||||
- Use Gitea MCP tools first for issue/PR/review operations.
|
||||
- Do not use `tea` or other CLI Gitea clients unless MCP is unavailable.
|
||||
- Never claim completion without fresh verification output.
|
||||
|
||||
## Quick Command Pattern
|
||||
- Invoke as: `/do-task <issue-id>`
|
||||
- Example: `/do-task 12`
|
||||
@@ -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.
|
||||
Reference in New Issue
Block a user