thuanleandClaude Opus 4.7
b013c68988
- 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>
54 lines
1.7 KiB
Markdown
54 lines
1.7 KiB
Markdown
---
|
|
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`
|