discordmsg
Skill1 starsChanged 4 months agoMITView on GitHub
Repackage the current answer / chat context into a ready-to-paste Discord message — bold headers, emojis where they slap, written as an explanation/overview for someone who wasn't in the chat — kept under the 2000-char message limit — or auto-escalated to a Discord embed (6k budget) when it runs over — with important overflow spilled to an attachable .txt file only past 6k, and copied to your clipboard. Use when the user says "/discordmsg", "discord this", "make a discord message", "discordmsg <context>", "post this to discord", "send this to the team on discord".
In this repository9 other files it gives its agents.
- commitpushSkill
- discordembedSkill
- endSkill
- handoffSkill
- prettyhtmlSkill
- prettymsgSkill
- startSkill
- wrapupSkill
- wtfSkill
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 5 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 32
If the args ask for a specific length/tone ("short", "1 paragraph", "ELI5", "very detailed"), that
- Distinctive: line 37
Write the message in Discord-flavored markdown:
- Very specific: line 39
Bold headers: Use Discord headers ## / ### for sections (they render bold + sized) and ...
- Distinctive: line 51
Don't pad. A tight 1200-char overview beats a bloated 3800-char one.
- Distinctive: line 61
Escalate, don't amputate: Do NOT simplify, pad, or sweat landing under the message limit — losing the detail is a worse outcome than …
- Very specific: line 76
Only if the writeup exceeds even 6000 is that attachment-scale detail → keep a tight embed and spill the overflow (logs / raw numbers / …
- Very specific: line 86
Write the raw message body (no surrounding fence) to a temp file, e.g.
- Very specific: line 123
if a .txt attachment was written, its absolute path + a one-line note on what's in it.
- Very specific: line 127
Read $ARGUMENTS → pick the subject (the named thing, or the latest substantive result) and the audience/tone (default: explain to an …
- Distinctive: line 138
Do not send anything anywhere and do not commit — this skill only formats and copies.
≈ “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
/discordmsg — package an answer as a paste-ready Discord message
Take whatever was just figured out / asked / produced in this chat and rewrite it as a clean Discord message the user can copy-paste straight into Discord. Discord renders markdown, so the message body IS Discord markdown. This skill formats for paste and copies to the clipboard — it does not send. (No webhook/bot required. If you want real auto-posting, that's a separate setup.)
What the user wants (the spec)
- Paste-ready Discord message, kept within the character limit.
- Over the limit only if the extra detail is genuinely important → put that overflow in a
.txtfile they can attach to the Discord message. - Bold headers. Emojis where they slap (tasteful, relevant — not confetti on every line).
- Written in explanation / overview format — for a reader who was NOT in this chat.
Args
$ARGUMENTS is an optional focus string:
| Arg given? | What to summarize | How to frame it |
Yes (e.g. /discordmsg the fix for the team) | The thing the args name, drawn from this chat | Aim it at the audience/angle in the args (team, a non-coder, "keep it short", etc.) |
No (/discordmsg) | The most recent substantive answer / result in the conversation | General share — explain it so an outsider gets it |
If the args ask for a specific length/tone ("short", "1 paragraph", "ELI5", "very detailed"), that overrides the defaults below — but the hard character limit still applies.
The Discord format (rules of the output)
Write the message in Discord-flavored markdown:
- Bold headers. Use Discord headers
##/###for sections (they render bold + sized) and**...**for inline key terms. A short bolded line per section — the user wants bold headers. - Lead with a one-line TL;DR (often
## 🎯 TL;DRor-#subtext) so it's skimmable, then bolded sections with bullets (-). Overview first, detail second. - Emojis where they slap — one in most section headers + the odd inline accent (✅ done, 🐛 bug, 🔧 fix, ⚠️ caveat, 🚀 shipped, 📊 numbers, 🎯 goal, 📎 attachment). Relevant, not random. Don't emoji every bullet. Plain unicode emoji only (avoid exotic ones that may render as tofu).
- Explain for an outsider. The reader wasn't in the chat — give the one sentence of context needed to understand, name the thing plainly, skip the journey/dead-ends. Overview, not transcript.
- Discord markdown you can use:
## H/### Hheaders,**bold**,*italic*,> quote,`inline code`,``` ```fenced code,-bullets,1.lists,-#subtext. Masked[text](url)links do not render in normal messages — paste raw URLs. - Don't pad. A tight 1200-char overview beats a bloated 3800-char one. Length serves clarity.
Character limit + the .txt overflow rule
LIMIT = 2000 # Free Discord's per-message ceiling — the safe default.
# Discord Nitro raises it to 4000; if the poster has Nitro, change this number.
EMBED_LIMIT = 6000 # a Discord embed's roomier budget (description ≤ 4096, whole payload ≤ 6000).Escalate, don't amputate. Do NOT simplify, pad, or sweat landing under the message limit — losing the detail is a worse outcome than switching format. Write the overview at its natural length, then:
- Compose the overview message per the format above (natural length — don't compress to hit 2000).
- Count its characters (the whole message body).
- If length ≤ 2000 → output the plain Discord message as-is. No
.txt, no embed. - If length > 2000 → do NOT trim it, simplify it, or spill to a
.txtto squeeze under 2000. Deliver the SAME writeup as a Discord EMBED instead — the embed's ~6000 budget is exactly why we escalate.- Re-render in embed style:
**bold**section headers, NOT##/###(Discord headers do not render inside an embed); lead with the TL;DR; masked[text](url)links are fine. Budgetdescription ≤ 4096, whole payload≤ 6000. These are the/discordembedrules — follow that skill's "embed format" section. Save to${TMPDIR:-/tmp}/discord-embed.txtand copy that. - Say in your reply that it ran over 2000 so you switched to an embed; report
chars / 6000. - Only if the writeup exceeds even 6000 is that attachment-scale detail → keep a tight embed
and spill the overflow (logs / raw numbers / code) to a
.txt(step 5).
- Re-render in embed style:
- Where the .txt goes: a temp dir (
${TMPDIR:-/tmp}), e.g.${TMPDIR:-/tmp}/discord-fix.txt. Name it descriptively. Print the absolute path in your reply so the user can attach it. The.txtis plain text / light markdown (an attachment, not a rendered message — no 2000 limit).
Copy to clipboard (always)
The user wants the message on the clipboard, ready to paste. After composing it:
- Write the raw message body (no surrounding fence) to a temp file, e.g.
${TMPDIR:-/tmp}/discord-msg.txt. Writing to a file (not a shell var) avoids emoji/quote escaping bugs. - Copy that file to the clipboard with whatever's available on this OS — try in order and use the
first that exists:
F="${TMPDIR:-/tmp}/discord-msg.txt" if command -v pbcopy >/dev/null; then pbcopy < "$F" # macOS elif command -v wl-copy >/dev/null; then wl-copy < "$F" # Linux / Wayland elif command -v xclip >/dev/null; then xclip -selection clipboard -i "$F" # Linux / X11 elif command -v xsel >/dev/null; then xsel -b -i < "$F" # Linux / X11 (alt) elif command -v clip.exe >/dev/null; then clip.exe < "$F" # Windows / WSL else echo "no clipboard tool found — use the copy block below"; fi - ⚠️ Remote/SSH caveat — say this when it applies. If
SSH_CONNECTIONis set, the clipboard command writes to the remote machine's clipboard, which usually does not reach the user's local machine over plain SSH. In that case the copy-friendly fenced block (below) is their fallback — always print it too.
How to deliver it back to the user
Also present the Discord message inside a copy-friendly fenced block (belt-and-suspenders: the
fallback when the clipboard can't cross SSH) so one select grabs the raw markdown (Discord then
renders the **, ##, emojis). If the message itself contains a ``` code block, wrap the
whole thing in a longer fence (4 backticks) so it doesn't break:
````
## 🎯 TL;DR
... the Discord message ...
````Then, below the block, in your normal reply (NOT inside the copy block):
- a line confirming the message is on the clipboard (+ the SSH caveat if it applies);
- one line confirming char count vs the ceiling (e.g.
1,180 / 2000 chars ✅for a plain message, or2,408 / 6000 chars ✅when it escalated to an embed); - if a
.txtattachment was written, its absolute path + a one-line note on what's in it.
Execution steps
- Read
$ARGUMENTS→ pick the subject (the named thing, or the latest substantive result) and the audience/tone (default: explain to an outsider; honor any tone/length the args request). - Draft the message in Discord markdown: TL;DR → bold-headed sections → bullets, emojis where they slap, outsider-readable.
- Count chars. ≤ 2000 → deliver as a plain Discord message. > 2000 → re-render the SAME
content as an EMBED (bold headers not
##, budget ≤ 6000) and deliver that instead — do NOT trim to fit 2000. Only if it exceeds 6000 does the overflow spill to a.txt. - Copy the raw message to the clipboard (write to
discord-msg.txt→ clipboard command → confirm), per the Copy to clipboard section. Flag the SSH caveat ifSSH_CONNECTIONis set. - Output the message in a copy-friendly fence; below it confirm it's on the clipboard, report char count, and give any attachment path.
- Do not send anything anywhere and do not commit — this skill only formats and copies.
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.

