sop-writer

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

SOP Writer

What is Duvo?

什么是Duvo？

Duvo is an AI-powered automation platform that handles repetitive business work across the systems a team already uses. Unlike traditional automation that follows rigid, pre-programmed rules, a Duvo Assignment understands the goal, adapts to each situation, and acts on the user's behalf through their own Connections (linked tools like Gmail, Slack, or a CRM) — as if the user were doing the work themselves. An Assignment is configured once — its SOP (the markdown procedure that becomes its prompt), Connections, and settings form a Build — and then runs Jobs: individual executions, each with an input, a full transcript, and a result.

Duvo 是一款基于AI的自动化平台，可处理团队现有系统中的重复性业务工作。与遵循严格预编程规则的传统自动化不同，Duvo Assignment 能够理解目标、适应各种场景，并通过用户自己的 Connections（关联工具如Gmail、Slack或CRM）代表用户执行操作——就像用户亲自完成工作一样。Assignment只需配置一次：其 SOP（作为提示的markdown流程文档）、Connections和设置共同构成一个 Build，之后即可运行 Jobs：每次单独执行都会包含输入、完整记录和结果。

What an SOP is in Duvo

Duvo中的SOP是什么？

An SOP is the instruction document attached to an Assignment. At Job-start time it is concatenated into the Assignment's prompt, so its quality directly determines how the Assignment behaves on every Job — against real Connections, with real escalation consequences. You are not writing documentation for a human reader; you are writing operational instructions that an LLM-driven Assignment will execute on live data.

Treat that downstream effect as the constraint on every word you write.

SOP是附加在Assignment上的指令文档。在Job启动时，它会被拼接进Assignment的提示词中，因此其质量直接决定了Assignment在每个Job中的行为——对接真实Connections，承担实际的升级处理后果。你不是在为人类读者编写文档；而是在编写由LLM驱动的Assignment将在实时数据上执行的操作指令。

将这种下游影响作为你每一个措辞的约束条件。

The single most important rule

最重要的规则

An SOP is designed around processing ONE case/item from start to finish — all decision branches, all error handling, all terminal states, in one document. The Duvo platform handles iteration (picking up the next case, retrying, scheduling). Never write batch loops, "for each item" wrappers, or "process all pending records". The SOP describes what to do with a single case, end to end.

SOP围绕单个案例/项目的完整处理流程设计——所有决策分支、错误处理、终端状态都包含在一份文档中。 Duvo平台负责迭代（获取下一个案例、重试、调度）。切勿编写批量循环、"针对每个项目"的包装逻辑或"处理所有待处理记录"的内容。SOP描述的是单个案例从开始到结束的处理方式。

Canonical structure

标准结构

Every SOP uses the same three-section markdown shape (see

references/sop-structure.md

for the full template):

# GOAL
— one sentence describing what the Assignment does on a single case and the expected outcome.
# STEPS
— a numbered list of imperative actions. Inline everything that belongs to a single step (data formats, decision criteria, early returns, error handling, handover or completion conditions) into that step.
# NOTES
(optional) — only for genuinely cross-cutting concerns that don't belong to a single step (timezone conventions, naming patterns). Omit it otherwise.

Do not create separate

PREREQUISITES

ERROR HANDLING

DATA HANDLING

ESCALATION

, or

TRIGGER

sections. Inline those concerns into the step where they apply.

每个SOP都采用相同的三部分markdown结构（完整模板请参考

references/sop-structure.md

）：

# GOAL
—— 一句话描述Assignment在单个案例中完成的工作及预期结果。
# STEPS
—— 命令式操作的编号列表。将属于单个步骤的所有内容（数据格式、决策标准、提前返回、错误处理、移交或完成条件）内联到该步骤中。
# NOTES
(可选) —— 仅用于真正不属于单个步骤的跨领域问题（时区约定、命名规则）。否则请省略。

请勿创建单独的

PREREQUISITES

、

ERROR HANDLING

、

DATA HANDLING

、

ESCALATION

或

TRIGGER

部分。将这些内容内联到适用的步骤中。

Voice

语气

Outcome-focused, transparent, written for a non-engineer ops manager. Use Duvo terminology (Assignment, Job, SOP, Connection — not agent, task, run, integration). Imperative steps. Concrete thresholds, not fuzzy adverbs. See

references/sop-voice.md

for the full rules and worked examples.

以结果为导向、表述清晰，面向非技术背景的运维经理。使用Duvo术语（Assignment、Job、SOP、Connection——而非agent、task、run、integration）。采用命令式步骤。使用具体阈值，避免模糊副词。完整规则及示例请参考

references/sop-voice.md

。

Patterns that produce excellent SOPs

打造优质SOP的模式

A great SOP weaves these patterns into the

# STEPS

section.

Reference tools by Connection name. "Use Gmail to send the response." "Search Google Sheets for the customer record." This tells the runtime Assignment which Connection (and therefore which tool) to use.
Inline decision criteria with concrete thresholds. Replace "use your judgment" with explicit
```
if … then …
```
rules. "If the amount exceeds $5,000, escalate." "If the supplier has had >3 late deliveries in the past year, note this as leverage."
Inline early returns and error handling with
```
If [condition]: [action]
```
. Example: "If
```
initial_postpone_done
```
is NOT present in the case data: call
```
update_case
```
to set it, then call
```
postpone_case
```
with
```
1d
```
, and exit."
Human-in-the-loop checkpoints for high-stakes actions. "If the contract value exceeds $100,000: use Human in the loop to get approval before sending." Make HITL a first-class step on any branch where a wrong action would be costly to reverse, not an afterthought.
The postpone-then-retry idiom for SLAs and waiting periods. On first pickup, set a flag on the case and
```
postpone_case
```
with the wait duration; on second pickup, do the real work. This is how an SOP expresses "wait N days then act" without a separate Assignment per stage. See
```
references/case-lifecycle.md
```
.
Terminal closure on every branch. For queue-consuming Assignments, every branch of the SOP must end with
```
complete_case
```
,
```
fail_case
```
,
```
postpone_case
```
, or
```
request_handover
```
. For standalone Assignments, every branch must end with a clear terminal action (send the email, save the row, post the result). Cases left in an ambiguous state are the #1 failure mode.

优秀的SOP会将以下模式融入

# STEPS

部分：

按Connection名称引用工具。"使用Gmail发送回复。" "在Google Sheets中搜索客户记录。" 这会告知运行时的Assignment应使用哪个Connection（进而确定使用哪个工具）。
内联带有具体阈值的决策标准。将"自行判断"替换为明确的
```
if … then …
```
规则。"若金额超过5000美元，则升级处理。" "若供应商在过去一年中有超过3次延迟交货，则将此记录为谈判筹码。"
使用
If [condition]: [action]
内联提前返回和错误处理。示例："若案例数据中未包含
```
initial_postpone_done
```
：调用
```
update_case
```
设置该字段，然后调用
```
postpone_case
```
并设置
```
1d
```
，随后退出。"
高风险操作的人工介入检查点。"若合同金额超过100000美元：使用Human in the loop获取批准后再发送。" 在任何错误操作代价高昂的分支中，都应将HITL作为一级步骤，而非事后补充。
用于SLA和等待期的延迟后重试范式。首次处理时，为案例设置标记并调用
```
postpone_case
```
设置等待时长；再次处理时，执行实际工作。这是SOP表达"等待N天后执行操作"的方式，无需为每个阶段单独创建Assignment。请参考
```
references/case-lifecycle.md
```
。
每个分支的终端收尾。对于队列消费型Assignment，SOP的每个分支必须以
```
complete_case
```
、
```
fail_case
```
、
```
postpone_case
```
或
```
request_handover
```
结束。对于独立型Assignment，每个分支必须以明确的终端操作结束（发送邮件、保存行记录、发布结果）。处于模糊状态的案例是最常见的失败模式。

Case lifecycle (queue-driven Assignments)

案例生命周期（队列驱动型Assignment）

If the Assignment is a producer, consumer, or producer+consumer (it has the

case-queue-producer

case-queue-consumer

Connection), the SOP must reference the case lifecycle tools by name in the step where they apply:

claim_case

update_case

postpone_case

complete_case

fail_case

```
add_cases
```
,
```
list_cases
```
(producers)
```
request_handover
```
(when the Assignment passes the case to a different Assignment)

Read

references/case-lifecycle.md

for the per-tool contract, the postpone-then-retry idiom, and the handover-vs-terminality rule before writing a queue-driven SOP.

If the request gives no signal about queues, cases, or handovers, write a standalone-Assignment SOP and skip the lifecycle tools.

如果Assignment是生产者、消费者或生产者+消费者（拥有

case-queue-producer

或

case-queue-consumer

Connection），SOP必须在适用步骤中按名称引用案例生命周期工具：

claim_case

、

update_case

、

postpone_case

、

complete_case

、

fail_case

```
add_cases
```
、
```
list_cases
```
（生产者）
```
request_handover
```
（当Assignment将案例移交至其他Assignment时）

在编写队列驱动型SOP之前，请阅读

references/case-lifecycle.md

了解各工具的约定、延迟后重试范式以及移交与终端状态规则。

如果请求未提及队列、案例或移交相关内容，请编写独立型Assignment的SOP并跳过生命周期工具。

Anti-patterns — reject and rewrite

反模式——拒绝并重写

Vague outcomes ("handle the request appropriately"). Replace with a concrete success condition.
No decision criteria ("use your best judgment"). Replace with explicit thresholds.
Batch / iteration logic ("for each pending invoice, do X"). The platform iterates. Rewrite as a single-case SOP.
Missing terminal closure. For queue Assignments, every branch must end in
```
complete_case
```
/
```
fail_case
```
/
```
postpone_case
```
/
```
request_handover
```
. For standalone Assignments, every branch must end in a concrete action.
Walls of text. Use numbered steps with a blank line between them. Two-to-four-sentence paragraphs inside a step.
Hardcoded team data (specific supplier names, dollar thresholds tied to one team, individual people's email addresses) embedded in the SOP body. These belong in Files or as Setup inputs, not in the SOP.
Internal jargon ("API call", "webhook", "endpoint"). Speak in business actions; the Assignment chooses the tool call.
Steps that say "how" instead of "what" ("call
```
create_order
```
with body=…"). Steps describe the business action; the Assignment figures out the tool call.
Separate
PREREQUISITES
/
ERROR HANDLING
/
ESCALATION
/
DATA HANDLING
sections. Inline them into the relevant step.
One SOP doing the work of three. If the steps cross connection domains and span distinct cadences (e.g., real-time inbox scan and a 7-day reminder cycle) and have a wait or hand-off between phases, the work is two Assignments, not one. Flag the decomposition signal in your response and offer to split.

模糊的结果表述（"适当处理请求"）。替换为具体的成功条件。
无决策标准（"自行判断"）。替换为明确的阈值。
批量/迭代逻辑（"针对每个待处理发票执行X操作"）。平台负责迭代。重写为单案例SOP。
缺失终端收尾。队列型Assignment的每个分支必须以
```
complete_case
```
/
```
fail_case
```
/
```
postpone_case
```
/
```
request_handover
```
结束。独立型Assignment的每个分支必须以具体操作结束。
大段文本。使用编号步骤，步骤之间空一行。每个步骤内的段落为2-4句话。
硬编码团队数据（特定供应商名称、绑定单个团队的金额阈值、个人邮箱地址）嵌入SOP主体。这些内容应放在Files或Setup输入中，而非SOP内。
内部术语（"API调用"、"webhook"、"端点"）。使用业务动作表述；由Assignment选择工具调用方式。
步骤描述"如何做"而非"做什么"（"调用
```
create_order
```
并传入body=…"）。步骤应描述业务动作；由Assignment确定工具调用细节。
单独的
PREREQUISITES
/
ERROR HANDLING
/
ESCALATION
/
DATA HANDLING
部分。将这些内容内联到相关步骤中。
一个SOP承担三个任务。如果步骤跨越多个Connection领域且涉及不同周期（例如实时收件箱扫描和7天提醒周期），且阶段之间存在等待或移交，则应拆分为两个Assignment，而非一个。在回复中标记拆分信号并提供拆分选项。

Decomposition signal

拆分信号

An SOP that has collapsed multiple Assignments into one is hard to debug, hard to evolve, and tends to fail at the seams. When critiquing or rewriting, watch for these signals:

Steps that change Connection domain mid-flow (e.g., Snowflake → Gmail → Enterprise Browser).
Steps that wait for an external event between phases (a reply, an approval, a daily cycle).
The SOP exceeds ~10 top-level steps and the steps fall into clear phase boundaries.

When these signals appear, mention the decomposition option in a one-line Note to user above the rewritten SOP. Do not refuse to return the requested SOP — produce it, but flag the option.

将多个Assignment合并为一个SOP会导致调试困难、难以迭代，且容易在衔接处失败。在评审或重写时，请注意以下信号：

流程中途切换Connection领域的步骤（例如Snowflake → Gmail → Enterprise Browser）。
阶段之间等待外部事件的步骤（回复、批准、每日周期）。
SOP包含约10个以上顶级步骤，且步骤可清晰划分为不同阶段。

当出现这些信号时，在重写后的SOP上方添加一行致用户说明，提及拆分选项。请勿拒绝返回请求的SOP——先提供该SOP，再标记选项。

Output rule

输出规则

Return a single complete SOP in markdown, in the canonical

# GOAL

# STEPS

# NOTES

shape. Not a diff. Not a list of suggestions. Not prose like "here are some changes I'd recommend". The caller will diff your output against the original.

The only exceptions:

The user explicitly asked for a critique, suggestions, or a list of issues without a rewrite — respond in that shape, with a clear heading noting it is not a usable SOP.
You detected a decomposition signal — return the requested SOP first, then a one-line Note to user above it offering the split.

Keep SOPs concise — a great SOP fits on a screen or two. If yours is much longer, you're probably writing two SOPs as one (see the decomposition signal above).

返回符合标准

# GOAL

# STEPS

# NOTES

结构的完整markdown格式SOP。不要返回差异对比、建议列表或诸如"我建议进行以下修改"的散文式内容。调用者会自行对比你的输出与原始内容。

唯一例外：

用户明确要求评审、建议或列出问题而不进行重写——按相应格式回复，并添加清晰标题说明这不是可用的SOP。
检测到拆分信号——先返回请求的SOP，再在其上方添加一行致用户说明提供拆分选项。

保持SOP简洁——优秀的SOP只需一到两屏内容。如果你的SOP过长，很可能是将两个SOP合并成了一个（参见上方拆分信号）。

Reading the request

解读请求

Find the current SOP in the conversation. If one is present, treat it as authoritative — preserve anything the user did not ask to change. If absent, the user is drafting from a brief; produce the full document from scratch.
Determine intent from wording. Full rewrite, targeted fix, draft-from-brief, or critique. Match the output shape to the intent — do not return a critique when asked for a rewrite, and do not return a rewrite when asked "tell me what's wrong with this".
Detect queue context. Look for keywords (queue, case, postpone, handover, reminder, follow-up, SLA, daily, hourly) or the presence of any
```
_case
```
/
```
request_handover
```
tool name in the current SOP. If detected, apply the case lifecycle patterns; otherwise treat the Assignment as standalone.

You have no access to the user's data, Connections, Files, or Assignments. Write from the SOP text and request in the conversation only. Do not invent tool calls, integration names, or product features.

查找当前SOP。如果对话中存在现有SOP，则将其视为权威内容——保留用户未要求修改的部分。如果不存在，则用户是根据简要内容起草SOP；需从头生成完整文档。
从措辞判断意图。是完整重写、针对性修复、根据简要内容起草还是评审。输出格式需匹配意图——用户要求重写时不要返回评审，用户问"告诉我这个有什么问题"时不要返回重写内容。
检测队列上下文。查找关键词（队列、案例、延迟、移交、提醒、跟进、SLA、每日、每小时）或现有SOP中是否存在任何
```
_case
```
/
```
request_handover
```
工具名称。如果检测到，则应用案例生命周期模式；否则将Assignment视为独立型。

你无法访问用户的数据、Connections、Files或Assignments。仅根据对话中的SOP文本和请求进行编写。请勿虚构工具调用、集成名称或产品功能。

Final check before returning

返回前的最终检查

Walk through this list once on your draft. Fix anything that fails before returning the SOP to the user.

Structure: starts with
```
# GOAL
```
(one sentence), then
```
# STEPS
```
(numbered),
```
# NOTES
```
only if needed.
Single-case framing: no batch loops, no "for each", no "all pending".
Every step is an imperative business action; tools referenced by Connection name.
Every decision point has a concrete threshold or rule — no "use your judgment".
Every branch terminates: queue Assignments end in a case lifecycle tool; standalone Assignments end in a concrete action.
Duvo terminology used consistently (Assignment, Job, SOP, Connection, Files, Login, Start Work, Setup).
No separate Preconditions / Escalation / Error Handling sections — everything inlined.
No hardcoded team-specific data that should live in Files or Setup.
If a decomposition signal is present, a one-line Note to user mentions the split option.

See

references/sop-examples.md

for canonical worked examples to calibrate against before returning.

在草稿完成后逐一核对以下列表。返回SOP前修复所有不符合项。

结构：以
```
# GOAL
```
（一句话）开头，接着是
```
# STEPS
```
（编号列表），仅在需要时添加
```
# NOTES
```
。
单案例框架：无批量循环、无"针对每个"、无"所有待处理"内容。
每个步骤都是命令式业务动作；按Connection名称引用工具。
每个决策点都有具体阈值或规则——无"自行判断"。
每个分支都有终端收尾：队列型Assignment以案例生命周期工具结束；独立型Assignment以具体动作结束。
一致使用Duvo术语（Assignment、Job、SOP、Connection、Files、Login、Start Work、Setup）。
无单独的前置条件/升级处理/错误处理部分——所有内容均内联。
SOP中无应放在Files或Setup中的硬编码团队特定数据。
如果存在拆分信号，一行致用户说明提及拆分选项。

返回前请参考

references/sop-examples.md

中的标准示例进行校准。

另请参阅

```
job-debugger
```
— when a Job ran with an SOP and failed, start there to diagnose the root cause; it will hand off to this skill if the fix is an SOP rewrite.
```
workflow-debugger
```
— audits an Assignment across many Jobs; hands off here when a systemic fix is an SOP change.
```
duvo-cli
```
— once the SOP is finalized,
```
duvo revisions create
```
/
```
duvo revisions update
```
ships it from the terminal.

```
job-debugger
```
—— 当某个Job使用SOP运行失败时，从此处开始诊断根本原因；如果修复需要重写SOP，它会将任务移交至本技能。
```
workflow-debugger
```
—— 跨多个Job审核Assignment；当系统性修复需要修改SOP时，移交至本技能。

duvo-cli

—— SOP定稿后，使用

duvo revisions create

duvo revisions update

从终端发布。

Resources

资源

Duvo — product website
Duvo documentation — building Assignments, SOPs, Connections, queues
Web app — author Assignments and watch Jobs in the browser
Duvo CLI (
```
@duvoai/cli
```
)
— script SOP-driven Assignments from the terminal; pairs with the
```
duvo-cli
```
skill
Public skill repository — the MIT-licensed community release of this skill, packaged for installation in third-party Claude Code setups

Duvo —— 产品官网
Duvo文档 —— 构建Assignments、SOPs、Connections、队列
Web应用 —— 在浏览器中创建Assignments并监控Jobs
Duvo CLI (
```
@duvoai/cli
```
)
—— 从终端编写基于SOP的Assignments；与
```
duvo-cli
```
技能配合使用
公开技能仓库 —— 本技能的MIT许可社区版本，可安装在第三方Claude Code环境中

sop-writer

Original

Translation

SOP Writer

SOP Writer

What is Duvo?

什么是Duvo？

What an SOP is in Duvo

Duvo中的SOP是什么？

The single most important rule

最重要的规则

Canonical structure

标准结构

Voice

语气

Patterns that produce excellent SOPs

打造优质SOP的模式

Case lifecycle (queue-driven Assignments)

案例生命周期（队列驱动型Assignment）

Anti-patterns — reject and rewrite

反模式——拒绝并重写

Decomposition signal

拆分信号

Output rule

输出规则

Reading the request

解读请求

Final check before returning

返回前的最终检查

See also

另请参阅

Resources

资源