Add acceptance-driven workflow skills (#277)
* add acceptance-driven workflow skills * chore: sync acceptance workflow skills metadata --------- Co-authored-by: sck_0 <samujackson1337@gmail.com>
This commit is contained in:
JX2E
GitHub
@@ -2,7 +2,7 @@
|
||||
|
||||
Generated at: 2026-02-08T00:00:00.000Z
|
||||
|
||||
Total skills: 1246
|
||||
Total skills: 1249
|
||||
|
||||
## architecture (80)
|
||||
|
||||
@@ -600,7 +600,7 @@ no matching field, parse error, widget... | makepad, reference | makepad, refere
|
||||
| `zod-validation-expert` | Expert in Zod — TypeScript-first schema validation. Covers parsing, custom errors, refinements, type inference, and integration with React Hook Form, Next.js... | zod, validation | zod, validation, typescript, first, schema, covers, parsing, custom, errors, refinements, type, inference |
|
||||
| `zustand-store-ts` | Create Zustand stores with TypeScript, subscribeWithSelector middleware, and proper state/action separation. Use when building React state management, creati... | zustand, store, ts | zustand, store, ts, stores, typescript, subscribewithselector, middleware, proper, state, action, separation, building |
|
||||
|
||||
## general (295)
|
||||
## general (296)
|
||||
|
||||
| Skill | Description | Tags | Triggers |
|
||||
| --- | --- | --- | --- |
|
||||
@@ -672,6 +672,7 @@ no matching field, parse error, widget... | makepad, reference | makepad, refere
|
||||
| `context-optimization` | This skill should be used when the user asks to "optimize context", "reduce token costs", "improve context efficiency", "implement KV-cache optimization", "p... | optimization | optimization, context, skill, should, used, user, asks, optimize, reduce, token, costs, improve |
|
||||
| `cpp-pro` | Write idiomatic C++ code with modern features, RAII, smart pointers, and STL algorithms. Handles templates, move semantics, and performance optimization. | cpp | cpp, pro, write, idiomatic, code, features, raii, smart, pointers, stl, algorithms, move |
|
||||
| `create-branch` | Create a git branch following Sentry naming conventions. Use when asked to "create a branch", "new branch", "start a branch", "make a branch", "switch to a n... | create, branch | create, branch, git, following, sentry, naming, conventions, asked, new, start, switch, starting |
|
||||
| `create-issue-gate` | Use when starting a new implementation task and an issue must be created with strict acceptance criteria gating before execution. | create, issue, gate | create, issue, gate, starting, new, task, must, created, strict, acceptance, criteria, gating |
|
||||
| `daily` | Documentation and capabilities reference for Daily | daily | daily, documentation, capabilities, reference |
|
||||
| `daily-news-report` | Scrapes content based on a preset URL list, filters high-quality technical information, and generates daily Markdown reports. | daily, news, report | daily, news, report, scrapes, content, preset, url, list, filters, high, quality, technical |
|
||||
| `debugging-strategies` | Master systematic debugging techniques, profiling tools, and root cause analysis to efficiently track down bugs across any codebase or technology stack. Use ... | debugging, strategies | debugging, strategies, systematic, techniques, profiling, root, cause, analysis, efficiently, track, down, bugs |
|
||||
@@ -918,10 +919,11 @@ matrix-sdk, matrix client, robrix, mat... | robius, matrix, integration | robius
|
||||
| `yann-lecun-tecnico` | Sub-skill técnica de Yann LeCun. Cobre CNNs, LeNet, backpropagation, JEPA (I-JEPA, V-JEPA, MC-JEPA), AMI (Advanced Machinery of Intelligence), Self-Supervise... | persona, cnn, jepa, self-supervised, pytorch | persona, cnn, jepa, self-supervised, pytorch, yann, lecun, tecnico, sub, skill, cnica, de |
|
||||
| `youtube-summarizer` | Extract transcripts from YouTube videos and generate comprehensive, detailed summaries using intelligent analysis frameworks | [video, summarization, transcription, youtube, content-analysis] | [video, summarization, transcription, youtube, content-analysis], summarizer, extract, transcripts, videos, generate, detailed, summaries |
|
||||
|
||||
## infrastructure (132)
|
||||
## infrastructure (134)
|
||||
|
||||
| Skill | Description | Tags | Triggers |
|
||||
| --- | --- | --- | --- |
|
||||
| `acceptance-orchestrator` | Use when a coding task should be driven end-to-end from issue intake through implementation, review, deployment, and acceptance verification with minimal hum... | acceptance, orchestrator | acceptance, orchestrator, coding, task, should, driven, issue, intake, through, review, deployment, verification |
|
||||
| `agent-evaluation` | Testing and benchmarking LLM agents including behavioral testing, capability assessment, reliability metrics, and production monitoring—where even top agents... | agent, evaluation | agent, evaluation, testing, benchmarking, llm, agents, including, behavioral, capability, assessment, reliability, metrics |
|
||||
| `airflow-dag-patterns` | Build production Apache Airflow DAGs with best practices for operators, sensors, testing, and deployment. Use when creating data pipelines, orchestrating wor... | airflow, dag | airflow, dag, apache, dags, operators, sensors, testing, deployment, creating, data, pipelines, orchestrating |
|
||||
| `api-testing-observability-api-mock` | You are an API mocking expert specializing in realistic mock services for development, testing, and demos. Design mocks that simulate real API behavior and e... | api, observability, mock | api, observability, mock, testing, mocking, specializing, realistic, development, demos, mocks, simulate, real |
|
||||
@@ -961,6 +963,7 @@ scripts. | bash | bash, pro, defensive, scripting, automation, ci, cd, pipelines
|
||||
| `cicd-automation-workflow-automate` | You are a workflow automation expert specializing in creating efficient CI/CD pipelines, GitHub Actions workflows, and automated development processes. Desig... | cicd, automate | cicd, automate, automation, specializing, creating, efficient, ci, cd, pipelines, github, actions, automated |
|
||||
| `claude-d3js-skill` | Creating interactive data visualisations using d3.js. This skill should be used when creating custom charts, graphs, network diagrams, geographic visualisati... | claude, d3js, skill | claude, d3js, skill, creating, interactive, data, visualisations, d3, js, should, used, custom |
|
||||
| `claude-monitor` | Monitor de performance do Claude Code e sistema local. Diagnostica lentidao, mede CPU/RAM/disco, verifica API latency e gera relatorios de saude do sistema. | monitoring, performance, diagnostics, system-health | monitoring, performance, diagnostics, system-health, claude, monitor, de, do, code, sistema, local, diagnostica |
|
||||
| `closed-loop-delivery` | Use when a coding task must be completed against explicit acceptance criteria with minimal user re-intervention across implementation, review feedback, deplo... | closed, loop, delivery | closed, loop, delivery, coding, task, must, completed, against, explicit, acceptance, criteria, minimal |
|
||||
| `cloud-architect` | Expert cloud architect specializing in AWS/Azure/GCP multi-cloud infrastructure design, advanced IaC (Terraform/OpenTofu/CDK), FinOps cost optimization, and ... | cloud | cloud, architect, specializing, aws, azure, gcp, multi, infrastructure, iac, terraform, opentofu, cdk |
|
||||
| `cloud-devops` | Cloud infrastructure and DevOps workflow covering AWS, Azure, GCP, Kubernetes, Terraform, CI/CD, monitoring, and cloud-native development. | cloud, devops | cloud, devops, infrastructure, covering, aws, azure, gcp, kubernetes, terraform, ci, cd, monitoring |
|
||||
| `code-review-ai-ai-review` | You are an expert AI-powered code review specialist combining automated static analysis, intelligent pattern recognition, and modern DevOps practices. Levera... | code, ai | code, ai, review, powered, combining, automated, static, analysis, intelligent, recognition, devops, leverage |
|
||||
|
||||
12
README.md
12
README.md
@@ -1,7 +1,7 @@
|
||||
<!-- registry-sync: version=7.5.0; skills=1246; stars=23194; updated_at=2026-03-11T15:21:11+00:00 -->
|
||||
# 🌌 Antigravity Awesome Skills: 1,246+ Agentic Skills for Claude Code, Gemini CLI, Cursor, Copilot & More
|
||||
<!-- registry-sync: version=7.5.0; skills=1249; stars=23495; updated_at=2026-03-12T11:15:03+00:00 -->
|
||||
# 🌌 Antigravity Awesome Skills: 1,249+ Agentic Skills for Claude Code, Gemini CLI, Cursor, Copilot & More
|
||||
|
||||
> **The Ultimate Collection of 1,246+ Universal Agentic Skills for AI Coding Assistants — Claude Code, Gemini CLI, Codex CLI, Antigravity IDE, GitHub Copilot, Cursor, OpenCode, AdaL**
|
||||
> **The Ultimate Collection of 1,249+ Universal Agentic Skills for AI Coding Assistants — Claude Code, Gemini CLI, Codex CLI, Antigravity IDE, GitHub Copilot, Cursor, OpenCode, AdaL**
|
||||
|
||||
[](https://github.com/sickn33/antigravity-awesome-skills/stargazers)
|
||||
[](LICENSE)
|
||||
@@ -18,7 +18,7 @@
|
||||
[](apps/web-app)
|
||||
[](https://buymeacoffee.com/sickn33)
|
||||
|
||||
**Antigravity Awesome Skills** is a curated, battle-tested library of **1,246+ high-performance agentic skills** designed to work seamlessly across the major AI coding assistants.
|
||||
**Antigravity Awesome Skills** is a curated, battle-tested library of **1,249+ high-performance agentic skills** designed to work seamlessly across the major AI coding assistants.
|
||||
|
||||
**Welcome to the V7.4.0 Release!** This repository gives your agent reusable playbooks for planning, coding, debugging, testing, security review, infrastructure work, product thinking, and much more.
|
||||
|
||||
@@ -32,7 +32,7 @@
|
||||
- [🎁 Curated Collections (Bundles)](#curated-collections)
|
||||
- [🧭 Antigravity Workflows](#antigravity-workflows)
|
||||
- [📦 Features & Categories](#features--categories)
|
||||
- [📚 Browse 1,246+ Skills](#browse-1246-skills)
|
||||
- [📚 Browse 1,249+ Skills](#browse-1249-skills)
|
||||
- [🤝 How to Contribute](#how-to-contribute)
|
||||
- [💬 Community](#community)
|
||||
- [☕ Support the Project](#support-the-project)
|
||||
@@ -282,7 +282,7 @@ The repository is organized into specialized domains to transform your AI into a
|
||||
|
||||
Counts change as new skills are added. For the current full registry, see [CATALOG.md](CATALOG.md).
|
||||
|
||||
## Browse 1,246+ Skills
|
||||
## Browse 1,249+ Skills
|
||||
|
||||
- Open the interactive browser in [`apps/web-app`](apps/web-app).
|
||||
- Read the full catalog in [`CATALOG.md`](CATALOG.md).
|
||||
|
||||
@@ -626,6 +626,7 @@
|
||||
"description": "Operations, observability, and delivery pipelines.",
|
||||
"skills": [
|
||||
"007",
|
||||
"acceptance-orchestrator",
|
||||
"agent-evaluation",
|
||||
"airflow-dag-patterns",
|
||||
"api-testing-observability-api-mock",
|
||||
@@ -642,6 +643,7 @@
|
||||
"backend-development-feature-development",
|
||||
"cicd-automation-workflow-automate",
|
||||
"claude-monitor",
|
||||
"closed-loop-delivery",
|
||||
"cloud-devops",
|
||||
"code-review-ai-ai-review",
|
||||
"convex",
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"generatedAt": "2026-02-08T00:00:00.000Z",
|
||||
"total": 1246,
|
||||
"total": 1249,
|
||||
"skills": [
|
||||
{
|
||||
"id": "00-andruia-consultant",
|
||||
@@ -162,6 +162,31 @@
|
||||
],
|
||||
"path": "skills/ab-test-setup/SKILL.md"
|
||||
},
|
||||
{
|
||||
"id": "acceptance-orchestrator",
|
||||
"name": "acceptance-orchestrator",
|
||||
"description": "Use when a coding task should be driven end-to-end from issue intake through implementation, review, deployment, and acceptance verification with minimal human re-intervention.",
|
||||
"category": "infrastructure",
|
||||
"tags": [
|
||||
"acceptance",
|
||||
"orchestrator"
|
||||
],
|
||||
"triggers": [
|
||||
"acceptance",
|
||||
"orchestrator",
|
||||
"coding",
|
||||
"task",
|
||||
"should",
|
||||
"driven",
|
||||
"issue",
|
||||
"intake",
|
||||
"through",
|
||||
"review",
|
||||
"deployment",
|
||||
"verification"
|
||||
],
|
||||
"path": "skills/acceptance-orchestrator/SKILL.md"
|
||||
},
|
||||
{
|
||||
"id": "accessibility-compliance-accessibility-audit",
|
||||
"name": "accessibility-compliance-accessibility-audit",
|
||||
@@ -7983,6 +8008,32 @@
|
||||
],
|
||||
"path": "skills/close-automation/SKILL.md"
|
||||
},
|
||||
{
|
||||
"id": "closed-loop-delivery",
|
||||
"name": "closed-loop-delivery",
|
||||
"description": "Use when a coding task must be completed against explicit acceptance criteria with minimal user re-intervention across implementation, review feedback, deployment, and runtime verification.",
|
||||
"category": "infrastructure",
|
||||
"tags": [
|
||||
"closed",
|
||||
"loop",
|
||||
"delivery"
|
||||
],
|
||||
"triggers": [
|
||||
"closed",
|
||||
"loop",
|
||||
"delivery",
|
||||
"coding",
|
||||
"task",
|
||||
"must",
|
||||
"completed",
|
||||
"against",
|
||||
"explicit",
|
||||
"acceptance",
|
||||
"criteria",
|
||||
"minimal"
|
||||
],
|
||||
"path": "skills/closed-loop-delivery/SKILL.md"
|
||||
},
|
||||
{
|
||||
"id": "cloud-architect",
|
||||
"name": "cloud-architect",
|
||||
@@ -9520,6 +9571,32 @@
|
||||
],
|
||||
"path": "skills/create-branch/SKILL.md"
|
||||
},
|
||||
{
|
||||
"id": "create-issue-gate",
|
||||
"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.",
|
||||
"category": "general",
|
||||
"tags": [
|
||||
"create",
|
||||
"issue",
|
||||
"gate"
|
||||
],
|
||||
"triggers": [
|
||||
"create",
|
||||
"issue",
|
||||
"gate",
|
||||
"starting",
|
||||
"new",
|
||||
"task",
|
||||
"must",
|
||||
"created",
|
||||
"strict",
|
||||
"acceptance",
|
||||
"criteria",
|
||||
"gating"
|
||||
],
|
||||
"path": "skills/create-issue-gate/SKILL.md"
|
||||
},
|
||||
{
|
||||
"id": "create-pr",
|
||||
"name": "create-pr",
|
||||
|
||||
106
skills/acceptance-orchestrator/SKILL.md
Normal file
106
skills/acceptance-orchestrator/SKILL.md
Normal file
@@ -0,0 +1,106 @@
|
||||
---
|
||||
name: acceptance-orchestrator
|
||||
description: Use when a coding task should be driven end-to-end from issue intake through implementation, review, deployment, and acceptance verification with minimal human re-intervention.
|
||||
risk: safe
|
||||
source: community
|
||||
date_added: "2026-03-12"
|
||||
---
|
||||
|
||||
# Acceptance Orchestrator
|
||||
|
||||
## Overview
|
||||
|
||||
Orchestrate coding work as a state machine that ends only when acceptance criteria are verified with evidence or the task is explicitly escalated.
|
||||
|
||||
Core rule: **do not optimize for "code changed"; optimize for "DoD proven".**
|
||||
|
||||
## Required Sub-Skills
|
||||
|
||||
- `create-issue-gate`
|
||||
- `closed-loop-delivery`
|
||||
- `verification-before-completion`
|
||||
|
||||
Optional supporting skills:
|
||||
- `deploy-dev`
|
||||
- `pr-watch`
|
||||
- `pr-review-autopilot`
|
||||
- `git-ship`
|
||||
|
||||
## Inputs
|
||||
|
||||
Require these inputs:
|
||||
- issue id or issue body
|
||||
- issue status
|
||||
- acceptance criteria (DoD)
|
||||
- target environment (`dev` default)
|
||||
|
||||
Fixed defaults:
|
||||
- max iteration rounds = `2`
|
||||
- PR review polling = `3m -> 6m -> 10m`
|
||||
|
||||
## State Machine
|
||||
|
||||
- `intake`
|
||||
- `issue-gated`
|
||||
- `executing`
|
||||
- `review-loop`
|
||||
- `deploy-verify`
|
||||
- `accepted`
|
||||
- `escalated`
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Intake**
|
||||
- Read issue and extract task goal + DoD.
|
||||
|
||||
2. **Issue gate**
|
||||
- Use `create-issue-gate` logic.
|
||||
- If issue is not `ready` or execution gate is not `allowed`, stop immediately.
|
||||
- Do not implement anything while issue remains `draft`.
|
||||
|
||||
3. **Execute**
|
||||
- Hand off to `closed-loop-delivery` for implementation and local verification.
|
||||
|
||||
4. **Review loop**
|
||||
- If PR feedback is relevant, batch polling windows as:
|
||||
- wait `3m`
|
||||
- then `6m`
|
||||
- then `10m`
|
||||
- After the `10m` round, stop waiting and process all visible comments together.
|
||||
|
||||
5. **Deploy and runtime verification**
|
||||
- If DoD depends on runtime behavior, deploy only to `dev` by default.
|
||||
- Verify with real logs/API/Lambda behavior, not assumptions.
|
||||
|
||||
6. **Completion gate**
|
||||
- Before any claim of completion, require `verification-before-completion`.
|
||||
- No success claim without fresh evidence.
|
||||
|
||||
## Stop Conditions
|
||||
|
||||
Move to `accepted` only when every acceptance criterion has matching evidence.
|
||||
|
||||
Move to `escalated` when any of these happen:
|
||||
- DoD still fails after `2` full rounds
|
||||
- missing secrets/permissions/external dependency blocks progress
|
||||
- task needs production action or destructive operation approval
|
||||
- review instructions conflict and cannot both be satisfied
|
||||
|
||||
## Human Gates
|
||||
|
||||
Always stop for human confirmation on:
|
||||
- prod/stage deploys beyond agreed scope
|
||||
- destructive git/data operations
|
||||
- billing or security posture changes
|
||||
- missing user-provided acceptance criteria
|
||||
|
||||
## Output Contract
|
||||
|
||||
When reporting status, always include:
|
||||
- `Status`: intake / executing / accepted / escalated
|
||||
- `Acceptance Criteria`: pass/fail checklist
|
||||
- `Evidence`: commands, logs, API results, or runtime proof
|
||||
- `Open Risks`: anything still uncertain
|
||||
- `Need Human Input`: smallest next decision, if blocked
|
||||
|
||||
Do not report "done" unless status is `accepted`.
|
||||
117
skills/closed-loop-delivery/SKILL.md
Normal file
117
skills/closed-loop-delivery/SKILL.md
Normal file
@@ -0,0 +1,117 @@
|
||||
---
|
||||
name: closed-loop-delivery
|
||||
description: Use when a coding task must be completed against explicit acceptance criteria with minimal user re-intervention across implementation, review feedback, deployment, and runtime verification.
|
||||
risk: safe
|
||||
source: community
|
||||
date_added: "2026-03-12"
|
||||
---
|
||||
|
||||
# Closed-Loop Delivery
|
||||
|
||||
## Overview
|
||||
|
||||
Treat each task as incomplete until acceptance criteria are verified in evidence, not until code is merely changed.
|
||||
|
||||
Core rule: **deliver against DoD (Definition of Done), not against code diff size.**
|
||||
|
||||
## When to Use
|
||||
|
||||
Use this skill when:
|
||||
- user gives a coding/fix task and expects end-to-end completion
|
||||
- task spans code + tests + PR comments + dev deploy + runtime checks
|
||||
- repeated manual prompts like "now test", "now deploy", "now re-check PR" should be avoided
|
||||
|
||||
Do not use this skill for:
|
||||
- pure Q&A/explanations
|
||||
- prod deploy requests without explicit human approval
|
||||
- tasks blocked by missing secrets/account access that cannot be inferred
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Before execution, define these once:
|
||||
- task goal
|
||||
- acceptance criteria (DoD)
|
||||
- target environment (`dev` by default)
|
||||
- max iteration rounds (default `2`)
|
||||
|
||||
If acceptance criteria are missing, request them once. If user does not provide, propose a concrete default and proceed.
|
||||
|
||||
## Issue Gate Dependency
|
||||
|
||||
Before execution, prefer using `create-issue-gate`.
|
||||
|
||||
- If issue status is `ready` and execution gate is `allowed`, continue.
|
||||
- If issue status is `draft`, do not execute implementation/deploy/review loops.
|
||||
- Require user-provided, testable acceptance criteria before starting execution.
|
||||
|
||||
## Default Workflow
|
||||
|
||||
1. **Define DoD**
|
||||
- Convert request into testable criteria.
|
||||
- Example: checkout task DoD = "checkout endpoint returns a valid, openable third-party payment URL in dev".
|
||||
|
||||
2. **Implement minimal change**
|
||||
- Keep scope tight to task goal.
|
||||
|
||||
3. **Verify locally**
|
||||
- Run focused tests first, then broader checks if needed.
|
||||
|
||||
4. **Review loop**
|
||||
- Fetch PR comments/reviews.
|
||||
- Classify valid vs non-actionable.
|
||||
- Fix valid items, re-run verification.
|
||||
|
||||
5. **Dev deploy + runtime verification**
|
||||
- Deploy to `dev` when runtime behavior matters.
|
||||
- Verify via real API/Lambda/log evidence against DoD.
|
||||
|
||||
6. **Completion decision**
|
||||
- Only report "done" when all DoD checks pass.
|
||||
- Otherwise continue loop until pass or stop condition.
|
||||
|
||||
## PR Comment Polling Policy
|
||||
|
||||
Avoid noisy short polling by default. Use batched windows:
|
||||
|
||||
- **Round 1:** wait `3m`, collect delta comments/reviews
|
||||
- **Round 2:** wait `6m`, collect delta again
|
||||
- **Final round:** wait `10m`, collect all remaining visible comments/reviews
|
||||
|
||||
At each round:
|
||||
- process all new comments in one batch
|
||||
- avoid immediate re-poll after each single comment
|
||||
- after the `10m` round, stop waiting and proceed with all comments visible at that point
|
||||
|
||||
If CI is still running, align polling to check completion boundaries instead of fixed rapid polling.
|
||||
|
||||
## Human Gate Rules (Must Ask)
|
||||
|
||||
Require explicit user confirmation for:
|
||||
- production/staging deploy beyond agreed scope
|
||||
- destructive operations (history rewrite, force push, data-destructive ops)
|
||||
- actions with billing/security posture changes
|
||||
- secret values not available in repo/runtime
|
||||
- ambiguous DoD that materially changes outcome
|
||||
|
||||
## Iteration/Stop Conditions
|
||||
|
||||
Stop and escalate with a concise blocker report when:
|
||||
- DoD still fails after max rounds (`2` default)
|
||||
- external dependency blocks progress (provider outage, missing creds, account permission)
|
||||
- conflicting review instructions cannot both be satisfied
|
||||
|
||||
Escalation report must include:
|
||||
- what passed
|
||||
- what failed
|
||||
- evidence (commands/logs/API result)
|
||||
- smallest decision needed from user
|
||||
|
||||
## Output Contract
|
||||
|
||||
When claiming completion, always include:
|
||||
- acceptance criteria checklist with pass/fail
|
||||
- commands/tests run
|
||||
- runtime evidence (endpoint/Lambda/log key lines)
|
||||
- PR status (new actionable comments count)
|
||||
|
||||
Do not claim success without evidence.
|
||||
89
skills/create-issue-gate/SKILL.md
Normal file
89
skills/create-issue-gate/SKILL.md
Normal file
@@ -0,0 +1,89 @@
|
||||
---
|
||||
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.**
|
||||
|
||||
## 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.
|
||||
@@ -79,6 +79,16 @@
|
||||
"source": "community",
|
||||
"date_added": "2026-02-27"
|
||||
},
|
||||
{
|
||||
"id": "acceptance-orchestrator",
|
||||
"path": "skills/acceptance-orchestrator",
|
||||
"category": "uncategorized",
|
||||
"name": "acceptance-orchestrator",
|
||||
"description": "Use when a coding task should be driven end-to-end from issue intake through implementation, review, deployment, and acceptance verification with minimal human re-intervention.",
|
||||
"risk": "safe",
|
||||
"source": "community",
|
||||
"date_added": "2026-03-12"
|
||||
},
|
||||
{
|
||||
"id": "accessibility-compliance-accessibility-audit",
|
||||
"path": "skills/accessibility-compliance-accessibility-audit",
|
||||
@@ -3219,6 +3229,16 @@
|
||||
"source": "community",
|
||||
"date_added": "2026-02-27"
|
||||
},
|
||||
{
|
||||
"id": "closed-loop-delivery",
|
||||
"path": "skills/closed-loop-delivery",
|
||||
"category": "uncategorized",
|
||||
"name": "closed-loop-delivery",
|
||||
"description": "Use when a coding task must be completed against explicit acceptance criteria with minimal user re-intervention across implementation, review feedback, deployment, and runtime verification.",
|
||||
"risk": "safe",
|
||||
"source": "community",
|
||||
"date_added": "2026-03-12"
|
||||
},
|
||||
{
|
||||
"id": "cloud-architect",
|
||||
"path": "skills/cloud-architect",
|
||||
@@ -3859,6 +3879,16 @@
|
||||
"source": "unknown",
|
||||
"date_added": null
|
||||
},
|
||||
{
|
||||
"id": "create-issue-gate",
|
||||
"path": "skills/create-issue-gate",
|
||||
"category": "uncategorized",
|
||||
"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"
|
||||
},
|
||||
{
|
||||
"id": "create-pr",
|
||||
"path": "skills/create-pr",
|
||||
|
||||
Reference in New Issue
Block a user