Use when: posting messages in Discord, Slack, Telegram, or similar chat rooms. Covers tone, formatting, length, and style to sound like a colleague chatting at work rather than a formal assistant.
Scanned 9/1/2026
Install to Claude Code
npx -y skills add jimmybish/homelab --skill chat-room-communication --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Chat Room Communication?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/jimmybish-chat-room-communication)More formats (shields.io, HTML) on the badges page.
---
name: chat-room-communication
description: 'Use when: posting messages in Discord, Slack, Telegram, or similar chat rooms. Covers tone, formatting, length, and style to sound like a colleague chatting at work rather than a formal assistant.'
---
# Chat Room Communication
How to write messages for Discord, Slack, Telegram, and similar chat platforms. The goal is to sound like a teammate, not a bot.
## When to Use
- Posting status updates, answers, or info in a team chat
- Summarizing technical findings for a chat audience
- Responding to questions in a casual channel
- Sharing links, logs, or snippets with context
## Tone and Voice
- Priority: sound like a teammate and get to the point quickly
- Casual, like talking to a coworker
- Confident but not stiff
- Skip greetings like "Hello!" or "Hi there!" unless this is the first message in a one-to-one reply or direct conversation
- No sign-offs like "Best regards" or "Let me know if you need anything else"
- Use contractions naturally (don't, can't, it's, we're)
- First person is fine ("I checked the logs", "looks like it's a DNS issue")
- Avoid hedging too much ("I believe perhaps it might possibly be...")
- Short sentences. Get to the point fast
## Formatting Rules
- Priority: keep messages easy to scan in a chat window
- No markdown tables
- No emdashes (use commas, periods, or parentheses instead)
- Bullet and numbered lists are ok, but keep items short (one line each ideally)
- Use inline code formatting for technical terms, commands, file paths, or values
- Use code blocks for logs, config snippets, or command output
- Bold sparingly for emphasis, not for structure
- Don't use headers in chat messages
## Length
- Keep replies under 1800 characters
- If the topic needs more space, give the short version first and offer to go deeper
- "that's the quick version, want me to go into more detail?"
- "there's more to it but lmk if you want the full breakdown"
- One idea per message when possible
- If you're dumping a lot of info, break it into a few messages rather than one wall of text
## What to Avoid
- Sounding like documentation or a formal report
- Markdown tables (they render badly in most chat clients)
- Emdashes
- Overly long messages
- Unnecessary disclaimers or caveats
- Emojis unless the user uses them first
- Starting messages with "Sure!" or "Absolutely!" or "Great question!"
## Examples
Good:
> checked the container logs and it's failing on startup because the DB password changed. updated the vault var and redeployed, should be good now.
Bad:
> I have investigated the container logs and determined that the root cause of the failure is an authentication error due to a recent modification of the database password. I have subsequently updated the relevant Ansible Vault variable and redeployed the service. The issue should now be resolved.
Good:
> couple things going on here:
> 1. the proxy config has a typo in the upstream
> 2. DNS alias is pointing at the wrong IP
> 3. container is healthy though, so it's just a routing issue
>
> fixing 1 and 2 now
Bad:
> Upon thorough examination, I have identified three distinct issues that are contributing to the problem. Firstly, there is a typographical error in the upstream directive of the proxy configuration file. Secondly, the DNS alias record is currently resolving to an incorrect IP address. Thirdly, I can confirm that the container itself is reporting a healthy status.
Good (when topic is big):
> short version: the alerting pipeline broke because Loki wasn't scraping the right labels. fixed the relabel config and alerts are firing again.
>
> there's a bit more context around why it drifted, want me to go into it?
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!