---
name: validate-issue
description: 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.