10 Claude prompts that triage your inbox in 20 minutes in 2026

Inbox triage is the highest-frequency cognitive switching cost on a knowledge worker's calendar — and the job where chained LLM prompts deliver the largest hour-per-week recovery. Ten Claude prompts compress a 90-minute morning triage into a 20-minute session: a 5-bullet briefing of the overnight pile, an action-item extractor with owner and due date, a reply-or-delegate classifier, a no-reply identifier, a follow-up surfacer, a threat-versus-noise scanner, an attached-doc TL;DR, a thread summarizer for newly added participants, a 3-sentence reply drafter that adapts by sender tier, and a weekly-archive synthesizer for the retro.

Each prompt carries the full text, design reasoning, a sample output, and a cadence — plus a single redaction guardrail that has to sit upstream of every prompt or the whole chain becomes a data-exfiltration risk.

<a href="https://www.anthropic.com/pricing?utm_source=aipromptshub&utm_medium=blog&utm_campaign=inbox-triage-tldr" style={{display:"inline-block",padding:"10px 18px",background:"#0a66ff",color:"white",borderRadius:"6px",textDecoration:"none",fontWeight:"bold"}}> Try Claude Pro for the inbox chain → </a>

Email volume has not stabilized — it has migrated. Microsoft's 2024 Work Trend Index Annual Report measured the average information worker reading or responding to email 8.8 hours per week, with 85% of those emails read in under 15 seconds and 60% of the daily total arriving outside of 9-to-5. McKinsey's foundational The Social Economy study put email at 28% of the knowledge-worker week, and the 2023 State of Organizations Report confirmed the number has not meaningfully fallen despite a decade of collaboration tooling.

Two findings explain why the cost compounds. Microsoft's data shows attention recovery after an email interrupt averages 64 seconds, and only 23% of email-derived action items make it into a task system within the same business day. The gap between reading and acting is where leverage hides.

Sentiment and intent classification have hit reliability thresholds where chained prompts can replace the read-and-decide loop for the obvious 70-80% of email. Anthropic's prompt engineering documentation emphasizes structured outputs with explicit confidence flags — the same pattern the customer-feedback chain uses, and the pattern the prompts below repeat. Anthropic's model documentation covers when Sonnet 4.5 is enough and when Opus 4.7 earns the latency tax.

Ten prompts treat the inbox as a pipeline: each does one job, accepts a defined input shape, and emits a defined output shape that feeds the next. The chain runs against Sonnet 4.5 for high-volume per-email steps and Opus 4.7 for synthesis-heavy steps.

The anti-pattern that destroys this workflow on the first day: pasting a raw inbox into a model. Email bodies routinely contain credentials, contracts, customer PII, internal salary data, and legal-privileged threads. A redaction step upstream of every prompt is the load-bearing safety control.

**The redaction prompt (always runs first):**

``` You are a data-protection preprocessor. You receive raw email bodies and return a redacted copy safe for downstream processing. INPUT: a list of emails with from, to, subject, date, body. For each email, output the same shape with body replaced by: - A version where the following are replaced with placeholder tokens (e.g., [API_KEY_REDACTED]): - API keys, access tokens, OAuth secrets, bearer tokens - Password resets and one-time codes - Full credit card numbers, bank account numbers, SSNs - Customer email addresses other than the sender and the immediate thread participants - Phone numbers in the email body that are not the sender's signature - Anything inside a block marked CONFIDENTIAL, ATTORNEY-CLIENT, or NDA - Salary figures, equity grant amounts, and severance terms Rules: - Subject and from/to/date are NOT redacted — they are required for triage. - Replace, do not delete — the placeholder tokens must remain so triage prompts can still reason about structure. - If the body is mostly redacted (>60% replaced), flag redaction_heavy: true. - Never include the original sensitive text in the output, even as an explanation. ```

**Why this matters:** Every downstream prompt assumes input has passed through this filter. Without it, this chain is a one-step ticket to leaking the company's last legal hold into a sampled training corpus. Anthropic's data usage policy covers what Claude does and does not retain, but a redaction step on your side is the right belt-and-suspenders posture for any inbox automation. The exact-substring quote-grounding pattern from the prompt engineering docs applies — never let a prompt invent a credential it claims to have seen.

The first scan is the one that sets the rest of the day. The goal is not summarization — the goal is the briefing a chief of staff would hand the executive on the walk to the desk.

**The prompt:**

``` You are a chief of staff compressing the overnight inbox into a 5-bullet morning briefing. INPUT: 30-80 redacted emails received since the user's last triage, each with from, to, subject, date, body, and folder/label if known. OUTPUT: { "period": "<from timestamp to timestamp>", "email_count": <number>, "briefing": [ "<bullet 1 — the single most important thing>", "<bullet 2>", "<bullet 3>", "<bullet 4>", "<bullet 5>" ], "what_did_not_arrive": "<one sentence — pattern or sender notably absent, or 'n/a'>", "low_value_count": <number — newsletters, automated digests, calendar noise>, "low_value_examples": [<2-3 subject lines>] } Rules: - Exactly 5 bullets. Not 4, not 7. - Bullet 1 must be the highest-stakes item in the pile, not the most recent. - Each bullet ends with a parenthetical sender or thread reference so the user can jump to the email. - Do not lead with newsletter content. - The what_did_not_arrive field is mandatory — absence is information ("the auditor's confirmation has not landed"). - Bullets cannot exceed 25 words each. ```

**Why it works:** The hard count of 5 prevents the briefing from drifting into a re-read of the inbox. The stakes-first ordering rule fights recency bias — Outlook telemetry in the Work Trend Index shows users open the newest email first 71% of the time, and that order rarely matches importance. The what_did_not_arrive field surfaces the silence that matters: the customer who did not respond, the legal review that did not land.

**Sample output:** 52 emails → 5 bullets. Top bullet: *"Series A term sheet revised by Sequoia partner with a 1.5x liquidation preference change requesting reply by 5pm ET (thread: Sequoia / Series A redline v3)."* low_value_count: 31. what_did_not_arrive: *"The auditor PBC list confirmation has not landed; due Friday."*

**When to use:** Once at the start of the morning, again after lunch. Feeds prompts #2, #3, #5.

Action items inside email bodies are where commitments go to die. Microsoft's data shows only 23% reach a task system the same day. This prompt is the conveyor belt between reading and acting.

**The prompt:**

``` You are an executive assistant extracting action items from a batch of redacted emails. INPUT: a list of emails with from, to, subject, date, body. For each email containing an action item, output: { "email_subject": "<exact subject>", "action": "<verb-led, one sentence>", "owner": "me | <named person> | UNCLEAR", "due_date": "<YYYY-MM-DD>" | "none stated" | "asap_explicit" | "asap_implied", "due_date_source": "<exact substring of the email body that justified the date>", "action_type": "reply | decide | review | attend_meeting | send_file | introduce | pay | other", "effort_estimate": "<5min | 15min | 30min | 1hr+ | unknown>", "confidence": "high | medium | low", "is_implicit": true | false } Rules: - An action item must have a verb. "FYI" is not an action item. - The owner is "me" only if the email is addressed to the user OR a request is made of the user explicitly. - due_date_source must be an exact substring of the body (or "derived from header date" if from arrival time). - is_implicit=true for actions inferred from social convention ("would love to see you next week" implies an RSVP); confidence cannot be "high" for implicit items. - If multiple actions sit in one email, return one row per action. ```

**Why it works:** The due_date_source field is the load-bearing guardrail against hallucinated deadlines. The is_implicit flag forces the model to acknowledge social-convention reads — the most common failure mode is over-extraction (every email becomes a task) which trains the user to ignore the list within a week. Anthropic's prompt engineering guidance on exact-substring grounding maps directly.

**Sample output:** 52 emails → 18 action items. 11 owned by user, 4 delegated, 3 UNCLEAR. Top: *"Action: send revised Sequoia signature page. Owner: me. Due: 2026-06-10 17:00 ET. Source: 'need this back by 5pm ET'."*

**When to use:** Right after #1, before the user touches a single reply. Outputs go to the task system, not the inbox.

The reply/delegate/schedule/archive split is the single decision that absorbs the most cognitive load in a morning triage. A prompt that makes the call with a confidence flag lets the user override the 10% that matter and accept the 90% that don't.

**The prompt:**

``` You are a triage operator classifying each email by next action. INPUT: a list of emails with from, to, subject, date, body, and a sender_tier hint (vip | customer | internal | vendor | unknown) if available. For each email, output: { "email_subject": "<exact subject>", "from": "<sender name or email>", "next_action": "reply_personally | delegate_to_<role> | schedule_meeting | archive | block_time_to_read | flag_for_legal", "rationale": "<one sentence — why this bucket>", "delegate_target_role": "<EA | CSM | finance | legal | engineering | n/a>", "reply_deadline": "<YYYY-MM-DD or 'eod' or 'this week' or 'none'>", "confidence": "high | medium | low", "override_signal": "<one phrase that would justify a different bucket, or 'none'>" } Rules: - VIP-tier and explicit customer escalations cannot be archived — minimum bucket is reply_personally. - delegate_to_<role> requires that the role can actually act without the user — generic "team" is not allowed. - flag_for_legal triggers on: contract redlines, demand letters, regulatory inquiries, NDA breaches, terminations. - The override_signal field exists for the human reviewer — name the thing that, if true, would change the bucket. - Confidence "high" requires the bucket to be obvious from the body alone, not from the sender alone. ```

**Why it works:** The override_signal field models doubt explicitly — the user scans rows where override_signal is non-empty and confidence is low, and trusts the rest. The role-not-team rule prevents the failure mode where every delegate target is "the team" and nothing leaves the inbox.

**Sample output:** 52 emails → 8 reply_personally (4 high-confidence), 14 delegate_to_EA, 6 delegate_to_CSM, 18 archive, 4 schedule_meeting, 2 flag_for_legal. Two override-signal flags get human re-review and one bucket changes.

**When to use:** Immediately after #2. The classification drives the rest of the morning's keystrokes.

Reply guilt is what keeps the inbox at 2,400 instead of 200. This prompt isolates the emails where the social cost of not replying is provably zero — newsletters, automated digests, FYIs without questions, and broadcast announcements.

**The prompt:**

``` You are a triage operator identifying emails that require no reply. INPUT: a list of emails with from, to, subject, date, body. For each email, output: { "email_subject": "<exact subject>", "no_reply_candidate": true | false, "no_reply_reason": "automated_digest | newsletter | broadcast_announcement | fyi_no_question | thank_you_with_no_question | calendar_invite_no_action | other | n/a", "confidence": "high | medium | low", "social_cost_if_skipped": "none | low | medium | high", "override_keywords_present": [<list of phrases that might warrant a reply anyway, or empty>] } Rules: - no_reply_candidate=true requires social_cost_if_skipped to be 'none' or 'low'. - A direct question in the body (ends with ? AND addressed to the user) disqualifies no_reply_candidate. - override_keywords_present catches things like "please confirm", "let me know", "thoughts?", "by EOD" — even in a long FYI thread. - VIP senders default to no_reply_candidate=false regardless of body — leave the call to the user. - A thank-you that contains a follow-up question is NOT a no-reply candidate. ```

**Why it works:** Most users archive too few because they fear missing the buried ask. The override_keywords_present list surfaces the exact phrases that signal a hidden ask inside an otherwise informational email — the user scans the override list, not the bodies. Microsoft's data shows ~40% of inbox volume is automated digest content; this prompt is the throughput multiplier.

**Sample output:** 52 emails → 27 no_reply_candidate=true (22 high-confidence). 5 medium-confidence flagged for a 30-second human glance. Override keywords surfaced in 3 "FYI" emails that actually contained a soft ask.

**When to use:** Right after #3, against the archive bucket. Catches the false-archive cases before they happen.

Stalled threads where the user is the bottleneck are the most expensive items in the inbox — the deals, the introductions, and the answers that decay in value daily. This prompt surfaces them.

**The prompt:**

``` You are a relationship-management analyst identifying threads that need a user-initiated follow-up. INPUT: a list of email threads from the trailing 14 days, each with thread_id, participants, subject, last_message_date, last_message_sender, last_message_excerpt, thread_summary. For each thread that meets the follow-up bar, output: { "thread_id": "<id>", "subject": "<exact subject>", "days_since_last_user_message": <number>, "who_is_the_ball_with": "user | counterparty | mutual", "follow_up_recommended": true | false, "follow_up_reason": "awaiting_user_reply | user_promised_followup | counterparty_silent_after_user_ask | scheduled_event_unconfirmed | other", "draft_one_liner_followup": "<one sentence the user could send as-is>", "urgency": "this_morning | today | this_week | watch_only", "value_at_stake": "<one phrase — what dies if this thread ages further>" } Rules: - Only flag follow_up_recommended=true if the ball is genuinely with the user OR with a counterparty after the user did their part. - The draft_one_liner_followup must be polite, specific, and reference the prior thread (use a substring of last_message_excerpt to anchor). - value_at_stake is mandatory — if you can't name what's at risk, the follow-up isn't worth it. - Threads where the counterparty owes the user but the user has already pinged twice should be flagged "counterparty_silent_after_user_ask" with a one-liner that offers a graceful exit, not a third nag. ```

**Why it works:** The value_at_stake field is the bullshit-detector — it forces the model to articulate the cost of inaction, which most stalled threads can't justify. The graceful-exit rule prevents the three-pings-and-burn-the-bridge failure mode. Adapted from the Trusted Advisor framework (Maister, 2000) — relationships die from inertia, not conflict.

**Sample output:** 14 days of threads → 6 follow-up candidates. Top: *"Sequoia partner: 4 days since their last message, ball is with user (response to revised redline), value_at_stake: 'momentum on term sheet'. Draft: 'Wanted to circle back on the revised liquidation preference language — can send a redline this afternoon or hop on a 15-min call.'"*

**When to use:** Once per week (Monday) plus once after any inbox-zero session. Feeds the personal CRM.

Threats in the inbox cluster around legal, security, and customer-churn signals. False positives drown the real ones. This prompt distinguishes a real threat from a loud-but-empty one.

**The prompt:**

``` You are a risk analyst scanning the inbox for threat signals. INPUT: a list of emails with from, to, subject, date, body. For each email, output: { "email_subject": "<exact subject>", "threat_class": "legal | security | customer_churn | regulatory | financial | reputational | none", "is_real_threat": true | false, "signal_strength": "high | medium | low", "concrete_signals": [<list of exact substrings from the body that justify the rating>], "noise_signals": [<list of substrings that look threatening but are not, e.g. boilerplate "failure to respond" footers>], "recommended_route": "counsel | security_team | account_lead | finance | exec_brief | watch_only", "time_to_first_response": "now | <24h | this_week | watch", "confidence": "high | medium | low" } Rules: - is_real_threat=true requires at least one concrete_signal that is specific to this email (not generic boilerplate). - The noise_signals field is mandatory and the most important field — it explains why a scary-looking email is not actually a threat. - Phishing-looking emails go in threat_class: security; do not click any links. - Confidence "high" requires the email to name a specific party, dollar amount, or regulation, not vague language. - Customer-churn signals require an explicit cancellation intent, competitor switch, or contract non-renewal — frustration alone is not a churn threat. ```

**Why it works:** The noise_signals field is the rarely-modeled inverse of concrete_signals — it forces the model to explain away the surface scary words. Most threat-scanners fail because they trip on "failure to respond" boilerplate. The specific-party-or-amount gate for high confidence stops the over-escalation failure mode.

**Sample output:** 52 emails → 2 real threats, 4 noisy false positives, 46 clean. Real: *"Demand letter from competitor counsel, threat_class: legal, signal: 'cease use of the contested trademark within 30 days', route: counsel, time_to_first_response: <24h."*

**When to use:** Continuous in the background. The 2 real threats route to a Slack channel watched by counsel and the executive.

Attachments are where reply-procrastination compounds. A 40-page contract that takes 90 minutes to read becomes a 3-day delay. This prompt produces the TL;DR that gets the user to a yes/no fast.

**The prompt:**

``` You are an analyst producing a TL;DR of an attached document for a busy reader. INPUT: - Email metadata (from, to, subject, date) - Attachment filename and type - Attachment text content (already extracted) - Why the reader received it (one sentence from the email body) OUTPUT: { "document_title": "<the actual title>", "document_type": "contract | spec | report | proposal | invoice | deck | research | other", "reader_role_inferred": "<role — approver | reviewer | informed | unclear>", "three_sentence_summary": "<exactly 3 sentences>", "the_one_thing_that_matters": "<the single decision or fact the reader is being asked to react to>", "redline_or_change_summary": "<only if a redline — what changed from prior version, else 'n/a'>", "open_questions_for_reader": [<2-4 questions the reader should ask before signing/approving>], "recommended_next_action": "approve | reject | request_changes | escalate | read_in_full | n/a", "red_flags": [<list of exact phrases from the document that should make the reader pause>], "length_in_pages_or_words": <number> } Rules: - three_sentence_summary is EXACTLY three sentences. Period. - red_flags are exact substrings of the document — never paraphrased. - For contracts, red_flags must include: any liability cap above $5M, any auto-renewal, any exclusivity, any non-standard indemnity, any IP assignment to counterparty. - For proposals, red_flags must include: implementation deadlines, payment terms, scope ambiguities. - the_one_thing_that_matters is one sentence — if you can't fit it in one sentence, the document needs human review. ```

**Why it works:** The exactly-three-sentences rule fights the failure mode where a TL;DR becomes a re-summarization. The red_flags-as-exact-substrings rule prevents the model from inventing scary clauses that aren't in the document. The contract-specific red flag list is the muscle memory of a deal lawyer compressed into a prompt.

**Sample output:** 42-page MSA redline → 3-sentence summary, recommended_next_action: request_changes. red_flags: *"unlimited indemnity for IP infringement"*, *"auto-renewal for successive 24-month terms"*. open_questions: 3.

**When to use:** On every attachment that the user has not opened within 24 hours. Feeds prompt #9 (reply drafter).

Being looped in on message 30 of a thread is one of the most expensive cognitive interrupts in a knowledge worker's day. This prompt produces the catch-up that makes the new participant useful inside a minute.

**The prompt:**

``` You are a thread historian producing a catch-up summary for a newly added participant. INPUT: - A thread with subject, full participant list, all messages in chronological order, and the date the new participant was added. - The new participant's role (named or 'unknown'). OUTPUT: { "thread_topic": "<one phrase>", "current_status": "awaiting_decision_from_<role> | blocked_on_<role> | in_progress | resolved | stalled", "what_was_decided_so_far": [<list of decisions with the message that locked each one in>], "open_questions": [<list of questions still on the table>], "why_you_were_added": "<one sentence — the inferred reason, with the message excerpt that suggests it>", "key_participants": [{ "name": "<x>", "role_in_thread": "<decider | proposer | blocker | informed | scribe>" }], "recommended_first_action_for_new_participant": "<one sentence>", "what_NOT_to_say_yet": [<list of topics that have already been settled and re-litigating would be a footgun>] } Rules: - The 'what_NOT_to_say_yet' field is mandatory — landing on a settled topic is the most common newcomer mistake. - key_participants role assignments must be based on actual message behavior, not job titles. - If the new participant's role is 'unknown', state the inferred role with a low confidence flag in why_you_were_added. - Decisions must be quoted (exact substring) — if a decision can't be quoted, it's not actually a decision. ```

**Why it works:** The what_NOT_to_say_yet field is the senior-EA move — it tells the newcomer where the live wires are buried. The role-from-behavior-not-title rule catches the case where the CFO is the scribe and the VP of engineering is the actual decider.

**Sample output:** 32-message thread on board deck approval → topic, status (awaiting_decision_from_CEO), 4 decisions quoted with message IDs, why_added: *"Asked to validate the financial assumptions in slide 14."* what_NOT_to_say_yet: *"Whether to include the Q3 churn cohort — already debated and resolved on May 28."*

**When to use:** Every time the user is added to an in-flight thread of 8 or more messages. Saves the read, prevents the footgun reply.

The default LLM reply is too long, too neutral, and too generic. This prompt drafts a reply tuned to a sender tier — VIP, customer, internal peer, vendor, unknown — and stays inside three sentences.

**The prompt:**

``` You are a communications drafter producing 3-sentence reply drafts tuned to sender tier. INPUT: - The email being replied to (from, subject, body) - Sender tier: vip | customer | internal_peer | direct_report | vendor | unknown - Desired reply intent: agree | decline | hedge | ask_clarifying_question | delegate | acknowledge_only - User's voice profile: brief (e.g. "warm, direct, uses 'happy to', avoids exclamation marks") OUTPUT: { "reply_draft": "<exactly 3 sentences>", "opening_sentence_function": "acknowledge_their_message | name_the_decision | answer_first | thank_concisely", "second_sentence_function": "give_the_substance | propose_the_meeting | name_the_constraint", "closing_sentence_function": "next_step | offer_optionality | sign_off_warmly", "tier_adaptations_applied": [<list — what changed for this tier>], "red_flags_in_draft": [<list — phrases that might land wrong, or empty>] } Rules: - EXACTLY three sentences. No bullet points, no postscript. - VIP tier: open with the decision/answer, not pleasantries. - Customer tier: acknowledge the specific issue named by the customer in their words before the substance. - Internal_peer / direct_report: skip the pleasantries entirely; go straight to the substance. - Vendor / unknown: include a polite no if the intent is decline, with no over-explanation. - The voice_profile is honored — no exclamation marks if the profile excludes them, no "happy to" if the profile doesn't use it. - Never invent commitments — if a date or number isn't in the input, write "<DATE>" or "<NUMBER>" placeholders for the user to fill. ```

**Why it works:** The three-sentences-exactly constraint is the ruthless filter — three sentences forces the model to pick its single substance sentence. The voice_profile honoring fights the failure mode where every LLM reply sounds like every other LLM reply. The placeholder-for-numbers rule prevents the worst failure mode: a confident-sounding made-up date inside the user's voice.

**Sample output:** Reply to a VIP investor asking for a quick status update, intent: hedge. Draft: *"Closing the round inside the next two weeks pending the redlined liquidation preference language. I can send a one-paragraph update Thursday morning or set a 15-minute call — your call. Will flag the moment the term sheet lands."*

**When to use:** Inside the reply_personally bucket from prompt #3. The user reads the 3 sentences, edits, sends — total: under 60 seconds per email.

The inbox is a passive log of how the user actually spent their attention. A weekly retro against the archive surfaces the patterns — sender concentration, time-of-day skew, and the categories of email that ate the most reply time — that no calendar audit catches.

**The prompt:**

``` You are an executive operations analyst synthesizing the user's weekly email archive for a Friday retro. INPUT: - The user's archived/sent emails from the trailing 7 days (subjects + metadata only — bodies are not required). - The user's stated priorities for the week (3-5 bullets). OUTPUT: { "week_of": "<YYYY-MM-DD>", "total_emails_received": <number>, "total_emails_sent": <number>, "top_5_senders_by_volume": [{ "sender": "<x>", "received": <n>, "sent": <n>, "net": "net_consumer | net_producer | balanced" }], "time_of_day_skew": "<one sentence — when the user was most active>", "category_breakdown": [{ "category": "<x>", "emails": <n>, "share": <0-1> }], "alignment_with_stated_priorities": [{ "priority": "<x>", "email_volume": <n>, "alignment": "strong | weak | none" }], "biggest_time_sink": "<category or sender — the single biggest cost", "one_change_to_try_next_week": "<a concrete experiment — a filter, a delegated sender, a templated reply, a no-meeting block>", "absence_signal": "<a person or category that was notably absent — what does that mean>" } Rules: - The alignment_with_stated_priorities section is mandatory and must reference the user-provided priorities verbatim. - 'One change to try next week' must be concrete and reversible — not 'spend less time on email'. - The biggest_time_sink must be named — if multiple are tied, pick the one with the highest cost to the priority list. - Bodies are not required; this is a metadata-level synthesis. - The absence_signal field is the half of the retro most users skip — name it. ```

**Why it works:** Tying the archive to stated priorities surfaces the priority-versus-attention gap that the user can't see from inside the week. The one-concrete-reversible-experiment rule prevents the retro from collapsing into "do better" — a failure mode of every productivity ritual. Drucker's Managing Oneself defined the feedback-analysis discipline this prompt operationalizes.

**Sample output:** 287 emails received, 94 sent. Top sender by volume: a vendor flagged "net_consumer." Biggest time sink: "Sequoia thread, 18 emails / ~2.5h reply time — alignment: strong with stated priority 'close Series A'." One change: "Move all non-Sequoia VC threads to a Friday-only batch." Absence: "No customer-success escalations this week — first time in 6 weeks."

**When to use:** Friday afternoon, 10 minutes. Output feeds the user's weekly review, not a public report.

<a href="https://www.anthropic.com/claude?utm_source=aipromptshub&utm_medium=blog&utm_campaign=inbox-triage-weekly-retro" style={{display:"inline-block",padding:"10px 18px",background:"#0a66ff",color:"white",borderRadius:"6px",textDecoration:"none",fontWeight:"bold",marginTop:"12px"}}> Run the weekly retro on Claude → </a>

The chain that compresses a 90-minute morning triage into 20 minutes:

1. **Pre-triage (automated, 0 min user).** Run the redaction guardrail across the overnight pile. 2. **Minute 0-2 (automated).** Run #1 (briefing) and #6 (threat scanner) in parallel. 3. **Minute 2-4 (human, 2 min).** Read the 5-bullet briefing. Scan threat scanner output. Decide nothing yet. 4. **Minute 4-6 (automated).** Run #2 (action items) and #3 (reply/delegate/schedule/archive) on the full pile. 5. **Minute 6-9 (human, 3 min).** Approve the action items into the task system. Skim the archive bucket for the override_signal flags. 6. **Minute 9-11 (automated).** Run #4 (no-reply candidates) on the archive bucket and #7 (attachment TL;DRs) on flagged emails. 7. **Minute 11-14 (human, 3 min).** Confirm the no-reply archives. Read the 3-sentence document summaries; decide approve/reject/escalate. 8. **Minute 14-18 (automated → human).** Run #9 (3-sentence reply drafter) against the reply_personally bucket. User edits and sends. 9. **Minute 18-20 (human, 2 min).** Run #8 against any in-flight thread that ballooned overnight. 10. **Friday only.** Run #5 (follow-up surfacer) and #10 (weekly retro). 15 extra minutes once a week.

Cost: 20 minutes of human time plus roughly $1-$3 of token spend per Anthropic's pricing page at current Sonnet 4.5 + Opus 4.7 rates. Replaces a 90-minute morning triage. The throughput multiplier is the redaction guardrail and the 3-sentence reply drafter together — without them, the user reverts to old habits inside a week.

<a href="https://www.anthropic.com/pricing?utm_source=aipromptshub&utm_medium=blog&utm_campaign=inbox-triage-chain" style={{display:"inline-block",padding:"10px 18px",background:"#0a66ff",color:"white",borderRadius:"6px",textDecoration:"none",fontWeight:"bold",marginTop:"12px"}}> Start the 20-minute chain on Claude Pro → </a>

### Which Claude model should I use for inbox triage prompts?

Sonnet 4.5 is the default for high-volume per-email classification (#2, #3, #4, #6) — fast and cheap enough to run against an entire morning pile in under a minute. Use Opus 4.7 for the synthesis-heavy steps (#1 briefing, #8 thread summarizer, #10 weekly retro) where holding many messages in working context matters more than latency. See Anthropic's model selection guide.

### Is it safe to paste my inbox into Claude?

Only after the redaction step. The redaction prompt at the top of this article is the load-bearing safety control — it replaces credentials, PII, and confidential blocks with placeholder tokens before any triage prompt sees the body. Anthropic's commercial terms document data handling, but a redaction step on your side is the right belt-and-suspenders posture for any inbox automation.

### Will Claude make up deadlines from email bodies?

Yes, unless constrained. Prompt #2's due_date_source field requires the model to return the exact substring of the email body that justified the deadline. If no substring exists, due_date is 'none stated'. The same exact-substring discipline appears in Anthropic's prompt engineering documentation.

### How does this compare to Outlook Copilot or Gmail's built-in summarizer?

Outlook Copilot and Gmail summaries do the equivalent of prompt #1 — and they do it well — but they don't chain. The 90-minutes-to-20-minutes gain comes from chaining briefing into action-item extraction into reply drafting with confidence flags routing the override cases.

### Can these prompts replace an executive assistant?

No. The prompts replace the read-and-classify labor; they don't replace the relationship judgment an EA brings — which messages need warmth, which board members hate one-line replies, which vendor is one nag away from being fired.

### What if my inbox is too large to fit in one Claude call?

Chunk by date range (last 12 hours, last 24 hours) and run #1-#4 per chunk. Sonnet 4.5's 200K context handles roughly 300-500 typical emails per call before chunking is required.

### Are the sample outputs synthesized or real?

Synthesized for illustration. The structure, constraint compliance, and confidence-flag behavior are representative of Sonnet 4.5 and Opus 4.7 outputs with the prompts as written; specific senders, threads, and dates are illustrative.

- Microsoft, 2024 Work Trend Index Annual Report. - McKinsey Global Institute, The Social Economy: Unlocking value and productivity through social technologies. - McKinsey, The State of Organizations 2023. - Peter Drucker, Managing Oneself (HBR Classic, 2005). - David Maister, Charles Green, Robert Galford, *The Trusted Advisor* (Free Press, 2000). - Anthropic prompt engineering documentation. - Anthropic model documentation. - Anthropic commercial terms. - Anthropic pricing page.

---