/human-approval

name: human-approval
scope: common
description: "Request human approval before performing a SAFETY-CRITICAL, IRREVERSIBLE, or SCOPE-EXPANDING action — submit a structured context (action, scope, risk, consequence) plus options, then STOP the current turn. The platform redispatches the agent after the human decides. NEVER use for routine deliverables (writing docs / generating files / summarising chats / answering questions / explaining concepts / read-only tool calls) — those are pre-authorized; just produce the output. The 5-minute-rollback litmus test applies: if the wrong outcome can be undone in <5 minutes by editing or deleting, it is NOT approval-eligible. Routine misuse (intro/explain/summarise/file-generation) burns the user's attention budget and is a contract violation. Executes via `cloud approval` CLI."

Human Approval

> **Autonomous by default (release203).** Agents operate autonomously. Do > NOT request approval for routine tool use, running commands, or delivering > artifacts (`cloud deliver`). Only use this skill for genuinely high-risk > actions, and only when your role is explicitly configured for it. If your > `approvalPolicy` is `autonomous`, you should essentially never reach for > this skill — just do the work and report the result. > > **Anti-confabulation rule.** NEVER claim to be "waiting for human > approval" / "等待人工确认" unless you ACTUALLY invoked the approval tool > (`cloud approval request` / `prismer.approval.request_human_approval`) and > received a real `approvalId`. Narrating an approval pause you never > triggered is a hallucination — it strands the user with a phantom gate > that nothing will ever clear.

Some actions need a human in the loop **before** they execute: production deploys, large credit spend, deleting data, scope-expanding decisions. This skill submits a structured request and **halts the current turn**. The platform stores the request, notifies the human, and **redispatches the agent** with the decision when the human responds — you don't poll, you don't re-ask in the same turn.

When to use

• **Production-impacting** action: deploy, schema change, infra reconfig, payment send.
• **Irreversible**: delete files, drop tables, revoke keys, close accounts.
• **Scope-expanding**: the task as-stated implies more changes than the user originally agreed to.
• **High credit cost**: any operation that would spend > expected budget.
• **Authority-elevating**: granting access, changing roles, modifying ACLs.

Not when to use

• Routine clarifying questions ("what column name do you want?") — just ask in chat.
• Choosing between two equivalent options where the user clearly didn't care — pick one and proceed.
• When the user already explicitly approved this action in the current conversation — proceed.

Skill scope guard (v2.0.8)

The "Not when to use" list above is the **load-bearing rule**. As of release 2.0.8 we tightened it because routine deliverables (write a doc, summarise a chat, draft a slide deck, answer a question) were incorrectly triggering approval gates — the user got a yellow "等待 人工确认" banner for a request as simple as "@ceo 给我介绍一下产品 PDF", which is a deliverable request, not a scope-expansion.

The following 8 categories are **never** approval-eligible. Run them directly and report the result in the same turn:

| Category | Why it's not approval-eligible | Use instead | |---|---|---| | Writing a document / generating a report / outputting PDF, DOCX, PPTX, XLSX, CSV | The user *asked for the deliverable*; gating it is anti-UX. | Call `office-artifacts` and ship. | | Summarising a conversation / writing meeting notes | Pure synthesis from data the user already has. | Reply in chat. | | Answering a question / explaining a concept | The user invited the answer by asking. | Reply in chat. | | Asking the user for a preference ("Chinese or English?") | A chat question is the correct affordance. | Ask in chat — `human-approval` is overkill. | | Choosing model parameters / temperature / sampling style | Internal agent decision; users don't have context to judge. | Decide and proceed; mention the choice in the reply. | | Naming files / picking output paths | Internal agent decision; reversible by renaming. | Pick sensible defaults; let user override if asked. | | Internal brainstorming / scoring multiple candidates | The user asked for the *winner*, not the deliberation. | Do the work, surface the winner. | | Calling read-only MCP tools (search, web fetch, file read) | No side effect; trivially reversible. | Call directly. |

**The litmus test:** "**If this step turns out wrong, can I roll it back in under 5 minutes by editing or deleting something?**"

• If **yes** → not approval-eligible. Ship it.
• If **no** → safety-critical / irreversible / scope-expanding → approval-eligible.

Mis-using `human-approval` for routine work burns the user's attention budget, breaks chat flow, and signals lack of agent confidence — all three are real costs. The role templates (Team Manager / engineer / marketer / researcher / verifier) carry an explicit `operatingPrinciples` line as of 2.0.8: "Never trigger human-approval for routine deliverables".

CLI Reference

**Anchor required.** `POST /api/im/approvals` rejects requests with neither `taskId` nor `conversationId`, because the platform needs a target to deliver the human decision to. Every invocation MUST pass one of `--task-id` or `--conversation-id`.

# Linked to a task — the platform resumes the task on decision (preferred for marketplace / agent flows)
cloud approval request-human \
  --task-id <taskId> \
  --action "approve marketplace task completion" \
  --context "Result: scan-deps found 3 CVEs. Report attached." \
  --risk "Releases 10-credit escrow to the assignee."

# Linked to a conversation — the decision is posted back as a chat message
cloud approval request-human \
  --conversation-id <conversationId> \
  --action "delete branch feat/old-experiment" \
  --co