ef285b5c97
* fix: stabilize validation and tests on Windows * test: add Windows smoke coverage for skill activation * refactor: make setup_web script CommonJS * fix: repair aegisops-ai frontmatter * docs: add when-to-use guidance to core skills * docs: add when-to-use guidance to Apify skills * docs: add when-to-use guidance to Google and Expo skills * docs: add when-to-use guidance to Makepad skills * docs: add when-to-use guidance to git workflow skills * docs: add when-to-use guidance to fp-ts skills * docs: add when-to-use guidance to Three.js skills * docs: add when-to-use guidance to n8n skills * docs: add when-to-use guidance to health analysis skills * docs: add when-to-use guidance to writing and review skills * meta: sync generated catalog metadata * docs: add when-to-use guidance to Robius skills * docs: add when-to-use guidance to review and workflow skills * docs: add when-to-use guidance to science and data skills * docs: add when-to-use guidance to tooling and automation skills * docs: add when-to-use guidance to remaining skills * fix: gate bundle helper execution in Windows activation * chore: drop generated artifacts from contributor PR * docs(maintenance): Record PR 457 sweep Document the open issue triage, PR supersedence decision, local verification, and source-only cleanup that prepared PR #457 for re-running CI. --------- Co-authored-by: sickn33 <sickn33@users.noreply.github.com>
96 lines
2.4 KiB
Markdown
96 lines
2.4 KiB
Markdown
---
|
|
name: create-issue-gate
|
|
description: Use when starting a new implementation task and an issue must be created with strict acceptance criteria gating before execution.
|
|
risk: safe
|
|
source: community
|
|
date_added: "2026-03-12"
|
|
---
|
|
|
|
# Create Issue Gate
|
|
|
|
## Overview
|
|
|
|
Create GitHub issues as the single tracking entrypoint for tasks, with a hard gate on acceptance criteria.
|
|
|
|
Core rule: **no explicit, testable acceptance criteria from user => issue stays `draft` and execution is blocked.**
|
|
|
|
## When to Use
|
|
|
|
- You are starting a new implementation task and want a GitHub issue to be the required tracking entrypoint.
|
|
- The work must be blocked until the user provides explicit, testable acceptance criteria.
|
|
- You need to distinguish between `draft`, `ready`, and `blocked` work before execution begins.
|
|
|
|
## Required Fields
|
|
|
|
Every issue must include these sections:
|
|
- Problem
|
|
- Goal
|
|
- Scope
|
|
- Non-Goals
|
|
- Acceptance Criteria
|
|
- Dependencies/Blockers
|
|
- Status (`draft` | `ready` | `blocked` | `done`)
|
|
|
|
## Acceptance Criteria Gate
|
|
|
|
Acceptance criteria are valid only when they are testable and pass/fail checkable.
|
|
|
|
Examples:
|
|
- valid: "CreateCheckoutLambda-dev returns an openable third-party payment checkout URL"
|
|
- invalid: "fix checkout" / "improve UX" / "make it better"
|
|
|
|
If criteria are missing or non-testable:
|
|
- still create the issue
|
|
- set `Status: draft`
|
|
- add `Execution Gate: blocked (missing valid acceptance criteria)`
|
|
- do not move task to execution
|
|
|
|
## Issue Creation Mode
|
|
|
|
Default mode is direct GitHub creation using `gh issue create`.
|
|
|
|
Use a body template like:
|
|
|
|
```md
|
|
## 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>)
|
|
```
|
|
|
|
## Status Rules
|
|
|
|
- `draft`: missing/weak acceptance criteria or incomplete task definition
|
|
- `ready`: acceptance criteria are explicit and testable
|
|
- `blocked`: external dependency prevents progress
|
|
- `done`: acceptance criteria verified with evidence
|
|
|
|
Never mark an issue `ready` without valid acceptance criteria.
|
|
|
|
## Handoff to Execution
|
|
|
|
Execution workflows (for example `closed-loop-delivery`) may start only when:
|
|
- issue status is `ready`
|
|
- execution gate is `allowed`
|
|
|
|
If issue is `draft`, stop and request user-provided acceptance criteria.
|