Enforce Issue Acceptance Criteria for Code Tasks

This skill turns a task request into a GitHub issue that cannot proceed to execution without explicit, testable acceptance criteria. When the user has not supplied criteria that are testable and pass/fail checkable, the resulting issue is left in draft status and blocked from execution rather than allowed to move forward on vague intent.

Every issue must carry seven fixed sections in order - Problem, Goal, Scope, Non-Goals, Acceptance Criteria, Dependencies/Blockers, and Status (draft, ready, blocked, or done). A criterion only counts as valid acceptance criteria when it is testable and checkable pass/fail, not phrases like "fix checkout" or "improve UX" that offer no way to verify satisfaction.

Where criteria are missing or too vague to test, the issue is still opened, but Status is set to draft and an "Execution Gate: blocked (missing valid acceptance criteria)" line is added, halting any handoff to execution. Issues are opened directly through the GitHub CLI via gh issue create, populated from a fixed body template that keeps every issue the skill produces in the same shape.

Use this skill when starting a new implementation task and you want a GitHub issue to act as the required tracking entrypoint before any code gets written, or whenever work must be blocked until the user supplies explicit, testable acceptance criteria rather than a vague description of intent. It is also the right tool when you need a consistent, mechanical way to distinguish draft, ready, and blocked work before execution begins, instead of relying on a person's judgment call each time.

Do not use it as a substitute for environment-specific validation, testing, or expert review - creating a well-gated issue says nothing about whether the eventual implementation is correct or safe. The skill is explicitly scoped: it should only be used when the task clearly matches the issue-gating scope described above, not as a general-purpose project management tool. If required inputs, permissions, safety boundaries, or success criteria are missing, the skill is designed to stop and ask the user for clarification rather than guess and proceed.

The input is a task description from the user, which may or may not already include candidate acceptance criteria. The output is a GitHub issue created via gh issue create, following this required body template:

### Problem
<what is broken or missing>

### Goal
<what outcome is expected>

### Scope
- <in scope item>

### Non-Goals
- <out of scope item>

### Acceptance Criteria
- <explicit, testable criterion 1>

### Dependencies/Blockers
- <dependency or none>

### Status
draft|ready|blocked|done

### Execution Gate
allowed|blocked (<reason>)

with the Status and Execution Gate fields set according to whether valid, testable acceptance criteria were actually supplied. The Status field follows fixed rules: draft means the acceptance criteria are missing or weak, or the task definition is incomplete; ready means the acceptance criteria are explicit and testable; blocked means an external dependency is preventing progress; and done means the acceptance criteria have been verified with evidence, not just marked complete. An issue is never marked ready without valid acceptance criteria, even if everything else about the task looks complete - the gate is on the criteria specifically, not on the surrounding description quality.

Issue creation runs entirely through the GitHub CLI (gh issue create), so the skill assumes gh is installed and authenticated against the target repository. Downstream execution workflows - the source names closed-loop-delivery as an example - may start only when the issue's status is ready and its execution gate is explicitly allowed. If the issue is still draft, execution stops and the user is asked to provide acceptance criteria before anything proceeds, keeping the gate enforced at the handoff boundary rather than left to the executing workflow to check.

Engineers and teams who want every implementation task to pass through a single GitHub issue with enforced, testable acceptance criteria before execution can begin. It is particularly useful for anyone who has been burned by vague or underspecified tickets turning into open-ended work, since the skill mechanically refuses to let a task reach ready or done status without criteria that can actually be checked pass or fail.