firefrost-gaming/antigravity-skills-reference

Files

Al-Garadi ef285b5c97 fix: sync upstream main with Windows validation and skill guidance cleanup (#457 )

* 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>

2026-04-05 21:04:39 +02:00

3.2 KiB

Raw Blame History

name, description, risk, source, date_added

name	description	risk	source	date_added
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 human re-intervention.	safe	community	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".

When to Use

The task already has an issue or clear acceptance criteria and should run end-to-end with minimal human re-intervention.
You need structured handoff across implementation, review, deployment, and final verification.
You want explicit stop conditions and escalation instead of silent partial completion.

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

Intake
- Read issue and extract task goal + DoD.
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.
Execute
- Hand off to closed-loop-delivery for implementation and local verification.
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.
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.
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.

3.2 KiB Raw Blame History