| name | tinytown-agent-communications |
| description | Use when coordinating Tinytown agents, running mission mode, or showing example conductor/worker/reviewer message flows. Covers task assignment, worker handoffs, reviewer gating, and Slack-style communication examples. |
Tinytown Agent Communications
Use this skill when the user wants help with Tinytown orchestration patterns rather than only code changes:
- starting or steering a multi-agent run
- assigning work to workers and reviewers
- showing example
tt send / inbox message flows
- formatting example communication history as chat or Slack logs
Default Pattern
- Conductor assigns a concrete task to the owning worker.
- Sidecar workers send focused verification or research back to the owner.
- Reviewer waits until the work is actually review-ready.
- Conductor steps in for scope decisions, blockers, and concrete correction.
Prefer direct worker-to-worker handoffs when the next step is obvious.
Message Types
task: use for new owned workinfo: use for progress, findings, or concrete fix feedbackquery: use only for real blockers or scope decisionsack: use for lightweight confirmation when needed
Good Message Shape
Keep messages short and actionable:
- identify the issue / mission / task id
- say exactly what the recipient owns
- name the file or behavior to inspect
- say what to do next
Conductor Shorthand Directives
Use these shorthand references when the user wants repeatable Tinytown conductor flows without restating the full instruction block.
$tt.finish
Expand this to:
Ok, we just merged this PR to main. Switch to main and pull, then look at the gh issues and recommend the next one to work on.
$tt.next <id>
Expand this to:
If <id> is empty then reference the ID that was suggested above. Open a tinytown mission for <id> and start it. Clean up and delete the mess of agents in this town first. Then examine this task carefully (<id>) and come up with the best combination of agents and roles to encourage agent to agent communication, task parallelism, and feedback, brainstorming, and teamwork between the agents. Then act as the conductor and monitor everything and conduct it to completion and pr submission.
$tt.c / $tt.continue
Expand this to:
You are the conductor of this tinytown. Continue to check the status and ensure it is conducted to completion and submission of a clean PR with all bugbot comments addressed and responded to, let me know the status of the tinytown and if applicable mission, then continue conducting.
Recommended Templates
Assignment
@worker Mission <run-id>, issue #<n>.
Own <specific scope>. Preserve <constraints>.
When done, send reviewer a concrete handoff naming files changed and send supervisor an info update.
Scope correction
@worker For issue #<n>, focus on <scope>.
Do not expand into <out-of-scope area>; that belongs to issue #<m>.
Test handoff
@owner Added verification in <file> covering <cases>.
Remaining gap: <specific missing case>.
Reviewer gate
@reviewer Wait for a review-ready handoff, then review <files/behavior>.
Focus on <risk areas>. Route concrete fixes back to the owner.
Concrete fix feedback
@owner I ran <command> and the current patch fails on:
1. <specific defect>
2. <specific defect>
After fixing, rerun <command> and then hand off to reviewer.
Slack-Style Transcript Format
When the user asks for examples, prefer this format:
[YYYY-MM-DD HH:MM:SS TZ] sender: @recipient message
Example:
[2026-03-24 09:45:41 MDT] conductor: @proxy For issue #18, focus on pool behavior and redirect hardening only.
[2026-03-24 09:49:33 MDT] tester: @proxy Added focused verification in proxy/src/proxy.rs covering MOVED, ASKING, and reconnect behavior.
[2026-03-24 09:51:23 MDT] conductor: @reviewer18 Current proxy patch is not review-ready yet; wait for a successful test run before reviewing.
Practical Rules
- Do not send the reviewer in early.
- Do not let stale informational messages pile up without summarizing them.
- If a worker asks a scope question, answer narrowly and tie it back to issue ownership.
- If you verify locally and find defects, send exact failures, not vague “please fix” notes.
- If two agents touch the same file, watch for overlap and explicitly route ownership.
