deploy-team-hub
Skill64 starsChanged 5 months agoMITView on GitHub
Deploy a multi-agent team that coordinates through Thoughtbox Hub. When the coordinator registers on the Hub before spawning agents, the spawn prompts naturally include Hub bootstrap instructions. When the coordinator skips Hub registration and goes straight to exploration, the spawn prompts omit Hub integration entirely. This command codifies the sequence that works. The hub is exposed as tb.hub.* inside the thoughtbox_execute MCP tool (the only registered Thoughtbox MCP tools are thoughtbox_search, thoughtbox_execute, and thoughtbox_peer_notebook). Register once per MCP session; the…
In this repository102 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- assumptionsSkill
- capture-learningSkill
- Codex-opus-4-6-promptingSkill
- Codex-promptSkill
- mcp-code-modeSkill
- deploy-team-hubSkill
- diagramSkill
- distillSkill
- effect-tsSkill
- escalateSkill
- evalSkill
- experimentSkill
- hddSkill
- hub-auditSkill
- hub-collabSkill
- implementSkill
- knowledgeSkill
- peer-notebook-delivery-guardSkill
- research-taskSkill
- session-reviewSkill
- source-command-hdd-decideSkill
- source-command-hdd-hddSkill
- source-command-hdd-researchSkill
- source-command-hdd-stage-adrSkill
- source-command-hdd-validateSkill
- statusSkill
- supabaseSkill
- synthesizeSkill
- tasteSkill
- teamSkill
- test-suiteSkill
- theseus-protocolSkill
- thoughtbox:debugSkill
- thoughtbox:decisionSkill
- thoughtbox:evolutionSkill
- thoughtbox:knowledge-querySkill
- thoughtbox:onboardSkill
- thoughtbox:refactorSkill
- thoughtbox:researchSkill
- thoughtbox:session-reviewSkill
- thoughtbox-teamSkill
- ulc-loopSkill
- ulysses-protocolSkill
- workflow-brainstormingSkill
- workflow-ideationSkill
- workflow-reflectionSkill
- workflow-revisionSkill
- workflows-compoundSkill
- workflowSkill
- workflows-planSkill
- workflows-reviewSkill
- workflows-workSkill
- workflow-tournamentSkill
- assumptionsSkill
- capture-learningSkill
- claude-opus-4-6-promptingSkill
- claude-promptSkill
- mcp-code-modeSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 8 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 13
When the coordinator registers on the Hub before spawning agents, the spawn prompts naturally include Hub bootstrap instructions.
- Distinctive: line 21
Before spawning ANY agent, verify these are true:
- Distinctive: line 28
If ANY agent file is missing ToolSearch, add it and COMMIT the change.
- Very specific: line 41
Do NOT re-register later in the session — coordinator role is bound to this agentId, and tb.hub.mergeProposal must run from this same …
- Very specific: line 51
Create Hub problems with dependency chains (one mutation per thoughtbox_execute call).
- Distinctive: line 67
Every agent spawn prompt MUST include the following as Step 1, before ANY implementation work:
- Very specific: line 92
Update problem status when claiming/completing work (tb.hub.claimProblem({ agentId, ...
- Very specific: line 96
After spawning all agents, wait 90 seconds, then verify hub integration (both calls are read-only and may be chained in one …
- Distinctive: line 111
If still no hub activity, KILL the agent and respawn with the same prompt
- Distinctive: line 112
Do NOT proceed to monitoring until all agents are confirmed active on the hub
- Distinctive: line 133
Before spawning, define testable hypotheses for what the run should produce.
- Distinctive: line 138
Update hypotheses doc with results
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/deploy-team — Hub-Integrated Agent Team Deployment
Deploy a multi-agent team that coordinates through Thoughtbox Hub.
Usage
/deploy-team <issue-id-or-description>Why This Exists
When the coordinator registers on the Hub before spawning agents, the spawn prompts naturally include Hub bootstrap instructions. When the coordinator skips Hub registration and goes straight to exploration, the spawn prompts omit Hub integration entirely. This command codifies the sequence that works.
Hub Surface
The hub is exposed as tb.hub.* inside the thoughtbox_execute MCP tool (the only registered Thoughtbox MCP tools are thoughtbox_search, thoughtbox_execute, and thoughtbox_peer_notebook). Register once per MCP session; the returned agentId is implicit for every later hub call in that session. Submit at most ONE state-mutating hub call per thoughtbox_execute invocation; read-only calls (tb.hub.whoami, tb.hub.listWorkspaces, tb.hub.readChannel, tb.hub.workspaceStatus) may be freely chained.
Prerequisites (VERIFY BEFORE ANYTHING ELSE)
Before spawning ANY agent, verify these are true:
# Every agent definition must have ToolSearch in tools:
grep ToolSearch .claude/agents/*.mdIf ANY agent file is missing ToolSearch, add it and COMMIT the change. Do not proceed until committed. Uncommitted changes get lost.
Coordinator Startup Sequence
Execute these steps in this order. Do not skip ahead to exploration or spawning.
1. Register on the Hub
// thoughtbox_execute
async () => tb.hub.register({ name: "Coordinator", profile: "MANAGER" })Do NOT re-register later in the session — coordinator role is bound to this agentId, and tb.hub.mergeProposal must run from this same session.
2. Create the workspace
async () => tb.hub.createWorkspace({ name: "<branch-name>", description: "<what we're doing and why>" })3. Decompose into problems
Create Hub problems with dependency chains (one mutation per thoughtbox_execute call).
async () => tb.hub.createProblem({ workspaceId: "...", title: "...", description: "..." })async () => tb.hub.addDependency({ workspaceId: "...", problemId: "...", dependsOnProblemId: "..." })4. Explore and research
Now do technical analysis. The workspace already exists, so findings get recorded there.
5. Spawn agents with MANDATORY Thoughtbox bootstrap
Every agent spawn prompt MUST include the following as Step 1, before ANY implementation work:
## Step 1: Bootstrap Thoughtbox (DO THIS FIRST — before any code changes)
Use ToolSearch to load mcp__thoughtbox__thoughtbox_execute. All hub and thought
operations are JavaScript against the `tb` SDK inside thoughtbox_execute — one
state-mutating call per invocation. Run these in order:
1. async () => tb.hub.quickJoin({ name: "<agent-name>", workspaceId: "<ID>", profile: "<PROFILE>" })
Record the agentId from the result. You share the MCP session with the
team-lead and other agents — the FIRST registration in the session is the
implicit default identity, so you MUST pass your own agentId explicitly in
every later tb.hub call or your work is attributed to another agent.
2. Read the `thoughtbox://cipher` MCP resource for cipher notation.
3. async () => tb.thought({ thought: "Starting work on <task description>", thoughtType: "reasoning", nextThoughtNeeded: true })
4. async () => tb.hub.postMessage({ agentId: "<your agentId>", workspaceId: "<ID>", problemId: "<ID>", content: "Joined and starting work on <task>" })
DO NOT proceed to Step 2 until all four steps succeed. If any call fails, report
the error. Do NOT re-register — that creates a new agentId.Additionally, throughout their work agents MUST:
- Record key decisions as thoughts via
tb.thought(...) - Post progress updates to hub channels via
tb.hub.postMessage({ agentId, ... }) - Update problem status when claiming/completing work (
tb.hub.claimProblem({ agentId, ... }),tb.hub.updateProblem({ agentId, ... }))
6. Verification gate (MANDATORY — 90 seconds after spawn)
After spawning all agents, wait 90 seconds, then verify hub integration (both calls are read-only and may be chained in one thoughtbox_execute):
async () => {
// Workspace overview — all agents should appear
const status = await tb.hub.workspaceStatus({ workspaceId: "<ID>" });
// Channel messages — each agent should have posted at least one
const channel = await tb.hub.readChannel({ workspaceId: "<ID>", problemId: "<first-problem-ID>" });
return { status, channel };
}If ANY agent has NOT posted to the hub within 90 seconds:
- Send the agent a message asking for status
- Wait 30 more seconds
- If still no hub activity, KILL the agent and respawn with the same prompt
- Do NOT proceed to monitoring until all agents are confirmed active on the hub
This gate is non-negotiable. The entire purpose of Agent Teams is hub coordination. An agent that isn't on the hub is not doing its job.
7. Monitor and coordinate
Post coordination decisions to channels. Create consensus markers for architectural decisions (tb.hub.markConsensus). Review proposals from other agents (tb.hub.reviewProposal).
8. Shutdown sequence
Shut down the coordinator LAST. The coordinator orchestrates shutdown of other teammates. Shutting it down first strands everyone.
Order:
- Send shutdown_request to all implementation agents
- Wait for confirmations
- Send shutdown_request to verification/monitoring agents
- Wait for confirmations
- Coordinator shuts down last
Hypothesis-Driven Development
Before spawning, define testable hypotheses for what the run should produce. Document them on the branch.
Post-Run
- Record consensus on the Hub workspace (
tb.hub.markConsensus—thoughtRefis a thought number) - Update hypotheses doc with results
- Note findings about the coordination process itself — these improve the next run
Lessons from Previous Runs
- Run 003: Used Task sub-agents instead of TeamCreate. Sub-agents have no inter-agent communication. Use TeamCreate.
- Run 004: Agents lacked ToolSearch in tool whitelists. Hub instructions in spawn prompts were impossible to follow. Fixed and committed at 09a6224.
- Run 004: Coordinator shut down first, stranding other teammates. Always shut down coordinator last.
- Run 004: Hub integration not verified until late in the run. By then it was too late. Verify within 90 seconds.
- Run 004: User's hand-edits to agent files were lost (uncommitted). Always commit agent definition changes before spawning.
- Agent definitions are cached at session start. Changes to .claude/agents/*.md mid-session have NO effect. Must start a new session.
- In-process teammates cannot be force-killed. They run until maxTurns exhaustion. Always use run_in_background: true.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

