agentleFS
umitsu-techumitsu-tech/claude-code-discord-bot/skills/configure/SKILL.md

configure

Skill0 starsChanged 52 days agoMITView on GitHub

Set up the Discord channel — save the bot token to the state directory's .env, show the current token and access status, and steer the access policy toward a locked allowlist.

  • Reads credentials

43 other projects use a version of this, 16 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use calendar, setup and 2 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • jacobraskSkill

    calendar

    Interact with Apple Calendar via AppleScript. Use when the user asks to check calendar, view events, create events, manage schedule, find free time, or list calendars. Triggers include "my calendar", "my schedule", "calendar events", "create event", "add to calendar", "what's on my calendar", "free time", "available slots", "upcoming events", "today's events". Requires macOS with Calendar.app.

    Also in 3 projects that use this

  • VercelSkill

    setup

    Set up Vercel CLI and project configuration. Use when the user says "set up Vercel", "configure Vercel", "link to Vercel", or "vercel init".

    Also in 7 projects that use this

  • AnthropicSkill

    status

    Case status summary by audience — client-facing (plain language), internal (for the professor), or court-ready (formal caption format per local rules). Same facts, different framing and depth. Use when a student needs to update the client, brief the professor, or prepare a court status report.

    Also in 3 projects that use this

  • Microsoft AzureSkill

    build

    Build the TypeSpec Rust emitter from source. Run this after cloning the repo, after pulling changes, or when TypeScript source files have been modified.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

12 rules. 0 are common, 5 are distinctive, and 7 are very specific to this project.

  • 0

    Common

    Most of the 43 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read both state files and give the user a complete picture:

    line 33
  2. Very specific:

    No token → *"Run /discord-bot:configure <token> with your bot token from the Developer Portal → Bot → Reset Token."*

    line 46
  3. Distinctive:

    Read the allowlist. Tell the user who's in it.

    line 61
  4. Distinctive:

    Ask: *"Is that everyone who should reach you through this bot?"*

    line 62
  5. Very specific:

    If yes and policy is still pairing → *"Good.

    line 63
  6. Very specific:

    If no, people are missing → *"Have them DM the bot.

    line 67
  7. Distinctive:

    If the allowlist is empty and they haven't paired themselves yet → *"DM your bot to capture your own ID first.

    line 72
  8. Very specific:

    If policy is already allowlist → confirm this is the locked state.

    line 75
  9. Distinctive:

    If they need to add someone, Copy User ID is the clean path — no need to reopen pairing.

    line 76
  10. Very specific:

    Treat $ARGUMENTS as the token (trim whitespace).

    line 85
  11. Very specific:

    Read existing .env if present.

    line 89
  12. Very specific:

    Delete the DISCORD_BOT_TOKEN= line (or the file if that's the only line).

    line 96

“Common” is measured: kept by at least 6 in 10 of the 43 edited versions of this file we could read. “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

/discord-bot:configure — Discord Channel Setup

Writes the bot token to the state directory's .env and orients the user on access policy. The server reads both files at boot.

The state directory is ${DISCORD_STATE_DIR:-~/.claude/channels/discord}/ unless the environment variable DISCORD_STATE_DIR is set (check with echo "${DISCORD_STATE_DIR:-}" before touching any file). Every path below is written as ${DISCORD_STATE_DIR:-~/.claude/channels/discord} to mean "that directory". Running several bots on one machine relies on this variable to keep their tokens and allowlists apart.

Arguments passed: $ARGUMENTS


Dispatch on arguments

No args — status and guidance

Read both state files and give the user a complete picture:

  1. Token — check ${DISCORD_STATE_DIR:-~/.claude/channels/discord}/.env for DISCORD_BOT_TOKEN. Show set/not-set; if set, show first 6 chars masked.
  2. Access — read ${DISCORD_STATE_DIR:-~/.claude/channels/discord}/access.json (missing file = defaults: dmPolicy: "pairing", empty allowlist). Show:
    • DM policy and what it means in one line
    • Allowed senders: count, and list display names or snowflakes
    • Pending pairings: count, with codes and display names if any
    • Guild channels opted in: count
  3. What next — end with a concrete next step based on state:
    • No token → "Run /discord-bot:configure <token> with your bot token from the Developer Portal → Bot → Reset Token."
    • Token set, policy is pairing, nobody allowed → "DM your bot on Discord. It replies with a code; approve with /discord-bot:access pair <code>."
    • Token set, someone allowed → "Ready. DM your bot to reach the assistant."

Push toward lockdown. The goal for every setup is allowlist with a defined list. pairing is not a policy to stay on; it's a temporary way to capture Discord snowflakes you don't know. Once the IDs are in, pairing has done its job and should be turned off.

Drive the conversation this way:

  1. Read the allowlist. Tell the user who's in it.
  2. Ask: "Is that everyone who should reach you through this bot?"
  3. If yes and policy is still pairing → "Good. Let's lock it down so nobody else can trigger pairing codes:" and offer to run /discord-bot:access policy allowlist. Do this proactively — don't wait to be asked.
  4. If no, people are missing → "Have them DM the bot; you'll approve each with /discord-bot:access pair <code>. Run this skill again once everyone's in and we'll lock it." Or, if they can get snowflakes directly: "Enable Developer Mode in Discord (User Settings → Advanced), right-click them → Copy User ID, then /discord-bot:access allow <id>."
  5. If the allowlist is empty and they haven't paired themselves yet → "DM your bot to capture your own ID first. Then we'll add anyone else and lock it down."
  6. If policy is already allowlist → confirm this is the locked state. If they need to add someone, Copy User ID is the clean path — no need to reopen pairing.

Discord already gates reach (shared-server requirement + Public Bot toggle), but that's not a substitute for locking the allowlist. Never frame pairing as the correct long-term choice. Don't skip the lockdown offer.

<token> — save it

  1. Treat $ARGUMENTS as the token (trim whitespace). Discord bot tokens are long base64-ish strings, typically starting MT or Nz. Generated from Developer Portal → Bot → Reset Token; only shown once.
  2. mkdir -p ${DISCORD_STATE_DIR:-~/.claude/channels/discord}
  3. Read existing .env if present; update/add the DISCORD_BOT_TOKEN= line, preserve other keys. Write back, no quotes around the value.
  4. chmod 600 ${DISCORD_STATE_DIR:-~/.claude/channels/discord}/.env — the token is a credential.
  5. Confirm, then show the no-args status so the user sees where they stand.

clear — remove the token

Delete the DISCORD_BOT_TOKEN= line (or the file if that's the only line).


Implementation notes

  • The channels dir might not exist if the server hasn't run yet. Missing file = not configured, not an error.
  • The server reads .env once at boot. Token changes need a session restart or /reload-plugins. Say so after saving.
  • access.json is re-read on every inbound message — policy changes via /discord-bot:access take effect immediately, no restart.

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.