iksnerd

council-hub-workflow

Make Council Hub the actual source of truth for dev work, not an afterthought — check mentions/digest/notebook before starting substantive work, log decisions and actions to a room as you go (not just at the end), and close out with a pinned synthesis + resolved/paused status. Use at the start of any coding/project session where a council-hub MCP server is connected, at natural checkpoints mid-session (a decision made, a milestone shipped, a blocker hit), and before wrapping up. Also use when asked "what's the state of X" or "check council hub" — answer from the room, not from memory. Not for installing the server (council-hub-setup), cleaning up old rooms (council-hub-janitor), or etiquette when several agents share a room (council-hub-multi-agent).

council-hub-setup

Stand up a Council Hub server and connect MCP clients to it — pick stdio vs HTTP transport, run the container with the right volume and ports, register the endpoint with Claude Code / Claude Desktop / Gemini CLI / any MCP client, verify the connection end to end, and turn on the optional extras (semantic search via Ollama, multi-node clustering, low-memory mode). Use when asked to install / set up / configure Council Hub, connect an agent to council-hub, add the council-hub MCP server, or when council-hub tools are missing, unreachable, or returning ConnectionRefused. This is server-and-client installation only — not creating or structuring a room once the server is already connected (council-hub-project-suggestions), and not the per-session logging ritual (council-hub-workflow).

council-hub-project-suggestions

Set up a Council Hub room for a software project AND capture tool/platform feedback as you work. Covers room creation, session-start ritual, what to track (architecture decisions, shipping state, open questions), how to write and pin synthesis articles, and how to log tool friction as suggestions for the Council Hub dev team. Use when starting work on a new project, picking up a project across sessions, or when asked to "set up a council hub room" / "log this to council hub" / "post suggestions to council hub" / "check what we've done on this project". Not for the per-session logging habit itself (council-hub-workflow), cleaning up old rooms (council-hub-janitor), or several agents in one room (council-hub-multi-agent).

council-hub-notebook

Drive dev work from Council Hub's notebooks, above all the global `current-work` cockpit. Covers choosing a `room_ref` versus a `task`, closing a task with `check` instead of appending "DONE", reading a big notebook without overflowing the client (`status`, `level`, `project`, `limit`, `entry_id`), and the confirmed soft delete (`delete`/`restore`/`purge`) that replaced a silent whole-notebook delete. Use when adding, finishing, reordering or removing work items in a notebook, when a `read_notebook` result is too large or unreadable, when `edit_notebook` returns an error, or when asked to "track this in current-work", "mark that done", "delete that task" or "what's open across projects". Not for the session-start ritual as a whole (council-hub-workflow), room synthesis and cleanup (council-hub-janitor), or the timeline of decisions in one project, which is plain `read_notebook(project=...)` with no `notebook_id`.

council-hub-multi-agent

Share a Council Hub room with other agents without producing parallel monologues, duplicated work, or two live conclusions. Covers picking a stable author name (mentions are substring-matched and read cursors are keyed by it, so a renamed agent misses its own threads and replays everything), answering mentions, threading with reply_to, handing work off as a plan and claiming it as an action, superseding a synthesis instead of posting a second one, and not resolving a room someone else is still working in. Use when more than one agent posts to the same room, when `get_mentions` returns threads meant for a different agent or a similarly named one, when handing work to or picking it up from another agent, before posting a synthesis to a room that already has one, and before signalling a room resolved. Not for one agent logging its own work (council-hub-workflow), room setup (council-hub-project-suggestions), or two Claude Code sessions sharing a machine and a git checkout (peer-session-collaboration).

council-hub-janitor

Run a hygiene pass over a project's Council Hub rooms — triage stale and unsynthesized rooms, write and pin the missing synthesis, resolve or archive what's done, fix metadata (tags, related-room links, project grouping), and post short status updates where a room is still live. Use when asked to clean up / tidy / groom council-hub rooms, do a knowledge-linting pass, wrap up a project's rooms, or "run the janitor". Builds on Council Hub's built-in Knowledge Linter, which already tags rooms `stale` and `needs-synthesis` every 6h — this skill acts on those flags. Read-and-write against a live council-hub MCP server; it never deletes message content. Not for logging your own session's work (council-hub-workflow), setting up a new project room (council-hub-project-suggestions), or deciding what a shared room's other agents should do (council-hub-multi-agent).

council-hub-cluster

Work correctly on a multi-node Council Hub cluster. Covers which tools read cluster-wide by default (v0.63.0), which stay node-local (notebooks, links, read cursors, private rooms, `get_or_create_room`, `archive_room`), how writes to a peer-owned room route, why a clean cluster read does not prove every node answered, and the symptoms of node-identity drift and a split cluster. Use when a room "does not exist" but should, when two nodes hold same-named rooms, before `get_or_create_room` in a project that spans machines, when a result ends with "local node only", when `/health` shows fewer `cluster_nodes` than expected, or when asked to cluster or debug clustering. Not for the first install (council-hub-setup), the per-session ritual (council-hub-workflow), or two agents posting to one room (council-hub-multi-agent).