laith-max · laith-max · Mar 19, 2026
diff --git a/.gemini/skills/behavioral-evals/references/fixing.md b/.gemini/skills/behavioral-evals/references/fixing.md
@@ -33,16 +33,35 @@ evaluation.
     - **Warning**: Do not lose test fidelity by making prompts too direct/easy.
     - **Primary Fix Trigger**: Adjust tool descriptions, system prompts
       (`snippets.ts`), or **modules that contribute to the prompt template**.
-    - Fixes should generally try to improve the prompt `@packages/core/src/prompts/snippets.ts` first.
-    - **Instructional Generality**: Changes to the system prompt should aim to be as general as possible while still accomplishing the goal. Specificity should be added only as needed.
-      - **Principle**: Instead of creating "forbidden lists" for specific syntax (e.g., "Don't use `Object.create()`"), formulate a broader engineering principle that covers the underlying issue (e.g., "Prioritize explicit composition over hidden prototype manipulation"). This improves steerability across a wider range of similar scenarios.
-      - *Low Specificity*: "Follow ecosystem best practices"
-      - *Medium Specificity*: "Utilize OOP and functional best practices, as applicable"
-      - *High Specificity*: Provide ecosystem-specific hints as examples of a broader principle rather than direct instructions. e.g., "NEVER use hacks like bypassing the type system or employing 'hidden' logic (e.g.: reflection, prototype manipulation). Instead, use explicit and idiomatic language features (e.g.: type guards, explicit class instantiation, or object spread) that maintain structural integrity."
-    - **Prompt Simplification**: Once the test is passing, use `ask_user` to determine if prompt simplification is desired.
-      - **Criteria**: Simplification should be attempted only if there are related clauses that can be de-duplicated or reparented under a single heading.
-      - **Verification**: As part of simplification, you MUST identify and run any behavioral eval tests that might be affected by the changes to ensure no regressions are introduced.
-    - Test fixes should not "cheat" by changing a test's `GEMINI.md` file or by updating the test's prompt to instruct it to not repro the bug.
+    - Fixes should generally try to improve the prompt
+      `@packages/core/src/prompts/snippets.ts` first.
+    - **Instructional Generality**: Changes to the system prompt should aim to
+      be as general as possible while still accomplishing the goal. Specificity
+      should be added only as needed.
+      - **Principle**: Instead of creating "forbidden lists" for specific syntax
+        (e.g., "Don't use `Object.create()`"), formulate a broader engineering
+        principle that covers the underlying issue (e.g., "Prioritize explicit
+        composition over hidden prototype manipulation"). This improves
+        steerability across a wider range of similar scenarios.
+      - _Low Specificity_: "Follow ecosystem best practices"
+      - _Medium Specificity_: "Utilize OOP and functional best practices, as
+        applicable"
+      - _High Specificity_: Provide ecosystem-specific hints as examples of a
+        broader principle rather than direct instructions. e.g., "NEVER use
+        hacks like bypassing the type system or employing 'hidden' logic (e.g.:
+        reflection, prototype manipulation). Instead, use explicit and idiomatic
+        language features (e.g.: type guards, explicit class instantiation, or
+        object spread) that maintain structural integrity."
+    - **Prompt Simplification**: Once the test is passing, use `ask_user` to
+      determine if prompt simplification is desired.
+      - **Criteria**: Simplification should be attempted only if there are
+        related clauses that can be de-duplicated or reparented under a single
+        heading.
+      - **Verification**: As part of simplification, you MUST identify and run
+        any behavioral eval tests that might be affected by the changes to
+        ensure no regressions are introduced.
+    - Test fixes should not "cheat" by changing a test's `GEMINI.md` file or by
+      updating the test's prompt to instruct it to not repro the bug.
     - **Warning**: Prompts have multiple configurations; ensure your fix targets
       the correct config for the model in question.
 4.  **Architecture Options**: If prompt or instruction tuning triggers no

diff --git a/docs/admin/enterprise-controls.md b/docs/admin/enterprise-controls.md
@@ -21,7 +21,8 @@ preferred method for enforcing policy.
 
 **Enabled/Disabled** | Default: enabled
 
-If enabled, users will not be able to enter yolo mode.
+If enabled, users will not be able to use the `--yolo` flag or wildcard tool
+policies.
 
 ### Extensions
 

diff --git a/docs/cli/cli-reference.md b/docs/cli/cli-reference.md
@@ -50,10 +50,9 @@ These commands are available within the interactive REPL.
 | `--model`                        | `-m`  | string  | `auto`    | Model to use. See [Model Selection](#model-selection) for available values.                                                                                            |
 | `--prompt`                       | `-p`  | string  | -         | Prompt text. Appended to stdin input if provided. Forces non-interactive mode.                                                                                         |
 | `--prompt-interactive`           | `-i`  | string  | -         | Execute prompt and continue in interactive mode                                                                                                                        |
-| `--worktree`                     | `-w`  | string  | -         | Start Gemini in a new git worktree. If no name is provided, one is generated automatically. Requires `experimental.worktrees: true` in settings.                       |
 | `--sandbox`                      | `-s`  | boolean | `false`   | Run in a sandboxed environment for safer execution                                                                                                                     |
-| `--approval-mode`                | -     | string  | `default` | Approval mode for tool execution. Choices: `default`, `auto_edit`, `yolo`, `plan`                                                                                      |
-| `--yolo`                         | `-y`  | boolean | `false`   | **Deprecated.** Auto-approve all actions. Use `--approval-mode=yolo` instead.                                                                                          |
+| `--approval-mode`                | -     | string  | `default` | Approval mode for tool execution. Choices: `default`, `auto_edit`, `plan`                                                                                              |
+| `--yolo`                         | `-y`  | boolean | `false`   | Auto-approve all actions. Equivalent to `--allowed-tools=*`.                                                                                                           |
 | `--experimental-acp`             | -     | boolean | -         | Start in ACP (Agent Code Pilot) mode. **Experimental feature.**                                                                                                        |
 | `--experimental-zed-integration` | -     | boolean | -         | Run in Zed editor integration mode. **Experimental feature.**                                                                                                          |
 | `--allowed-mcp-server-names`     | -     | array   | -         | Allowed MCP server names (comma-separated or multiple flags)                                                                                                           |

diff --git a/docs/cli/plan-mode.md b/docs/cli/plan-mode.md
@@ -35,19 +35,20 @@ To launch Gemini CLI in Plan Mode once:
 To start Plan Mode while using Gemini CLI:
 
 - **Keyboard shortcut:** Press `Shift+Tab` to cycle through approval modes
-  (`Default` -> `Auto-Edit` -> `Plan`). Plan Mode is automatically removed from
-  the rotation when Gemini CLI is actively processing or showing confirmation
-  dialogs.
+  (`Default` -> `Auto-Edit` -> `Plan`).
 
-- **Command:** Type `/plan [goal]` in the input box. The `[goal]` is optional;
-  for example, `/plan implement authentication` will switch to Plan Mode and
-  immediately submit the prompt to the model.
+  > **Note:** Plan Mode is automatically removed from the rotation when Gemini
+  > CLI is actively processing or showing confirmation dialogs.
+
+- **Command:** Type `/plan` in the input box.
 
 - **Natural Language:** Ask Gemini CLI to "start a plan for...". Gemini CLI
   calls the
   [`enter_plan_mode`](../tools/planning.md#1-enter_plan_mode-enterplanmode) tool
-  to switch modes. This tool is not available when Gemini CLI is in
-  [YOLO mode](../reference/configuration.md#command-line-arguments).
+  to switch modes.
+  > **Note:** This tool is not available when Gemini CLI has been instructed to
+  > [auto-approve all actions](../reference/configuration.md#command-line-arguments)
+  > (e.g. via `--yolo`).
 
 ## How to use Plan Mode
 
@@ -56,21 +57,19 @@ Gemini CLI takes action.
 
 1.  **Provide a goal:** Start by describing what you want to achieve. Gemini CLI
     will then enter Plan Mode (if it's not already) to research the task.
-2.  **Discuss and agree on strategy:** As Gemini CLI analyzes your codebase, it
-    will discuss its findings and proposed strategy with you to ensure
-    alignment. It may ask you questions or present different implementation
-    options using [`ask_user`](../tools/ask-user.md). **Gemini CLI will stop and
-    wait for your confirmation** before drafting the formal plan. You should
-    reach an informal agreement on the approach before proceeding.
-3.  **Review the plan:** Once you've agreed on the strategy, Gemini CLI creates
-    a detailed implementation plan as a Markdown file in your plans directory.
+2.  **Review research and provide input:** As Gemini CLI analyzes your codebase,
+    it may ask you questions or present different implementation options using
+    [`ask_user`](../tools/ask-user.md). Provide your preferences to help guide
+    the design.
+3.  **Review the plan:** Once Gemini CLI has a proposed strategy, it creates a
+    detailed implementation plan as a Markdown file in your plans directory.
     - **View:** You can open and read this file to understand the proposed
       changes.
     - **Edit:** Press `Ctrl+X` to open the plan directly in your configured
       external editor.
 
 4.  **Approve or iterate:** Gemini CLI will present the finalized plan for your
-    formal approval.
+    approval.
     - **Approve:** If you're satisfied with the plan, approve it to start the
       implementation immediately: **Yes, automatically accept edits** or **Yes,
       manually accept edits**.
@@ -123,7 +122,6 @@ These are the only allowed tools:
   [`glob`](../tools/file-system.md#4-glob-findfiles)
 - **Search:** [`grep_search`](../tools/file-system.md#5-grep_search-searchtext),
   [`google_web_search`](../tools/web-search.md),
-  [`web_fetch`](../tools/web-fetch.md) (requires explicit confirmation),
   [`get_internal_docs`](../tools/internal-docs.md)
 - **Research Subagents:**
   [`codebase_investigator`](../core/subagents.md#codebase-investigator),
@@ -181,16 +179,9 @@ As described in the
 rule that does not explicitly specify `modes` is considered "always active" and
 will apply to Plan Mode as well.
 
-To maintain the integrity of Plan Mode as a safe research environment,
-persistent tool approvals are context-aware. Approvals granted in modes like
-Default or Auto-Edit do not apply to Plan Mode, ensuring that tools trusted for
-implementation don't automatically execute while you're researching. However,
-approvals granted while in Plan Mode are treated as intentional choices for
-global trust and apply to all modes.
-
-If you want to manually restrict a rule to other modes but _not_ to Plan Mode,
-you must explicitly specify the target modes. For example, to allow `npm test`
-in default and Auto-Edit modes but not in Plan Mode:
+If you want a rule to apply to other modes but _not_ to Plan Mode, you must
+explicitly specify the target modes. For example, to allow `npm test` in default
+and Auto-Edit modes but not in Plan Mode:
 
 ```toml
 [[rule]]
@@ -212,7 +203,6 @@ your specific environment.
 
 ```toml
 [[rule]]
-toolName = "*"
 mcpName = "*"
 toolAnnotations = { readOnlyHint = true }
 decision = "allow"
@@ -418,9 +408,7 @@ To build a custom planning workflow, you can use:
   [custom plan directories](#custom-plan-directory-and-policies) and
   [custom policies](#custom-policies).
 
-<!-- prettier-ignore -->
-> [!TIP]
-> Use [Conductor] as a reference when building your own custom
+> **Note:** Use [Conductor] as a reference when building your own custom
 > planning workflow.
 
 By using Plan Mode as its execution environment, your custom methodology can

diff --git a/docs/extensions/reference.md b/docs/extensions/reference.md
@@ -23,15 +23,14 @@ Gemini CLI creates a copy of the extension during installation. You must run
 GitHub, you must have `git` installed on your machine.
 
 ```bash
-gemini extensions install <source> [--ref <ref>] [--auto-update] [--pre-release] [--consent] [--skip-settings]
+gemini extensions install <source> [--ref <ref>] [--auto-update] [--pre-release] [--consent]
 ```
 
 - `<source>`: The GitHub URL or local path of the extension.
 - `--ref`: The git ref (branch, tag, or commit) to install.
 - `--auto-update`: Enable automatic updates for this extension.
 - `--pre-release`: Enable installation of pre-release versions.
 - `--consent`: Acknowledge security risks and skip the confirmation prompt.
-- `--skip-settings`: Skip the configuration on install process.
 
 ### Uninstall an extension
 
@@ -235,9 +234,7 @@ skill definitions in a `skills/` directory. For example,
 
 ### Sub-agents
 
-<!-- prettier-ignore -->
-> [!NOTE]
-> Sub-agents are a preview feature currently under active development.
+> **Note:** Sub-agents are a preview feature currently under active development.
 
 Provide [sub-agents](../core/subagents.md) that users can delegate tasks to. Add
 agent definition files (`.md`) to an `agents/` directory in your extension root.
@@ -256,12 +253,10 @@ Rules contributed by extensions run in their own tier (tier 2), alongside
 workspace-defined policies. This tier has higher priority than the default rules
 but lower priority than user or admin policies.
 
-<!-- prettier-ignore -->
-> [!WARNING]
-> For security, Gemini CLI ignores any `allow` decisions or `yolo`
-> mode configurations in extension policies. This ensures that an extension
-> cannot automatically approve tool calls or bypass security measures without
-> your confirmation.
+> **Warning:** For security, Gemini CLI ignores any `allow` decisions or
+> `allow-all` wildcard configurations in extension policies. This ensures that
+> an extension cannot automatically approve tool calls or bypass security
+> measures without your confirmation.
 
 **Example `policies.toml`**