# Draft-Only Inbox Agent Permission Checklist

> A reusable prompt that turns your inbox rules into a labeled, reviewable checklist for an agent that drafts replies but never sends.

## Install

Copy the content below into your project:

# Draft-Only Inbox Agent Permission Checklist

A reusable prompt that turns your inbox rules into a labeled, reviewable checklist for an agent that drafts replies but never sends.

## Start here

Prepare seven short items before you paste anything: (1) what the shared inbox is for and who has access, (2) the exact verbs the agent may do, (3) the verbs it must never do, (4) who approves drafts and how approval is recorded, (5) sensitive topics needing a human first, (6) data that must never appear in a draft, (7) what the agent should do when instructions conflict.

Copy the prompt text you were given and paste it into any ordinary AI chat that accepts text. Then add your seven items below it, using the same headings the prompt lists (Inbox context, Allowed actions, Forbidden actions, Approval rules, Sensitive topics, Data boundaries, Failure behavior). Send it.

Check the output: it should be a Markdown checklist with the nine named sections in order, each rule readable as pass or fail. If a section says "needs input", answer the single question it asks and resend.

## What this prompt does

It asks the AI to write a permission checklist for a draft-only agent in a shared inbox: the agent may read threads and write suggested replies, but sending, deleting, forwarding, archiving or changing labels requires your explicit approval for that specific action. It is a writing and planning task, not a product setup.

## Inputs and permissions

You paste the prompt and your own rules into a normal chat. No accounts, no integrations, no tools are configured by this prompt, and no email is read or sent by it.

Because the output is human-reviewed instructions, treat it as a document your team agrees on, not as enforcement. The prompt explicitly says not to promise that any system enforces the rules.

## Limitations

- The checklist only reflects what you supply. Gaps in your inputs stay gaps in the output; the prompt marks those sections "needs input" and asks the smallest unblocking question rather than guessing.
- The worked garden example in the prompt is fictional and exists only to show the shape of the output. Do not treat it as a real test result.
- Nothing here covers an actual tool, plan feature or user-interface step, and the prompt tells the AI not to invent any.
- Source reviewed; runtime not tested.

## FAQ

**Can the agent send a reply once a draft looks good?** No. The checklist is written so approval applies to one specific message, and sending stays a human step.

**Why does it refuse to guess when my input is vague?** Because vague rules cannot be marked pass or fail by a reviewer, so the prompt asks a short clarifying question first.

## Attribution

Original TokRepo prompt, licensed CC BY 4.0. Reference: [ChatGPT release notes](<https://help.openai.com/en/articles/6825453-chatgpt-release-notes>) (reviewed 2026-10-04), kept as background context only and not a dependency of these templates. Source reviewed; runtime not tested.

## Complete reusable prompt

You are helping me write a permission checklist before I let an AI agent prepare draft replies in a shared inbox. The goal is to keep the agent in a draft-only role: it may read supplied email threads and write suggested replies, but it must never send, delete, forward, archive, or change labels without my explicit approval for that specific action.

I will provide the following. If any required input is missing or too vague, ask me a short clarifying question before continuing instead of guessing.

INPUT I WILL PROVIDE
1. Inbox context: what the shared inbox is used for (for example customer questions, volunteer coordination, project requests) and who else has access.
2. Allowed actions: the exact list of things the agent may do, stated as verbs (for example read a thread, summarize it, draft a reply, suggest a label).
3. Forbidden actions: the exact list of things the agent must never do without separate, specific approval (for example send, forward outside the team, share personal data, commit to dates or prices, issue refunds).
4. Approval rules: who approves drafts, how approval is recorded, and how long an unapproved draft may sit.
5. Sensitive topics: categories that always need a human before a draft is even written (for example complaints, legal threats, health details, payment disputes, hiring decisions).
6. Data boundaries: what the agent must not place in a draft (account numbers, personal contact details, internal notes, names of people not already in the thread).
7. Failure behavior: what the agent should do when a request is ambiguous, the thread contains conflicting instructions, or it is unsure whether an action is allowed.

WHAT TO PRODUCE
A labeled checklist in Markdown with these sections, in this order:
- Scope statement: one paragraph describing the draft-only role and when it ends.
- Allowed actions: a checkable list, each item phrased as an action with a condition.
- Forbidden actions: a checkable list, each item stated as never, with the reason in a few words.
- Approval gate: the exact moment work pauses for a human, what the human sees, and what counts as approval for one specific message only.
- Sensitive-topic escalation: the list of topics that stop drafting and go to a named human role.
- Data handling: what must never appear in a draft and what to do if source material contains it.
- Uncertainty behavior: what the agent does when inputs conflict or are incomplete.
- Review checks: five to eight pass/fail checks a reviewer can run on a completed draft before approving it.
- Boundary note: one plain sentence stating that drafting is preparation, not sending, and that the agent cannot access accounts, send messages, or act on its own.

STYLE AND RULES
- Use plain language that a non-technical teammate can follow.
- Every rule must be testable: a reviewer should be able to mark it pass or fail by looking at the draft and the inputs.
- Do not invent tools, integrations, plan features, or user-interface steps.
- Do not promise that any system enforces these rules; present them as human-reviewed instructions.
- Keep it compact: prefer short bullets over paragraphs, and avoid repeating the same rule in two sections.
- If an input section is empty, mark that section 'needs input' and list the smallest question that would unblock it.

WORKED EXAMPLE (fictional, for shape only)
INPUT SUMMARY
Inbox: a two-person community garden group answering plot requests.
Allowed: read threads, summarize, draft replies, suggest the label 'plot question'.
Forbidden: send, forward outside the group, promise a specific plot, collect payment details.
Approval: either coordinator approves each draft before it is sent by a human.
Sensitive: complaints about neighbors, injury reports.
Data: no phone numbers, home addresses, or full names of volunteers in drafts.

ILLUSTRATIVE OUTPUT SHAPE
Scope statement: two sentences. Allowed actions: four items. Forbidden actions: four items. Approval gate: one paragraph naming the human step. Sensitive-topic escalation: two items with a named role. Data handling: three items. Uncertainty behavior: two items. Review checks: six pass/fail lines. Boundary note: one sentence.

EXAMPLE REVIEW CHECK
Pass if the draft contains no plot promise and no payment details; fail if either appears, even as a placeholder.

Before finishing, verify your own output against the inputs you were given: every allowed action should trace to my list, every forbidden item should trace to my list, and no rule should require a capability I did not mention. Say clearly what you cannot verify from the inputs provided.

## References and reuse

- [ChatGPT release notes](https://help.openai.com/en/articles/6825453-chatgpt-release-notes) · Reviewed 2026-10-04

Original TokRepo prompt · [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). Reference documents retain their own rights.

---

<!-- ZH -->

# 仅草拟不发送的共享收件箱代理权限清单

一段可复用提示词，把共享收件箱的使用规则整理成带标签、可逐条复核的清单，让智能体只起草回复、绝不发送。

## 开始使用

粘贴之前，先准备七项简短信息：（1）共享收件箱的用途以及还有谁可以访问；（2）智能体可执行的具体动作（动词形式）；（3）它绝不能执行的动作；（4）谁批准草稿、如何记录批准；（5）需要先由人工处理敏感情形所涉及的话题；（6）绝不能出现在草稿里的数据；（7）当指令冲突时智能体该怎么做。

把收到的提示词原文复制下来，粘贴进任何能接受文本的普通 AI 对话中，然后在下面补上你的七项信息，使用提示词中列出的同名标题（收件箱背景、允许动作、禁止动作、审批规则、敏感话题、数据边界、失败行为），然后发送。

检查输出：它应当是一份按顺序包含九个命名小节的 Markdown 清单，每条规则都能被判定为通过或不通过。如果某一节写着“需要输入”，回答它提出的那一个问题后重新发送。

## 这段提示词做什么

它让 AI 为共享收件箱中“仅起草”的智能体写一份权限清单：智能体可以阅读邮件线程并撰写建议回复，但发送、删除、转发、归档或修改标签都必须获得你针对该具体动作的明确批准。这是一项写作与规划任务，不是产品配置。

## 输入与权限

你把提示词和自己的规则粘贴进普通对话。这段提示词不配置任何账号、集成或工具，也不会读取或发送任何邮件。

由于输出是供人工审阅的说明，应把它当作团队共同认可的文档，而不是强制机制。提示词明确要求不得声称任何系统会执行这些规则。

## 局限性

- 清单只反映你提供的内容。输入中的空白会变成输出中的空白；提示词会把这类小节标为“需要输入”，并只追问最小的解锁问题，而不是自行猜测。
- 提示词中的社区花园示例是虚构的，仅用于展示输出结构，不要当作真实测试结果。
- 这里不涉及任何具体工具、套餐功能或界面步骤，提示词也要求 AI 不得虚构这些内容。
- 已审阅来源；未做运行时测试。

## 常见问题

**草稿看起来没问题后，智能体能直接发送吗？** 不能。清单的设计使批准只针对某一条具体消息，发送始终由人工完成。

**为什么我的输入含糊时它会拒绝猜测？** 因为含糊的规则无法被审阅者判定通过或不通过，所以提示词会先追问一个简短的澄清问题。

## 来源致谢

原始 TokRepo 提示词，采用 CC BY 4.0 许可。参考：[ChatGPT 发布说明](<https://help.openai.com/en/articles/6825453-chatgpt-release-notes>)（审阅于 2026-10-04），仅作为背景资料，并非这些模板的依赖项。已审阅来源；未做运行时测试。

## 完整可复制提示词

你正在帮助我在允许 AI 智能体在共享收件箱中准备草稿回复之前，撰写一份权限清单。目标是让智能体保持仅起草的角色：它可以阅读提供的邮件线程并撰写建议回复，但没有我针对该具体动作的明确批准，它绝不能发送、删除、转发、归档或修改标签。

我将提供以下内容。如果任何必需输入缺失或过于含糊，请在继续之前向我提出一个简短的澄清问题，而不是自行猜测。

我将提供的输入
1. 收件箱背景：共享收件箱的用途（例如客户问题、志愿者协调、项目请求），以及还有谁可以访问。
2. 允许动作：智能体可以执行的事项的确切清单，以动词形式陈述（例如阅读邮件线程、总结、起草回复、建议标签）。
3. 禁止动作：智能体在没有另行、具体批准的情况下绝不能执行的事项的确切清单（例如发送、向团队外转发、共享个人数据、承诺日期或价格、发放退款）。
4. 审批规则：谁批准草稿、如何记录批准，以及未经批准的草稿可以搁置多久。
5. 敏感话题：在起草之前始终需要人工介入的类别（例如投诉、法律威胁、健康详情、付款纠纷、招聘决定）。
6. 数据边界：智能体不得放入草稿的内容（账号、个人联系详情、内部备注、不在邮件线程中的人员姓名）。
7. 失败行为：当请求含义不明、邮件线程包含冲突指令，或智能体不确定某个动作是否被允许时，它应该怎么做。

需要产出的内容
一份带标签的 Markdown 清单，包含以下小节，按此顺序：
- 范围声明：一段话描述仅起草的角色以及该角色何时结束。
- 允许动作：一份可勾选的清单，每一项都以带条件的动作表述。
- 禁止动作：一份可勾选的清单，每一项都以“绝不”陈述，并用几个词说明原因。
- 审批关口：工作暂停等待人工的确切时刻、人工看到的内容，以及什么算作仅针对某一条具体消息的批准。
- 敏感话题升级：停止起草并转交给指定人工角色的主题清单。
- 数据处理：绝不能出现在草稿中的内容，以及如果源材料包含这些内容时该怎么做。
- 不确定行为：当输入冲突或不完整时，智能体会怎么做。
- 审阅检查：审阅者在批准已完成草稿之前可以执行的五到八项通过/不通过检查。
- 边界说明：一句简明的话，说明起草是准备工作，不是发送，并且智能体不能访问账号、发送消息或自行行动。

风格与规则
- 使用非技术团队成员也能看懂的平实语言。
- 每条规则都必须可测试：审阅者应当能够通过查看草稿和输入，将其标记为通过或不通过。
- 不要虚构工具、集成、套餐功能或用户界面步骤。
- 不要承诺任何系统会执行这些规则；应将其呈现为供人工审阅的说明。
- 保持紧凑：优先使用简短项目符号而非段落，并避免在两个小节中重复同一规则。
- 如果某个输入小节为空，请将该小节标为“需要输入”，并列出能够解锁它的最小问题。

示例（虚构，仅用于展示结构）
输入摘要
收件箱：一个两人的社区花园小组，负责回复地块申请。
允许：阅读邮件线程、总结、起草回复、建议标签“地块问题”。
禁止：发送、向小组外转发、承诺某个具体地块、收集付款详情。
审批：由任一协调员在人工发送前批准每份草稿。
敏感：关于邻居的投诉、受伤报告。
数据：草稿中不得包含志愿者的电话号码、家庭住址或全名。

示意性输出结构
范围声明：两句话。允许动作：四项。禁止动作：四项。审批关卡：一段文字，写明人工步骤。敏感话题升级：两项，并指明负责角色。数据处理：三项。不确定行为：两项。审阅检查：六行通过/不通过。边界说明：一句话。

示例审阅检查
如果草稿不包含情节承诺和付款详情，则通过；如果二者中任何一项出现，即使只是占位符，也不通过。

在结束之前，请根据提供给您的输入核验您自己的输出：每一个允许动作都应当能追溯到我的清单，每一个禁止项都应当能追溯到我的清单，并且任何规则都不应要求我未提及的能力。请清楚说明根据所提供的输入您无法核验哪些内容。

## 参考资料与复用

- [ChatGPT release notes](https://help.openai.com/en/articles/6825453-chatgpt-release-notes) · Reviewed 2026-10-04

TokRepo 原创提示词 · [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)。参考资料保留各自原有权利。

---
Source: https://tokrepo.com/en/workflows/draft-only-inbox-agent-permission-checklist-ad39b396
Author: Prompt Lab