agentleFS
princessingprincessing/claude-skills/skills/discordmsg/SKILL.md

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".

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
  1. Distinctive:

    If the args ask for a specific length/tone ("short", "1 paragraph", "ELI5", "very detailed"), that

    line 32
  2. Distinctive:

    Write the message in Discord-flavored markdown:

    line 37
  3. Very specific:

    Bold headers: Use Discord headers ## / ### for sections (they render bold + sized) and ...

    line 39
  4. Distinctive:

    Don't pad. A tight 1200-char overview beats a bloated 3800-char one.

    line 51
  5. Distinctive:

    Escalate, don't amputate: Do NOT simplify, pad, or sweat landing under the message limit — losing the detail is a worse outcome than …

    line 61
  6. Very specific:

    Only if the writeup exceeds even 6000 is that attachment-scale detail → keep a tight embed and spill the overflow (logs / raw numbers / …

    line 76
  7. Very specific:

    Write the raw message body (no surrounding fence) to a temp file, e.g.

    line 86
  8. Very specific:

    if a .txt attachment was written, its absolute path + a one-line note on what's in it.

    line 123
  9. Very specific:

    Read $ARGUMENTS → pick the subject (the named thing, or the latest substantive result) and the audience/tone (default: explain to an …

    line 127
  10. Distinctive:

    Do not send anything anywhere and do not commit — this skill only formats and copies.

    line 138

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

/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 .txt file 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 summarizeHow to frame it
Yes (e.g. /discordmsg the fix for the team)The thing the args name, drawn from this chatAim 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 conversationGeneral 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;DR or -# 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/### H headers, **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:

  1. Compose the overview message per the format above (natural length — don't compress to hit 2000).
  2. Count its characters (the whole message body).
  3. If length ≤ 2000 → output the plain Discord message as-is. No .txt, no embed.
  4. If length > 2000 → do NOT trim it, simplify it, or spill to a .txt to 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. Budget description ≤ 4096, whole payload ≤ 6000. These are the /discordembed rules — follow that skill's "embed format" section. Save to ${TMPDIR:-/tmp}/discord-embed.txt and 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).
  5. 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 .txt is 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:

  1. 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.
  2. 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
  3. ⚠️ Remote/SSH caveat — say this when it applies. If SSH_CONNECTION is 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, or 2,408 / 6000 chars ✅ when it escalated to an embed);
  • if a .txt attachment was written, its absolute path + a one-line note on what's in it.

Execution steps

  1. 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).
  2. Draft the message in Discord markdown: TL;DR → bold-headed sections → bullets, emojis where they slap, outsider-readable.
  3. 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.
  4. 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 if SSH_CONNECTION is set.
  5. Output the message in a copy-friendly fence; below it confirm it's on the clipboard, report char count, and give any attachment path.
  6. Do not send anything anywhere and do not commit — this skill only formats and copies.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.