manual-tasks

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/manual-tasks

/manual-tasks

The agent-side half of "things I need to do by hand." Skills file into it; this skill works it down.
这是“需手动完成事项”的Agent端实现。其他技能负责提交任务,而本技能负责逐步处理这些任务。

The boundary that makes this work

实现此功能的边界设定

Before this existed, an agent had exactly one channel for human work:
needs input:
, which halts the ticket. So an agent that discovered "this needs a Vercel env var before it works in prod" had to either block otherwise-shippable code, or bury it in a run report nobody re-reads. It was always the second, and that's what got lost.
  • needs input:
    — blocking, needs an answer now, halts one ticket. Unchanged.
  • A manual task — deferrable, needs an action in an external system, does not block the merge.
If you're about to
needs input:
something the human could do later without stalling you, file a manual task and keep going instead.
在此功能出现之前,Agent只有一种请求人工协助的渠道:
needs input:
,这会暂停工单处理。因此,如果Agent发现“在生产环境运行前需要配置Vercel env var”,它要么阻塞原本可交付的代码,要么将该需求埋在无人重读的运行报告中。通常会选择后者,而这就导致需求丢失。
  • needs input:
    —— 阻塞式,需要立即得到答复,会暂停单个工单。此机制保持不变。
  • 手动任务 —— 可延迟处理,需要在外部系统执行操作,不会阻塞合并流程
如果你打算使用
needs input:
请求人工协助,但该事项可延后处理且不会阻碍当前流程,那么请提交手动任务并继续当前工作。

Conventions

约定

yaml
manual_tasks:
  team: thesignup                      # defaults to linear.team
  project: "Manual tasks (evergreen)"  # created on first use if absent
  label: manual
The project is evergreen: never marked Completed, no
.handoffs/
bundle, never an execution target.
/project-start
and
/project-retro
skip it.
If the project doesn't exist for a team, create it (state
started
, label every ticket
manual
) rather than pausing.
yaml
manual_tasks:
  team: thesignup                      # 默认值为linear.team
  project: "Manual tasks (evergreen)"  # 首次使用时若不存在则自动创建
  label: manual
该项目是常青项目:永远不会标记为已完成,没有
.handoffs/
包,永远不会成为执行目标。
/project-start
/project-retro
会跳过此项目。
如果团队对应的项目不存在,请创建它(状态设为
started
,所有工单都标记
manual
标签),而非暂停流程。

Filing a task

提交任务

Other skills call this path. File anything a human must do outside the repo — env vars, DNS, dashboard config, OAuth consent screens, key rotation, third-party signups, feature-flag flips, a decision only the user can make. Err toward filing: an over-full list is cheaper to prune than a missing item is to rediscover.
Do not file: anything you could just do yourself, and anything already covered by an open task (search the project first — duplicates are the fastest way to make the list unreadable).
mcp__claude_ai_Linear__save_issue
with the configured team, project, and
labels: ["manual"]
. Body must answer four things:
markdown
**Why** — <what needs this, linking the ticket/PR that surfaced it>

**Do this**
1. <literal steps or commands, not a description of them>

**Verify**<how to tell it's actually done>

**Until then**<what stays broken or inert>

*Filed by <SKILL> during <TICKET-ID>.*
The Verify line is the one that matters. Without it you build a list you can't close, because in three weeks you won't remember whether you already did it — and neither will the agent. "Do this" written as a description ("set the API key") rather than a command (
vercel env add RESEND_API_KEY production
) has the same failure: you have to re-derive the task before you can do it.
Set priority Urgent only when shipped code is inert or broken until this happens. Otherwise leave priority unset. This is the sole tier — don't invent more.
After filing, mention it in your run output (one line, with the id). Filing silently defeats the point.
其他技能会调用此路径。所有需人工在仓库外完成的事项都可提交——env vars配置、DNS设置、仪表板配置、OAuth授权界面、密钥轮换、第三方注册、功能开关切换、仅用户可做出的决策等。尽量提交任务:待办列表过满总比遗漏事项后重新找回成本更低。
请勿提交:你可自行完成的任何事项,以及已有未完成任务覆盖的事项(提交前先搜索项目——重复任务会最快让列表变得难以阅读)。
调用
mcp__claude_ai_Linear__save_issue
接口,传入配置的团队、项目及
labels: ["manual"]
。任务内容必须包含以下四个部分:
markdown
**原因** —— <说明需求来源,关联触发该需求的工单/PR>

**执行步骤**
1. <具体步骤或命令,而非描述性文字>

**验证方式** —— <如何确认任务已完成>

**未完成影响** —— <任务未完成时,哪些功能会失效或无法启用>

*由<SKILL>在<TICKET-ID>处理过程中提交。*
验证方式是关键。没有验证方式的话,你会得到一个无法关闭的任务列表,因为三周后你既记不清是否已完成,Agent也无法确认。如果“执行步骤”写成描述性文字(如“设置API密钥”)而非具体命令(
vercel env add RESEND_API_KEY production
),也会导致同样的问题:你必须重新推导任务内容才能执行。
仅当已交付代码因该任务未完成而失效或损坏时,才将优先级设为Urgent。否则保持优先级为空。这是唯一的优先级层级——请勿新增其他层级。
提交任务后,需在运行输出中提及(一行内容,包含任务ID)。静默提交会失去该功能的意义。

Reviewing — the
/manual-tasks
run

审核——
/manual-tasks
运行流程

1. Load

1. 加载任务

mcp__claude_ai_Linear__list_issues
on the configured project with
state
filtered to non-done. Also query
label: manual
across the team and report anything with the label but not the project (or vice versa) — that's a filing bug worth seeing.
Order: Urgent first, then oldest-created. Age is the signal that matters; a task nobody has done in six weeks is either not real or genuinely stuck, and both are worth surfacing.
调用
mcp__claude_ai_Linear__list_issues
接口,筛选配置项目中未完成状态的任务。同时查询团队内所有带有
manual
标签的任务,报告那些标签与项目不匹配的任务(即有标签但不在项目中,或在项目中但无标签)——这属于提交错误,需要关注。
排序规则:先Urgent优先级,再按创建时间从早到晚。任务时长是重要信号:六周未处理的任务要么并非真实需求,要么确实陷入停滞,这两种情况都需要重点关注。

2. Pre-verify before asking for anything

2. 请求协助前预先验证

For every open task, run its Verify step first — read-only, no confirmation needed. Some are already done and never got closed; closing those costs you nothing and shortens the list before the user looks at it.
Close anything that verifies as already-done, with a comment saying what you checked.
对于每个未完成任务,先执行其验证方式步骤——仅读取数据,无需确认。有些任务可能已完成但未关闭;关闭这些任务无需成本,还能在用户查看列表前缩短列表长度。
对于验证通过的任务,将其关闭并添加备注说明检查内容。

3. Walk the remainder, one at a time

3. 逐一处理剩余任务

For each task, do the parts you have access to, then hand back what's left.
Act without asking when the action is additive and reversible — adding an env var, creating a resource, reading config, running a check, updating Linear. Report what you did.
Confirm first when it is destructive, irreversible, spends money, or is visible to real users — rotating or deleting a credential, changing billing or plan, touching DNS on a live domain, flipping a flag that changes production behavior, anything against real user data. State the exact command and wait. Approval on one task does not carry to the next.
Hand back what needs the user's own hands or credentials — a dashboard with no API, an account only they can create, a decision only they can make. Print the literal steps and move on; don't stall the walk waiting on it.
After each, re-run Verify and close on success. If Verify fails after you acted, say so plainly and leave it open — a task closed on an unverified action is worse than one left open, because it stops being visible.
对于每个任务,完成你有权限执行的部分,然后将剩余部分移交人工。
无需询问即可执行的操作:可添加且可撤销的操作——添加env vars、创建资源、读取配置、运行检查、更新Linear。执行后需报告操作内容。
需先确认再执行的操作:破坏性、不可撤销、产生费用或对真实用户可见的操作——轮换或删除凭证、更改账单或套餐、修改实时域名的DNS、切换影响生产环境行为的功能开关、任何涉及真实用户数据的操作。需说明具体命令并等待确认。单个任务的批准不适用于其他任务。
移交人工处理的内容:需要用户亲自操作或使用其凭证的事项——无API的仪表板、仅用户可创建的账户、仅用户可做出的决策。打印具体步骤后继续处理下一个任务;不要因等待该任务而停滞整个流程。
每个任务处理完成后,重新执行验证步骤,验证通过则关闭任务。如果执行操作后验证失败,需明确说明并保持任务为未完成状态——未经验证就关闭任务比保留未完成更糟糕,因为它会不再被关注。

4. Report

4. 生成报告

result: manual tasks — N closed (M auto-verified), K need you, P deferred
Then the "need you" items as a short list with their steps, so the user has everything in one place without opening Linear.
结果:手动任务 —— 已关闭N个(其中M个为自动验证通过),K个需你处理,P个已延迟
然后列出“需你处理”的任务及其步骤,让用户无需打开Linear即可在一处查看所有相关内容。

/manual-tasks add <description>

/manual-tasks add <description>

File one by hand from the current conversation. Fill the four fields from context; ask only for what you genuinely can't infer. Useful when the user notices something mid-conversation and doesn't want to lose it.
从当前对话中手动提交一个任务。根据上下文填充四个字段;仅询问你确实无法推断的信息。当用户在对话过程中注意到某事项并不想遗忘时,此功能非常有用。

What this skill does NOT do

本技能不具备的功能

  • Does not write code or open PRs. If the fix is code, it's a normal ticket — use
    /start
    .
  • Does not mark the evergreen project Completed. Ever.
  • Does not close a task on a report alone — only on a passing Verify, or an explicit "done, trust me" from the user.
  • Does not re-file a task that's already open. Search first.
  • 不编写代码或创建PR。如果修复需要代码,应创建常规工单——使用
    /start
  • 不会将常青项目标记为已完成。永远不会。
  • 不会仅根据报告关闭任务——仅在验证通过或用户明确说明“已完成,相信我”时才关闭。
  • 不会重复提交已存在的未完成任务。提交前先搜索。