Back to Details

permission-preflight

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Permission Preflight

权限预检

Reduce interruptions by grouping foreseeable authorizations for the current task. Respond in the user's language.
通过将当前任务中可预见的授权归组来减少中断。请使用用户的语言回复。

Prepare the list

准备列表

Inspect context, applicable instructions, and available tools using actions already authorized. Identify actions that actually require additional authorization, accounting for approvals already given in the conversation. Continue independent work that is already authorized.
Prepare concrete, reviewable results before requesting approval to publish, send, deploy, or perform another action with external effects. Present an early forecast when useful, but request approval for those effects after the result is prepared. If the user only wants an inventory, provide the forecast without starting execution.
Assign requests stable numbers throughout the task. Each item must specify:
  • The action and target: path, branch, environment, service, or recipient.
  • The purpose and concrete reason authorization is needed, including the originating instruction or restriction when applicable.
  • The relevant effect: publication, production changes, deletion, cost, or additional access.
Separate actions the user can approve independently. Limit access to the necessary resource. Mark conditional permissions with the event that would make them necessary. If no requests are needed, state this briefly and proceed.
Present the list in chat and end the request with:
You can reply “approve all”, “approve all except 4”, “approve 1 and 3”, or “approve none”.
Ask directly in chat for authorization; reserve optional question tools for preferences and clarification when those tools do not support permission requests.
使用已经获得授权的操作检查上下文、适用的指令和可用工具。识别确实需要额外授权的操作，并考虑对话中已经给予的批准。继续执行已经获得授权的独立工作。
在请求批准发布、发送、部署或执行其他具有外部影响的操作之前，先准备好具体、可审查的结果。如果有用，可以尽早提供预测，但应在结果准备就绪后再请求批准这些影响。如果用户只需要一份权限清单，则提供预测，不要开始执行。
在整个任务过程中，为请求分配稳定的编号。每个条目必须明确：
  • 操作和目标：路径、分支、环境、服务或接收方。
  • 目的以及需要授权的具体原因；适用时，还要注明来源指令或限制。
  • 相关影响：发布、生产环境变更、删除、费用或额外访问权限。
将用户可以独立批准的操作分开。访问权限应限制在必要范围内。对于有条件触发的权限，请标明使其成为必要权限的事件。如果不需要任何请求，请简要说明并继续执行。
在聊天中呈现该列表，并以以下内容结束请求：
你可以回复“全部批准”“除 4 外全部批准”“批准 1 和 3”或“全部拒绝”。
直接在聊天中询问授权；仅当可选问题工具不支持权限请求时，才使用这些工具来了解偏好和澄清事项。

Interpret and execute

解释并执行

Map the response to the presented list:
  • “Approve all” authorizes every item in that list within its stated limits.
  • “Approve all except 4” authorizes the other items and denies item 4.
  • “Approve 1 and 3” authorizes only those items; the rest remain unauthorized.
  • “Approve none” denies the list.
Accept equivalent wording, ranges, and multiple exclusions when the meaning is unambiguous. Clarify ambiguous responses or nonexistent numbers before executing affected actions. Silence is not approval.
Briefly acknowledge approved or excluded numbers and continue authorized work. Preserve the decision across subsequent turns of the same task. When a denied item blocks another, explain the dependency and continue independent parts; do not perform the denied action through an alternative route.
Append newly discovered permissions with new numbers, preserving earlier numbers. Material changes to a target, effect, or scope require a new item and fresh approval. Blanket approval applies only to the list the user saw.
将回复与所呈现的列表进行映射：
  • “全部批准” 表示在各自所述范围内授权列表中的每个条目。
  • “除 4 外全部批准” 表示批准其他条目，并拒绝第 4 项。
  • “批准 1 和 3” 表示仅批准这两个条目；其余条目仍未获授权。
  • “全部拒绝” 表示拒绝整个列表。
在含义明确时，接受等同表述、范围和多项排除。对于含义不明确的回复或不存在的编号，在执行受影响的操作之前进行澄清。沉默不视为批准。
简要确认已批准或已排除的编号，并继续执行已获授权的工作。在同一任务的后续轮次中保留这些决定。当某个被拒绝的条目阻塞另一项操作时，说明依赖关系并继续执行独立部分；不要通过替代路径执行被拒绝的操作。
以新编号追加新发现的权限，同时保留之前的编号。目标、影响或范围发生实质性变化时，需要新增条目并重新获得批准。一揽子批准仅适用于用户看到的列表。

Approval boundaries

批准边界

Chat approval records the user's authorization; mandatory tool, sandbox, or platform confirmations still apply when the action is performed. Explain this distinction when relevant without promising to eliminate those dialogs. Advance approval does not replace a confirmation that applicable instructions require immediately before execution.
If an automatic review rejects an action, seek an alternative within the approved scope. If the action remains blocked, separately report the rejected action and stated reason; request intervention only for what still depends on the user.
聊天中的批准记录了用户的授权；执行操作时，工具、沙箱或平台强制要求的确认仍然适用。相关时应解释这一区别，但不要承诺可以消除这些对话框。提前获得的批准不能替代适用指令要求的、执行前必须立即进行的确认。
如果自动审查拒绝某项操作，请在已批准的范围内寻找替代方案。如果该操作仍被阻止，请单独报告被拒绝的操作及其所述原因；仅就仍然依赖用户处理的部分请求介入。