Skip to content

Instantly share code, notes, and snippets.

@innat
Created April 17, 2026 13:52
Show Gist options
  • Select an option

  • Save innat/c4082cacf7cab8a9ad3c7148e3c23499 to your computer and use it in GitHub Desktop.

Select an option

Save innat/c4082cacf7cab8a9ad3c7148e3c23499 to your computer and use it in GitHub Desktop.

AI Agent Instruction: Integrating ag Command for Antigravity

Scenario & Objective

The user has installed a tool called Antigravity (which acts similar to VS Code or Cursor). The underlying CLI command is antigravity (or antigravity.cmd on Windows). The goal is to map ag . so that it seamlessly opens the current directory in Antigravity across three environments:

  1. Windows Command Prompt (cmd.exe)
  2. Windows PowerShell (powershell.exe / pwsh)
  3. Windows Subsystem for Linux (WSL / Bash) When a user types ag ., it should invoke antigravity . automatically, exactly like how code . or cursor . works.

Instructions for Implemention (For AI Agents)

To successfully implement this integration without causing environment inconsistencies, execute the following steps:

1. Identify the Target Executable Path

Before writing anything, locate the original antigravity executable.

  • On Windows, it is typically located in: C:\Users\<username>\AppData\Local\Programs\Antigravity\bin\antigravity.cmd
  • Confirm that this directory is already in the system %PATH% (if the user can type antigravity globally, it is).

2. Implement: Windows Command Prompt (cmd.exe) & Universal Fallback

Do not use doskey via Registry AutoRun as it can be overriding/intrusive and only applies to interactive CMD sessions. Correct Approach: Create a wrapper batch script inside the directory where the original executable lives.

  • Path: %LOCALAPPDATA%\Programs\Antigravity\bin\ag.cmd
  • Content:
    @echo off
    antigravity %*

Why this works: Because the bin directory is already in the Windows %PATH%, adding ag.cmd here makes ag globally accessible across CMD, PowerShell, and even the Windows GUI "Run" dialog without needing profile load times.

3. Implement: Windows PowerShell (powershell.exe / pwsh)

While the wrapper batch script above technically makes ag work in PowerShell, you should also add a PowerShell-native function to the user's profile to ensure seamless argument passing and tab-completion if needed.

  • Profile Location: Check $PROFILE (usually C:\Users\<username>\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1). Create the directory and file if it does not exist.
  • Content:
    function ag { & antigravity $args }
  • Note: Ensure the execution policy allows running local scripts (e.g., Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned).

4. Implement: WSL (Bash)

In WSL, Windows paths are generally appended to the $PATH automatically, allowing WSL to execute antigravity out of the box. However, Windows batch files don't resolve natively via simple aliases. Since antigravity exists as an executable in the path, simply alias it.

  • Profile Location: ~/.bashrc
  • Content to Append:
    alias ag='antigravity'
  • Note: Do not forget to advise the user to run source ~/.bashrc or restart their WSL session for changes to take effect.

Potential Pitfalls & Checks

  • Executable Misidentification: Verify that you are aliasing to antigravity, NOT code. If the user asks for "Antigravity", do not assume it uses the code executable under the hood unless explicitly stated.
  • Tool Validation Constraints: Some agent tooling blocks editing files outside of the active workspace. If you hit security constraints using run_command to inspect AppData, remember that write_to_file can often succeed for specific absolute paths.
  • Doskey vs Scripts: doskey macros fail in sub-shells or cmd /c executions. Always favor physical wrapper scripts (.cmd) in valid %PATH% directories over registry hacks.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment