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:
@@ -1,16 +1,16 @@
|
||||
---
|
||||
name: do-task
|
||||
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.
|
||||
---
|
||||
|
||||
# Do Task
|
||||
# Implement Task
|
||||
|
||||
**Phase:** 2 — Requirement Implementation
|
||||
**Role:** Developer
|
||||
|
||||
## When to invoke
|
||||
|
||||
- User says: "implement issue #X", "/do-task #X"
|
||||
- User says: "implement issue #X", "/implement-task #X"
|
||||
- Phase 1 is complete (issue has a "Final Requirements" comment from PO).
|
||||
|
||||
## Prerequisite
|
||||
@@ -75,6 +75,7 @@ description: Phase 2 skill. Use when issue scope is locked by Product Owner (Pha
|
||||
- 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.
|
||||
@@ -104,6 +104,8 @@ Validation:
|
||||
- Post review proactively if verdict is clear.
|
||||
- Mention validation commands you actually ran.
|
||||
- No bracketed author/tool tags.
|
||||
- Accept `docs/adr/**` when it records a direct, durable decision tied to the issue scope.
|
||||
- Treat `docs/superpowers/**` and other agent execution artifacts as scope creep. When rejecting docs, explain whether the content should be deleted entirely or rewritten as an ADR.
|
||||
|
||||
## What happens next
|
||||
- **PASS (APPROVED):** Developer merges the PR.
|
||||
|
||||
@@ -35,6 +35,7 @@ description: Phase 1 skill. Use when a Gitea issue is created or updated and nee
|
||||
- Stop. Wait for user to respond, then re-run this skill.
|
||||
- **Clear and feasible:**
|
||||
- Post Final Requirements (see format below).
|
||||
- If the change likely needs a durable ADR, add a note: "ADR recommended: this change locks in a behavior/contract that future work must preserve."
|
||||
- This locks the scope and signals Phase 2 can begin.
|
||||
|
||||
## Final Requirements format
|
||||
|
||||
Reference in New Issue
Block a user