Token导航 LogoToken导航TokenDH.com
研究检索只读clawhub未标认证来源可访问clear审计通过

background-delivery-sop后台交付 SOP

Agent Skill

background-delivery-sop 用于查找、检索和筛选相关信息,适合在 OpenClaw 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

3,403

周安装

139

GitHub Stars

公开资料未说明

下载量

1,090
OpenClaw

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

MIT-0

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:background-delivery-sop(后台交付 SOP)
来源仓库:https://github.com/wangwang0301/background-delivery-sop
安装命令:
openclaw skills install background-delivery-sop
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 OpenClaw 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

ClawHubOpenClaw
openclaw skills install background-delivery-sop

简介

background-delivery-sop 用于查找、检索和筛选相关信息,适合在 OpenClaw 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。

  • 适用于后台任务交付标准化流程管理场景。
  • 可规范子代理或 ACP 会话中的工作交接机制。
  • 安装命令:openclaw skills install background-delivery-sop,需确认是否允许修改任务调度策略。
  • 使用前建议核对现有工作流兼容性,避免中断正在运行的任务。

SKILL.md

name
background-delivery-sop
description
Standardize how agents handle tasks that run in the background, via sub-agents, or via ACP sessions, so completed work is always proactively delivered back to the user. Use when creating or improving agent workflows for async/background execution, fixing cases where results finish but are not sent, or teaching another agent how to do receipt → execution → final delivery without making the user chase for updates.

Background Delivery SOP

Use this skill to enforce a simple rule: if work finishes in the background, the user should not have to ask for the result.

This skill is for orchestration and delivery discipline, not for the task domain itself.

Core Rule

Treat every background completion as a delivery obligation.

If a task was delegated to:

  • a background run,
  • a sub-agent,
  • an ACP session,
  • or any async workflow,

then the parent / main agent must actively close the loop with the user.

5-Line SOP

  1. If no tools are needed, answer in the main session.
  2. If tools are needed, run in background instead of expanding execution in the main session.
  3. Send exactly one short start acknowledgment.
  4. When background work completes, proactively deliver the result / progress / blocker.
  5. Do not wait for the user to ask again unless the completion adds nothing new.

Delivery States

When a background task returns, classify it into exactly one of these states and act immediately.

1. Final result available

Send the final result now.

Use when:

  • the requested work is complete,
  • the user can act on the answer immediately,
  • no further confirmation is required.

Output pattern:

  • concise conclusion,
  • essential evidence or summary,
  • next step only if useful.

2. Partial progress available

Send a progress update now.

Use when:

  • work is not fully complete,
  • but there is meaningful progress,
  • or the user benefits from seeing interim findings.

Output pattern:

  • what is done,
  • what remains,
  • expected next step / ETA if known.

3. Blocked

Send the blocker now.

Use when:

  • approval is needed,
  • input is missing,
  • permissions or environment prevent completion,
  • or an external dependency failed.

Output pattern:

  • what is blocked,
  • why,
  • exactly what the user needs to provide or approve.

Required Two-Phase Pattern

Use this fixed pattern for background work:

Phase 1: Start acknowledgment

Send one short message when the task begins.

Examples:

  • "我去后台查,查完主动回你。"
  • "我先放后台跑,完成后直接给你结果。"
  • "我去处理,完成后我会主动同步。"

Rules:

  • send it once,
  • keep it short,
  • do not repeat synonymous "already working on it" messages.

Phase 2: Completion delivery

When the background task completes, send exactly one substantive follow-up:

  • final result,
  • meaningful progress,
  • or blocker.

Never leave the task in a state where:

  • the start acknowledgment was sent,
  • the background run completed,
  • but no user-facing delivery followed.

Completion Event Handling

When a completion event reaches the main agent, default to this interpretation:

This is not just internal orchestration data. This is pending user delivery.

So the default action is:

  • deliver, not ignore;
  • summarize, not dump raw internal logs;
  • close the loop, not wait for another prompt.

When NO_REPLY Is Allowed

Only allow silence if at least one of these is true:

  1. The returned content is materially identical to what the user already received.
  2. The user has already received an equivalent final answer.
  3. The agent is suppressing a duplicate internal event and will immediately send the proper delivery message.

If none of those are true, do not swallow the completion.

Anti-Patterns

Avoid these failure modes:

  • Background task completes, but the agent says nothing.
  • Main session treats completion as internal-only and never converts it into a user-facing update.
  • Agent waits for "any update?" before sending finished work.
  • Agent sends multiple start acknowledgments but no real completion delivery.
  • Agent dumps raw internal status instead of a cleaned user-facing answer.

Quick Decision Tree

If the user asks a simple question and no tools are needed

Answer directly in the main session.

If tools or multi-step work are needed

Move execution to background / sub-agent / ACP as appropriate.

After spawning or delegating

Send one short acknowledgment.

When the async work finishes

Ask:

  • Is there a final result? → deliver it.
  • Is there useful progress? → send it.
  • Is there a blocker? → explain it.
  • Is it only duplicate noise? → silence is allowed.

Minimal Handoff Template For Other Agents

Use this template when teaching another agent or building a workflow rule:

If you move work into the background, you own the final delivery. Send one short acknowledgment when work starts. When the background task completes, proactively send either the final result, a meaningful progress update, or a blocker. Do not wait for the user to ask again unless the completion is truly duplicate.

Success Criteria

This SOP is being followed if:

  • users do not need to chase completed work,
  • background tasks consistently end with proactive delivery,
  • start acknowledgments are short and non-repetitive,
  • completion events are converted into clean user-facing updates.

Adaptive Thinking Profile

Use task-level adaptive thinking instead of trying to hot-switch the main conversation constantly.

Recommended mapping:

  • Normal chat / simple direct answersoff
  • Routine tool tasks / short checkslow
  • Multi-step analysis / complex diagnosis / multi-source researchmedium
  • Programming / code changes / engineering debugging / ACP coding harness workhigh

Recommended operating pattern:

  • keep the main session lightweight by default,
  • raise thinking mainly in background runs, sub-agents, or ACP sessions, not through frequent main-session toggling.

中文极简版

适合直接教给中文 agent 的一句话原则:

只要任务转入后台、sub-agent 或 ACP 执行,完成后就必须主动把结果发给用户;不要等用户追问。

中文 5 行 SOP

  1. 不用工具:主会话直接答。
  2. 需要工具:默认后台执行。
  3. 启动时:只发一次简短回执。
  4. 完成后:主动发结果 / 进度 / 卡点。
  5. 非重复内容:禁止等用户追问才回复。

中文交付口径

后台任务完成后,主会话必须三选一:

  • 有最终结果 → 直接交付结果
  • 有阶段进度 → 主动同步进度
  • 被阻塞 → 主动说明卡点和所需确认

中文反模式

以下都算没按 SOP 执行:

  • 后台做完了但不发
  • 用户不追问就不回
  • 连续发“在处理”但不给结果
  • 把完成事件当内部消息吞掉

适合场景

01

OpenClaw 用户查找和安装 Skill 时

02

用户想查找某类 Agent Skill 时

03

需要根据任务场景推荐可安装能力包时

04

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

补充不同宿主或平台的使用分布数据

能力 5

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

OpenClaw

93.38%
按下载量换算1,018

安全审计

VirusTotal

通过

ClawScan

通过

Static analysis

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills