caelaxie · Oct 20, 2026 · Oct 20, 2026 · caelaxie · Oct 20, 2026
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
@@ -161,6 +161,7 @@ jobs:
 
             const validAgentTools = new Set([
               "send_message",
+              "read_file",
               "view_file",
               "grep_search",
               "find_by_name",
@@ -169,8 +170,10 @@ jobs:
               "search_web",
               "schedule",
               "generate_image",
+              "edit_file",
               "multi_replace_file_content",
               "replace_file_content",
+              "write_file",
               "write_to_file",
               "run_command",
               "manage_task",

diff --git a/skills/architect/SKILL.md b/skills/architect/SKILL.md
@@ -10,7 +10,7 @@ Sketch types, function signatures, class shapes, and module boundaries with `not
 
 ## Start
 
-Open a todolist by writing and updating `<appDataDir>/brain/<conversation-id>/task.md` with `write_to_file` (the system prompt names `<appDataDir>` and `<conversation-id>`). Antigravity has no native todolist tool, so that file is the list. Give it one entry per phase before starting.
+Open a todolist by writing and updating `<appDataDir>/brain/<conversation-id>/task.md` with `write_file` or `write_to_file` (the system prompt names `<appDataDir>` and `<conversation-id>`). Antigravity has no native todolist tool, so that file is the list. Give it one entry per phase before starting.
 
 1. Ground
 2. Sketch
@@ -28,7 +28,7 @@ Skip Phase A only when the work is genuinely greenfield with no surrounding syst
 
 Run the **arena** skill with the design-sketch task and the Phase A grounding artifacts. Pass `references/runner-prompt.md` as each runner's prompt.
 
-Take the runners from the `architect runners` line in `~/.gemini/config/rules/pstack-models.md`, in place of the `arena runners` line. That file is an always-applied rule, already in context when present, so do not `view_file` it. If the rule is not in context or that line is missing, use `pro` and `flash`. Alias and rejected entries follow the runner rules in the **arena** skill's Phase A.
+Take the runners from the `architect runners` line in `~/.gemini/config/rules/pstack-models.md`, in place of the `arena runners` line. That file is an always-applied rule, already in context when present, so do not `read_file` or `view_file` it. If the rule is not in context or that line is missing, use `pro` and `flash`. Alias and rejected entries follow the runner rules in the **arena** skill's Phase A.
 
 Design it twice. Require at least two structurally distinct candidates before synthesis, even when the first looks sufficient. This is the **exhaust-the-design-space** principle skill made concrete. Whole-shape alternatives, not point fixes inside one shape.
 

diff --git a/skills/arena/SKILL.md b/skills/arena/SKILL.md
@@ -6,15 +6,15 @@ disable-model-invocation: true
 
 # Arena
 
-Open a todolist by writing and updating `<appDataDir>/brain/<conversation-id>/task.md` with `write_to_file` (the system prompt names `<appDataDir>` and `<conversation-id>`). Antigravity has no native todolist tool, so that file is the list. Give it one entry per phase (Frame, Fan out, Cross-judge, Pick, Graft, Verify) before launching anything.
+Open a todolist by writing and updating `<appDataDir>/brain/<conversation-id>/task.md` with `write_file` or `write_to_file` (the system prompt names `<appDataDir>` and `<conversation-id>`). Antigravity has no native todolist tool, so that file is the list. Give it one entry per phase (Frame, Fan out, Cross-judge, Pick, Graft, Verify) before launching anything.
 
 ## Phase A: Frame
 
 Every candidate gets the same prompt, so the prompt is the contract.
 
 1. State the artifact each candidate is producing.
 2. Derive the rubric, 3-6 concrete gradeable criteria for what success looks like on *this* task. It is the picker's tool in Phase D. Candidates only see the task.
-3. Pick the runners. Use the `arena runners` line in `~/.gemini/config/rules/pstack-models.md`. That file is an always-applied rule, already in context when present, so do not `view_file` it. If the rule is not in context or that line is missing, default to one each on `Model: "pro"` and `Model: "flash"`. An `inherit`, `auto`, or `inherit-parent` entry in this line or the cross-judge line means the parent model (`Model: "inherit"`). Spawn more runners when the arena covers multiple design directions. Use the same model tier N times when the work is generation-bound rather than judgment-sensitive. Pick each subagent's model tier for the job, per the Subagents section of the **poteto-mode** skill.
+3. Pick the runners. Use the `arena runners` line in `~/.gemini/config/rules/pstack-models.md`. That file is an always-applied rule, already in context when present, so do not `read_file` or `view_file` it. If the rule is not in context or that line is missing, default to one each on `Model: "pro"` and `Model: "flash"`. An `inherit`, `auto`, or `inherit-parent` entry in this line or the cross-judge line means the parent model (`Model: "inherit"`). Spawn more runners when the arena covers multiple design directions. Use the same model tier N times when the work is generation-bound rather than judgment-sensitive. Pick each subagent's model tier for the job, per the Subagents section of the **poteto-mode** skill.
 4. Give each candidate its own output location (a git worktree or `Workspace: "branch"` where possible, otherwise `/tmp/arena-<slug>/candidate-<n>/`), per the **separate-before-serializing-shared-state** principle skill.
 
 ## Phase B: Fan out
@@ -25,7 +25,7 @@ If a candidate produces no output, proceed with N-1 and note the dropout.
 
 ## Phase C: Cross-judge
 
-After all Phase B candidates complete, choose one model tier from the `arena cross-judge pool` line in `~/.gemini/config/rules/pstack-models.md`. That file is an always-applied rule, already in context when present, so do not `view_file` it. If the rule is not in context or that line is missing, choose from `pro` and `flash`. Prefer a different tier from the parent's. Spawn one read-only judge subagent (`TypeName: "research"`) on that tier. It sees the rubric and the candidates by path label, scores each criterion, and recommends a base with rationale. It runs in parallel with your reading in Phase D. Don't spawn it while candidates are still writing.
+After all Phase B candidates complete, choose one model tier from the `arena cross-judge pool` line in `~/.gemini/config/rules/pstack-models.md`. That file is an always-applied rule, already in context when present, so do not `read_file` or `view_file` it. If the rule is not in context or that line is missing, choose from `pro` and `flash`. Prefer a different tier from the parent's. Spawn one read-only judge subagent (`TypeName: "research"`) on that tier. It sees the rubric and the candidates by path label, scores each criterion, and recommends a base with rationale. It runs in parallel with your reading in Phase D. Don't spawn it while candidates are still writing.
 
 ## Phase D: Pick a base
 

diff --git a/skills/figure-it-out/SKILL.md b/skills/figure-it-out/SKILL.md
@@ -10,7 +10,7 @@ When the task matches no playbook, design one. The deliverable before any code i
 
 ## Start
 
-Open a todolist by writing and updating `<appDataDir>/brain/<conversation-id>/task.md` with `write_to_file` (the system prompt names `<appDataDir>` and `<conversation-id>`). Antigravity has no native todolist tool, so that file is the list. Its first item is to read the Principles section of the **poteto-mode** skill. Then add the phases below as todos.
+Open a todolist by writing and updating `<appDataDir>/brain/<conversation-id>/task.md` with `write_file` or `write_to_file` (the system prompt names `<appDataDir>` and `<conversation-id>`). Antigravity has no native todolist tool, so that file is the list. Its first item is to read the Principles section of the **poteto-mode** skill. Then add the phases below as todos.
 
 ## Phase A: Frame
 

diff --git a/skills/how/SKILL.md b/skills/how/SKILL.md
@@ -8,7 +8,7 @@ disable-model-invocation: true
 
 Explore the codebase to answer "how does X work?" questions. Produce architectural explanations at the level of a senior engineer onboarding onto a subsystem, enough to build a working mental model, not so much that it reads like annotated source code.
 
-Every spawn uses `invoke_subagent` with `TypeName: "research"`. Explorers use the `how explorer` line in `~/.gemini/config/rules/pstack-models.md` (default `Model: "flash"`), and every explainer uses the `how explainer` line (default `Model: "pro"`). That file is an always-applied rule, already in context when present, so do not `view_file` it. Set `Model` to that line's value, or to the default if the rule is not in context or the line is missing. Use `Model: "inherit"` when the value is `inherit`, `auto`, or `inherit-parent`. Pick each subagent's model tier for the job, per the Subagents section of the **poteto-mode** skill.
+Every spawn uses `invoke_subagent` with `TypeName: "research"`. Explorers use the `how explorer` line in `~/.gemini/config/rules/pstack-models.md` (default `Model: "flash"`), and every explainer uses the `how explainer` line (default `Model: "pro"`). That file is an always-applied rule, already in context when present, so do not `read_file` or `view_file` it. Set `Model` to that line's value, or to the default if the rule is not in context or the line is missing. Use `Model: "inherit"` when the value is `inherit`, `auto`, or `inherit-parent`. Pick each subagent's model tier for the job, per the Subagents section of the **poteto-mode** skill.
 
 ## 1. Assess complexity
 

diff --git a/skills/how/references/explainer-prompt.md b/skills/how/references/explainer-prompt.md
@@ -20,7 +20,7 @@ The explorers each investigated a different angle of the same subsystem. Their f
 
 Write an explanation a senior engineer unfamiliar with this area could read and walk away with a solid mental model, understanding the architecture well enough to start working in it confidently.
 
-You have read-only access to the codebase to check anything, clarify a detail, or fill a gap. Use `view_file`, `grep_search`, and `find_by_name` as needed. If you use `run_command`, only run read-only inspection. Do not mutate the repository or any remote. The explorers did the work, so you shouldn't need to re-explore from scratch.
+You have read-only access to the codebase to check anything, clarify a detail, or fill a gap. Use `read_file`, `view_file`, `grep_search`, and `find_by_name` as needed. If you use `run_command`, only run read-only inspection. Do not mutate the repository or any remote. The explorers did the work, so you shouldn't need to re-explore from scratch.
 
 ## Output Format
 

diff --git a/skills/interrogate/SKILL.md b/skills/interrogate/SKILL.md
@@ -24,7 +24,7 @@ Before spawning reviewers, state the intent in one clear paragraph from the user
 
 ## Step 3, Spawn Reviewers
 
-Launch all reviewers in a single `invoke_subagent` call, one per entry on the `interrogate reviewers` line in `~/.gemini/config/rules/pstack-models.md`, labeled Reviewer A, B, and so on to match the entry count. That file is an always-applied rule, already in context when present, so do not `view_file` it. If the rule is not in context or that line is missing, use the table defaults.
+Launch all reviewers in a single `invoke_subagent` call, one per entry on the `interrogate reviewers` line in `~/.gemini/config/rules/pstack-models.md`, labeled Reviewer A, B, and so on to match the entry count. That file is an always-applied rule, already in context when present, so do not `read_file` or `view_file` it. If the rule is not in context or that line is missing, use the table defaults.
 
 | Subagent | Default model tier |
 |----------|--------------------|

diff --git a/skills/interrogate/references/rubric.md b/skills/interrogate/references/rubric.md
@@ -20,7 +20,7 @@ When you find a potential bug, trace the execution path. Don't just flag "this c
 
 Is the code fixing the actual problem or papering over a symptom?
 
-Answering this often requires looking beyond the changed files. Read the surrounding code (callers, callees, type definitions, sibling modules) and understand the architecture the change lives in. Use the tools available to you (`view_file`, `grep_search`, `find_by_name`) to follow the call chain, read the types, and understand why the code exists before judging whether the change addresses the right layer.
+Answering this often requires looking beyond the changed files. Read the surrounding code (callers, callees, type definitions, sibling modules) and understand the architecture the change lives in. Use the tools available to you (`read_file`, `view_file`, `grep_search`, `find_by_name`) to follow the call chain, read the types, and understand why the code exists before judging whether the change addresses the right layer.
 
 - Guard clauses that mask a deeper invariant violation
 - Retry logic that hides a broken contract

diff --git a/skills/poteto-mode/SKILL.md b/skills/poteto-mode/SKILL.md
@@ -93,7 +93,7 @@ Read the leaf skill in full for any principle you apply. Each entry names when i
 
 **Use `TypeName: "poteto-agent"` in `invoke_subagent` for any subagent you spawn inside a playbook step** (code-writing delegates, ad-hoc helpers). The chat that receives `/poteto-mode` runs the playbook. Never spawn a `poteto-agent` to run the playbook itself. Routed workflow skills (`how`, `why`, `interrogate`, `reflect`, `swarm`) set their own `TypeName` (`research` or `self`) for diverse-model review. Respect what the skill prescribes, don't override to `poteto-agent`.
 
-**Defaults for every `invoke_subagent` call.** Background execution, agent mode (`TypeName: "self"` when MCP access is needed; `TypeName: "research"` is read-only and has no MCP tools), file pointers not inlined context, explicit model tier per role (configurable via `/setup-pstack` in `~/.gemini/config/rules/pstack-models.md`. Defaults `Model: "flash"` for code, `Model: "pro"` for prose and judgment). `~/.gemini/config/rules/pstack-models.md` is an always-applied rule already in context when present. Do not `view_file` it, including when the file is absent. Code delegates tier by difficulty. The hardest changes (cross-cutting design, gnarly concurrency, subtle algorithms) go to your strongest judgment tier (`Model: "pro"`), whether the task needs judgment on vague intent or is a precisely specified sequence of steps to execute to the letter. Trivial mechanical edits go to your fast code tier (`Model: "flash"` or `"flash_lite"`). Per-role lines in `~/.gemini/config/rules/pstack-models.md` override these defaults and the model choices in the routed skills (`how`, `why`, `arena`, `swarm`, `architect`, `interrogate`, `reflect`). A role with no line keeps its default, and a role line of `inherit`, `inherit-parent`, or `auto` runs that role on the parent chat model (`Model: "inherit"`). Each code playbook's configured model comes from its line (`feature, refactoring`, `bug-fix`, `perf-issue`, or `hillclimb`), and the hardest changes read `hardest tasks`. Prose and judgment read `judgment and prose`.
+**Defaults for every `invoke_subagent` call.** Background execution, agent mode (`TypeName: "self"` when MCP access is needed; `TypeName: "research"` is read-only and has no MCP tools), file pointers not inlined context, explicit model tier per role (configurable via `/setup-pstack` in `~/.gemini/config/rules/pstack-models.md`. Defaults `Model: "flash"` for code, `Model: "pro"` for prose and judgment). `~/.gemini/config/rules/pstack-models.md` is an always-applied rule already in context when present. Do not `read_file` or `view_file` it, including when the file is absent. Code delegates tier by difficulty. The hardest changes (cross-cutting design, gnarly concurrency, subtle algorithms) go to your strongest judgment tier (`Model: "pro"`), whether the task needs judgment on vague intent or is a precisely specified sequence of steps to execute to the letter. Trivial mechanical edits go to your fast code tier (`Model: "flash"` or `"flash_lite"`). Per-role lines in `~/.gemini/config/rules/pstack-models.md` override these defaults and the model choices in the routed skills (`how`, `why`, `arena`, `swarm`, `architect`, `interrogate`, `reflect`). A role with no line keeps its default, and a role line of `inherit`, `inherit-parent`, or `auto` runs that role on the parent chat model and preserves its reasoning effort (`Model: "inherit"`), whereas `pro`, `flash`, and `flash_lite` resolve to the backend default for that tier. Each code playbook's configured model comes from its line (`feature, refactoring`, `bug-fix`, `perf-issue`, or `hillclimb`), and the hardest changes read `hardest tasks`. Prose and judgment read `judgment and prose`.
 
 **Match the model to the job.** Before each spawn, start from the role's line or default and pick the model tier the job needs. The `/setup-pstack` budget sets each role's starting tier. Raise it one step, up to `pro`, for the hardest or subtlest work. Lower it one step for judgment and two or more steps for routine work. The ladder, low to high, is `flash_lite`, `flash`, `pro`. Antigravity has no separate fast or standard speed, so the tier is the only effort knob. Verification is the exception and stays on the `swarm workers` tier (`Model: "flash"` by default). When a panel names different tiers, keep those seats on different tiers unless the job's difficulty is what moved one of them. A role on `inherit`, `auto`, or `inherit-parent` stays on the parent model (`Model: "inherit"`). If `invoke_subagent` rejects the adjusted tier, do not try another adjusted tier. Use the role's line or default and say so.
 
@@ -121,7 +121,7 @@ Comments follow the same rule as the reply. Write them clean as you go. Keep a c
 
 ## Playbooks
 
-Open a todolist by writing and updating `<appDataDir>/brain/<conversation-id>/task.md` with `write_to_file` (the system prompt names `<appDataDir>` and `<conversation-id>`). Antigravity has no native todolist tool, so that file is the list. Its first items are the matched playbook's steps, copied in verbatim, before any task-specific todos. A step you choose not to do stays in the list with a one-line `skip: <reason>`. Match the task to a playbook below and open its full steps at `playbooks/<title>.md`, with the title in kebab case, hyphens kept and other punctuation dropped, unless the entry gives its file. Copy its steps in verbatim.
+Open a todolist by writing and updating `<appDataDir>/brain/<conversation-id>/task.md` with `write_file` or `write_to_file` (the system prompt names `<appDataDir>` and `<conversation-id>`). Antigravity has no native todolist tool, so that file is the list. Its first items are the matched playbook's steps, copied in verbatim, before any task-specific todos. A step you choose not to do stays in the list with a one-line `skip: <reason>`. Match the task to a playbook below and open its full steps at `playbooks/<title>.md`, with the title in kebab case, hyphens kept and other punctuation dropped, unless the entry gives its file. Copy its steps in verbatim.
 
 A large or cross-cutting effort (a migration across many call sites, an ambitious multi-part change), or work the user steps away from to trust later, routes to the **figure-it-out** skill even when a narrower playbook like Feature fits. Use **figure-it-out** whenever no bundled playbook fits. It designs a bespoke, rigorous playbook for the task. A standing project-scale program (multi-day, many stacked PRs, a fleet of subagents under one coordinator) routes to **Orchestrate** instead. figure-it-out designs one bespoke run, orchestrate runs the program.