Asw Review

Antigravity Swarm Review

Use this skill before release, publication, merge, or any claim that broad work is complete.

Lead with findings. Approval is earned by evidence.

Review Lanes

Lane 1: Goal Fidelity

Check:

• newest user request,
• explicit non-goals,
• version and publish constraints,
• requested commit/push behavior,
• language and tone constraints,
• private/reference exclusion requirements.

Reject if the diff solves a different problem or leaves a requested criterion unaddressed.

Lane 2: Behavior

Check:

• changed behavior has RED-to-GREEN proof,
• refactors have characterization coverage,
• errors and edge cases are preserved,
• public API or CLI flags are stable unless intentionally changed,
• status line examples match real output,
• installer menu output matches tests and manual smoke.

Reject if behavior is inferred instead of proven.

Lane 3: Real Surface

Check the surface the user actually touches:

• tmux transcript for CLI and terminal UX,
• HTTP transcript for APIs,
• browser screenshot and action log for web,
• desktop automation evidence for GUI,
• package install transcript for npm installers,
• plugin validation transcript for Antigravity plugin surfaces.

Tests alone are not enough for user-visible behavior.

Lane 4: Code Quality

Check:

• local patterns,
• type and diagnostic output,
• dead code,
• needless abstraction,
• duplicated logic,
• oversized modules,
• comments and docs quality,
• generated-looking filler.

Reject if cleanup removes meaningful behavior or adds broad speculative architecture.

Lane 5: Release Surface

Check:

• git status,
• ignored private/runtime files,
• package allowlist,
• tarball file list,
• hook manifest,
• skill inventory,
• agent inventory,
• generated assets,
• README examples,
• version fields.

Reject if private/reference/runtime material can ship.

Lane 6: Antigravity Compatibility

Check:

• Antigravity plugin validation,
• hook phase registration,
• hook command paths after install,
• global skill shims,
• agent TOML shape,
• status line command,
• IDE-compatible config path,
• no stale platform claims.

Evidence

Every review should list evidence actually inspected:

• test commands and outcomes,
• manual QA channel and artifact,
• package dry-run output,
• plugin validation output,
• residue scan,
• git status,
• installed-path smoke,
• screenshots or captured panes when visual output changed.

Missing evidence is a blocker.

Review Context

Gather context before launching review lanes:

1. Read the newest user request.
2. Confirm the current branch and dirty state.
3. Identify changed files.
4. Inspect the diff.
5. Identify generated files.
6. Identify package or install surfaces.
7. Identify user-visible surfaces.
8. Identify requested commit, push, publish, or no-publish constraints.
9. Identify private/runtime exclusion constraints.
10. Identify the commands already run by the implementer.

Context packet:

Goal:
Non-goals:
Changed files:
Generated files:
User-visible surfaces:
Package surfaces:
Private/runtime risks:
Verification already run:
Missing verification:

Do not review from memory. The review starts from the actual diff and the newest request.

Parallel Review

For broad changes, run independent review lanes in parallel or simulate them one by one if subagents are unavailable. The lanes are intentionally redundant; overlap catches false confidence.

Required lanes:

• Goal Fidelity Reviewer,
• QA Reviewer,
• Code Quality Reviewer,
• Security Reviewer,
• Context Mining Reviewer.

Each reviewer returns:

Lane:
Files inspected:
Evidence:
Findings:
Blockers:
Recommended checks:
Verdict:

If any lane rejects, the final verdict rejects.

Goal Fidelity Reviewer

Mission:

• compare the diff to the user's exact request,
• check that newer user messages override older assumptions,
• check version constraints,
• check naming constraints,
• check language constraints,
• check commit/push/publish constraints,
• check that README claims match actual behavior.

Questions:

• Did the implementation solve the requested problem?
• Did it solve an older problem instead?
• Did it add marketing or internal notes the user rejected?
• Did it preserve the requested package/version policy?
• Did it avoid private/reference leakage?
• Did it leave a requested workflow incomplete?

Reject on:

• missing requested file,
• stale README example,
• wrong version,
• unrequested publish,
• missing commit/push when explicitly asked,
• internal management notes in public docs.

QA Reviewer

Mission:

• exercise the surface users actually touch,
• verify terminal, CLI, HUD, package, browser, or IDE behavior as applicable,
• compare screenshots or transcripts to documentation,
• verify failure paths when the change affects error handling.

QA scenario process:

1. Brainstorm realistic user scenarios.
2. Pick the smallest scenarios that cover changed behavior.
3. Execute through the real surface.
4. Capture command, output, screenshot, or transcript.
5. Compare to README and tests.
6. Report gaps.

For Antigravity Swarm changes, QA may include:

• agy plugin validate,
• temp install and verify,
• hook alias smoke,
• status line payload smoke,
• npm pack --dry-run,
• README rendering inspection,
• cover image visual inspection,
• installed config path inspection.

Reject when user-visible behavior is only unit-tested but not exercised through the real surface.

Code Quality Reviewer

Mission:

• inspect maintainability,
• inspect local pattern consistency,
• inspect whether abstractions pay for themselves,
• inspect test quality,
• inspect generated-looking clutter,
• inspect file sizes and responsibility boundaries.

Focus areas:

• behavior hidden in UI helpers,
• IO mixed with rendering,
• parsing repeated across layers,
• broad exception swallowing,
• string manipulation where structured parsing exists,
• stale compatibility paths,
• duplicated tests that do not assert behavior,
• oversized files without ownership split.

Reject when cleanup or refactor weakens behavior proof.