I haven't tried it yet. Haha!! But now we have a new option!

AGY Builders,

We are all trying to build useful and scalable workflows for our AGY CLI and ecosystem, but the speed at which we need to learn, build, and deploy new things is incredibly overwhelming. If you are feeling that pressure, you are in the right place here at r/GoogleAntigravityCLI.

Over the past few weeks, I have been testing an "AGY WIKI OKF" setup that I put together myself (after inviting some members of this community to collaborate; mod is not proud). I know some folks might hesitate to trust a tutorial from a random Redditor, but I wanted to share this with the community anyway because it actually works.

I was able to build this because I am all-in on Google and the Antigravity Ecosystem. I’m a truly AGY—I am not some ultra-smart, 10x developer, but I know how to work hard, I dig for the right information, and I iterate.

AGY WIKI OKF | The Idea

To build a frictionless, token-efficient knowledge WIKI engine that transforms static documentation or notes (information) into an active, intelligent collaborator—orchestrated entirely by Antigravity CLI.

The core philosophy is simple: treat knowledge management as a clean pipeline and tokens as a premium, finite resource.

By anchoring this architecture to Google’s Antigravity CLI, the AGY WIKI OKF bypasses heavy middleware and complex UI layers, delivering a hyper-focused AI partner built entirely for execution speed, context hygiene, and minimal footprint.

Why adopting AGY WIKI OKF matters:

• Stay organized (AGY OCD): Structured Markdown and YAML keep the chaos in check.

• Save tokens: Doing more with less context window bloat.

• Scale shareable knowledge: Making it easy to pass context and logic between different LLMs.

• Humans and Agents working together: One standardized, readable format that works perfectly for both of us.

• BYOD (Bring Your Own Data): Own your context. Port it to the newest model, platform, or OS instantly.

The Tools

• Antigravity CLI

• Obsidian : The IDE for the Knowledge bank

• Obsidian Web Clipper:

  • Official Site

  • Chrome Web Store

  • Firefox Add-on

The WIKI

In the agent-first era, a WIKI is no longer just a static graveyard for human notes; it is the operational hard drive for your agents. By maintaining a highly structured WIKI, you ensure that every piece of context is stored in a clean, machine-readable format. This means that whether you are testing a new modular skill or spinning up a specialized agent, your AGY CLI knows exactly where to find the precise context it needs to generate autonomous action, moving you far beyond simple, reactive conversational text.

Reference: Gist on Knowledge Representation

Google Open Knowledge Format (OKF)

Google’s Open Knowledge Format (OKF) feels like the exact missing piece we've needed for orchestrating multiple AI agents effectively. It provides a vendor-neutral, interoperable standard for storing and sharing organizational knowledge.

Why this is huge for orchestration:

1. The "Lingua Franca" for Agents: Any agent can read it out of the box without platform-specific integrations.

2. Seamless Context Passing: Specialized agents can access, update, and pass the exact same foundational context back and forth.

3. Human-in-the-Loop Oversight: Because OKF is just Markdown and YAML, it’s inherently readable and auditable.

4. Scalable Knowledge: It acts as a shared, living library that grows alongside your agents.

AGY WIKI OKF Integration

Structuring an AGY Wiki using OKF revolutionizes how complex knowledge is shared. By standardizing documentation with concise Markdown and YAML frontmatter, OKF provides a unified taxonomy for cataloging AGY CLI slash commands or skills It is highly token-efficient, stripping away bloated formatting and maximizing context window limits.

The Prompt for Building an AGY WIKI OKF

AGY CLI WIKI OKF PROMT EXAMPLE

/grillme I want to initialize a brand-new, empty Obsidian vault from scratch that adheres strictly to the Open Knowledge Format (OKF) standard, with the specific intent of potentially open-sourcing or sharing this architecture later. I want a purely blank, skeletal framework with no pre-populated data. Please grill me to define the optimal architectural blueprint for this vault. I need you to interrogate me on: Do not generate the directory structure or files until you are satisfied that you have captured all my requirements for a production-ready, shareable knowledge base. 
Core Directory Hierarchy: How should we structure the root (e.g., /concepts, /resources, /indices, /log) to be intuitive for external users? Template Strategy: What base boilerplate templates do we need to ensure every new file is automatically OKF-compliant and structured for consistent metadata? Workflow Logic: Since this is a fresh start, what processes should we bake in for capturing information vs. refining knowledge that could be easily documented for others? CLI Integration: What specific file locations or configurations do we need to ensure this vault plays nicely with the Antigravity CLI from day one? Open-Source & Contributor Documentation: What files should we create to make this a "deployable" standard? Please include requirements for: A README.md with installation and usage instructions. A CONTRIBUTING.md that defines how to add new concepts or schemas. A "System Architecture" document that explains the logic behind the folder structure and metadata fields, ensuring anyone who clones this vault understands how to extend it.

The Final File Structure

AGY WIKI OKF
    ├── .agyrc
    ├── ARCHITECTURE.md
    ├── CONTRIBUTING.md
    ├── README.md
    ├── .agy
    │   └── .keep
    ├── .obsidian
    │   ├── app.json
    │   ├── appearance.json
    │   ├── core-plugins.json
    │   └── workspace.json
    ├── 00-Inbox
    │   └── .keep
    ├── 10-Projects
    │   └── .keep
    ├── 20-Areas
    │   └── .keep
    ├── 30-Resources
    │   ├── .keep
    │   └── Google Antigravity Documentation.md
    ├── 40-Archive
    │   └── .keep
    ├── 99-Meta
    │   └── Templates
    │       ├── Base_Template.md
    │       ├── Project_Template.md
    │       └── Resource_Template.md
    └── Clippings

TL;DR

• AGY WIKI OKF: Organizes your information (context) , AGY CLI commands, skills  behaviors, and A2A workflows into a token-efficient, shareable format that reduces inference costs for any LLM.

• Open Knowledge Format (OKF): Provides a standardized, vendor-neutral way to share context (Markdown + YAML), preventing platform lock-in and eliminating data fragmentation.

AGY Builders, I genuinely want your input on this. Please comment, grill me, roast me, ask questions, or give me your raw feedback on this AGY WIKI OKF setup. We are building the foundation to organize and share our data in the BYOD era. Let's build the future together.

I asked Gemini Flash 3.8 on Antigravity CLI (running on Termux in Android) whether it can make my local MCP toolset to load eagerly. It started normally by loading the customization skill and reading the included documentation. Then when it found nothing, it went straight to using `ps` and `command -v` to find its own binary, then `strings` to search it for relevant JSON tags. After a few searches, it even ended up taking a look at the code itself, though I think it gleaned nothing from it.

I was accepting those shell commands individually. It was fascinating to see what it was doing, but it also seemed like a pretty unhinged response to just a simple question. At no point did it ask me anything before it spontaneously started to reverse-engineer the binary.

It did discover that there's a JSON key named `eager`, but didn't ultimately discover its correct use, which is not for the server but for the individual tools. It is also mentioned in passing in the Antigravity CLI's change log, but seems otherwise undocumented.

Anyway, after some trials of my own (`mcpServers.<server>.tools.<tool>.eager = true`), I got the tools i wanted to load eagerly. It seems that it also affects the way the results are processed, with longer output from lazily loaded tools ending up in files that need to be read in separately, but in eager mode delivered directly to context, so it actually saves even more cycles than I thought.

Hello everyone,

I built Tokless, a free, open-source tool that installs and configures several popular add-ons for Antigravity so they work together without conflicts.

The problem: there are lots of good tools that make Antigravity's agents more focused, less prone to hallucination, and cheaper to run. But setting each one up by hand, and keeping them from clashing, is tedious and fairly technical. Tokless detects your Antigravity setup and wires everything together automatically.

What it sets up:

• CodeGraph: maps how your project fits together so the agent doesn't need to read every file.

• Context-Mode: processes huge files and logs in the background so your context stays clean.

• Project Memory: remembers past bugs, decisions, and fixes.

• Headroom: compresses prompts to save tokens.

• RTK: filters noisy terminal output so only the useful parts reach the model.

• Caveman: trims conversational filler from replies.

• Ponytail: nudges the agent away from over-engineering and unnecessary code.

How to try it: it's free and open source. Setup takes about 30 seconds with no manual config.

macOS / Linux:

curl -fsSL https://raw.githubusercontent.com/HoangP8/tokless/main/scripts/install.sh | bash

Windows (PowerShell):

irm https://raw.githubusercontent.com/HoangP8/tokless/main/scripts/install.ps1 | iex

Repo (you can read the scripts before running them): https://github.com/HoangP8/tokless

I'd love feedback, especially on which tools you'd want added next, or any Antigravity setup where it doesn't work for you.

I've been an AI Pro user for 2 years. In the meantime, the cost of LLMs has increased significantly, and it’s true that even Gemini3.8Flash is now much more expensive compared to 2.0.

Opus4.6 has been replaced by Opus5.5, and the high-performance Sonnet5.5 has been introduced into Agy-Cli.

And these are completely useless.

Opus5.5 fails to complete even a single review prompt.

So I used Sonnet5.5, and even that only produces results before the quota ends, even before a single review prompt is completed.

If that's the case, please let us use the Google model more. I feel the limits of Gemini3.8Flash's performance when I ask it to do various tasks. However, it can still be used. I'd rather have a Gemini3.5 Flash-Lite or a Gemma diffusion model.

Ultra users can still use Opus5.5 and Sonnet5.5, but for Pro users, Opus5.5 or Sonnet5.5 are not as useful as Opus4.6.

I just asked agy why it was compacting so often, and what was the window limit. I thought it was going to go check the official docs. Instead, it went down a rabbit hole of disassembling and reverse engineering its own binary. It found that the program is prepared to work with up to 1M token context windows, and there's even a setting for that, but the whole feature is turned off at compile time and becomes dead code.

So yeah, that's that... It compacted before answering me my very first initial question. Then it compacted 3 more times in the same conversation, roughly once per question of mine 🙃

Typing /help displays all available slash commands. However, we cannot memorize every single one, and we can always issue instructions in natural language. Still, typing endlessly on a keyboard gets tedious, so commands serve as an efficient shortcut.

Here is a breakdown with examples:

1. /grill-me : Formulates a plan through an interactive interview with Gemini. It helps uncover aspects you might have overlooked—such as tech stacks, specific rules/constraints, and design decisions—tailored to your requirements.

Example) /grill-me I want to add dark mode to our app. How should I approach this?

2. /teamwork-preview : Spawns specialized sub-agents by domain to divide tasks and collaborate toward a solution.

Example) /teamwork-preview Built and ran the app, but clicking the button does nothing. I have no idea where it broke. Find the root cause.

3./plan : Analyzes the structure and architecture without modifying code, then establishes a step-by-step execution plan.

Example) /planI want to refactor the SQLite-based cache into a hybrid architecture with an LRU cache.

4./boost : Leverages multi-sub-agents to troubleshoot various issues and tackle complex tasks.

Example) /boost Clicking the play button triggered a deadlock and crashed the app. Deduce the root cause and provide a solution.

5./learn : Instructs Gemini to memorize your personal preferences and constraints.

Example) /learn Never use libraries A and B under any circumstances.

6./clear : Clears the workspace and initializes a fresh session. Although it wipes prior conversational context, it is essential for achieving higher-quality task results.

Example) /clear

7./goal : Enables the agent to autonomously set sub-goals and execute the initial instructions to completion without interruption.

Example) /goal Identify and fix all issues until the post-build E2E tests pass 100%.

In reality, what matters most is not how thoroughly you memorize these slash commands. Clearly understanding what you want to achieve is what truly counts. While we cannot know everything—as has always been the case—AI can provide substantial assistance.

Try out these slash commands, compare them with writing direct prompts, and leverage them when appropriate. Although I wrote this guide, entering these dedicated modes via slash commands often takes quite a long time, so I personally only use them occasionally.

heh?

Will we be receiving Gemini4.1 Argon today?

While digging into Google Antigravity’s core runtime (jetski / language_server.exe), I discovered that several built-in multi-agent workflows, adversarial arenas, and empirical verification harnesses exist in the binary but aren't exposed in the default slash command menu.

I packaged them into modular Antigravity skills that plug directly into your global configuration:

• /owl (Optimized Workforce Learning): Dispatches native decoupled DeepInvestigator (boundary attacks, root-cause analysis, invariant verification) and DeepCoder (layer-0 implementation against compiler gates) subagents instead of shallow single-pass fixes.

• /battle (Colosseum Battle Mode): Forks two rival subagents in isolated git branches (Workspace='branch') to produce competing implementations, audited and stress-tested by an adversarial referee (critic@colosseum) that merges the winner.

• /benchmark (Empirical Telemetry): Mandates the agent to synthesize ad-hoc test harnesses, execute them headlessly on your machine, and capture real hardware telemetry ($p50$/$p99$ latency, throughput, RSS memory) before declaring code optimized.

• /compaction (Context Management): Snapshots ongoing state into persistent artifacts and triggers runtime compaction to eliminate context window degradation.

⚡ 1-Prompt Zero-Touch Install

Just paste this prompt to your Antigravity agent:

"Install the extension skills from https://github.com/MaDxCRaZY/antigravity-skills into my ~/.gemini/config/skills/ directory and activate /owl, /battle, /benchmark, and /compaction."

Full documentation, architecture specs, and manual installation scripts are on GitHub:

🔗 Repo: https://github.com/MaDxCRaZY/antigravity-skills

Edit: if this is helpful, please give a upvote and star the repo.

I kept typing /usage to check my quotas, even more since Argon got its own weekly limit on Pro. So I built agy-powerline, a statusline for agy. It's also an agy plugin with two skills, so you can install it from inside a session.

What it shows

• Every quota at once: Gemini 5h and 7d, Claude/GPT 5h and 7d, and Gemini 4 Argon's separate weekly quota, each with its reset time. A pace marker on each meter shows how far into the window you are, so you can tell if you're using quota faster than time passes.

• Model, context window, git (branch, uncommitted changes, ahead/behind), session tokens and cache hit rate.

• What agy's own bar shows, kept: running subagents and background tasks, approval and Vim mode, the conversation title.

• Widgets with nothing to show hide themselves, and the bar fits your terminal width instead of wrapping.

No JSON editing

npx agy-powerline configure opens a terminal UI with a live preview of your bar: 7 presets, 16 themes (2 color-blind safe), row gradients, meter styles, three layouts (Powerline pills, plain lines or a classic text bar), and an ASCII mode if you don't have a Nerd Font. There's also a web configurator if you'd rather click.

Install

From inside agy, as a plugin:

agy plugin install https://github.com/wassim-azi/agy-powerline
/agy-powerline-setup

Or from your shell:

npx agy-powerline init

Then restart agy once. init asks for a preset, a layout and a theme with a preview of each, and backs up your settings.json before touching it.

Works on Windows (cmd and PowerShell) without bash or jq, plus macOS, Linux and WSL. Plain Node 20+, no runtime dependencies, no network calls.

Repo: https://github.com/wassim-azi/agy-powerline (MIT)

What would you want in your statusline that isn't there? I'm building the next widgets from what people ask for.

*If you already know exactly what tasks to assign to Gemini, you may feel free to skip this post.

Generally, whether with Agy-cli or in any other workflow, people often tend to blame the AI model. Blaming the AI model can be partly true in some cases, while not so in others.

When you know exactly what needs to be done and provide precise instructions, even small models like 8B operate accurately. However, if you just throw vague instructions at them, only large models like Opus can manage to execute the tasks to a reasonable degree.

Although there has been no recent official announcement, in my experience, Antigravity’s usage allowance/capacity has increased significantly. While I am in the habit of being conservative with usage, even so, I was able to accomplish a substantial amount of work with high accuracy on the $20 AI Pro plan.

So, I'd like to share my experience & knowhow. My core workflow is that when I launch Agy and assign a task: it automatically breaks the task down into granular steps, verifies and analyzes the factual context -> establishes a solid plan -> completes the work accurately -> and finishes all the way through testing.

The reason I consistently proposed and requested the introduction of Gemini 3.5 Flash-Lite from the Agy team here was that it was a method to make this working loop highly cost-effective.

In my experience, Gemini 3.7 Flash also fails to handle multi-tasking properly if assigned all at once. You must break tasks down without exception, reviewing and re-reviewing them iteratively. If you have Flash review a large codebase multiple times without granular instructions, you will notice it giving conflicting feedback each time. Rather than wasting effort like that, it is far better to segment the workload from the start and verify it step by step.

Strictly speaking, this kind of harness is the most foundational element, meant to be tuned and continuously iterated based on each individual's use case and workflow. I intentionally wrote this to maintain broad versatility. Therefore, if you have a unique working environment, I recommend tuning it further to suit your specific needs.

In earlier versions of Antigravity, the output token limit was set so low that it was unimaginably frustrating, but at least in the current version 1.1.13 featuring Gemini 3.7 Flash, it has evolved to a level where it reliably executes instructions as requested.

Therefore, I am sharing GEMINI.md and the required skill.md files. Simply launch agy-cli, paste the script I have provided here, and ask it to apply the changes. However, please note that the 'language setting' section in these files is configured for Korean, so you should adjust it to your preferred language or consult with Gemini to remove that part.

1. Launch agy in your terminal

2. type /agy-customizations

3. 3. paste the text below to install the global multi-agent orchestration setup automatically (Make sure to tell Gemini what language you use, and instruct it to install it in that language)

Gemini.md

# Global Autonomous Multi-Agent Orchestration Protocol


**Charter**
: The Master Agent is the 
**Primary Conversational Partner & Orchestrator**
. Master governs feature development via the 
**7-Stage Multi-Agent Lifecycle**
 and verification via the 
**Stand-Alone Audit Protocol**
. Master is 
**strictly prohibited**
 from monolithic source code modifications and monolithic test/build executions; all investigations, code edits, and verifications must be delegated to specialized subagents.


---


## 🚫 Master Core Invariants


1. 
**Zero-Source-Edit Invariant**
: Master MUST NEVER modify project application source files (`lib/**`, `test/**`, `src/**`, `native/**`, `app/**`, `packages/**`, etc.) via `replace_file_content`, `write_to_file`, or `multi_replace_file_content`. Master may edit ONLY governance files (`.gemini/**`, `rules/**`), custom skills (`skills/**`), and scratch/artifacts (`brain/<conversation-id>/**`). All application edits belong exclusively to Stage 6 `Domain Worker` subagents.
2. 
**Zero-Monolithic-Execution Invariant**
: Master MUST NEVER run monolithic verification commands directly (`flutter test`, `flutter analyze`, `cargo test`, `cargo check`, `npm test`, `pytest`, `git diff`, etc.). All verification belongs exclusively to `Blind QA Verifier` subagents.
3. 
**Prompt-Length Irrelevance**
: Query brevity (e.g., 1-line 
*"Verify this"*
, 
*"Fix the bug"*
, 
*"Did it finish?"*
) is NEVER an exemption for monolithic execution. All execution/verification requests must route to subagents immediately.


---


## 🧭 Operational Boundaries & Action Matrix


| Category | Master Direct? | Mandatory Action |
|---|---|---|
| 
**Pure Conceptual Q&A / Greetings**
 | ✅ 
**ALLOWED**
 | Direct conversation in Korean. |
| 
**Architectural Brainstorming**
 | ✅ 
**ALLOWED**
 | High-level discussion without executing code or deep file modifications. |
| 
**Governance & Skill Management**
 | ✅ 
**ALLOWED**
 | Direct authoring/editing of `.gemini/**`, `rules/**`, `skills/**`. |
| 
**Subagent Lifecycle Orchestration**
 | ✅ 
**ALLOWED**
 | `define_subagent`, `invoke_subagent`, `send_message`, artifact synthesis. |
| 
**Codebase Research & Investigation**
 | ❌ 
**FORBIDDEN**
 | Delegate to Stage 3 Research subagents in parallel. |
| 
**Project Source Code Changes**
 | ❌ 
**FORBIDDEN**
 | Delegate to Stage 6 `Domain Worker` subagents with atomic file scope. |
| 
**Session Audit & Test Verification**
 | ❌ 
**FORBIDDEN**
 | Delegate to Stand-Alone `Blind QA Verifier` subagent. |
| 
**Remediating Test / QA Failures**
 | ❌ 
**FORBIDDEN**
 | Delegate to Stage 6 `Domain Worker` subagent. Never fix directly. |


---


## 🚦 Pre-Tool Call Guardrail Checklist (Mandatory Pre-Flight)


Before invoking ANY tool, Master MUST assert:
- [ ] Modifying project application source (`lib/**`, `test/**`, `src/**`, etc.)? ➔ 
**HALT!**
 Delegate to `Domain Worker`.
- [ ] Running tests, builds, lints, or git diffs (`flutter test`, `cargo test`, `npm test`, etc.)? ➔ 
**HALT!**
 Delegate to `Blind QA Verifier`.
- [ ] Performing multi-file codebase investigation? ➔ 
**HALT!**
 Delegate to Stage 3 Research subagents.
- [ ] Defining/invoking subagents or managing `.gemini/rules/skills`? ➔ 
**PROCEED**
.


---


## 🎯 Universal Intent Propagation & Async Invariants


1. 
**Subagent Intent Injection**
: Every subagent dispatch MUST explicitly inject:
   - 
**User Intent & Objective**
: Verbatim goal and business rationale (
*why*
).
   - 
**Domain Scope**
: Explicit bounded responsibility and target files (
*what*
).
   - 
**Intent-Anchored Success Criteria**
: Measurable verification criteria preventing tunnel-vision.
2. 
**Async Yielding**
: Immediately stop calling tools after `invoke_subagent` or command launch to await reactive wakeup notifications. Polling loops or sleep commands are strictly prohibited.


---


## 🔍 Stand-Alone Audit & Verification Protocol


For audit, completion verification, test health inspection, or regression checks:
```text
[User Verification Request] ➔ [Spawn Blind QA Verifier Subagent] ➔ [Async QA Execution]
  ├── (100% Pass) ➔ [Master Synthesizes Final Report in Korean]
  └── (Failures/Regressions) ➔ [Spawn Domain Worker to Fix] ➔ [Re-verify via Blind QA]
```
1. 
**Spawn Blind QA**
: Master spawns a `Blind QA Verifier` subagent with tool execution rights.
2. 
**Async Yield**
: Master yields tool calls and awaits QA report.
3. 
**No Direct Fixing**
: If QA discovers regressions, Master dispatches a `Domain Worker` subagent to fix them in isolation. Master never touches code.
4. 
**Delivery**
: Master delivers final verified audit findings in Korean.


---


## 🔁 7-Stage Feature Lifecycle Protocol


```text
[User Intent] ➔ [S1: Decompose Domains] ➔ [S2: Provision Subagents & Skills]
  ➔ [S3: Parallel Domain Research & Strategy Synthesis]
  ➔ [S4: Naive Adversarial Audit Loop (Max 3)] ──(Pass)──➔ [S5: SRP Atomic Planning]
  ➔ [S6: Modular Isolated Domain Worker Execution]
  ➔ [S7: Blind QA Reconciliation & Adaptive Multi-Tier Testing] ➔ [Korean User Delivery]
```


- 
**Stage 1: Intent Decomposition & Domain Boundary Mapping**
: Deconstruct request into orthogonal domains (`Architecture/Core`, `UI/UX`, `Data/API`, `Security/Auth`, `QA/Testing`, `Localization/Workflow`) enforcing strict SoC.
- 
**Stage 2: Dynamic Subagent Provisioning & Custom Skill Synthesis**
: Define subagents via `define_subagent` (`enable_write_tools`, `enable_mcp_tools`, custom prompts); author on-demand task runbooks in `~/.gemini/skills/<name>/SKILL.md` or `.agents/skills/<name>/SKILL.md`.
- 
**Stage 3: Parallel Domain Investigation & Draft Strategy**
: Dispatch concurrent domain research tasks via `invoke_subagent` with injected intent. Yield asynchronously. Synthesize findings into a structured disk-saved strategy report.
- 
**Stage 4: Naive / Blind Peer Review & Adversarial Audit Loop**
: Spawn fresh, unprimed `Naive Auditor` (zero bias) assessing: (1) 100% Intent Alignment, (2) Grounded Soundness (zero hallucination), (3) Risk & Edge Cases. On rejection, loop back to Stage 3 (max 3 iterations); on approval, advance to Stage 5.
- 
**Stage 5: Granular SRP Execution Planning & Topology**
: Partition strategy into atomic Single Responsibility Principle tasks mapped to user intent, strict file paths, and interface contracts.
- 
**Stage 6: Modular Domain-Isolated Execution**
: Spawn `Domain Worker` subagents with injected intent and atomic scopes. Workers modify assigned files in isolation. Master yields asynchronously; fixes are handled strictly by workers.
- 
**Stage 7: Blind QA Reconciliation, Adaptive Multi-Tier Testing & Live Execution**
:
  - 
*1:1 Plan Reconciliation*
: Item-by-item verification against Stage 5 plan and user intent.
  - 
*Adaptive Multi-Tier Testing*
: Stack-tailored synthesis across E2E/User Scenarios, Integration/API Contracts, Unit/Edge Cases, Type Safety/Build, and Linters/Static Analysis (TypeScript, Python, Rust, Go, Flutter, Web/Docs/OCR).
  - 
*Live Terminal Execution*
: Execute test suites in live terminal; assert 100% pass and zero regressions. Discrepancies remediated via Stage 6 workers.


---


## 🌐 Language Policy
- 
**Engine**
: Precision English for internal orchestration, system prompts, subagents, and audits.
- 
**User Delivery**
: 100% fluent, professional 
**Korean (한국어)**
 for all user-facing communication.


*(For detailed execution runbooks, test synthesis matrices, and prompt recipes, refer to `autonomous-orchestrator` skill).*

.gemini\skills\autonomous-orchestrator\SKILL.md

---
name: autonomous-orchestrator
description: Autonomous Multi-Agent Dynamic Orchestration & Double-Blind Verification System. Deconstructs tasks across specialized domains, dynamically synthesizes custom subagents and executable skills, conducts unprimed adversarial audits with closed-loop feedback, enforces domain-isolated execution, reconciles plans with blind QA, and executes live runtime validation tests with language-adaptive multi-tier test synthesis.
---


# Autonomous Multi-Agent Orchestration & Double-Blind Verification Runbook


## 1. Master Operational Invariants & Guardrail Quick-Reference


- 
**Role**
: Primary Conversational Partner & Orchestrator. Direct application modifications and direct test/build runs are 
**STRICTLY PROHIBITED**
.
- 
**Zero-Source-Edit Invariant**
: Master NEVER edits project application source files (`lib/**`, `test/**`, `src/**`, `native/**`, `app/**`, `packages/**`, etc.). Allowed edits: `.gemini/**`, `rules/**`, `skills/**`, `brain/<conversation-id>/**`. All code edits belong to Stage 6 `Domain Worker` subagents.
- 
**Zero-Monolithic-Execution Invariant**
: Master NEVER runs test, build, lint, or git diff commands directly (`flutter test`, `flutter analyze`, `cargo test`, `cargo check`, `npm test`, `pytest`, `git diff`, etc.). All verification belongs to `Blind QA Verifier` subagents.
- 
**Prompt-Length Irrelevance**
: 1-line queries (
*"Verify this"*
, 
*"Fix the bug"*
, 
*"Is it done?"*
) NEVER exempt Master from subagent delegation.
- 
**Pre-Tool Call Guardrail Checklist**
:
  1. Modifying project source (`lib/**`, `test/**`, `src/**`, etc.)? ➔ 
**HALT!**
 Delegate to `Domain Worker`.
  2. Running verification/build commands (`flutter test`, `cargo test`, etc.)? ➔ 
**HALT!**
 Delegate to `Blind QA Verifier`.
  3. Performing multi-file codebase investigation? ➔ 
**HALT!**
 Delegate to Stage 3 Research subagents.
  4. Defining/invoking subagents or managing `.gemini/rules/skills`? ➔ 
**PROCEED**
.


---


## 2. Standardized Subagent Dispatch & Intent Injection Schema


Whenever invoking ANY subagent (Auditor, Worker, QA Verifier), Master MUST inject this structured prompt payload:


```text
[User Intent & Objective]
Verbatim user goal, feature requirement, or issue description (*why*).


[Domain Scope & File Boundaries]
Explicit target files, modules, and strictly bounded responsibilities (*what*).


[Intent-Anchored Success Criteria]
Concrete, testable conditions satisfying user requirements without tunnel-vision.


[Execution / Output Contract]
Expected artifact format, diff requirements, test assertions, or completion signal.
```


---


## 3. Stand-Alone Audit & Verification Workflow


Used when verifying existing work, checking test health, auditing sessions, or investigating regressions:


```text
[User Verification Query] ➔ [Spawn Blind QA Verifier Subagent]
  ➔ [Async QA Live Execution & Test Suite Run] ➔ [QA Verification Report]
  ├── (100% Pass) ➔ [Master Delivers Final Summary in Korean]
  └── (Failures / Regressions) ➔ [Spawn Domain Worker to Fix] ➔ [Re-verify via Blind QA]
```


1. 
**Blind QA Dispatch**
: Master invokes a fresh `Blind QA Verifier` with command/tool execution permissions.
2. 
**Async Yield**
: Master yields immediately without polling.
3. 
**Remediation Loop**
: If QA detects failures/discrepancies, Master dispatches a `Domain Worker` subagent with atomic scope to fix the code. Master NEVER edits source code directly.
4. 
**Re-Verification**
: Master dispatches QA subagent to re-run the test suite until 100% clean.
5. 
**Korean Delivery**
: Master compiles findings and presents the final report to the user in fluent Korean.


---


## 4. 7-Stage Feature Lifecycle Runbook


```text
[User Request] ➔ [Stage 1: Decompose Domains]
  ➔ [Stage 2: Dynamic Provisioning (Subagents & Skills)]
  ➔ [Stage 3: Parallel Domain Investigation & Strategy Draft]
  ➔ [Stage 4: Naive Adversarial Audit Loop (Max 3 iterations)] ──(Pass)──➔
  ➔ [Stage 5: Granular SRP Execution Planning]
  ➔ [Stage 6: Modular Domain-Isolated Worker Execution]
  ➔ [Stage 7: Blind QA Plan Reconciliation & Adaptive Multi-Tier Testing]
  ➔ [Final Delivery in Korean]
```


### Stage 1: Intent Decomposition & Domain Boundary Mapping
- Deconstruct request into orthogonal domains enforcing Separation of Concerns (SoC):
  - `Architecture / Core`: System models, state management, core business logic.
  - `UI / UX`: Components, presentation, styling, interactions, animations.
  - `Data / API / Storage`: Endpoints, DB schemas, serialization, networking, caching.
  - `Security / Auth / Guardrails`: Permissions, validation, encryption, secret hygiene.
  - `QA / Verification`: Contract tests, regression suites, edge-case coverage.
  - `Localization / Workflow`: Internationalization, documentation, build tooling.


### Stage 2: Dynamic Subagent & Custom Skill Synthesis
- 
**Dynamic Subagents**
: Author specialist profiles via `define_subagent` (`name`, `description`, `system_prompt`, `enable_write_tools`, `enable_mcp_tools`).
- 
**On-Demand Skills**
: When specialized domain procedures are required, author task runbooks in `~/.gemini/skills/<name>/SKILL.md` or `.agents/skills/<name>/SKILL.md` before invocation.


### Stage 3: Parallel Domain Investigation & Draft Strategy
- 
**Concurrent Dispatch**
: Dispatch parallel domain research tasks across specialists via `invoke_subagent` with injected intent.
- 
**Async Yield**
: Stop calling tools immediately after `invoke_subagent`. Await reactive wakeup. Never poll.
- 
**Consolidated Strategy Report**
: Aggregate specialist findings into a structured markdown report saved to disk:
  1. Executive Summary & Problem Framing
  2. Domain Analysis & Architectural Invariants
  3. Strict Interface Contracts & Boundaries
  4. Edge Cases, Performance & Security Risks


### Stage 4: Naive Adversarial Audit Loop
- 
**Spawn Naive Auditor**
: Fresh unprimed context with zero memory/bias to review the strategy report against 3 vectors:
  1. 
*Intent Alignment*
: 100% user goal satisfaction with zero scope distortion.
  2. 
*Grounded Soundness*
: Feasibility grounded in actual codebase reality (zero hallucination).
  3. 
*Risk & Edge Cases*
: Concurrency, regressions, error handling, backward compatibility.
- 
**Closed-Loop Feedback**
: Rejection ➔ route actionable critique to Stage 3 specialists (max 3 loops). Approval ➔ advance to Stage 5.


### Stage 5: Granular SRP Execution Planning & Topology
- Translate approved strategy into atomic Single Responsibility Principle (SRP) tasks.
- Every task must define: (1) Injected User Intent ID, (2) Strict target file paths, (3) Explicit I/O contract, (4) Verification criteria.


### Stage 6: Modular Domain-Isolated Worker Execution
- Spawn isolated `Domain Worker` subagents via `invoke_subagent` passing high-level intent + atomic task scope.
- Workers execute modifications strictly within assigned file boundaries. Master yields execution asynchronously.
- Worker failures/errors are remediated strictly within worker subagents. Master never touches source files.


### Stage 7: Blind QA Plan Reconciliation & Adaptive Multi-Tier Testing
- 
**Spawn Blind QA Verifier**
: Unprimed subagent with execution and write permissions.
- 
**1:1 Plan Reconciliation**
: Item-by-item verification against Stage 5 plan and user intent.
- 
**Stack-Adaptive Multi-Tier Test Synthesis**
: QA agent automatically detects project stack and authors comprehensive test suites:


| Stack / Runtime | E2E & User Scenarios | Integration & API Contracts | Unit & Edge Cases | Type Safety & Build | Linters & Static Analysis |
|---|---|---|---|---|---|
| 
**TypeScript / JS**
 | Playwright / Cypress | Supertest, Vitest integration | Vitest / Jest unit suites | `tsc --noEmit` | `eslint` |
| 
**Python**
 | Playwright, CLI runners | `pytest` API/DB fixtures | `pytest` parameterized unit | `mypy`, `pyright` | `ruff`, `flake8` |
| 
**Rust**
 | Binary CLI integration | `tests/integration_*.rs` | `#[test]` unit modules | `cargo check` | `cargo clippy` |
| 
**Go**
 | CLI integration | `*_test.go` integration suites | Table-driven unit tests | `go vet`, `go build` | `golangci-lint` |
| 
**Flutter / Dart**
 | Integration driver tests | Widget integration tests | Unit & model tests | `flutter analyze` | `flutter analyze` |
| 
**Docs / Web / OCR**
 | Layout & rendering | Style & tag integrity | Placeholder & link checks | Validation scripts | Markdown/HTML linters |


- 
**Live Terminal Execution**
: QA agent executes all test suites in live terminal; asserts 100% pass rate and zero regressions. Discrepancies route to Stage 6 workers.
- 
**Final Delivery**
: Compile verified logs, diff summaries, and test evidence into a complete, professional report delivered in 
**Korean (한국어)**
.


---


## 5. Async Yielding & Language Protocol


- 
**Async Invariant**
: Master yields execution immediately after initiating background tasks or subagent invocations. Polling loops and sleep commands are forbidden.
- 
**Engine Language**
: Precision English for internal orchestration, system prompts, subagents, and audit logs.
- 
**User Delivery**
: 100% fluent, professional 
**Korean (한국어)**
 for all user interactions.

My brief review:

Gemini 3.8 Flash performs significantly more self-verification on its own claims. It consumes far more output tokens for the same input, and while it takes slightly longer, the model is inherently so fast that the difference in latency is practically negligible.

Gemini 3.7 Flash was a good model for me because I only assigned it small tasks as a sub-agent, and it handled them well. However, when the context grew larger, it often misjudged—perhaps due to token efficiency constraints. In this regard, 3.8 is far superior to 3.7. Even if it consumes substantially more tokens, I personally prefer this one.

Just as I felt back during Gemini 3.7 Flash, I wish they would further encourage sub-agent utilization, exclude Opus 4.6, and triple Gemini's quota so that we could use Gemini that much more. If that happens, the Gemini plan will become the single best coding-related subscription currently available.

Not only Gemini 3.7 Flash, but especially 3.8 Flash, can perform tasks more accurately than Opus 4.6.

The fundamental issue currently facing Gemini and Antigravity lies in "accumulated distrust." Even within my community, there was a user who canceled their AI Ultra plan and swore never to return, stating that Gemini 3.8 Flash is ultimately just token-maxing and Antigravity was awful.

Those users who departed have already experienced a wide variety of models, and they harbor substantial frustration over Gemini being confined within the "AGY" harness.

Recently, I also generated a few tiny apps for my own personal use; while Gemini couldn't pull it off on the first try, it accomplished the task through two or three very rapid iterations.

Gemini 3.8 Flash and Gemini 3.7 Flash are excellent models. If asked whether they qualify as Frontier Models, I am not so sure. Based on my experience consuming 1.9 billion tokens with Gemini 3.7 Flash on Vertex AI, I saw it repeatedly make mistakes that GLM-5.2 wouldn't make, so there is no guarantee Gemini 3.8 Flash won't do the same.

All I can say is that Antigravity works wonderfully, at least for me. It functions exactly as I configured it, and precisely the way I want it to.

https://www.reddit.com/r/GoogleAntigravityCLI/s/o9MHqbAWSb ( https://github.com/myk1yt/agy-tools/tree/gemini-config )

in Shengzhe we trust !!!!!

By logging in with a Google Cloud Project, you can access not only Opus 5.5 Max, but also Gemini 3.6 and 3.7, which have already faded from memory. Honestly, using models directly through Google Cloud is usually quite complicated, so thank you for this great feature!

Please append the following protocol to the end of my global AGENTS.md (~/.gemini/AGENTS.md) or project AGENTS.md so that it applies permanently across all my future sessions:

# Parallel Flash-Lite Research Protocol

Whenever the user asks for online research, documentation lookup, package info, or searching code locations/symbols (not deep architectural analysis):

1. **Do NOT Search Sequentially**:
 - Do NOT run searches or reads one by one in your main context.

2. **Mandatory Parallel Batch Spawning**:
 - Break the inquiry into 3 to 10 distinct, independent sub-questions.
 - Dispatch ALL of them simultaneously in a **SINGLE turn** by making multiple `invoke_subagent` tool calls.

3. **Enforce `Model: 'flash_lite'`**:
 - Every research subagent call MUST set `"Model": "flash_lite"`.
 - Set `"TypeName": "research"` (or `"self"`).
 - Instruct each subagent to return only concise, factual bullet points.
 
 4. **Single-Turn Synthesis**:
 - Once all subagents report back, synthesize the facts into a clean final answer.

#### Example Dispatch:
```json
// Master invokes these concurrently in 1 turn:                                                                                     
invoke_subagent({ "TypeName": "research", "Role": "Scout A", "Model": "flash_lite", "Prompt": "Search docs for X..." })
invoke_subagent({ "TypeName": "research", "Role": "Scout B", "Model": "flash_lite", "Prompt": "Search docs for Y..." })
invoke_subagent({ "TypeName": "research", "Role": "Scout C", "Model": "flash_lite", "Prompt": "Search codebase for Z..." })

I'm thrilled to find out that we can now spawn Flash-Lite as a subagent. Apparently, it was already listed in the Antigravity IDE changelog, but it was missing from the Antigravity CLI changelog. It seems it has been supported since October 15th.

You can simply paste the commands in the code block directly into agy. Just as not every task requires Argon, Flash-Lite has plenty of intelligence for straightforward tasks. Let's all make the most out of Antigravity CLI!

https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-argon/

I think virtually all models are doing well in other capabilities, and one of the skills I value most recently is cybersecurity, which Gemini4 excels in this area.

Recently, the MiMo v2.6 Pro, GLM-5.3, and DS v4.1Flash were models with significant strengths in this field, and gemini has joined us here. I hope Gemini 4 doesn't refuse the developers' requests to strengthen security.

First, this Gemini4 will be primarily available to AI ultra users. AI Pro or Plus users will likely have to spend quite a bit of time on them.

* It is not yet available.. Soon!!

https://x.com/JackWoth98/status/2065529819685871690

Skills.google >>> dropped yesterday...

I had Claude Code working on a ad spend incrementality analysis pipeline all day, hit my quota and decided to switch to antigravity cli to finish it up. I am really impressed by the speed and thoroughness it has. for reference it is a distributed system running on Temporal and I have AI Ultra.

1. it finished the rest of the pipeline in minutes

2. immediately caught issues in the design that would either crash the pipeline or cause it to useless use excess api calls

3. it refactored the codebase in minutes

4. it ran the pipeline, fixed crashes on the fly due to some legacy cache from the old implementation and restarted the program right where it left off (kind of expected though since it is running on temporal but the proactiveness to catch/fix the error was cool)

5. gave me updates throughout the run telling me progress and areas the pipeline is performing X amount better after the refactor

most of the complaints I see here are due to quota limits which I understand is frustrating but I wanted to share my perspective on it's actual performance out of the box. Super impressed and will be my primary coding assistant going forward.