Enforce Issue Acceptance Criteria for Code Tasks

Creates GitHub issues as the single required tracking entrypoint for a new implementation task, with a hard gate: an issue with no explicit, testable acceptance criteria from the user stays Status: draft and execution is blocked. Every issue must include Problem, Goal, Scope, Non-Goals, Acceptance Criteria, Dependencies/Blockers, and Status (draft/ready/blocked/done) sections. Acceptance criteria only count as valid when they are testable and pass/fail checkable - "CreateCheckoutLambda-dev returns an openable third-party payment checkout URL" is valid, "fix checkout," "improve UX," or "make it better" are not. If criteria are missing or non-testable, the skill still creates the issue but sets Status: draft and Execution Gate: blocked (missing valid acceptance criteria), and does not move the task into execution.

• <explicit, testable criterion 1>

draft|ready|blocked|done

allowed|blocked ()

Default issue-creation mode is direct GitHub creation via `gh issue create` using this body template. Status is governed by explicit rules: `draft` for missing/weak acceptance criteria or an incomplete task definition, `ready` only once acceptance criteria are explicit and testable, `blocked` when an external dependency prevents progress, and `done` once acceptance criteria are verified with evidence - an issue is never marked `ready` without valid acceptance criteria.

Use it when starting a new implementation task and a GitHub issue needs to be the required tracking entrypoint, work must be blocked until the user supplies explicit, testable acceptance criteria, and execution needs to distinguish draft, ready, and blocked work before it begins. Downstream execution workflows (for example a closed-loop-delivery workflow) may only start once the issue's status is ready and its execution gate is allowed; if the issue is draft, the correct action is to stop and request acceptance criteria from the user, not to proceed anyway.

Input is the user's description of the problem, goal, and scope for a new task, and, ideally, explicit testable acceptance criteria. Output is a created GitHub issue following the required body template, with its Status and Execution Gate fields set according to whether valid acceptance criteria were supplied.

Uses the GitHub CLI (gh issue create) to create issues directly, and is designed to gate downstream execution workflows such as a closed-loop-delivery workflow, which may only begin once the created issue reaches ready/allowed.

Teams and agents that want every implementation task tracked as a GitHub issue and want execution structurally blocked until acceptance criteria are explicit and testable, rather than relying on someone remembering to check.