Esta página se muestra en inglés. Una traducción al español está en curso.
其他Oct 4, 2026·7 min de lectura

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.

Listo para agents

Instalación lista para agent

Este activo puede instalarse después de elegir el runtime, revisar el plan y ejecutar el comando correspondiente.

Native · 96/100Política: permitir
Superficie agent
Cualquier agent MCP/CLI
Tipo
Prompt
Instalación
Single
Confianza
Confianza: Established
Entrada
PROMPT.md
Comando de instalación directa
npx -y tokrepo@latest install ad39b396-1b4f-43a8-ba62-0a7310ba044f --target codex

Ejecutar después de confirmar el plan con dry-run.

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 (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

Original TokRepo prompt · CC BY 4.0. Reference documents retain their own rights.

Discusión

Inicia sesión para unirte a la discusión.
Aún no hay comentarios. Sé el primero en compartir tus ideas.

Activos relacionados