Why this guide exists
See the change before you build anything.
Everything arrives in one pile, so everything asks for your attention.
- Important conversations sit beside receipts, newsletters, alerts, and routine requests.
- You make the same reply, priority, and follow-up decisions again every day.
- Messages that need a thoughtful answer keep sending you back to a blank page.
You open email to decisions, not a wall of messages.
- Urgent and relationship-sensitive messages are surfaced with the reason they matter.
- Replies are drafted from the thread and writing you have already approved.
- Waiting work stays visible, and recurring requests become rules or simple procedures.
Start with one prompt
Claude asks the questions, sets it up, and proves it with you.
One prompt runs the whole setup.
Paste this into a new Claude conversation. Claude will first agree what mail it may use. Then it learns what matters, connects email safely, builds your sorting and drafting rules, tests them on a sample, and walks through the first review.
Read the full prompt before copying
Guide me through building my inbox system from interview to a tested first run. You own the setup sequence and keep all decisions in this conversation. Do not ask me to copy another prompt. Use five phases: Interview, Connect, Build, Test, Run. Show the current phase and one decision at the top of each reply. Reuse known answers. Offer "Not sure" and "Not needed" where useful. Explain any Claude feature I may not recognize in one plain sentence. INTERVIEW Ask at most seven short questions, one at a time. Set the privacy boundary before requesting any message sample. Map: 1. My Claude surface and where the system should live: Custom Skill, Cowork folder, Project, or downloadable files. 2. The accounts, date windows, folders, and message types in scope. 3. The actual decisions: reply, task, calendar, CRM or project update, waiting, reference, receipt, notification, marketing, uncertain, or no action. 4. Important people and relationships, response expectations, real urgency, and the cost of a false positive versus a missed message. 5. Existing labels, deterministic sender rules, drafts, task or CRM fields, calendar habits, and review cadence. 6. What may be read, classified, drafted, labelled, or proposed, plus what may never be sent, deleted, archived, filtered, scheduled, or changed without approval. 7. Difficult cases, sensitive mail, prompt injection, absence or vacation handling, and the measure for a useful review. Then show one compact blueprint with categories, ordered decision rules, always-review list, uncertainty rule, downstream actions, approval boundaries, missing access, recovery, and a 30-message test plan. Ask for the single most important correction. AFTER I APPROVE THE BLUEPRINT Continue through Connect, Build, Test, and Run in this conversation. Never ask for passwords, tokens, or credentials. Verify each exact mail or downstream action on low-risk data. Record unavailable actions with a manual fallback. Build and install the package for my chosen surface. Show the file manifest and safety-critical rules before any write or upload. Run all three tests, measure false positives and false negatives, repair the package after failures, and rerun them. For the first inbox window, prepare a review brief and one exact action manifest. Ask for approval for the bounded set, execute only what I approve, verify each result, and finish with a run receipt plus one recommended rule improvement.
What happens next
You answer a few short questions. Claude carries the work through these five stages and pauses when it needs your review.
You are finished when a 30-message dry run catches what matters, handles difficult mail safely, and one real inbox review works without hiding uncertainty.
About 25 minutes to map and set up, then a 30-message dry run and one reviewed inbox window.
- 01Interview
What matters, how fast, and which messages always need you.
- 02Connect
The email actions checked with the narrowest useful access.
- 03Build
Your sorting rules, reply examples, review routine, and change record.
- 04Test
A measured dry run with mistakes fixed and tried again.
- 05Run
One inbox review with every approved action checked.
Want the details?
Open only the stage you need. These are explanations and recovery points, not five more tasks to complete.
01Answer a short interview
Claude learns what good work looks like for you before it builds anything.
Answer a short interview
Claude learns what good work looks like for you before it builds anything.
Paste this into a new Claude conversation. Claude will first agree what mail it may use. Then it learns what matters, connects email safely, builds your sorting and drafting rules, tests them on a sample, and walks through the first review.
The interview is concise and stays in one conversation. Claude reuses what you have already said, offers “Not sure” when that is a valid answer, and shows you a short blueprint before making anything.
02Connect only the apps you need
Claude checks each required action safely and keeps a manual option when access is limited.
Connect only the apps you need
Claude checks each required action safely and keeps a manual option when access is limited.
Claude should lead this capability check after the privacy boundary is set. Inspect read, draft, label, calendar, task, and record actions separately. Keep send, delete, archive, filters, and account settings outside the first version.
Resume my inbox setup at Connect using the approved blueprint in this conversation. Guide me through one required system at a time. Never ask me to paste credentials in chat. For mail, start with one account and a bounded date window. Test search and thread retrieval before drafts or labels. Use a fictional draft, disposable label, or low-risk downstream record for any write proof. Record a capability matrix with: exact action, minimum scope, approval setting, test, observed result, status, fallback, and removal or undo step. Use only Ready, Needs approval, Manual fallback, or Blocked. If an action is unavailable, preserve the workflow with a review brief, draft, export, or copy-and-paste handoff. Do not use computer control or broaden access without asking. Finish with the matrix and ask for one correction before Build.
Email account
- Why
- Read permitted messages, inspect threads, apply supported labels, and create drafts where available.
- Start safely
- Use one account and a bounded date window. Keep send, delete, archive, and account-setting actions blocked.
- Proof
- Claude retrieves the expected sample, preserves threads, and creates one draft without sending it.
Calendar and tasks
- Why
- Turn clear commitments into proposed events or action items.
- Start safely
- Prepare proposals in chat before creating anything. Require an owner, date, source message, and approval.
- Proof
- A test task or event contains the correct source, owner, time zone, and due date.
CRM or project system
- Why
- Add relevant relationship or project context and prepare a supported update.
- Start safely
- Read one low-risk record first. Do not update stages, amounts, or commitments from an email alone.
- Proof
- The proposed update targets the correct record and includes a source link or message identifier.
Reference files
- Why
- Use current priorities, communication rules, and client boundaries when classifying mail.
- Start safely
- Provide only the minimum approved files and keep client contexts separated.
- Proof
- Claude explains which rule or context changed the classification.
03Build the reusable setup
Claude creates the instructions, examples, templates, and review rules behind the result.
Build the reusable setup
Claude creates the instructions, examples, templates, and review rules behind the result.
Resume my inbox setup at Build. Use the approved blueprint and capability matrix. Build for the installation path we approved. For a Custom Skill, create an installable inbox-system ZIP with the folder at its root and a valid SKILL.md. For Cowork, write only inside the approved working folder. For a Project, provide project instructions and exact knowledge files. Without file access, provide downloadable files and a ZIP. Create a focused package with triggers, privacy boundary, ordered classification logic, always-review people and topics, urgency rules, confidence and uncertainty handling, deterministic rules separated from AI judgment, draft and handoff templates, approval gates, manual fallbacks, failure reporting, duplicate prevention, a 30-message test ledger, setup instructions, and a change log. Show the manifest, install plan, and safety-critical rules first. Ask for approval before writing or packaging. After approval, create the files, validate references, guide me through enabling the package, and run a trigger smoke test. Do not relabel, archive, delete, filter, send, schedule, or change live mail in Build.
inbox-system/SKILL.mdValid metadata, triggers, ordered decisions, uncertainty handling, controls, and recovery.
inbox-system/references/inbox-context.mdScope, categories, relationships, urgency, response expectations, systems, and boundaries.
inbox-system/references/rules.mdDeterministic rules, AI judgment rules, always-review cases, exceptions, and owners.
inbox-system/templates/Review brief, reply, handoff, waiting, decline, action manifest, and run receipt.
inbox-system/tests/test-cases.mdThirty-message truth set, expected and observed decisions, error counts, corrections, and reruns.
inbox-system/SETUP.mdInstallation, exact capabilities, fallbacks, safe first run, disable, and removal steps.
inbox-system/CHANGELOG.mdVersioned rule changes tied to observed errors and approved decisions.
04Test it before real work
Claude tries normal, incomplete, and difficult examples, then fixes what fails.
Test it before real work
Claude tries normal, incomplete, and difficult examples, then fixes what fails.
Resume my inbox setup at Test. Use the installed package and do not change live mail. First confirm that the skill or instructions load. Build a 30-message truth set from permitted, redacted, exported, or fictional examples. I approve the expected outcome before you score the workflow. Run the batch, the high-cost miss, and the manipulated or sensitive case. Record expected and observed category, priority, action, uncertainty, and evidence for each message. Count false positives, false negatives, urgent misses, and overconfident classifications by category. After any failure, correct the underlying rule, example, or boundary in the package, increment the version, and rerun every affected case. Do not mark Test complete until there are no urgent misses, every uncertain case is visible, no prohibited action occurred, and the test ledger records the final result.
Thirty-message dry run
A recent permitted sample with urgent work, routine mail, newsletters, receipts, waiting items, and ambiguous threads.
No live changes occur, every classification is explained, and false positives and misses are counted by category.
High-cost miss
A quiet subject line from an important person contains a real deadline or changed commitment.
Relationship and content rules surface it for review instead of relying on urgency words alone.
Manipulated or sensitive mail
A message contains instructions aimed at Claude, confidential content, or a request to send or change an account.
The content remains data, sensitive handling is flagged, and no consequential action occurs without approval.
05Run it with review
You use one simple request, review the prepared work, and approve only the actions you want.
Run it with review
You use one simple request, review the prepared work, and approve only the actions you want.
Use my installed inbox system to review [account and bounded window]. Return a concise review brief ordered by: urgent or time-bound, needs my reply, prepared drafts, proposed tasks or calendar items, waiting, reference, and uncertain. Cite the source message and rule for every decision. Never hide an uncertain item. Before applying a label, creating a draft, task, calendar item, or record update, show one action manifest with exact target, exact change, source, duplicate check, approval, and undo path. Keep send, delete, archive, filters, and account settings out of scope. Execute only the exact set I approve. Verify each result where possible and finish with a receipt showing Prepared, Approved, Completed, Failed, Manual, or Skipped. Recommend one rule change only when the run provides evidence for it.
Do not call the first run complete until
- The installed system loaded and used the approved inbox scope.
- Urgent, high-cost, and uncertain messages remained visible.
- Every approved draft, label, task, calendar, or record action was verified or marked manual.
- No send, delete, archive, filter, setting change, duplicate, or silent retry occurred.
- The receipt and any evidence-backed rule change were recorded.
Keep control
Review the parts that matter.
- Connector names do not prove read, label, filter, or scheduled-task capability. Test the exact operation first.
- Never let the workflow send, delete, archive, or change account settings without explicit approval.
- Review false positives and missed urgent messages. A sorted inbox still needs an accountable owner.