# Email Triage Actions

> Review and execute bounded Gmail or Outlook actions through IntentMail, including read state, archive, flag, move, draft-text generation, and local deletion staging. Use when acting on selected inbox items; trigger with "archive these", "flag for follow-up", "draft replies", or "clean my inbox".

- Skill: `jeremylongshore/email-triage-actions` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add jeremylongshore/email-triage-actions`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jeremylongshore/email-triage-actions/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- License: Apache-2.0
- Author: jeremylongshore (https://skillmd.com/u/jeremylongshore)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jeremylongshore/email-triage-actions

---


# Email Triage Actions

## Overview

Turn a scoped review into explicit provider actions with per-message receipts.
The plan is a human-readable preview; `mail_action` itself has no dry-run flag,
so do not call it until the user confirms the exact operation and messages.

## Prerequisites

- Run IntentMail on Node.js 20 or newer.
- Connect the target Gmail or Outlook account through IntentMail OAuth.
- Configure an AI provider before requesting draft generation.

## Authentication and privacy

- Require an account connected through `mail_auth_start`; never request OAuth
  credentials or AI keys in chat.
- Provider actions use the user's Gmail or Microsoft Graph token. OAuth tokens
  and the cache remain local.
- Cloud AI providers receive content supplied for draft generation; Ollama can
  keep inference local. No send tool is permitted by this skill.
- See the [action safety contract](references/action-safety.md).

## Workflow

1. Call `mcp__intentmail__mail_daily_digest` only when candidates were not
   already supplied. Bound the account, time window, and item count.
2. Present a plan containing each local email ID, subject, requested operation,
   provider effect, local effect, and known reversal. Do not hide bulk scope
   behind phrases such as "clean everything".
3. Obtain explicit confirmation for that exact plan. Any changed scope or
   operation requires a new confirmation.
4. For mark-read/unread, archive, flag/unflag, or move, call
   `mcp__intentmail__mail_action` one message at a time and record `newState`.
5. For a reply, call `mcp__intentmail__mail_draft`. It generates draft text;
   it does not create a Gmail/Outlook draft and cannot send. Return the text
   for user review without implying it was saved remotely.
6. For deletion requests, call `mcp__intentmail__mail_stage_delete` with
   `backupMime: true`, review via `mcp__intentmail__mail_list_staged`, and stop.
   Staging is local only. Permanent provider deletion is not implemented or
   permitted in this skill. Use `mcp__intentmail__mail_unstage` to cancel.
7. Report individual successes and failures. Never retry a provider mutation
   blindly when the result is ambiguous.

## Approval boundaries

- **Read:** a digest may be built within the user's stated scope.
- **Confirm once per exact plan:** mark state, archive, flag, or move actions.
- **Confirm before local staging:** show every message selected for staging.
- **Not permitted:** sending mail, committing local deletions, provider
  deletion, bulk scope expansion, or claiming an audit/rollback receipt that
  direct actions do not produce.

## Validation

- Match every result's email ID and operation to the approved plan.
- Treat `success` plus the returned `newState` as the receipt for direct
  actions; do not claim all direct actions are in the rule audit log.
- Verify generated draft text contains no invented recipients, commitments, or
  attachments before returning it.
- Verify staged count and IDs with `mail_list_staged`; never equate staging with
  provider deletion.

## Output

Return the approved scope, operation per message, provider/local effect,
`newState` receipts, draft text awaiting review, staged IDs and retention,
failures, ambiguous outcomes, and any manual provider-side step still required.

## Error Handling

- **Not authenticated:** stop and direct the user to the explicit OAuth flow.
- **Ambiguous or partial provider result:** stop that item and report it; do not
  assume the mutation failed or succeeded.
- **Unsupported send/delete/unsubscribe request:** explain the current boundary.
  The consolidated tool's `unsubscribe` operation only archives today, so this
  skill does not represent it as an unsubscribe.
- **Bad draft:** discard the output and ask for corrected facts or tone; never
  send or claim a provider draft exists.
- **Wrong staged item:** unstage it before doing anything else.

## Examples

```text
For account 1, show the five newsletters you propose to archive. Wait for my
confirmation, then archive them one at a time and report each newState.
```

```text
Generate reply text for email 42 in a concise professional tone. Do not save or
send it. Return the draft and any uncertain facts for my review.
```

## Resources

- [Action safety contract](references/action-safety.md)
- Provider action implementation: `src/connectors/email-actions.ts`
- Deletion staging: `src/storage/services/deletion-staging.ts`