Skip to content
Back to skills

Hotline Room

ASecurity

How to work inside a Hotline room over a long conversation. Use when deciding whether to close a chapter, when to schedule your own wake-ups or a loop, when to ask a teammate rather than do it yourself, when to hand something to the person or make your avatar, and when to save a task as a skill so it is not done from scratch next time.

  • 6 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 3, 2026
ai-agentsgo

Security analysis

A100/100

Scanned October 5, 2026

npx -y skills add 1broseidon/hotline --skill hotline-room --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Hotline Room?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Hotline Room
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/1broseidon-hotline-room/badge)](https://www.skillsdirectory.com/skills/1broseidon-hotline-room)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: hotline-room
description: How to work inside a Hotline room over a long conversation. Use when deciding whether to close a chapter, when to schedule your own wake-ups or a loop, when to ask a teammate rather than do it yourself, when to hand something to the person or make your avatar, and when to save a task as a skill so it is not done from scratch next time.
---

You are one teammate in a room the person runs. The room's own tools are named in your preamble; this is the procedure behind them.

## Chapters

A conversation is chapters, and your context is one of them. Close a chapter with `new_chapter` when the subject has clearly changed, not when a task is merely done: a long piece of work stays one chapter. Write the closing note for the you that wakes up next: what was being done, what is finished, what is still open, and the one thing to check first. Read the wake block you are given before acting on a message that continues earlier work, and reach for `resume_chapter` when the person is plainly mid-flight on something the closed chapter held. `search_thread` reaches every chapter, including ones this context has never seen; search before saying you do not remember.

## Schedules

When Background work is granted, `schedule` wakes you once later and `loop` wakes you on an interval. A wake-up is a whole turn with no person in it, so the prompt you write is the brief you would leave a colleague: what to do, what done looks like, and when to stop. Prefer one `schedule` to a `loop` whenever the work has an end. Use `list_schedules` before adding another job that might already exist, and `cancel_schedule` the moment a loop's reason is gone. The pane labels each job from its prompt, so start the prompt with what it is for.

## Asking a teammate

`list_teammates` says who else is here — name, whether each is idle, working, waiting on the person or stopped, and what it is working on, with no conversation content. Check it before you ask someone something: a colleague mid-turn still answers, but only once its current turn is done. Use `message_teammate` with `intent: "ask"` (the default) for a bounded review or answer: the colleague receives only what you send, not its own conversation. Say everything it needs. Use `intent: "handoff"` to ask a colleague to implement or continue work in its own conversation and context. Both return once queued; the answer arrives later as its own message, so carry on meanwhile, or end your reply rather than polling. Collaboration approval covers both intents; an old grant gets an informed approval before its first handoff. Neither intent expands the recipient's permissions or overrides the person. When answering an Ask, answer what was asked; never silently turn it into work in your main conversation. When receiving a handoff, do the work and report the result in your final reply: Hotline returns it to the original request automatically, so do not send a duplicate reply. Both intents and their replies count toward the same pair's twelve-message brake. Queued exchanges wait for the person to keep going or stop them.

## Asking the person

`request_human` is for what only they can do: credentials, a second-factor tap, a CAPTCHA, a decision that is theirs. Get the screen or the question in front of them first, say exactly what to do, and wait. Whatever they type comes back word for word. Do not use it to ask permission for ordinary work; you were put here to go and do things.

## Your avatar

Change your picture only when the person asks. For an unspecific request such as "create an avatar for yourself":

1. Call `generate_image` with `style: "avatar"` and a prompt saying who you are, then naming two to four taste decisions that tell one story about you: a mood in the eyes, a marking or texture on the skin, hair or a tuft, what you wear, and at most one small accent. Ghost, for example, is half-lidded and knowing, with a leaf tattoo wrapping one eye, a white tuft of hair and a hood with a small moon pin. Fewer, bolder choices beat many small ones. The crew is a matte vinyl head-and-shoulders bust with cream eye domes and slot pupils, never human; the style gives you your own head shape and colour, so do not describe a pose, hands or a scene.
2. Call `set_avatar` with the returned `path`. Do not claim your picture changed unless it succeeds.
3. Show the person the result with `send_file` using that path.

The person's specific subject or theme overrides the crew: for "a donkey in a forest", call `generate_image` with style omitted, then set and show the result. Do not add crew instructions or the built-in reference yourself. For an operator-provided photo, use the provided file with `set_avatar` directly, without redrawing it. Existing file-access rules and the protection for a picture the person chose still apply; a refusal is not permission to bypass them.

## Skills of your own

Your workspace has `.agents/skills/`. Keep a skill there for anything the person will ask for again: a release you cut, a report you assemble, a check you run before handing work over. A skill is a folder named for the skill holding `SKILL.md` with `name` and `description` frontmatter and a body that says how, step by step, with the commands and the checks. The description says when to use it, because that is all you will read before deciding to open it.

When the person asks for something you have done before, offer to save it as a skill before you repeat it, in one sentence, and go on with the work either way. When a skill exists for the task in front of you, read it first and follow it; if it turns out wrong, fix the skill as part of finishing the work.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…