78 lines
2.4 KiB
Markdown
78 lines
2.4 KiB
Markdown
---
|
|
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.
|