---
name: antigravity-browser-prompting
type: analysis
title: "Browser Prompting Profiles — Google Buganizer & Moma Internal Tooling"
description: "Analysis of the Antigravity browser automation prompts for Google's internal tools (Buganizer and Moma): what they reveal about Google's internal infrastructure and how they informed harness design."
tags: [antigravity, browser-prompting, buganizer, moma, google, automation, chrome-devtools, internal-tools]
timestamp: 2026-07-22
---

# Browser Prompting Profiles — Google Buganizer & Moma Internal Tooling

> **Source:** `/Users/alefita/.gemini/antigravity/prompting/browser/`
> **Files analyzed:** `buganizer.corp.google.com.md`, `moma.corp.google.com.md`

---

## 1. Overview

The Antigravity 2.0 harness ships with pre-built browser automation configurations for two of Google's internal tools: **Buganizer** (issue tracker) and **Moma** (internal wiki/search). These prompting profiles instruct the agent on how to navigate, interact with, and extract information from these tools via browser automation (Chrome DevTools MCP).

The existence of these profiles reveals the design philosophy of the Antigravity harness: it was built for **Google-internal workflows** and includes pre-configured automation for the tools Google engineers use daily.

---

## 2. Buganizer — Google's Internal Issue Tracker

### 2.1 What Is Buganizer

**Buganizer** (`buganizer.corp.google.com`) is Google's enterprise-grade issue tracking system. It is the internal equivalent of Jira, used across all Google engineering teams for:
- Bug tracking
- Feature requests
- Incident management
- Sprint planning
- Cross-team coordination

Buganizer organizes issues by **component** — a hierarchical identifier that maps to teams, products, or subsystems. Each component has a numeric ID used in URLs and API calls.

### 2.2 The Automation Prompt

The Buganizer prompt provides three capabilities:

**Create New Issue:**
1. Navigate to `buganizer.corp.google.com`
2. Fill required fields (title, description, priority, assignee)
3. Verify submission via DOM inspection
4. Return the created issue ID

**Find Component ID:**
1. Navigate to `go/componentsearch`
2. Search by team name, product name, or keyword
3. Extract the numeric component ID
4. Return the ID for use in issue URLs

**Component-Specific Issue Creation:**
```
https://buganizer.corp.google.com/issues/new?component={component_id}
```

### 2.3 What This Reveals

| Observation | Implication |
|-------------|------------|
| Direct URL patterns (`/issues/new?component=`) | Buganizer has a predictable REST-like URL scheme |
| `go/componentsearch` shortcut | Google uses internal `go/` shortlinks (similar to `go/links` at other companies) |
| DOM inspection for verification | The prompt relies on scraping, suggesting no stable API was available to the agent |
| Component ID system | Issues are organized in a hierarchical component tree with numeric IDs |
| Required fields | Buganizer enforces structured issue creation (unlike GitHub's freeform) |

### 2.4 Browser Automation Flow

```mermaid
sequenceDiagram
    participant Agent
    participant Chrome DevTools MCP
    participant Buganizer

    Agent->>Chrome DevTools MCP: navigate_page(buganizer.corp.google.com)
    Chrome DevTools MCP->>Buganizer: HTTP GET
    Buganizer-->>Chrome DevTools MCP: HTML response
    Chrome DevTools MCP-->>Agent: Page snapshot

    Agent->>Chrome DevTools MCP: fill_form(title, description, priority, component)
    Chrome DevTools MCP->>Buganizer: Form submission

    Agent->>Chrome DevTools MCP: take_snapshot()
    Chrome DevTools MCP-->>Agent: DOM state (verify issue created)

    Agent-->>Agent: Extract issue ID from DOM
```

---

## 3. Moma — Google's Internal Wiki & Search

### 3.1 What Is Moma

**Moma** (`moma.corp.google.com`) is Google's internal documentation search engine and wiki system. It serves as the central knowledge base for:
- Technical documentation
- Design documents
- Team wikis
- Process documentation
- Internal blog posts

Moma is indexed by Google's internal search infrastructure, providing full-text search across all internal documentation.

### 3.2 The Automation Prompt

The Moma prompt provides a search-and-synthesize workflow:

1. Navigate to `moma.corp.google.com` (explicitly **not** `go/moma` — the full URL is required for browser automation)
2. Enter a search query in the search box
3. Wait for results to load
4. Open and review the top 3-5 results
5. Create a comprehensive report summarizing findings

### 3.3 What This Reveals

| Observation | Implication |
|-------------|------------|
| "not go/moma" explicit instruction | `go/` shortlinks redirect and break browser automation state |
| Full-text search across all docs | Moma has a unified search index (likely powered by Google Search infrastructure) |
| "Top 3-5 links" instruction | Results are ranked by relevance (standard Google Search quality) |
| "Create comprehensive report" | The expected output is synthesis, not raw retrieval |
| No authentication flow mentioned | Browser automation inherits existing Google auth cookies |

### 3.4 Browser Automation Flow

```mermaid
sequenceDiagram
    participant Agent
    participant Chrome DevTools MCP
    participant Moma

    Agent->>Chrome DevTools MCP: navigate_page(moma.corp.google.com)
    Chrome DevTools MCP->>Moma: HTTP GET (with auth cookies)
    Moma-->>Chrome DevTools MCP: Search page

    Agent->>Chrome DevTools MCP: fill(search_box, query)
    Agent->>Chrome DevTools MCP: press_key(Enter)
    Chrome DevTools MCP->>Moma: Search request
    Moma-->>Chrome DevTools MCP: Results page

    loop Top 3-5 results
        Agent->>Chrome DevTools MCP: click(result_link)
        Chrome DevTools MCP->>Moma: Navigate to doc
        Moma-->>Chrome DevTools MCP: Document content
        Agent->>Chrome DevTools MCP: take_snapshot()
        Chrome DevTools MCP-->>Agent: Document text
    end

    Agent-->>Agent: Synthesize report from all documents
```

---

## 4. How These Profiles Informed Antigravity Harness Design

### 4.1 Pre-Built Automation as Design Pattern

The Buganizer and Moma profiles establish a design pattern in the Antigravity harness:

```mermaid
graph TD
    subgraph "Antigravity Harness"
        PROFILES["Browser Prompting Profiles"]
        CDP["Chrome DevTools MCP Server"]
        AGENT["Agent Core"]
    end

    subgraph "External Tools"
        BUGANIZER["Buganizer<br/>(Issue Tracker)"]
        MOMA["Moma<br/>(Wiki/Search)"]
        OTHER["Other Corp Tools"]
    end

    PROFILES -->|"pre-configured<br/>navigation + interaction"| AGENT
    AGENT -->|"tool calls"| CDP
    CDP -->|"browser automation"| BUGANIZER
    CDP -->|"browser automation"| MOMA
    CDP -.->|"extensible"| OTHER
```

The pattern is: **encode tool-specific knowledge as prompting profiles** that the agent loads before interacting with the tool. This separates tool knowledge (how to navigate Buganizer) from agent logic (what to do with the information).

### 4.2 Implications for the Research Harness

The same pattern was applied to Alefita's research setup:
- **Ghidra MCP** has tool-specific instructions for binary analysis workflows
- **NotebookLM MCP** has a complete skill file (`nlm-skill/SKILL.md`, 35,031 bytes) defining research workflows
- **Chrome DevTools MCP** (31 tools) provides the generic browser automation layer

The browser prompting profiles demonstrate that the Antigravity harness was designed to be **tool-aware**: the agent does not just have generic browser automation — it has pre-compiled knowledge about specific web applications.

### 4.3 The Corporate Access Question

The existence of these profiles raises the question: did Alefita have Google-internal access?

**Most likely explanation:** These are **template configurations** shipped with the Antigravity SDK. The AGY SDK is a Google product, and it ships with pre-built configurations for Google's internal tools as reference examples. The profiles use the `*.corp.google.com` domain, suggesting they were designed for Googlers or Google-adjacent engineers.

**Alternative explanation:** The profiles were included as part of the SDK's default configuration and were never actually used by Alefita. They may sit in the prompting directory as artifacts of the SDK installation, similar to how many software packages ship with example configurations.

**Evidence for template status:** The profiles are generic (no team-specific component IDs, no personalized search queries). They read as documentation of how to use the tools, not as records of actual automation sessions.

---

## 5. Technical Details

### 5.1 Chrome DevTools MCP Integration

The browser automation is powered by the Chrome DevTools MCP server, which exposes 31 tools. The relevant tools for Buganizer/Moma interaction:

| Tool | Used For |
|------|----------|
| `navigate_page` | Navigate to tool URL |
| `fill` / `fill_form` | Enter text in search boxes and form fields |
| `click` | Click links, buttons, menu items |
| `press_key` | Submit forms (Enter key) |
| `take_snapshot` | Capture page state for verification |
| `take_screenshot` | Visual verification of page state |
| `wait_for` | Wait for page loads, AJAX requests |
| `list_network_requests` | Monitor API calls made by the tool |

### 5.2 Authentication

Neither profile mentions authentication flows. This suggests:
- Browser automation inherits existing authentication cookies from the Chrome profile
- Google's internal tools use cookie-based SSO (likely Google's internal OAuth)
- The agent does not need to handle login — it operates within an already-authenticated browser session

### 5.3 DOM Interaction Strategy

The profiles rely on DOM inspection (via `take_snapshot`) rather than API calls. This means:
- The agent parses HTML structure to find form fields, links, and results
- Changes to the tool's frontend UI would break the automation
- The approach is fragile but universal (works with any web-based tool)

---

## 6. Broader Context: Google's Internal Tooling Ecosystem

### 6.1 Buganizer vs. Public Alternatives

| Feature | Buganizer | Jira | GitHub Issues |
|---------|-----------|------|---------------|
| **Scale** | Billions of issues | Millions per instance | Repository-scoped |
| **Component hierarchy** | Deep, team-organized | Project-based | Flat (labels) |
| **Search** | Full-text + structured | JQL | GitHub search |
| **API** | Internal REST | REST + GraphQL | REST + GraphQL |
| **Access control** | Google-internal ACL | Role-based | Repository permissions |
| **Integration** | Deep (Piper, Critique, Moma) | Via plugins | GitHub ecosystem |

### 6.2 Moma vs. Public Alternatives

| Feature | Moma | Confluence | Notion |
|---------|------|-----------|--------|
| **Search** | Google Search quality | Full-text | Full-text |
| **Scale** | All Google-internal docs | Workspace-scoped | Workspace-scoped |
| **Content** | Design docs, wikis, blogs | Wikis, docs | Docs, databases |
| **Access** | Google-internal | Role-based | Role-based |

### 6.3 The `go/` Shortlink System

The explicit instruction to use `moma.corp.google.com` rather than `go/moma` reveals Google's internal shortlink system. `go/` links are similar to `bit.ly` but internal:
- `go/moma` -> redirects to `moma.corp.google.com`
- `go/componentsearch` -> redirects to Buganizer's component search
- Hundreds of `go/` links exist for internal tools, teams, and documents

The redirect breaks browser automation because:
1. The agent navigates to `go/moma`
2. The browser follows the redirect to `moma.corp.google.com`
3. The agent's page reference becomes stale (it thinks it is on `go/moma`)
4. Subsequent `fill()` or `click()` calls fail because the page state is mismatched

---

## 7. Significance for the Antigravity Ecosystem

### 7.1 Design Philosophy

The browser prompting profiles reveal the Antigravity harness's core design philosophy: **pre-compile tool-specific knowledge** so the agent does not need to discover tool interfaces at runtime. This is the same philosophy as the Hermes Agent Research Wiki (see [[antigravity-hermes-wiki]]) — compile-time knowledge engineering over reactive discovery.

### 7.2 Extensibility

The pattern is extensible to any web-based tool:
1. Write a prompting profile documenting the tool's URL structure, DOM elements, and interaction patterns
2. Store it in the `prompting/browser/` directory
3. The agent loads the profile before interacting with the tool

This was subsequently applied to Alefita's own infrastructure: the `fitalabs-webfetch` MCP server at `https://api.unifita.app/mcp` (see [[antigravity-mcp-tools]]).

### 7.3 The Chrome DevTools MCP as Universal Adapter

Combined with the Chrome DevTools MCP (31 tools), the browser prompting profiles turn the Antigravity harness into a **universal web automation platform**. Any web application that a human can navigate in Chrome can be automated by the agent, provided a prompting profile documents the interaction patterns.

---

## Cross-References

- [[antigravity-mcp-tools]] — Chrome DevTools MCP server (31 tools) that powers the browser automation
- [[antigravity-hermes-wiki]] — The same compile-time knowledge philosophy applied to the Hermes wiki
- clickfix-handoff — Browser forensics used in the ClickFix incident response (related automation technique)