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>
2.4 KiB
2.4 KiB
name, description, risk, source, date_added
| name | description | risk | source | date_added |
|---|---|---|---|---|
| create-issue-gate | Use when starting a new implementation task and an issue must be created with strict acceptance criteria gating before execution. | safe | community | 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, andblockedwork 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:
## 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 definitionready: acceptance criteria are explicit and testableblocked: external dependency prevents progressdone: 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.