/tasks

name: tasks
scope: common
description: Manage Prismer workspace tasks across the full Kanban lifecycle — create, list, inspect, update, complete, approve, reject, cancel. Use whenever the user asks to add a card to the board, dispatch work to another agent, track progress, or move a task between states. Executes via the `cloud task` CLI.

Tasks

Use this skill to drive the **workspace Kanban** end-to-end. Tasks are durable board items with owner, priority, schedule, and conversation linkage. Every operation goes through the `cloud task` CLI — never reply that a task was created/moved/completed unless the command actually returned a task ID and status.

⛔ Hard rules — delegation discipline

When the user asks you to **assign / delegate / hand off** work to ANOTHER agent (e.g. "create kanban tasks and assign to @research-agent", "give this to Bob"):

1. **Call `cloud task create --assignee-name <agent>` (or `--assignee-id`).** That is the ONLY legitimate delegation path. A delegation is a **tracked board card that ALSO auto-dispatches**: the card shows on the Kanban (留痕/可观测) *and* the cloud routes it to the target agent's daemon the moment the assignee is set — the target picks it up via its own dispatch loop, no manual "drag to Running" needed. (A `--no-card` pure run exists for internal orchestrator sub-steps that should NOT surface a card.) 2. **For a delegation-only request, stop after reporting the returned IDs / titles.** If the user also requested orchestration, follow-through, or result collection, continue read-only status/result collection with bounded waits as described below. Never duplicate the assignee's work yourself. 3. **NEVER use a generic `Task` / subagent / fan-out / parallel-agent tool to silently do the work in-process.** That bypasses the kanban board, the assignee never sees the card, the user's mental model ("an agent is working on this") is violated, and the delegation is fake. If you find yourself reaching for any tool whose name is "Task", "Subagent", "Worker", "Fanout", "ParallelAgents", or anything else that spawns an inline executor — **stop and re-read this section**. 4. The phrase **"I've also started working on these"** after a `cloud task create` is a red flag that you violated rule 3. The correct phrase is **"Tasks created and assigned. @research-agent will pick up the cards."**

This is non-negotiable. Bypassing it makes the agent ecosystem look broken even when the cards are correct, because the user sees the answer come back too fast and notices that the supposed assignee was never @-mentioned in the conversation.

↩️ 结果回流 — 委派后怎么拿到结果（HARD）

委派出去之后，**结果不会自动回流**到你的对话或 run —— 没有回调、没有自动推送。被派的 agent 在它**自己的独立 context** 里执行（不进你当前这条会话、也不会在这里发言），产物落在 **task 卡 + 看板**上。所以：

• **要看结果，你必须主动拉**：`cloud task get <taskId>` 读 `status` / `result` / 附件。`status=completed` 才算交付；`review` 等你 approve/reject。
• **编排节奏**：`cloud task create --assignee-name <peer>` → 拿到 taskId → 反复 `cloud task get <taskId>` 直到 `status` 进终态 → 读产物 → 决定下一步。（有 `cloud task wait <id>` 时优先用它，省手搓轮询。）
• **「看不到对方回复 ≠ 它没在干」**。被派 agent 沉默是正常的——它在独立 context 里跑，结果只在卡上。**绝不要**因为对话里没动静就自己把活重做一遍（那就是影子执行，违反上面的 Hard rules）。
• 只要求委派时，报 taskId 后结束本轮；明确要求编排/收集结果时，同轮可继续 `cloud task get`，退避轮询、有超时，不重新执行受派任务。不要自行安排未来轮询或声称已有后台监控。

When to use

• The user asks to **create**, **assign**, **schedule**, or **track** work ("add to kanban", "give Bob this task", "remind me to ship X by Friday").
• You need to **delegate** a concrete deliverable to another agent. **(See ⛔ rules above.)**
• A long-running objective should persist as a workspace **goal** (`kind=goal`).
• The user asks about board state ("what's pending", "show me Bob's tasks", "what's blocking the release").
• A task already on the board needs to be **updated** (priority change, retitle, attach context), **completed**, **approved/rejected** in review, or **cancelled**.
• The task output is a document / deck / spreadsheet / PDF / report. In that

case use the `office-artifacts` skill before completion; a prose-only result is not enough for file-deliverable tasks.

Lifecycle

pending → assigned → running → review → completed | failed | cancelled
              ↑                     ↓
              └──── blocked ────────┤  (unblock returns to assigned)
                                    ↓
                             awaiting_approval
                                    ↓
                        approved / rejected (back to review)

Nine-state lifecycle: `pending / assigned / running / review / blocked / awaiting_approval / completed / failed / cancelled`. `awaiting_approval` cards stay visible on the review column — never treat them as gone. `blocked` has its own column.

A `work_item` shows on the Kanban; a `goal` shows on the Goals lane. Filter at list time with `--kind work_item,goal` if you only want board projection. A **delegation** (`cloud task create --assignee-name …`) is a `work_item` board card that also auto-dispatches (`dispatchPolicy=on-assign`) — it is BOTH visible on the board AND executing. A `work_item` you create for a human (or to drive yourself via the UI) stays `manual`: it only runs on an explicit drag-to-Running. **Only globally-visible formal tasks are board cards** — a chat `@mention` is a session-internal run, NOT a board card, and never produces one.

Permission model (v2.0 — `release 200` state machine)

The platform enforces a **trust-tier × transition matrix** (see `docs/release200/15-task-state-machine-and-kanban.md` §5.2). Each transition's `allowed` actors are part of the contract; calling outside the matrix returns `403 forbidden` with `{ actorTier, requiredTiers }`, and impossible transitions return `409 invalid-transition` with `{ allowedFromHere }`.

| Action | Permitted by | |---|---| | `create`, retitle, change priority, **reassign**, `cancel`, `approve`, `reject` | **creator** / orchestrator / admin | | `claim`, update `--progress` / `--status-message`, `complete` (assignee submits to revi