kanban-tasks
使用 agentao-kanban 看板进行任务管理(拆任务 / 状态流转 / 后台服务 / 看产物)。 本技能负责:① 初始化 .kanban/ 项目 ② 把需求拆成原子卡片入板 ③ 推动状态流转 INBOX → READY → DOING → REVIEW → DONE ④ 启停 daemon 与 Web UI ⑤ 察看卡片状态与产物。 触发关键词(中/英):看板 / kanban / 任务管理 / task board / 拆任务 / 任务卡 / 排期 / WIP / dispatcher / orchestrator。 复合触发短语(一键启停): • "启动 kanban" → daemon(mock 执行器,后台)+ Web UI(自动开浏览器) • "启动 kanban 真跑" → daemon(--executor agentao,真调 sub-agent)+ Web UI • "停止 kanban" → 先停 Web UI,再停 daemon
Best use case
kanban-tasks is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
使用 agentao-kanban 看板进行任务管理(拆任务 / 状态流转 / 后台服务 / 看产物)。 本技能负责:① 初始化 .kanban/ 项目 ② 把需求拆成原子卡片入板 ③ 推动状态流转 INBOX → READY → DOING → REVIEW → DONE ④ 启停 daemon 与 Web UI ⑤ 察看卡片状态与产物。 触发关键词(中/英):看板 / kanban / 任务管理 / task board / 拆任务 / 任务卡 / 排期 / WIP / dispatcher / orchestrator。 复合触发短语(一键启停): • "启动 kanban" → daemon(mock 执行器,后台)+ Web UI(自动开浏览器) • "启动 kanban 真跑" → daemon(--executor agentao,真调 sub-agent)+ Web UI • "停止 kanban" → 先停 Web UI,再停 daemon
Teams using kanban-tasks should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/kanban-tasks/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How kanban-tasks Compares
| Feature / Agent | kanban-tasks | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
使用 agentao-kanban 看板进行任务管理(拆任务 / 状态流转 / 后台服务 / 看产物)。 本技能负责:① 初始化 .kanban/ 项目 ② 把需求拆成原子卡片入板 ③ 推动状态流转 INBOX → READY → DOING → REVIEW → DONE ④ 启停 daemon 与 Web UI ⑤ 察看卡片状态与产物。 触发关键词(中/英):看板 / kanban / 任务管理 / task board / 拆任务 / 任务卡 / 排期 / WIP / dispatcher / orchestrator。 复合触发短语(一键启停): • "启动 kanban" → daemon(mock 执行器,后台)+ Web UI(自动开浏览器) • "启动 kanban 真跑" → daemon(--executor agentao,真调 sub-agent)+ Web UI • "停止 kanban" → 先停 Web UI,再停 daemon
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Kanban 任务管理 · 操作指南
底层是本仓库虚拟环境中以 editable 模式安装的 `agentao-kanban`(console scripts: `kanban`, `kanban-mcp`)。
所有命令必须用 `uv run kanban …`,不要直接 `python -m kanban`,也不要 `pip install`。
## 心智模型(先看这里再动手)
- **状态机**:卡片在 `INBOX → READY → DOING → REVIEW → DONE` 中流转,外加旁路状态 `BLOCKED`。
唯一合法的状态写入者是 orchestrator;CLI 的 `move` 是给人/Claude 用的运营手段。
- **板的位置**:`kanban init` 会在当前目录创建 `.kanban/`(项目根标记)和 `workspace/board/`(卡片
与事件文件)。从该目录或任意子目录运行 `kanban …` 都能自动找回这块板,**不要带 `--board`**。
- **执行器**:默认 `mock`(离线状态机,CI 安全),加 `--executor agentao` 才会真正调用四个角色
sub-agent。除非用户明确要求"真跑",**默认保持 mock**。
- **写锁**:所有写命令尊重 `.daemon.lock`。daemon 跑着的时候不要再用 `--force` 写卡(仅应急)。
- **工作区铁律**:板一旦由 `kanban init` 落到 `workspace/board/`,就不要把卡片相关材料散落到仓库根;
生成的笔记/数据按 `AGENTAO.md §Workspace` 入 `workspace/docs/`、`workspace/data/` 等。
## 前置自检(开工前一次)
```bash
uv run kanban --help >/dev/null # 确认 CLI 可用
uv run kanban doctor # 板 + 环境体检(无板时会提示先 init)
```
如果 `doctor` 报 stale lock / 缺失目录,运行 `uv run kanban doctor --fix`。
## 工作流
### Step 1 — 把用户的需求拆成原子卡片
在动 CLI 之前,**先在对话中用一个简短表格列出你打算建的卡**,让用户确认或调整:
| # | title | goal | priority | depends_on | acceptance(关键 1-3 条) |
|---|---|---|---|---|---|
拆卡原则(按本项目 `AGENTAO.md` 的 Code Review 思路:Survey → Classify → Prescribe → Verify):
1. **原子性**:一张卡 = 一个可独立完成、可独立验证的产出。"重构 X 模块"不是卡,"把 X.foo 拆成两个
纯函数并迁移调用点"才是卡。
2. **依赖显式化**:只有真依赖(B 必须等 A 的产出)才用 `--depends`。同主题不等于依赖。
3. **acceptance 是验收凭据**:每张卡至少 1 条 `acceptance`,写成可被人/CI 直接判定通过/失败的语句
("`uv run pytest tests/foo` 全绿"、"`workspace/reports/x.md` 存在且包含章节 …")。
4. **优先级保守用**:默认 `MEDIUM`。`CRITICAL` 仅留给阻断其他卡或线上故障类。
### Step 2 — 初始化(仅当 `.kanban/` 不存在)
```bash
uv run kanban init # 干净起步:建 .kanban/ + workspace/board/
# 或带示例卡先看效果:
uv run kanban init --demo
```
如果用户说"先看看 kanban 怎么跑",跑:
```bash
uv run kanban init --demo
uv run kanban demo # 把 4 张示例卡推到 DONE
uv run kanban list
```
### Step 3 — 建卡
每张卡用一条命令;`--acceptance` 与 `--depends` 可重复:
```bash
uv run kanban card add \
--title "把 ingest.py 拆成 reader/parser 两个纯函数" \
--goal "降低 ingest.py 圈复杂度并允许独立单测" \
--priority MEDIUM \
--acceptance "uv run pytest tests/ingest 全绿" \
--acceptance "ingest.py 中无对全局状态的读写"
```
记下输出里的 `card_id`。后续 `--depends <card_id>` 即指向它。
补充上下文 / 验收(可选,但建卡时建议立即补全;注意 `--path` 是命名参数,不是位置参数):
```bash
# context(可重复加;--kind 默认 required)
uv run kanban card context add <card_id> --path path/to/ref.py:42-88 \
[--kind required|optional] [--note "..."]
uv run kanban card context list <card_id>
uv run kanban card context rm <card_id> --path path/to/ref.py:42-88
# acceptance(add 追加 / edit 进 $EDITOR / rm 按 1-based 索引 / clear 清空)
uv run kanban card acceptance add <card_id> --item "uv run pytest tests/foo 全绿"
uv run kanban card acceptance edit <card_id>
uv run kanban card acceptance list <card_id>
uv run kanban card acceptance rm <card_id> 2
```
### Step 4 — 入队与跟进
```bash
uv run kanban list # 看全板(按状态分组)
uv run kanban show <card_id> # 看单卡(含 context_refs / acceptance)
uv run kanban move <card_id> ready # 入待办
uv run kanban events <card_id> # 看这张卡的事件流
```
被卡住时显式记录原因,不要直接放着不动(`reason` 是**位置参数**,不是 `--reason`;
`requeue` / `unblock` 的 `--to` 默认 `inbox`):
```bash
uv run kanban block <card_id> "等用户确认 schema"
uv run kanban unblock <card_id> [--to ready] # 默认回 inbox
uv run kanban requeue <card_id> [--to ready] [--note "失败现场已修"]
```
### Step 5 — 推动执行(默认离线安全)
两种节奏,按需选一种:
```bash
# A) 一步一步走,便于讲解:
uv run kanban tick
# B) 一直跑到 idle(全部进 DONE 或全部 BLOCKED 时停):
uv run kanban run
```
需要常驻 dispatcher(多卡并行 / 真 sub-agent)或浏览器看板时,见
**「后台服务(daemon & web UI)」**一节。
**只有用户明确要"真跑"时才加 `--executor agentao`**,例如:
`uv run kanban --executor agentao run`。否则一律保持默认 mock。
### Step 6 — 复盘
执行结束后按 **「察看卡片状态 / 产物」** 一节系统回看:先 `kanban events <id>` 看事件流,
再 `kanban traces <id> --latest` 看 agent 原始响应,必要时启动 Web UI(见
**「后台服务(daemon & web UI)」**)做可视化浏览。
> ⚠️ `kanban traces` 必须带 `<card_id>`(位置参数);没有"列全部 trace"的子命令。
> 要全板复盘,遍历各卡或直接看 `<board>/traces/`。
把可分享的复盘写到 `workspace/reports/`,把临时数据放 `workspace/data/`。
## 后台服务(daemon & web UI)
两个常驻进程,**职责互不重叠**:
| 服务 | 进程职责 | 是否写板 | 默认端口 |
|---|---|---|---|
| `kanban daemon` | 调度 + 执行卡片,按 `.daemon.lock` 串行写板 | 是 | — |
| `kanban web` | 读板渲染浏览器看板 | 否(除非加 `--enable-writes`) | 8000 |
约定(让启停脚本是幂等的):
- PID / 日志统一放在 board 目录下:
- daemon → 由 CLI 自己管理 `<board>/.daemon.lock` 与 `<board>/daemon.log`。
- web → 我们手动管 `<board>/.web.pid` 与 `<board>/web.log`。
- 默认 board 路径 `workspace/board/`;若用户在其他目录 `kanban init`,把下方命令里的
`workspace/board` 替换为实际 `<board>`,或先 `cd` 到 `.kanban/` 所在目录再执行。
### 一键启停("启动 kanban" / "启动 kanban 真跑" / "停止 kanban")
复合触发短语,**优先于**单独启停 daemon / web UI 的子节:
| 用户说 | 动作(按顺序) |
|---|---|
| **"启动 kanban"** | ① `daemon --detach`(默认 mock 执行器) ② Web UI 后台启动 + 探活 + 自动开浏览器 |
| **"启动 kanban 真跑"** | ① `--executor agentao daemon --detach`(**真调** sub-agent) ② Web UI 同上 |
| **"停止 kanban"** | ① 停 Web UI(避免它再轮询已经撤掉的板) ② `daemon stop` |
启停脚本(`BOARD/PORT/URL` 共用,三段是同一组变量):
```bash
BOARD=workspace/board
PORT=8000
URL="http://127.0.0.1:${PORT}/"
```
**▶ 启动 kanban(mock 执行器)**
```bash
# 1) Daemon — 后台 fork
uv run kanban daemon --detach
# 2) Web UI — 后台启动,幂等,端口就绪后自动开浏览器
if [ -f "$BOARD/.web.pid" ] && kill -0 "$(cat "$BOARD/.web.pid")" 2>/dev/null; then
echo "web already running (pid $(cat "$BOARD/.web.pid"))"
else
nohup uv run kanban web --host 127.0.0.1 --port "$PORT" \
> "$BOARD/web.log" 2>&1 &
echo $! > "$BOARD/.web.pid"
fi
for _ in $(seq 1 30); do
curl -fsS "$URL" >/dev/null 2>&1 && break
sleep 0.5
done
open "$URL" # macOS;Linux 用 xdg-open;WSL 用 wslview
# 3) 验证
uv run kanban daemon status
uv run kanban list
```
**▶ 启动 kanban 真跑**(与上完全一致,**只把第 1) 步换掉**;要先和用户确认)
```bash
# 1) Daemon — 真调四个角色 sub-agent
uv run kanban --executor agentao daemon --detach
# 2)、3) 同 "启动 kanban"
```
> 触发"真跑"前的检查清单:
> - 用户**已明确**要真跑(不要从"启动 kanban"擅自升级到 `--executor agentao`);
> - 板里有 `READY`/`INBOX` 的卡,且 acceptance / context 写齐;
> - 知晓真跑会消耗 LLM 配额、会真改 worktree 内文件。
**▶ 停止 kanban**
```bash
# 1) 先停 Web UI(幂等)
if [ -f "$BOARD/.web.pid" ]; then
PID=$(cat "$BOARD/.web.pid")
kill "$PID" 2>/dev/null && \
for _ in $(seq 1 10); do kill -0 "$PID" 2>/dev/null || break; sleep 0.2; done
kill -0 "$PID" 2>/dev/null && kill -9 "$PID" 2>/dev/null
rm -f "$BOARD/.web.pid"
echo "web: stopped"
else
echo "web: not running"
fi
# 2) 再停 daemon
uv run kanban daemon stop || echo "daemon: not running"
```
> 注意:执行器(mock vs `agentao`)由**启动 daemon 时**决定,重启 daemon 才能切换。
> 想从 mock 切到真跑,必须 "停止 kanban" → "启动 kanban 真跑"。
### Daemon · 启 / 停 / 体检
```bash
# 后台启动(fork 出去;CLI 自带 --detach)
uv run kanban daemon --detach
# 状态:running / stale / stopped
uv run kanban daemon status
# 跟踪日志
uv run kanban daemon logs -f
# 优雅停止(SIGTERM 给 .daemon.lock 里记录的 pid)
uv run kanban daemon stop
# 极少数情况下 daemon 已死但 lock 残留:
uv run kanban doctor --fix
```
并发 / 多 worker / 真 sub-agent 等高级用法(按需加,**默认不加**):
```bash
# 多 worker(一个 scheduler + 多个 worker)
uv run kanban daemon --detach --role scheduler --max-claims 4
uv run kanban daemon --detach --role worker --worker-id w1
uv run kanban daemon --detach --role worker --worker-id w2
# 真跑(调用四个角色 sub-agent,需用户明确同意)
uv run kanban --executor agentao daemon --detach
```
### Web UI · 启 / 停(启动后自动打开浏览器)
`kanban web` 自身没有 `--detach`,所以由我们用 `nohup` 后台化并自管 PID。
启动后用 `curl` 探活,端口起来后再 `open` 浏览器,保证用户落地不是空白页。
**启动(推荐:默认只读、loopback、自动开浏览器):**
```bash
BOARD=workspace/board
PORT=8000
URL="http://127.0.0.1:${PORT}/"
# 已经在跑就直接开浏览器,避免端口冲突
if [ -f "$BOARD/.web.pid" ] && kill -0 "$(cat "$BOARD/.web.pid")" 2>/dev/null; then
echo "web already running (pid $(cat "$BOARD/.web.pid"))"
else
nohup uv run kanban web --host 127.0.0.1 --port "$PORT" \
> "$BOARD/web.log" 2>&1 &
echo $! > "$BOARD/.web.pid"
fi
# 等端口就绪(最多 ~15s),就绪后开浏览器
for _ in $(seq 1 30); do
curl -fsS "$URL" >/dev/null 2>&1 && break
sleep 0.5
done
open "$URL" # macOS;Linux 用 xdg-open;WSL 用 wslview
```
**状态:**
```bash
BOARD=workspace/board
if [ -f "$BOARD/.web.pid" ] && kill -0 "$(cat "$BOARD/.web.pid")" 2>/dev/null; then
echo "web: running pid=$(cat "$BOARD/.web.pid") log=$BOARD/web.log"
else
echo "web: not running"
[ -f "$BOARD/.web.pid" ] && rm "$BOARD/.web.pid" # 清掉残留 pid
fi
```
**停止(幂等):**
```bash
BOARD=workspace/board
if [ -f "$BOARD/.web.pid" ]; then
PID=$(cat "$BOARD/.web.pid")
kill "$PID" 2>/dev/null && \
for _ in $(seq 1 10); do kill -0 "$PID" 2>/dev/null || break; sleep 0.2; done
kill -0 "$PID" 2>/dev/null && kill -9 "$PID" 2>/dev/null # 兜底强杀
rm -f "$BOARD/.web.pid"
echo "web: stopped"
else
echo "web: not running"
fi
```
**写入模式(仅在用户明确要"用浏览器建卡"时再开):**
```bash
# 只在 loopback 上开放 POST /api/cards
nohup uv run kanban web --host 127.0.0.1 --port 8000 --enable-writes \
> workspace/board/web.log 2>&1 &
echo $! > workspace/board/.web.pid
```
绑非 loopback(远端访问)时还要加 `--allow-remote-writes`,且**必须**和用户确认后再做——
那等于把板的写入面暴露到网络上。
### 常见坑(后台服务专属)
- **端口被占**:`lsof -nP -iTCP:8000 -sTCP:LISTEN`。换端口(`--port 8765`)或杀掉占用进程。
- **`web` 起来但浏览器空白**:通常是探活早于路由就绪。把 `seq 1 30` 调到 `seq 1 60`,或先
`tail workspace/board/web.log` 看启动日志。
- **`.web.pid` 指向已死进程**:`status` 块里的 `kill -0` 检查会发现并清理;如果你跳过了脚本,
手动 `rm workspace/board/.web.pid`。
- **daemon 写不动板**:先 `kanban daemon status`;若 `stale` 用 `kanban doctor --fix`;如果只是
本地误锁,`kanban --force …` 仅作应急。
- **同时跑 daemon + web**:完全 OK,两者职责不冲突;web 默认只读,daemon 才写。
## 察看卡片状态 / 产物
把"卡现在什么状态"和"卡到底产出了什么"分开看。两类问题对应不同的入口。
### A. 状态视图
| 想看什么 | 命令 | 备注 |
|---|---|---|
| 全板按状态分组 | `uv run kanban list` | 无 `--json` |
| 单卡详情(goal / priority / depends / context_refs / acceptance / status) | `uv run kanban show <id>` | 加 `--json` 喂下游 |
| 结构化事件流(含状态迁移、claim、artifact 快照) | `uv run kanban events <id>` | `--role planner\|worker\|reviewer\|verifier` 过滤;`--limit N`;`--json` |
| 活跃执行 claim(v0.1.2 并发) | `uv run kanban claims [<id>]` | `--json` |
| 在线 worker(多 worker 模式) | `uv run kanban workers` | — |
| 看 acceptance / context 是否齐全 | `uv run kanban card acceptance list <id>` / `card context list <id>` | — |
最常用的三连:
```bash
uv run kanban show <id> # 这张卡是什么、配置齐了吗
uv run kanban events <id> --limit 20 # 最近发生了什么
uv run kanban claims <id> # 现在谁在跑(如有)
```
### B. 产物视图("这张卡到底产出了什么")
产物分布在 **4 个位置**,按卡的当前状态决定先去哪里看:
| 卡的状态 | 产物在哪 | 怎么看 |
|---|---|---|
| **DOING**(worktree 在线) | `workspace/worktrees/<card-id>/`(分支 `kanban/<card-id>`) | `uv run kanban worktree list`<br>`uv run kanban worktree diff <id>` |
| **DONE / BLOCKED**(worktree 已 detach) | `workspace/raw/<card-id>/artifacts-<ts>/` | `ls -dt workspace/raw/<id>/artifacts-*/ \| head -1` |
| 任意状态:agent 原始响应 | `<board>/traces/...` | `uv run kanban traces <id> [--latest] [--role …]` |
| 任意状态:结构化事件 | `<board>/events.log` | `uv run kanban events <id>` |
工作流要点(来自 `kanban-cli-guide.md §9.4`):
- 产物**先**落到 live worktree;卡进入 `DONE` / `BLOCKED` 时 `WorktreeManager.detach()` 会把
`gitignored` 路径下的产出抢救到 `workspace/raw/<card-id>/artifacts-<ts>/`,并写一条
`worktree.artifacts_saved` 事件(含快照路径),`events`/Web UI 都能看到。
- 默认每卡保留最近 **5 份快照、上限 500 MiB**;环境变量 `KANBAN_ARTIFACTS_MAX_BYTES` 可调。
- 如果 worker 自报"已写文件"但卡完成后找不到,**第一站**永远是 `workspace/raw/<id>/artifacts-*/`。
### C. 三个最常被问的问题(一行流)
```bash
# "这张卡现在做到哪了?"
uv run kanban show <id> && uv run kanban events <id> --limit 20
# "worker 改了哪些文件?"
# DOING:
uv run kanban worktree diff <id>
# DONE/BLOCKED(找最新一份 artifact 快照并展开看):
SNAP=$(ls -dt workspace/raw/<id>/artifacts-*/ 2>/dev/null | head -1) && \
echo "$SNAP" && find "$SNAP" -maxdepth 3 -type f | head -50
# "agent 的原始输出是什么?"
uv run kanban traces <id> --latest
uv run kanban traces <id> --role worker # 只看 worker 角色的全部 transcript
```
### D. 盘点 / 脚本化(多卡批量查看)
```bash
# 当前所有活跃 worktree(隐含:哪些卡在 DOING)
uv run kanban worktree list
# 某卡最近一份 artifact 快照路径
ls -dt workspace/raw/<id>/artifacts-*/ 2>/dev/null | head -1
# JSON 输出(喂下游脚本 / 喂 LLM 总结)
uv run kanban show <id> --json
uv run kanban events <id> --json --limit 100
uv run kanban claims --json
# 全板事件复盘(最近 N 条;不带 card_id 即全板)
uv run kanban events --limit 200
```
> 注意:`kanban list` 目前**没有** `--json`;要程序化全板视图,遍历 `show --json` 或解析 `workspace/board/`
> 下的 Markdown frontmatter。
## 常见坑
- **"empty board"**:通常是 `.kanban/` 不存在且当前目录没有 `workspace/board/`。先 `kanban init`。
- **写命令报锁**:daemon 在跑。要么停 daemon (`daemon stop`),要么真的应急再加 `--force`。
- **状态卡死在 BLOCKED**:用 `kanban events <id>` 找到原因,修后 `kanban unblock` 或 `requeue`。
- **多个卡片同主题**:考虑合并而非加 `--depends`;依赖只表达"必须先完成",不表达"相关"。
- **改了 acceptance 之后**:用 `kanban card acceptance edit`,不要手改 `workspace/board/` 里的
Markdown frontmatter(除非你确定 daemon 停了且板状态干净)。
## 与本仓库其他约定的关系
- **引用规范**:在向用户报告进度或写复盘时,遵循 `AGENTAO.md §Evidence Conventions`——每条事实
要带 `path:line` 或 `[tool: kanban events <id>]` 这类 marker;推断结论标 `(unverified)` /
`(inferred from X)`。
- **分类标签**:复盘里给问题打 `[CRITICAL]` / `[WARNING]` / `[SUGGESTION]` / `[NITPICK]`。
- **隐私**:板上的卡片内容默认按机密处理,不要把 `workspace/board/` 里的原文发到外部。
## 最小骨架命令清单(贴心备忘)
板与卡:
```bash
uv run kanban init # 起板
uv run kanban card add --title T --goal G \
--acceptance "..." [--depends ID] [--priority HIGH]
uv run kanban list
uv run kanban show <id>
uv run kanban move <id> ready
uv run kanban tick # 单步推
uv run kanban run # 跑到 idle
uv run kanban block <id> "reason" # reason 是位置参数
uv run kanban unblock <id> [--to ready] # 默认回 inbox
uv run kanban events <id>
uv run kanban doctor [--fix]
```
后台服务(**复合触发优先;详见「一键启停」**):
```bash
# 用户说 "启动 kanban" → daemon (mock) + Web UI(自动开浏览器)
# 用户说 "启动 kanban 真跑" → daemon (--executor agentao) + Web UI
# 用户说 "停止 kanban" → 先停 Web UI,再停 daemon
# 单独操作 Daemon
uv run kanban daemon --detach # 启(mock)
uv run kanban --executor agentao daemon --detach # 启(真跑)
uv run kanban daemon status # 看
uv run kanban daemon logs -f # 跟踪
uv run kanban daemon stop # 停
# 单独操作 Web UI(详细启停见「Web UI · 启 / 停」一节)
nohup uv run kanban web --host 127.0.0.1 --port 8000 \
> workspace/board/web.log 2>&1 & \
echo $! > workspace/board/.web.pid && \
for _ in $(seq 1 30); do curl -fsS http://127.0.0.1:8000/ >/dev/null 2>&1 && break; sleep 0.5; done && \
open http://127.0.0.1:8000/ # 启 + 自动开浏览器
kill "$(cat workspace/board/.web.pid)" && rm workspace/board/.web.pid # 停
```
察看状态 / 产物:
```bash
# 状态
uv run kanban show <id> [--json] # 单卡详情
uv run kanban events <id> [--limit N] [--role R] [--json]
uv run kanban claims [<id>] [--json] # 谁在跑
uv run kanban workers # 多 worker 模式
# 产物
uv run kanban worktree list # DOING 时的活跃 worktree
uv run kanban worktree diff <id> # DOING 时 worker 的改动
ls -dt workspace/raw/<id>/artifacts-*/ | head -1 # DONE/BLOCKED 后的快照
uv run kanban traces <id> --latest [--role R] # agent 原始 transcript
```Related Skills
skill-creator
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, update or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
support-triage
Use for every inbound support ticket. Defines triage policy, tone, and escalation rules.
zootopia-ppt
将用户的演示讲稿转化为拟人化动物世界主题的演示文稿图像(顶级3D动画电影风格)。 分三步:① 理解演讲内容与受众 ② 生成每页的3D动画电影风格生图提示词(Markdown 格式,保存到 workspace/docs/outline/) ③ 调用 image_gen_ppt.py 批量生成图像(保存到 workspace/docs/slides/)。 触发条件:用户提供演示稿/PPT 内容,要求制作 疯狂动物城风格 / 拟人化动物 / 3D动画电影风格的图像或演示文稿。
pro-ppt
将用户的演示讲稿转化为「专业 · 高级感」风格的演示文稿图像(高端商务编辑风)。 视觉特征:极浅灰主色(#F2F2F2)、金属灰辅色、金色点缀、深蓝灰背景(#0F233B),整体克制、克莱因蓝调、印刷品级质感。 分三步:① 理解演讲内容与受众 ② 生成每页高级商务视觉提示词(Markdown 格式,保存到 workspace/docs/outline/) ③ 调用 image_gen_ppt.py 批量生成图像(保存到 workspace/docs/slides/)。 触发条件:用户提供演讲稿/PPT 内容,要求制作 专业 / 高级感 / 高端商务 / 企业级 / 资本市场 / 咨询风 / 编辑风 的演示文稿。
ocr
OCR image files using the Qwen VL model via the bundled scripts/ocr.py (lives in this skill's directory, NOT your cwd). Use when the user asks to extract text from an image, perform OCR on a photo or screenshot, or recognize characters in an image file (.jpg, .jpeg, .png, .gif, .webp). Requires QWEN_API_KEY and QWEN_BASE_URL (env vars, or a .env in the skill directory).
matplotlib-charts
Produce PNG charts with matplotlib. Save to chart-<slug>.png in the working directory.
duckdb-analyst
Use for any analytical question over ./data/*.parquet. Prefer DuckDB, always show the SQL.
daily-digest
Build a daily digest from curated sources. Follow the output contract strictly.
nx-run-tasks
Helps with running tasks in an Nx workspace. USE WHEN the user wants to execute build, test, lint, serve, or run any other tasks defined in the workspace.
generate-tasks
Convert PRD to structured task list with automatic linking
detecting-malicious-scheduled-tasks-with-sysmon
使用 Sysmon 事件 ID 1(schtasks.exe 进程创建)、11(任务 XML 文件创建)以及 Windows 安全事件 4698/4702 检测恶意计划任务的创建和修改。分析人员将任务创建与可疑父进程、公共目录路径和编码命令参数相关联, 以识别通过计划任务进行的持久化和横向移动。适用于计划任务检测、Sysmon 持久化狩猎或 T1053.005 计划任务/作业分析。
sdd-tasks
**Slash command**: `/sdd-tasks <slug>`