Antigravity Agentic Workflow

gistfile1.txt

### User Input

Once I give you a task, explain step-by-step what process you follow.

### Planner Response

When you give me a task, I follow a structured **Agentic Workflow** designed to ensure precision, transparency, and adherence to your project's standards.

Here is the step-by-step process I follow:

### 1. Analysis & Contextualization
*   **Input Processing**: I analyze your request along with the current state (open files, cursor position, terminal output).
*   **Rule Check**: I consult `GEMINI.md` (your project's "Constitution") to ensure I follow established patterns, architectural rules, and the "Golden Rule" (ask when unsure).
*   **Scope Determination**: I decide if this is a simple "chat" request (answering a question) or a complex "task" (modifying code).

### 2. Planning (The Task Boundary)
If the request involves coding or complex actions, I enter **Task Mode**:
*   **Initialize Task**: I call the `task_boundary` tool. This creates a dedicated UI block to track my progress (Planning → Execution → Verification).
*   **Create Checklist**: I update `task.md` with a detailed breakdown of the work.
*   **Design Plan**: For significant changes, I create an `implementation_plan.md`.
    *   I outline the goal, proposed changes (file by file), and verification strategy.
    *   I may use `notify_user` to ask for your approval on this plan before writing code.

### 3. Execution (The Loop)
I iterate through my checklist, updating the `task_boundary` status as I go:
*   **Research**: I use tools like `grep_search`, `find_by_name`, and `view_file` to locate relevant code and understand existing patterns (following the "Pattern-First" principle).
*   **Implementation**:
    *   I use `replace_file_content` for single-block edits.
    *   I use `multi_replace_file_content` for scattered edits in a file.
    *   I use `write_to_file` to create new components or tests.
*   **Course Correction**: If I encounter unexpected complexity, I pause, update the plan, and inform you.

### 4. Verification
I do not consider a task done until it is verified:
*   **Automated Checks**: I run `npm run typecheck`, `npm run lint`, and `npm run test` to ensure no regressions.
*   **Manual Verification**: I may ask you to verify UI changes or specific flows.
*   **Documentation**: I create or update `walkthrough.md` to summarize what was changed, why, and how to test it.

### 5. Completion
*   I mark items as complete `[x]` in `task.md`.
*   I exit Task Mode and provide a final summary of the work accomplished.

---

**Ready when you are!** Give me a task, and I'll start this engine.

### User Input

Give me the purpose of all the tools available to you (for example, task_boundary, grep_search, etc)

### Planner Response

Here is a breakdown of the tools available to me and their specific purposes, categorized by function:

### 🧠 Agentic & Task Management
These tools help me organize my work, track progress, and communicate with you effectively.

*   **`task_boundary`**: **CRITICAL**. This is the primary tool for managing complex tasks. It creates the "Task View" UI, allowing me to define a task name, summary, and current status. I use it to switch between Planning, Execution, and Verification modes.
*   **`notify_user`**: The **ONLY** way to communicate with you while I am in "Task Mode". I use this to ask clarifying questions, request approval for plans, or ask you to review files/artifacts.

### 🔍 Search & Navigation
These tools allow me to explore the codebase and find relevant files or code snippets.

*   **`list_dir`**: Lists the contents (files and subdirectories) of a specific directory.
*   **`find_by_name`**: Searches for files or directories by name using glob patterns (e.g., `*.tsx`).
*   **`grep_search`**: Uses `ripgrep` to find exact text matches or regex patterns within files.
*   **`codebase_search`**: Finds code snippets semantically related to a query (best for finding "how something is implemented" rather than exact strings).
*   **`search_in_file`**: Returns code snippets within a specific file that are relevant to a query.
*   **`view_file`**: Reads the contents of a file (text or binary).
*   **`view_file_outline`**: Shows the structure of a file (classes, functions) without reading the entire content.
*   **`view_code_item`**: Views specific nodes (functions/classes) within a file.

### 📝 File Manipulation
These tools allow me to create and modify code.

*   **`write_to_file`**: Creates a new file with specified content or overwrites an existing one (if `Overwrite` is true).
*   **`replace_file_content`**: Replaces a **single contiguous block** of text in a file.
*   **`multi_replace_file_content`**: Replaces **multiple non-contiguous blocks** of text in the same file in one go.

### 💻 Terminal & Execution
These tools allow me to run commands and interact with the shell.

*   **`run_command`**: Proposes a shell command to run (e.g., `npm run test`). You must approve it.
*   **`command_status`**: Checks the status and output of a background command.
*   **`send_command_input`**: Sends input to a running command (useful for interactive processes).
*   **`read_terminal`**: Reads the output history of a specific terminal process.

### 🌐 Web & Browser
These tools allow me to interact with the internet and web pages.

*   **`browser_subagent`**: Spawns a sub-agent to perform complex actions in a real browser (clicking, typing, navigating).
*   **`read_url_content`**: Fetches the text content of a URL (converts HTML to markdown).
*   **`view_content_chunk`**: Views a specific section of a document fetched by `read_url_content`.
*   **`search_web`**: Performs a Google search and returns a summary of results.

### 🎨 Design & Assets
*   **`generate_image`**: Generates images or UI mockups based on a text prompt.

### 🔌 MCP (Model Context Protocol)
These tools connect to external services (specifically Firebase in your current setup).

*   **`list_resources` / `read_resource`**: Generic tools to list and read resources from MCP servers.
*   **`mcp0_firebase_*`**: A suite of tools to interact with Firebase:
    *   **Core**: `login`, `logout`, `init`, `get_environment`, `update_environment`.
    *   **Projects**: `list_projects`, `create_project`, `get_project`.
    *   **Apps**: `list_apps`, `create_app`, `get_sdk_config`, `create_android_sha`.
    *   **Services**: `get_security_rules`.

### User Input

How is the implementation plan generated?

### Planner Response

The **Implementation Plan** is not auto-generated by a background process; **I write it personally** as the first major step of any complex task. It is a deliberate design document that I create to ensure we agree on the "What" and "How" before I touch any code.

Here is the exact process I follow to generate it:

### 1. The Research Phase (PLANNING Mode)
Before writing a single word of the plan, I enter **PLANNING** mode via `task_boundary`. I then use tools like `grep_search` and `view_file` to:
*   Identify the exact files that need modification.
*   Understand the dependencies and potential side effects.
*   Check for existing patterns to copy (following your "Pattern-First" rule).

### 2. Drafting the Content
Once I understand the scope, I structure the plan in my "mind" following the strict template defined in my system instructions:
*   **Goal Description**: A clear summary of what we are achieving.
*   **User Review Required**: I explicitly flag breaking changes, new dependencies, or architectural decisions that need your input.
*   **Proposed Changes**: I group changes by component. For every file, I list:
    *   `[MODIFY]`, `[NEW]`, or `[DELETE]` tags.
    *   A brief description of the logic changes (e.g., "Add `isLoading` state to `SettingsDialog`").
*   **Verification Plan**: I define *exactly* how I will prove it works (e.g., "Run `npm test src/components/ui/settings-dialog.test.tsx`" or "Manual check: Open Settings > Click Profile").

### 3. Writing the Artifact
I use the **`write_to_file`** tool to create or update the file at:
`/home/leon/.gemini/antigravity/brain/[UUID]/implementation_plan.md`

### 4. The Review Loop
I do **not** proceed to coding immediately. I call **`notify_user`** with `BlockedOnUser: true` and point you to the plan.
*   **If you approve**: I switch to **EXECUTION** mode.
*   **If you request changes**: I edit the plan using `replace_file_content` and ask for review again.

This process ensures that I am an **architect first, and a coder second**, preventing wasted effort on incorrect approaches.

### User Input

How is the workflow document generated?

### Planner Response

It depends on which "workflow" document you are referring to, as there are two distinct types in my system. I handle both manually using my tools.

### 1. The Task Walkthrough (`walkthrough.md`)
This is the **"Proof of Work"** document I generate at the *end* of a task to summarize what was done. It is the bookend to the Implementation Plan.

*   **When I generate it**: During the **VERIFICATION** phase, after I have finished coding and testing.
*   **How I generate it**: I use the **`write_to_file`** tool to create or update the file at `/home/leon/.gemini/antigravity/brain/[UUID]/walkthrough.md`.
*   **Content**:
    *   **Changes Made**: A high-level summary of the code modifications.
    *   **Verification Results**: Evidence that it works (e.g., "Ran `npm test` and all passed", "Manual verification of UI").
    *   **Visuals**: I often embed screenshots or screen recordings if I made UI changes.

### 2. Reusable Workflows (`.agent/workflows/*.md`)
These are **Standard Operating Procedures** (SOPs) that allow me to memorize and repeat specific multi-step processes (like "How to deploy" or "How to generate a commit message").

*   **When I generate it**: Only when you explicitly ask me to "create a workflow" for a repetitive task, or if I notice we are doing the same complex thing repeatedly.
*   **How I generate it**: I use **`write_to_file`** to create a markdown file in the `.agent/workflows/` directory (e.g., `.agent/workflows/deploy.md`).
*   **Content**:
    *   **YAML Frontmatter**: Metadata like `description: "How to deploy to staging"`.
    *   **Steps**: A numbered list of instructions or commands.
    *   **Annotations**: I can add `// turbo` to steps to indicate they can be auto-executed without asking for permission every time.

**In summary:** I do not have a "magic button" that auto-generates these. I write them thoughtfully using my file manipulation tools, just like I write code.

### User Input

How is the task workflow document generated?

### Planner Response

You are likely referring to **`task.md`**, which is the living checklist I use to track the specific steps of the *current* active task. It serves as the detailed "workflow" for the immediate job at hand.

Here is how I generate and manage it:

### 1. Creation (The Breakdown)
*   **When**: Immediately after I accept a complex request and enter **PLANNING** mode.
*   **How**: I use the **`write_to_file`** tool to create the file at `/home/leon/.gemini/antigravity/brain/[UUID]/task.md`.
*   **Process**:
    1.  I analyze your request.
    2.  I break it down into granular, logical steps (e.g., "Research", "Create Component", "Update Exports", "Test").
    3.  I write these as a Markdown checklist (using `[ ]` for todo).

### 2. Updates (The Progress Tracking)
*   **When**: Continuously throughout the task, usually right before or after I call the `task_boundary` tool.
*   **How**: I use **`replace_file_content`** (or `multi_replace_file_content`) to edit the file.
*   **Process**:
    *   When I start a sub-task, I change `[ ]` to `[/]` (my custom symbol for "In Progress").
    *   When I finish a sub-task, I change `[/]` to `[x]` (Completed).
    *   If I discover new work is needed, I add new bullet points to the list dynamically.

### 3. The "Task Boundary" Connection
While `task.md` is the *document*, the **`task_boundary`** tool is the *broadcaster*.
*   I update `task.md` to keep a detailed record for myself.
*   I call `task_boundary` to summarize that progress into the high-level UI status you see (e.g., "Implementing Feature X").

**Example `task.md` lifecycle:**
1.  **Start**:
    ```markdown
    - [ ] Analyze `settings-dialog.tsx`
    - [ ] Create `pricing-panel.tsx`
    ```
2.  **Mid-Task**:
    ```markdown
    - [x] Analyze `settings-dialog.tsx`
    - [/] Create `pricing-panel.tsx`
    ```
3.  **End**:
    ```markdown
    - [x] Analyze `settings-dialog.tsx`
    - [x] Create `pricing-panel.tsx`
    ```