/gmail-policy

name: gmail-policy
description: Use when managing Gmail messages, labels, or email workflows via gws CLI or Gmail MCP tools

Gmail Policy

Reading User Intent Before Acting

The most common mistake is treating every email-related request as an execution command. Before touching a single API, ask: is the user giving me context, or is the user giving me a command?

This is a reasoning step, not a checklist. Run it silently before every response.

The Four Questions

1. **Context or command?** Is the user describing a situation, or directing an action? 2. **If command -- explicit or ambiguous?** Explicit means the verb leaves no doubt (send, dile que sí y envíaselo). Ambiguous means the verb could be draft or send. 3. **Reversible or sensitive?** A simple scheduling reply is reversible. A lease acceptance, financial form, or commitment with a third party is sensitive -- draft first unless the user explicitly says send. 4. **Am I in a proactive triage context?** If I was just reviewing the inbox, I have permission to generate drafts ahead of being asked, then present them.

Intent Classification Table

This table is the single source of truth for how an email-related utterance maps to an action. Every process that reacts to a user trigger (including `gmail-triage`'s "Check My Mail") resolves the intent here first, then runs its process. The user-utterance column stays in the user's own words (Spanish); the interpretation and action are the policy.

| User utterance | Real intent | Correct action | |----------------|-------------|----------------| | "necesito analizar un correo y enviar unos correos importantes" | Context -- describing a plan, not executing it | Send nothing; wait for the specific command | | "chequea mis correos y ve si hay algo importante" | Review + initiative granted | Read inbox, triage, **generate drafts** for threads that merit a reply, present the list to the user | | "dile que aceptamos y envíaselo" | Explicit send command | Create and send directly (one T3 cycle, not draft->send) | | "mándale un correo a X diciéndole Y" | Ambiguous | Ask: draft to review, or direct send? | | "respóndele a Assetplan aceptando" | Ambiguous, leans to draft | Default to draft when the content involves personal data, commercial decisions, or forms | | "dile que llego a las 5pm" | Simple command, reversible content | Direct send is fine, no draft needed | | "prepara una respuesta para X" | Explicit draft | Create draft and report |

The "review + initiative granted" row is the interpretation `gmail-triage` depends on: a general review trigger ("chequea mi mail", "¿algo nuevo?") means *review with initiative*, not a bare listing. `gmail-triage` owns the PROCESS that follows; the meaning of the trigger is defined here.

The Anti-Drift Rule

There is no fixed pipeline where every send goes through draft→approve→send. That workflow exists as a safety net for sensitive cases, not as the default for every email. When the user says "envíaselo", they mean send -- one T3 approval, one action, done.

The question is not "should I always draft first?" The question is: **what did the user actually ask for, and how reversible is this action?**

If you're uncertain, ask once. Do not silently choose draft when the user said send.

Proactive Draft Generation (Triage Context)

During a triage or inbox review session ("chequea mis correos", "ve si hay algo importante"), the user grants implicit permission for proactive drafts. You do not need to ask for approval before creating each one.

Pattern: 1. Read inbox, identify threads that clearly need a response 2. For each, assess: does the reply require user input I don't have, or can I draft a reasonable response from context? 3. If draftable -- draft it. Store the draft in Gmail. Note the draft ID. 4. At the end of the review, present the complete list: "Generé 3 drafts: [subject 1], [subject 2], [subject 3]. ¿Quieres revisarlos?"

The user reviews and approves individual drafts before sending. The generation step does not require one-by-one confirmation -- the presentation step does.

Do not generate drafts proactively outside triage context. If the user opens a conversation about a single email, default to their explicit instruction.

Autonomous Action Boundary

This is the security rule that decides which email operations may run **without asking** and which must always be proposed. It governs every `gmail-triage` mode, and above all the headless run where no user is present to approve. It lives here, in the policy layer, precisely because a process must not be the only home of the rule it obeys.

**Permitted automatically** (no approval, safe unattended) -- moves that are **mechanical AND reversible**, where nothing is lost and the state can be flipped back:

• Classifying a new email into `_gaia/action` or `_gaia/waiting` on a clear signal (`addLabelIds`).
• The reversible state swaps: `action -> waiting` when the user replies, `waiting -> action` when a third party replies. Relabeling (`removeLabelIds` of the old state + `addLabelIds` of the new) is a swap, not a destruction.
• Staging unprocessed mail into `_gaia/pending`.

**Prohibited automatically** (always a proposal, never executed alone) -- operations that are **destructive OR a matter of criterion**:

• Moving to `_gaia/trash`, marking spam, unsubscribing, deleting.
• Deferring to `_gaia/someday` -- a judgment call, not a mechanical classification.
• Clearing a label to mark a thread done (here `removeLabelIds` *destroys* state).
• Sending a message, or creating any draft in an unattended/headless run. (Proactive drafts *for review* are allowed in interactive triage under the grant above; that grant is interactive-only and does not reach a headless run.)

In a headless run these prohibited operations are **listed in the report** for an interactive session to approve -- never executed. And the proactive-draft grant above is an **interactive-session grant only**: it