Discord Dual Bot Orchestrator

Set up and operate dual Discord bots on one machine with isolated memory, channel allowlists, mention-gated reviewer bot behavior, optional one-way reviewer-...

Security Scan

The skill's behavior generally matches a dual-Discord-bot setup, but metadata, declared requirements, and runtime usage of sensitive placeholders/config paths are inconsistent and could overwrite your existing bot configs if misused.

Purpose & Capability

The scripts and SKILL.md implement the advertised capabilities (creating isolated workspaces, writing .env templates, applying channel allowlists, backups and rollbacks). However, the package metadata declares no required environment variables or credentials while the runtime instructions and templates clearly rely on bot tokens, IDs, guild/channel IDs, and other placeholders — this mismatch is unexpected and should be clarified.

Instruction Scope

The instructions and scripts operate on configuration files under $HOME (e.g. ~/.openclaw/openclaw.json and ~/.openclaw-bot-b/openclaw.json), create directories in the user's filesystem, and overwrite those files during rollback. apply_policy.sh edits the bot-b JSON config and backup/rollback copy files without additional confirmation. These actions are coherent with the stated purpose but are potentially destructive and broaden the agent's scope to the user's OpenClaw config files.

Install Mechanism

No install spec is provided and included files are simple shell and small Python snippets. There is no external download or archive extraction. Risk from install mechanism is low.

Credentials

The SKILL.md lists many sensitive placeholders (BOT_A_TOKEN, BOT_B_TOKEN, BOT IDs, GUILD_ID, CHANNEL_ID_LIST) and the scripts read environment variables (BOTB_CONFIG, GUILD_ID, CHANNEL_ID_LIST, BASE_DIR, OUT_DIR). Yet the skill metadata declares no required env vars/primary credential. Sensitive tokens are necessary for the skill's function but their handling depends on the user replacing .env.template files; this mismatch and the absence of an explicit credential declaration is a red flag. The scripts also default to standard home paths which can expose or overwrite existing configs if mispointed.

Persistence & Privilege

The skill is not always-enabled and does not install persistent agents. However, its scripts directly modify and restore user config files under $HOME, which is a form of high-impact filesystem privilege. That behaviour is consistent with its purpose but increases blast radius if run unintentionally or with incorrect paths.

What to consider before installing

This skill appears to implement the advertised dual-bot orchestration, but it has two practical concerns you should address before running anything: (1) metadata claims no required credentials while the runtime templates and scripts clearly need bot tokens/IDs and will use values you place into .env files, and (2) the scripts read/write configs under your home directory and the rollback script will overwrite openclaw config files without prompts. Recommendations: inspect every script line-by-line, run in an isolated test account or container (not your real bot/guild), back up existing ~/.openclaw and ~/.openclaw-bot-b manually before using the provided backup/rollback, set BOTB_CONFIG/BASE_DIR/OUT_DIR to test paths to avoid clobbering production files, never commit real tokens into the skill files, and only provide credentials at runtime in the actual bot .env (not in the repo). If the package metadata can be corrected to declare the required credentials and path env vars explicitly, that would reduce ambiguity.

Use placeholders only. Never store real secrets in this skill.

Required placeholders

• BOT_A_NAME
• BOT_B_NAME
• BOT_A_TOKEN
• BOT_B_TOKEN
• BOT_A_ID
• BOT_B_ID
• GUILD_ID
• CHANNEL_ID_LIST (comma-separated)
• BASE_DIR (example: ~/.openclaw/bots)

Workflow

1. Create isolated workspaces for bot-a and bot-b.
2. Write .env files from template using placeholders.
3. Apply channel allowlist policy:
   • Bot-A: primary chat policy
   • Bot-B: requireMention=true on allowlisted channels
4. Optional: enable one-way bridge (bot-b -> bot-a) for reviewer feedback.
5. Create backup snapshot before each risky iteration.
6. If behavior regresses, rollback snapshot and restart both gateways.

Commands

Initialize layout

Run:

scripts/init_dual_bot.sh

Apply policy (placeholder-safe)

Run:

scripts/apply_policy.sh

Backup current state

Run:

scripts/backup_state.sh

Rollback from backup dir

Run:

scripts/rollback_state.sh <BACKUP_DIR>

Guardrails

• Keep BOT_B_TOKEN separate from BOT_A_TOKEN.
• Keep bot-b mention-gated in group channels.
• Never enable bidirectional auto-bridge (avoids reply loops).
• Always backup before patching runtime files.