菜单
Use when the user says "board", "kanban board", or "drill board" — explains the local board kanban workflow, board-per-cwd identity, the stage-to-column mapping, labels/checklists/due-dates, and the read-update-consult discipline that mirrors the drill ledger onto a card per task, idea, or major step.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | board |
| description | Use when the user says "board", "kanban board", or "drill board" — explains the local board kanban workflow, board-per-cwd identity, the stage-to-column mapping, labels/checklists/due-dates, and the read-update-consult discipline that mirrors the drill ledger onto a card per task, idea, or major step. |
board is the machine's kanban surface, absorbed into the hub singleton daemon
(a2). Hub exposes all 21 board verbs via MCP under the mcp__plugin_machine_hub__
prefix, backed by one repo-scoped JSON state file under .board/. The data model is
projects -> columns -> cards -> comments, where a card also carries tags, an
assignee, a due date, and named checklists (todo groups). On top sit a label color
registry (label_set/label_list/label_delete) and card_find for querying cards
by label. The driver uses the board as its living work surface and to mirror the live
/.machine/sessions/ ledger: a card per task, idea, or major step in flight, moved
across columns as it changes state.
The board is a projection of the ledger, not a second source of truth. The ledger
under /.machine/sessions/ remains the durable record; the board is the at-a-glance
view. When the two disagree, the ledger wins and the board is re-synced.
Hub serves the board on http://localhost:7777 (WebSocket live view at /ws,
REST API at /api/<verb>). Card operations work through MCP even when the web UI
is not open. All board writes are serialized by the same mkdir-lock used for mesh
state, so concurrent MCP calls and web drag-and-drop cannot corrupt .board/state.json.
Hub ships in-plugin as a Rust binary (hub/target/release/hub). Bootstrap builds it
with cargo build --release --manifest-path hub/Cargo.toml. The SessionStart hook
hub-ensure.sh starts hub serve on :7777 and polls health up to 5 seconds. An
already-running daemon is a no-op. Hub is the single process for both mesh and board
— no separate board daemon.
To remove board support: drop the board verb calls from skills and agents. The hub
binary continues serving mesh verbs. The .board/ state directory (gitignored) can
be deleted to discard board data.
Never hardcode a projectId. A board project id is a server-generated ULID; it is
not derivable from the cwd. Read .machine/board.json at the start of every board
operation — it is the single source of truth for this repo's project id, name, and
board URL.
.machine/board.json schema (per-repo runtime state, resolved on first use; not
committed):
version schema version (1)
cwd absolute working directory this project belongs to
name basename of cwd — the project name
projectId server-generated ULID — required by board_get and every card call
url web board URL (http://localhost:7777)
resolvedAt ISO-8601 timestamp of resolution
A board is one board project bound to this repo's cwd (board-per-cwd:
name = basename(cwd)). Set it up once; every later board call reads its id from
.machine/board.json. Resolve the project whenever .machine/board.json is missing
or stale, before any card work:
project_resolve with name = basename of the repo cwd. It is get-or-create
by name: an existing project with that name is returned, otherwise a new one is
created. The returned project.id is the ULID to persist..machine/board.json with the schema above (version 1, the absolute
cwd, the name, the returned projectId, url http://localhost:7777, and the
current ISO-8601 resolvedAt).column_create, left-to-right
in order, if the project has none yet.Open http://localhost:7777/ in a browser. The page connects via WebSocket and
live-reloads on every card or roster mutation. To start hub manually:
hub serve (default http://localhost:7777).
The drill creates ITS project with six fixed lifecycle columns via column_create,
left-to-right exactly: Gathered | Approved | In Progress | Mergable | To Merge |
Merged. The board IS the pipeline view: the agent gathers a task -> the user
approves it -> a subagent plans, reviews, and implements -> the build goes mergable ->
the user approves the merge -> it merges into master. This table is the single source
of truth for the drill-stage -> column mapping.
| Drill status | board column |
|---|---|
| grilling | Gathered |
| planning, plan-review, plan-ready | Approved |
| implementing | In Progress |
| arbiter, merge-proposed | Mergable |
| (user approved merge; resolve/merge in flight) | To Merge |
| merged | Merged (card KEPT, not deleted) |
| dropped | card removed (card_delete) |
Card title convention: [<status>] <label>. The card body carries the entry id,
the current stage, the git branch, and a one-line summary. On a stage transition,
card_move the card to the target column and card_update to retitle, as one action.
On merged, card_move the card to the Merged column and keep it there — the
Merged column is the completed-pipeline record. Only dropped calls card_delete
(an abandoned feature leaves no card); the /.machine/sessions/ ledger remains the
durable history in both cases.
Read the board before starting work on a feature, update the card the moment a feature changes state, and consult it when deciding what is in flight. Do not batch card updates to the end of a session. Every state change that touches a feature moves its card and refreshes its title in the same action; no silent edits, no card left in the wrong column.
Only the drill (the user-facing driver session) writes cards, exactly as only the
drill writes the /.machine/sessions/ ledger. A dispatched subagent reports stage
transitions through mesh; the drill reconciles those onto the ledger and projects
them onto the board on its own turn. A card the drill did not create this session is
untrusted and is surfaced for human review rather than acted on.
All board verbs are served by hub at http://localhost:7777/mcp under the prefix
mcp__plugin_machine_hub__. Tools are deferred — load via ToolSearch with
select:<name> first.
project_resolve (name) — get-or-create by name; project_list.board_get (projectId) — the project plus its columns left-to-right,
each carrying its cards by sort with a commentCount.column_create (projectId, name), column_update (id; name) — rename,
column_delete (id) — delete cascades to the column's cards and their comments.card_create (columnId, title; body?, tags?, assignee?, due?),
card_update (id; title?, body?, tags?, assignee?, due?) — assignee/due accept
null to clear, tags replaces the whole list; card_move (id, toColumnId;
newIndex?) — 0-based slot in the destination; card_delete (id) — also deletes the
card's comments; card_find (tag; projectId?) — cards carrying a tag/label.label_set (name, color), label_list, label_delete (name) — the color
registry behind tag chips; an unregistered tag falls back to an auto color.checklist_add (cardId; title?), checklist_remove (cardId,
checklistId); items: checkitem_add (cardId, checklistId, text), checkitem_set
(cardId, checklistId, itemId; done?, text?) — toggle/edit, checkitem_remove
(cardId, checklistId, itemId).comment_add (cardId, author, body), comment_list (cardId) —
oldest-first. A comment on a card with an assignee posts a board:comment mesh
message to that agent.Every mutation bumps state.rev and pushes a full state snapshot over the WebSocket
/ws channel so open browser tabs re-render immediately.
File a machine self-diagnostic report as a tagged GitHub issue. When a tool, daemon, hook, skill, or agent hangs, errors, returns garbage, or behaves wrong, open a `machine-report`-labeled issue on the machine plugin repo so every plugin user's reports funnel to the maintainer. Requires `gh` logged in. Write-side only — it logs, it does not fix. Trigger: "/report", "report a problem", "this tool is broken", "file a machine report", "log this hang/error/hiccup".
Consume the machine self-diagnostic backlog. Lists the open `machine-report` GitHub issues on the machine repo, ranks them by severity then age, fixes the single highest-priority one at its root cause, verifies green, then closes that issue. The act side of /report (which only writes). Machine-repo-only skill — not shipped to other installs. Trigger: "/resolve", "resolve a report", "triage the reports", "fix the top report", "work the reports backlog".
Second-AI review via the Codex CLI at the drill's single review point — the consolidated review of the finished diff, alongside the persona panel, before a landing is proposed. Advisory only: it returns notes and concerns for the driver and user to weigh, it never gates, blocks, merges, or edits. Skips cleanly when codex is not installed. Trigger via "/codex-review", "codex review", "second opinion from codex", or invoked by the drill skill.
The drill — the orchestrator's default driver mode. Runs grill-first: the drill and the user refine a request one question at a time until the user calls it a valid plan. From there the job runs autonomously — a plan subagent writes a markdown brief, a miner implements it on a git-fs branch inside the orchestrator's worktree, and the gate iterates until the build is green — with one consolidated advisory review (personas + codex) at the end. The drill surfaces only to land the work into main, plus on any blocker it cannot resolve. The live roster lives in the hub (claims + board), not on disk. Trigger via "/drill", "drill mode", "orchestrator mode", "background this", "spawn an agent for this", "drive this".
Promote crystallized brainstorm findings into board tickets. After a brainstorm (drill grill) settles one or more well-scoped features, this turns each into a card on the current cwd's board so the drill's plan step can iterate per ticket. The bridge between brainstorm and plan — it creates tickets, it does not plan or implement. Trigger: "/promote", "promote these", "promote to tickets", "make tickets", "turn findings into cards".
Run the single ongoing chat that resolves the open plan and implementation questions parallel agents raise. Plan/implement agents post questions to mesh and wait; the questioneer aggregates them into one prioritized queue, presents each to you for a decision, and writes the answer back so the waiting agent proceeds. It routes decisions — it does not plan, implement, or dispatch. Trigger: "/questioneer", "questioneer", "answer the questions", "resolve open questions", "what are the agents blocked on".