claw-email/.codex/skills/validate-issue/SKILL.md

name, description

name	description
validate-issue	Phase 1 skill. Use when a Gitea issue is created or updated and needs requirement validation. Analyze, clarify, and lock scope as Product Owner. Do NOT implement.

Validate Issue

Phase: 1 — Requirement Refinement Role: Product Owner

When to invoke

• User says: "check issue #X", "validate issue #X", "/validate-issue #X"
• A new issue is created or an existing issue is updated with new information.

Prerequisite

• Issue exists on Gitea.

Workflow

1. Load issue

   • Read issue: mcp__gitea__.issue_read (method: "get").
   • Read comments: mcp__gitea__.issue_read (method: "get_comments").

2. Analyze

   • Is the problem statement clear?
   • Is the scope well-defined or too broad?
   • Is it technically feasible?
   • What acceptance criteria will prove the change is done?
   • Will the change require docs updates or a durable ADR?
   • If needed, read relevant code: mcp__gitea__.get_file_contents.

3. Decide

   • Unclear or incomplete:
     • Post clarifying questions: mcp__gitea__.issue_write (method: "add_comment").
     • Stop. Wait for user to respond, then re-run this skill.
   • Clear and feasible:
     • Post Final Requirements (see format below) with specific acceptance criteria.
     • State whether docs updates are expected.
     • State whether an ADR is required, recommended, or not needed.
     • If ADR is required or recommended, tell the Developer to use create-adr during implementation.
     • This locks the scope and signals Phase 2 can begin.

Final Requirements format

## Final Requirements

**Summary:** <one-line summary>

**Scope:**
- <requirement 1>
- <requirement 2>

**Out of scope:**
- <explicitly excluded items>

**Acceptance criteria:**
- <verifiable check 1>
- <verifiable check 2>

**Documentation impact:**
- <README.md / .env.example updates required or not required>

**ADR:**
- <required / recommended / not needed, with one-line reason>

Rules

• Use Gitea MCP tools for all operations.
• Do NOT write code, create branches, or create PRs.
• Make acceptance criteria specific enough that Dev and Reviewer can verify Definition of Done without guessing.
• Do NOT proceed to Phase 2 — that is a separate skill.

Next skill

After Final Requirements are posted, the user invokes /implement-task <issue-id> on the Developer agent.