Menu

Individual skill

tasks

0upvotes

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.

sdk/cloud/catalog/skills/tasks/SKILL.md

Read pinned source

Source commit f83b859a173802a73d978197e92328ab2bf57a6e

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
Yes
Repository scan complete
No
Skill scan complete
No
Observed behavior
Network or broad shell
Last checked
Nov 9, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
1,364
Repository last updated
Oct 22, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt

# 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.