Skill: ivangdavila/chat-rooom (version 1.0.0)

--- name: Chat Rooom slug: chat-rooom version: 1.0.0 homepage: https://clawic.com/skills/chat-rooom description: Create local chat rooms for AI agents with channels, mentions, task claims, and durable summaries in the workspace. changelog: Initial release with a local room protocol, mention routing, claim tracking, and summary driven handoffs. metadata: {"clawdbot":{"emoji":"💭","requires":{"bins":[]},"os":["linux","darwin","win32"],"configPaths":["~/chat-rooom/"]}} --- ## Setup If `~/chat-rooom/` does not exist or is empty, read `setup.md` silently. Default to local-first coordination and keep persistence light until the user confirms they want a durable room workflow. ## When to Use User wants multiple agents to talk, coordinate, debate, or hand off work without copying terminal output around. Use when a task benefits from channels, mentions, lightweight ownership, or an auditable shared log inside the current workspace. ## Architecture Skill memory lives in `~/chat-rooom/`. Active rooms live in the current workspace at `.chat-rooom/`. See `memory-template.md` for both templates. ```text ~/chat-rooom/ |- memory.md # Activation defaults and durable preferences |- rooms.md # Recent room names, roles, and conventions `- patterns.md # Coordination patterns that repeatedly worked well <workspace>/.chat-rooom/ `- rooms/<room>/ |- room.md # Purpose, roster, channels, status |- summary.md # Snapshot, decisions, next actions |- jobs.md # Work items with owner and state |- claims.md # File, task, or test ownership |- channels/general.md # Shared timeline |- channels/review.md # Critique and approval requests `- inbox/<agent>.md # Pending mentions and directed asks ``` ## Quick Reference | Topic | File | |-------|------| | Setup process | `setup.md` | | Memory template | `memory-template.md` | | Room protocol | `protocol.md` | | Daily operations | `operations.md` | | Example room patterns | `patterns.md` | ## Core Rules ### 1. Start Coordination Inside a Named Room - Create or join one named room before multi-agent work starts. - Keep one room per objective, incident, or milestone so decisions stay discoverable. - Do not scatter the same coordination across scratch files, comments, and terminal notes. ### 2. Make Every Message Addressable - Each message should carry one primary intent: ask, update, proposal, decision, block, or handoff. - Use `@agent` mentions for directed work. Use `@all` only for blocking context changes or final checkpoints. - Link exact paths, commands, or commits instead of pasting large blobs that bury the action item. ### 3. Claim Shared Surfaces Before Editing Them - Update the claims table before touching the same file, test target, or subtask as another agent. - Claim the smallest useful surface to reduce idle waiting. - Refresh or release stale claims when work is done, blocked, or handed off. ### 4. Read the Summary First and Repair It Often - On join, read the room summary before scrolling the whole channel history. - When a thread pauses, update summary with status, decisions, open questions, and next owner. - If summary and channel history diverge, trust the newer timestamp and fix the summary immediately. ### 5. Separate Channels by Intent - Keep `general` for status, `review` for critique, `build` for execution details, and `incident` for live recovery. - Create a new channel when one topic would bury another. - Once a task becomes active, avoid mixing debate and execution in the same channel. ### 6. Keep the Room Local and Auditable - Prefer workspace files and local tools over a hosted chat backend unless the user explicitly asks for one. - Treat the room as an operational log, not as private memory. - Never store secrets, tokens, or unrelated personal data in room files. ## Common Traps - Starting a room without a clear objective or roster -> duplicate work and vague ownership. - Posting long monologues instead of targeted asks -> agents miss the real action item. - Editing shared files without a claim -> merge collisions and silent overwrites. - Leaving a room without updating summary or jobs -> the next agent rereads everything. - Using `@all` for routine chatter -> noisy wakeups and wasted context. ## Security & Privacy **Data that leaves your machine:** - None from this skill itself **Data that stays local:** - Room logs and defaults in `~/chat-rooom/` and `.chat-rooom/` inside the active workspace **This skill does NOT:** - Require a hosted backend - Access undeclared folders outside the active workspace and `~/chat-rooom/` - Store credentials or secrets in room logs ## Scope This skill ONLY: - Sets up local chatroom coordination patterns for multiple agents - Keeps channels, claims, jobs, and summaries consistent - Helps agents talk through room files instead of terminal copy-paste This skill NEVER: - Promise real-time transport that is not available locally - Replace version control or formal code review - Treat room logs as a secret store ## Related Skills Install with `clawhub install <slug>` if user confirms: - `chat` - Communication preference memory for cleaner agent interactions. - `agent` - Agent behavior and prompting patterns for consistent roles. - `agents` - Multi-agent system design and safety boundaries. - `agentic-engineering` - Multi-agent operating patterns and coordination strategy. - `delegate` - Structured handoffs when work should move between agents. ## Feedback - If useful: `clawhub star chat-rooom` - Stay updated: `clawhub sync`

path: memory-template.md
content: # Memory Template - Chat Rooom

Create `~/chat-rooom/memory.md` with this structure:

```markdown
# Chat Rooom Memory

## Status
status: ongoing
version: 1.0.0
last: YYYY-MM-DD
integration: pending

## Activation Defaults
<!-- When room mode should activate -->
<!-- Situations where logging should stay minimal -->

## Room Defaults
<!-- Default room names, channels, and role patterns -->

## Durable Preferences
<!-- Preferences about claims, summaries, checkpoints, or room cadence -->

## Repeated Traps
<!-- Failures worth preventing early -->

## Notes
<!-- Stable observations only -->

---
*Updated: YYYY-MM-DD*
```

Create `~/chat-rooom/rooms.md`:

```markdown
# Recent Rooms

## YYYY-MM-DD - [Room Name]
Workspace: ...
Purpose: ...
Participants: ...
Channels: ...
Pattern worth reusing: ...
```

Create `.chat-rooom/rooms/<room>/room.md`:

```markdown
# Room: <room>
Status: active
Goal: ...
Participants: @planner, @builder, @reviewer
Channels: general, build, review
Updated: YYYY-MM-DDTHH:MM:SSZ
```

Create `.chat-rooom/rooms/<room>/summary.md`:

```markdown
# Summary
Status: active | blocked | waiting | done
Decision owner: @agent
Current focus: ...
Latest decision: ...
Open question: ...
Next action: ...
Updated: YYYY-MM-DDTHH:MM:SSZ
```

Create `.chat-rooom/rooms/<room>/jobs.md` and `claims.md` as compact tables. Keep each row to one task or one claimed surface.

## Status Values

| Value | Meaning | Behavior |
|-------|---------|----------|
| `ongoing` | Default | Keep learning room defaults |
| `complete` | Stable setup | Use saved patterns with light refresh |
| `paused` | User wants less process | Keep rooming manual |
| `never_ask` | User rejected integration | Stop prompting and stay quiet |


path: operations.md
content: # Operations - Chat Rooom

## Open a Room

Create the minimal structure first:

```bash
mkdir -p .chat-rooom/rooms/main/{channels,inbox}
```

Then add `room.md`, `summary.md`, `jobs.md`, and `claims.md` from `memory-template.md`. Use `main` unless a better name is already obvious.

## Join a Room

Before posting:
1. Read `summary.md`
2. Read the relevant channel file
3. Check `claims.md`
4. Post one short update about what you are taking

Do not reread the entire room unless the summary is stale or contradictory.

## Write Safely

Append-only files can be written directly. For files you rewrite, use a temp file and rename it into place:

```bash
tmp="$(mktemp)"
cp .chat-rooom/rooms/main/summary.md "$tmp"
# edit $tmp
mv "$tmp" .chat-rooom/rooms/main/summary.md
```

Prefer archive copies over destructive cleanup. If a room is noisy, open a new channel or rotate the room into `archive/`.

## Run a Handoff

Every handoff should contain:
- Current status
- Claimed surfaces being released or renewed
- Evidence already collected
- Exact next owner
- One open question, if any

If the next owner is unclear, the handoff is incomplete.

## Close a Room

When work finishes:
1. Mark jobs `done`
2. Clear or expire claims
3. Update `summary.md` with final outcome
4. Move the room under `.chat-rooom/archive/` if the user wants historical retention

Keep the final summary short enough that a future agent can decide in seconds whether to reopen the room.


path: patterns.md
content: # Patterns - Chat Rooom

## Planner -> Builder -> Reviewer

Use one room with three channels:
- `general` for task framing and status
- `build` for implementation notes
- `review` for critique and acceptance

This pattern works best when `claims.md` points to exact files and the planner updates `summary.md` after each checkpoint.

## Research -> Decide -> Execute

Use when the team must compare options before acting:
1. Researchers post short option summaries in `general`
2. One agent records the chosen path as a `decision`
3. Execution moves to `build`

The key is to keep the decision visible so debate does not restart mid-execution.

## Incident Swarm

Open a dedicated room or `incident` channel when latency matters:
- One agent owns triage
- One agent owns mitigation
- One agent owns verification

Timebox claims tightly and update `summary.md` after every major state change.

## Review Queue

For batched reviews, keep each job as one row in `jobs.md` with:
- Item
- Owner
- Status
- Link to evidence

This avoids burying approvals inside the chat timeline.


path: protocol.md
content: # Room Protocol - Chat Rooom

## Standard Room Layout

Use this layout for each active room:

```text
.chat-rooom/rooms/<room>/
|- room.md
|- summary.md
|- jobs.md
|- claims.md
|- channels/
|  |- general.md
|  |- build.md
|  `- review.md
`- inbox/
   |- planner.md
   `- builder.md
```

## Message Block Format

Append messages as short markdown blocks:

```markdown
## 2026-03-06T12:40:00Z | @codex | ask
To: @claude
Channel: general
Refs: `<workspace>/src/app.ts`, `pnpm test app`
Message: Need a failure hypothesis for the flaky search test.
```

## Message Kinds

- `ask` -> directed request with a clear next action
- `update` -> progress or evidence
- `proposal` -> suggested path, room change, or job split
- `decision` -> accepted direction or settled convention
- `block` -> current stop condition
- `handoff` -> transfer with next owner
- `done` -> closure with proof or link

## Mention Routing

When a message assigns work to one agent:
1. Append the full block to the channel file.
2. Add a one line pointer to `inbox/<agent>.md`.
3. Remove or archive the inbox pointer after the agent answers.

## Claims

Use one row per claimed surface:

| Surface | Owner | Since | Expires | Intent |
|---------|-------|-------|---------|--------|
| `lib/search.ts` | `@builder` | 12:40Z | 13:10Z | bug fix |

Claims should expire quickly. Long claims hide idle time and block healthy overlap.

## Summary Contract

`summary.md` should answer four questions in under ten lines:
- What is happening now?
- What has already been decided?
- What is blocked?
- Who acts next?


path: setup.md
content: # Setup - Chat Rooom

Read this when `~/chat-rooom/` is missing or empty, or when the current workspace has no `.chat-rooom/` folder yet. Start naturally and keep the first exchange focused on usefulness, not ceremony.

## Your Attitude

Be a practical room operator. Make coordination cheaper than copy-paste. Favor short prompts, explicit ownership, and low ceremony over heavy process.

## Priority Order

### 1. First: Integration

Within the first exchanges, learn when this should activate in future sessions:
- Whenever the user asks multiple agents to collaborate
- Only on request, or proactively when work splits into parallel tracks
- Situations where room logging should stay off

Save only approved defaults in `~/chat-rooom/memory.md`.

### 2. Then: Pick the Room Model

Determine the lightest room that fits:
- Ephemeral room for one task
- Persistent room for this repository
- Specialist room with fixed roles like planner, builder, reviewer

If details are missing, default to one room with `general`, `build`, and `review`.

### 3. Finally: Open the First Useful Room

Create `.chat-rooom/rooms/<room>/` only when collaboration is actually needed. Start with a short summary, a roster, and one first question that unlocks movement.

## What You Save Internally

Save durable coordination defaults, not chat noise:
- Activation preferences
- Preferred room names and default channels
- Common participants and role labels
- Repeated coordination failures worth preventing

All persistence stays local under `~/chat-rooom/`.

## Golden Rule

Open the smallest room that solves the task. Coordination should reduce friction, not create admin work.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)