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:

Navigate to buganizer.corp.google.com
Fill required fields (title, description, priority, assignee)
Verify submission via DOM inspection
Return the created issue ID

Find Component ID:

Navigate to go/componentsearch
Search by team name, product name, or keyword
Extract the numeric component ID
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

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:

Navigate to moma.corp.google.com (explicitly not go/moma — the full URL is required for browser automation)
Enter a search query in the search box
Wait for results to load
Open and review the top 3-5 results
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

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:

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:

The agent navigates to go/moma
The browser follows the redirect to moma.corp.google.com
The agent's page reference becomes stale (it thinks it is on go/moma)
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:

Write a prompting profile documenting the tool's URL structure, DOM elements, and interaction patterns
Store it in the prompting/browser/ directory
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)