菜单
File-based issue tracker conventions — how specs, tickets, and small tasks live in agent/tasks/ and how to publish, fetch, claim, and retire them. Use when publishing or fetching a spec/ticket/task, picking work from the frontier, or when another skill says "publish to the issue tracker".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Work a feature's ticket DAG in parallel — one orchestrator fans independent frontier tickets out to parallel worker agents and integrates them on the feature branch until the feature ships. Use when a ticketed feature has independent frontier tickets, the user says "dispatch" or wants tickets worked in parallel, or when another skill routes parallel frontier work here.
Which mx skill or flow fits the current situation — a router over the mx workflow.
Run commands in tmux whenever they run long or need eyes on them — anything expected to take more than ~30–60s (training runs, ML experiments, builds, servers), anything worth observing mid-run (progress logs, monitoring output), and anything interactive (sudo prompts, REPLs, wizards), locally or on a remote host. Always reach for this instead of a fire-and-forget Bash call in those cases — the human can attach and step in at any time.
Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published per the tracker conventions — ticket files with blocked-by edges, or native blocking links on a real tracker.
Review and update Claude Code's auto-approved command allowlist based on Bash commands that triggered permission prompts in recent sessions.
Turn the current conversation into a spec and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.
| name | tracker |
| description | File-based issue tracker conventions — how specs, tickets, and small tasks live in agent/tasks/ and how to publish, fetch, claim, and retire them. Use when publishing or fetching a spec/ticket/task, picking work from the frontier, or when another skill says "publish to the issue tracker". |
Issues for this repo live as markdown files in agent/tasks/. These conventions are the default — if the project's CLAUDE.md declares a different tracker (e.g. GitHub Issues), follow that instead.
agent/tasks/<feature-slug>/
spec.md — the work order for the whole feature (written by /mx:to-spec)NN-<slug>.md — tickets, numbered from 01 (written by /mx:to-tickets)agent/tasks/<slug>.md — ticket-shaped, no spec neededFrontmatter:
status: open | claimed | done
blocked-by: [01, 02] # ticket numbers within the feature; omit when nothing blocks it
blocked-by is done.claimed marks a ticket a session is actively working. Set it before any work. When agents run in parallel, a single orchestrating agent oversees them and is the sole claim-writer — no cross-checkout coordination needed. (With a single agent in a single checkout, claiming is optional.)## Comments heading at the bottom of the file.spec.md — tickets don't repeat the feature context, the spec carries it.Set status: done when a ticket completes. When the whole feature has shipped, git rm -r agent/tasks/<feature-slug>/ — git history preserves it (git log --diff-filter=D -- agent/tasks finds retired work). If the repo doesn't track agent/tasks/, plain delete.