feat: add Antigravity CLI support and Gemini EOL migration notice

.antigravity/plugin.json

@@ -0,0 +1,5 @@
+{
+  "name": "ai-coding-setup",
+  "version": "0.1.0",
+  "description": "Set of skills to aid in utilizing Antigravity CLI in development workflows."
+}

.antigravity/skills/code-refinement/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: code-refinement
+description: "Review staged files for code quality (KISS, DRY, YAGNI, Clean Code) and fix linting issues."
+---
+
+# Code Refinement
+
+Review the staged files to ensure the changes adhere to the KISS, DRY, and YAGNI principles. Confirm that Clean Code standards are met (including clear, consistent naming and comments where needed).
+
+Check for opportunities to use established framework utilities, composables, or library functions instead of hand-rolled logic. If the staged code reimplements behavior that the project's framework or core libraries already provide, flag it and suggest the existing alternative.
+
+Verify that the project's UI framework components and utility classes are used where appropriate instead of custom CSS or HTML elements. Flag any custom styling that duplicates what the framework already provides.
+
+Run the project's linting command and fix all reported errors and warnings. Avoid using lint-suppression comments (e.g., eslint-disable, noqa, @ts-ignore) to make the lint pass unless absolutely necessary, and only with a clear justification in the code.
+
+Review tests and code coverage: check whether existing tests adequately cover the new or modified code, identify any gaps where additional tests are needed, and determine whether any existing tests must be updated to handle the new behavior correctly. When finished, ensure everything is ready for a high-quality code review.

.antigravity/skills/code-review/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: code-review
+description: "Review staged changes for security, correctness, performance, and clarity. Writes findings to agent-code-review.md."
+---
+
+# Role
+
+You are a senior code reviewer and security expert. You are tech stack agnostic and adapt your review to the project's languages and frameworks.
+You only read and analyze the code — you must never modify any source code files in the repository.
+The sole exception is writing your review output into a Markdown file.
+You never ask the user what to do next and you produce exactly one review report per run.
+
+## Output Location
+
+- Always write your complete review to a file named `agent-code-review.md` in the project root.
+- Overwrite the file completely on each run — do not append.
+- This file is the only file you may create or modify.
+- Do not stage, commit, or push this file.
+
+## Iterative Review Behavior
+
+- On each run, treat the task as a fresh review of the currently staged changes.
+- Continue reviewing until there are no High or Medium severity issues and no Low severity blockers, then clearly state in the Summary that the code is good to go.
+
+## Scope and Inputs
+
+- Review only files that are currently staged in Git, not the entire repository.
+- Focus on changed lines and minimal necessary surrounding context.
+- Use unified diffs to compute accurate new file line numbers for comments.
+- If information is missing, state reasonable assumptions and proceed.
+
+## How to Collect Context
+
+1. Verify staged files exist: git status --porcelain (look for changes in column 1)
+2. Get the diff: git diff --staged --unified=0 --no-color
+3. If diff is empty but status shows staged files: git diff --staged --no-color (fallback)
+4. For context when needed: git diff --staged -U3 --no-color
+   Parse output:
+   - Hunk headers: @@ -oldStart,oldCount +newStart,newCount @@
+   - Target line numbers from +newStart and +newCount
+   - File paths from diff --git lines
+
+   Fallback if inconsistent: Always trust git status --porcelain over empty diff output.
+5. For dead code detection or DRY/YAGNI opportunities, you may examine other project files (e.g., to confirm unused functions or repeated patterns). Restrict this exploration to the minimal files necessary to support the finding.
+
+## Review Policy
+
+Prioritize findings that materially improve:
+
+- Security, reliability, data integrity, privacy.
+- Correctness and performance where clearly impactful.
+- Clarity and Clean Code.
+
+Avoid nitpicks:
+
+- Do not flag purely stylistic issues unless a project style rule is clearly violated.
+- Recommend formatting or lint rules only when they prevent bugs or confusion.
+
+## Security Checklist
+
+- Map each finding to OWASP Top Ten, e.g., A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, etc.
+- For HTTP APIs, also consider OWASP API Top 10.
+- Provide actionable mitigations.
+
+## Clean Code and Clarity Checks
+
+- Prefer small, focused functions, clear names, elimination of duplication, obvious control flow.
+- Suggest local refactors near changed lines.
+- Provide minimal viable patches as examples when safe.
+- Identify dead code (unused variables, functions, imports, classes).
+- Check for DRY violations (repeated logic or patterns that could be abstracted).
+- Check for YAGNI violations (unnecessary code, abstractions, or parameters that add complexity without current value).
+
+## Output Format
+
+Write the following structure into `agent-code-review.md`:
+
+````markdown
+# Code Review Report
+
+**Iteration:** N
+**Date:** YYYY-MM-DD
+**Scope:** Staged changes only
+
+## Summary
+
+- One paragraph on overall risk and clarity.
+- Finding counts: High X, Medium Y, Low Z.
+- If no High or Medium remain and no Low blockers, state: **Verdict: good to go**.
+
+## Findings
+
+For each finding:
+
+[Severity, Impact area] path/to/file.ext, line X or lines X-Y
+- **Issue:** concise problem statement.
+- **Why it matters:** link to security, maintainability, or clarity impact.
+- **Recommendation:** specific, actionable fix.
+- **Suggested patch example, if safe:**
+
+```diff
+*** Begin Patch
+*** Update File: path/to/file.ext
+@@
+- old code
++ improved code
+*** End Patch
+```
+````

.antigravity/skills/commitmsg/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: commitmsg
+description: "Propose a single git commit message for the currently staged changes."
+---
+
+# Commit Message
+
+Propose a single git commit message for the currently staged changes.
+
+## Gather context
+
+Run these commands to understand the changes:
+
+- `git diff --staged` — the actual changes
+- `git status -s` — staged file list
+- `git log -n 20 --oneline` — recent style and to avoid repetition
+- `git branch --show-current` — if it contains a ticket ID (e.g. ABC-123), prefix the subject line
+
+## Rules
+
+Use Conventional Commits. Pick the most accurate type; prefer `feat` for new behavior. Optional scope allowed.
+
+Subject: imperative, max 72 chars, no trailing period. Capture the big picture and intent, not implementation details. Optimize for future readers.
+
+Body: include bullets only when the subject alone is insufficient. Each bullet must answer "what would be unclear or risky if omitted?" Merge related items; skip internal plumbing, helpers, and test scaffolding unless they are the primary change. Wrap at 72 chars. Omit the body entirely for minor or single-focus changes.
+
+## Output
+
+```text
+[ticket] type(scope): concise subject
+
+- Important change or impact
+- Another distinct change, only if necessary
+```

.antigravity/skills/dependency-review/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: dependency-review
+description: "Audit package dependency updates for supply-chain risk: publish-age gate, changelog/diff verification, security advisories, community signals, and breaking changes."
+---
+
+# Package Update Supply Chain Review
+
+Review dependency updates to catch supply chain attacks, breaking changes, and risky packages before they land in your codebase.
+
+## When to Use This Skill
+
+Activate this review whenever a branch, PR, or working directory includes changes to dependency manifests or lockfiles. Common triggers include version bumps in package.json, requirements.txt, pyproject.toml, Gemfile, go.mod, Cargo.toml, pom.xml, build.gradle, composer.json, pubspec.yaml, or their corresponding lockfiles.
+
+## Review Workflow
+
+For each updated or newly added package, work through all five checks below. Present findings in a single summary report at the end, grouped by package. Flag any failing check as a **HOLD** and recommend the team investigate before merging.
+
+---
+
+### 1. Publication Age Gate
+
+**Goal:** Confirm the release is at least 7 days old to allow the community time to discover and report compromises.
+
+**Steps:**
+
+1. Look up the package on its registry (npm, PyPI, RubyGems, crates.io, pub.dev, Maven Central, Go module proxy, Packagist, NuGet, etc.).
+2. Find the publish date for the exact version being pulled in.
+3. Calculate the number of days between the publish date and today.
+4. If fewer than 7 days have elapsed, flag this as **HOLD - TOO NEW** and include the publish date, the age in days, and a recommendation to wait or pin to the prior version.
+
+**Why this matters:** Attackers who hijack a maintainer account or publish a typosquatted package are often caught within the first few days. Letting a release "bake" gives the community, automated scanners, and the maintainer time to notice anomalies.
+
+---
+
+### 2. Changelog and Diff Verification
+
+**Goal:** Confirm the code changes match what the release notes claim.
+
+**Steps:**
+
+1. Locate the changelog, release notes, or GitHub releases page for the new version.
+2. Identify the claimed changes (bug fixes, features, refactors, etc.).
+3. Skim the actual source diff between the old and new version (use the repo's compare view, e.g. `github.com/<org>/<repo>/compare/v1.2.3...v1.4.0`).
+4. Look for discrepancies: Are there unexpected new files? New network calls? Obfuscated code? Post-install scripts that were not present before?
+5. Pay special attention to install hooks (`preinstall`, `postinstall` in npm; `setup.py` entry points in Python; `build.rs` changes in Rust; etc.) since these execute automatically and are a top vector for supply chain attacks.
+
+**Red flags to call out:**
+
+- Minified or obfuscated source added to an otherwise readable codebase
+- New outbound HTTP/DNS calls, especially to IP addresses or unusual domains
+- Environment variable reads for tokens, keys, or credentials
+- New native/binary dependencies or compiled assets
+- Changes to CI config or build scripts that fetch remote resources
+
+---
+
+### 3. Security Advisory Review
+
+**Goal:** Check whether the package or specific version has known vulnerabilities.
+
+**Steps:**
+
+1. Search the GitHub Advisory Database (GHSA), the National Vulnerability Database (NVD), and the ecosystem-specific advisory source (npm audit, pip-audit/Safety DB, RustSec, etc.) for the package name and version range.
+2. Check whether the update itself is a security patch. If so, note the CVE(s) it addresses and confirm the fix is present in the version being adopted.
+3. Check whether the new version introduces any new advisories. This can happen when a patch also pulls in a vulnerable transitive dependency.
+4. Report findings as: **No known advisories**, **Fixes CVE-XXXX-YYYY (severity)**, or **HOLD - OPEN ADVISORY: CVE-XXXX-YYYY**.
+
+---
+
+### 4. Community Signals
+
+**Goal:** See if real users are reporting problems, compromises, or regressions with this release.
+
+**Steps:**
+
+1. Check the package's GitHub Issues (filter to issues opened after the release date).
+2. Search the repository's Discussions tab if available.
+3. Search for the package name + version on relevant forums: Stack Overflow, Reddit (r/programming, r/node, r/python, r/rust, etc.), Hacker News, and the ecosystem's community channels (e.g. Discord servers for popular frameworks).
+4. Look for patterns: multiple people reporting the same crash, unexpected behavior, or suspicious activity.
+5. Note download counts and whether they are consistent with the package's historical trends. A sudden spike or drop can indicate typosquatting or an abandoned fork.
+
+**Report as:** A brief summary of community sentiment, or "No community issues found for this version" if clean.
+
+---
+
+### 5. Breaking Changes and Migration Notes
+
+**Goal:** Identify API or behavioral changes that could break existing code.
+
+**Steps:**
+
+1. Check if the version bump follows semver. A major version bump signals intentional breaking changes. A minor or patch bump with breaking changes is a red flag on its own (either accidental or a sign of poor maintenance practices).
+2. Read the migration guide or upgrade notes if one exists.
+3. Look at the diff for: removed or renamed exports, changed function signatures, altered default values, removed configuration options, or dropped support for runtimes/platforms.
+4. Search the codebase for usages of any changed or removed APIs. List the files and line numbers that may need updates.
+5. Note any changes to the package's peer dependency requirements, minimum runtime versions (Node, Python, Ruby, etc.), or required environment variables.
+
+**Report as:**
+
+- **No breaking changes** for seamless upgrades.
+- **Breaking changes detected** with a list of what changed and which files in the codebase are affected.
+- **Potential breaking changes** for behavioral changes that may not cause compile/import errors but could alter runtime behavior (e.g., a default timeout changing from 30s to 5s).
+
+---
+
+## Output Format
+
+Present the full review as a structured report. Here is the template:
+
+```text
+# Package Update Review
+
+## Summary
+- Packages reviewed: N
+- Holds: N (list package names)
+- Clean: N
+
+## Per-Package Review
+
+### <package-name>: <old-version> -> <new-version>
+
+| Check                  | Status       | Details                          |
+|------------------------|--------------|----------------------------------|
+| Publication age        | PASS / HOLD  | Published <date>, <N> days ago   |
+| Changelog verification | PASS / WARN  | <brief note>                     |
+| Security advisories    | PASS / HOLD  | <CVEs or "None found">           |
+| Community signals      | PASS / WARN  | <brief note>                     |
+| Breaking changes       | PASS / WARN  | <brief note or "None">           |
+
+**Recommendation:** APPROVE / HOLD / APPROVE WITH NOTES
+
+<details if any check is WARN or HOLD>
+
+(Repeat for each package)
+```
+
+## Edge Cases
+
+- **New dependencies** (not just version bumps): Apply the same five checks but also verify the package is the intended one (check for typosquatting by comparing to similarly named popular packages) and review its overall maintenance health (last commit date, number of maintainers, bus factor).
+- **Lockfile-only changes** with no manifest change: These can happen from transitive dependency resolution. Still review the transitive packages that changed, though a lighter touch is acceptable for patch-level transitive bumps in well-known packages.
+- **Monorepos with many packages:** Group related packages (e.g., `@babel/*` or `@angular/*`) and note that they are part of a coordinated release, which reduces (but does not eliminate) the need for individual diff review.
+- **Private/internal packages:** The publication age gate may not apply, but the diff verification and breaking change checks still do.
+
+## Tips for Efficiency
+
+- Start with the publication age gate; it is the fastest check and can immediately flag the riskiest updates.
+- For large dependency updates (e.g., Dependabot batches), prioritize direct dependencies over transitive ones, and prioritize packages with install hooks.
+- If a package has hundreds of thousands of weekly downloads and is maintained by a well-known org (e.g., Meta, Google, Vercel), the changelog and community checks can be lighter. But never skip the security advisory check.