By name: asw-goal description: Durable Antigravity Swarm goal orchestration with explicit success criteria, evidence ledger, manual QA channels, and completion audit.
Antigravity Swarm Goal
Use this skill when a task spans multiple turns, several deliverables, release surfaces, or strict completion criteria.
The invariant: a goal is complete only when every success criterion has current observable evidence.
Goal Files
Use .asw/goals/<slug>.md for durable local state when needed.
Keep it small:
- original objective,
- non-goals,
- success criteria,
- evidence ledger,
- blockers,
- cleanup receipts,
- final audit.
Do not store secrets, private transcripts, tokens, or unnecessary personal paths.
Success Criteria
Each criterion must include:
- id,
- scenario,
- expected evidence,
- automated test or diagnostic,
- Manual QA channels,
- adversarial risk,
- cleanup requirement,
- pass/fail/block condition.
Use at least:
- happy path,
- edge or malformed input,
- adjacent-surface regression,
- package or privacy surface when distribution is involved.
Manual QA channels
Choose the channel that matches the surface:
tmux
Use for CLI, installer, terminal HUD, hook-visible behavior, and terminal menus.
Evidence:
- command sent,
- captured pane output,
- cleanup receipt for the session if spawned.
HTTP
Use for APIs and local servers.
Evidence:
- request,
- status,
- headers when relevant,
- body,
- server cleanup.
Browser
Use for web pages and README render previews when visual layout matters.
Evidence:
- action log,
- screenshot path,
- browser/context cleanup.
Computer use
Use for desktop or IDE GUI behavior.
Evidence:
- action log,
- screenshot,
- app/window state,
- cleanup.
Auxiliary CLI output can support a criterion, but it does not replace the real channel for user-visible behavior.
Ledger
Record one entry per criterion attempt:
time:
criterion:
status: pass | fail | blocked
automated evidence:
manual channel:
artifact:
cleanup:
notes:
Never record pass without cleanup.
Execution Cycle
- Re-read the newest user request.
- Re-read the goal ledger.
- Pick one pending criterion.
- Confirm or create the RED test.
- Implement the smallest change.
- Run GREEN.
- Run the manual channel scenario.
- Capture evidence.
- Clean temporary state.
- Record pass, fail, or blocked.
- Continue to the next criterion.
Dynamic Steering
Revise the goal only with evidence:
- add a criterion when a real adjacent risk appears,
- split a criterion that is too broad,
- reorder work when dependencies are discovered,
- mark a criterion blocked when external state prevents verification,
- remove a criterion only when the newest user instruction changes the objective.
Do not mutate goals because the work feels hard.
Completion Audit
Before closing:
- every criterion is pass,
- tests and diagnostics are current,
- manual QA artifacts exist,
- cleanup receipts exist,
- package/git/private boundaries are clean,
- docs match behavior,
- reviewer has no blockers when review is required.
Failure Handling
If the same criterion fails repeatedly:
- Stop editing.
- Record attempts.
- State the likely cause.
- Name the evidence needed.
- Ask for user input only when no safe local path remains.
Output
When reporting goal status:
Goal:
Criteria:
- id: PASS | FAIL | BLOCKED - evidence
Verification:
Manual QA:
Cleanup:
Remaining risk:
Final status:
Final Rule
Green tests are necessary evidence, not completion. The user-visible surface decides completion.