update DoD

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

@@ -27,6 +27,8 @@ description: Phase 1 skill. Use when a Gitea issue is created or updated and nee
    - 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**
@@ -34,8 +36,9 @@ description: Phase 1 skill. Use when a Gitea issue is created or updated and nee
      - 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).
-     - 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."
+     - 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.
      - This locks the scope and signals Phase 2 can begin.
 
 ## Final Requirements format
@@ -55,11 +58,18 @@ description: Phase 1 skill. Use when a Gitea issue is created or updated and nee
 **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