docs: add AGENT.md workflow and local skills

- AGENT.md: role-based issue-driven workflow (PO → Dev → Reviewer)
- CLAUDE.md: points to AGENT.md
- .codex/skills/: validate-issue, do-task, review-pr with phase gates

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

.codex/skills/do-task/SKILL.codex.md

@@ -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`

.codex/skills/do-task/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: do-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
+
+**Phase:** 2 — Requirement Implementation
+**Role:** Developer
+
+## When to invoke
+
+- User says: "implement issue #X", "/do-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.
+
+## Next skill
+After PR is created, the user invokes `/review-pr <pr-number>` on the Reviewer agent.