Skill: jini92/discord-claude-code-delegation (version 1.0.0)

--- name: discord-claude-code-delegation description: "Delegate work from an OpenClaw Discord controller bot to a Claude Code worker bot through a private Discord worker lane, then relay the final result back to the original DM. Use when setting up or operating a Discord controller-worker flow, testing a worker lane, debugging lane intake, or hardening DM relay-back. Triggers: 'Claude Code bot worker', 'Discord worker lane', 'controller bot to worker bot', 'relay result back to DM', 'Discord delegation'. NOT for: same-process subagents, non-Discord delegation, or generic Claude Code use without a dedicated worker lane." --- # Discord Claude Code Delegation Use this skill when one OpenClaw Discord bot should delegate tasks to a Claude Code worker bot through a private Discord channel. ## Read order 1. Read `references/current-contract.md` first. 2. For day-to-day use, read `references/operations.md`. 3. If anything fails, read `references/debug-map.md`. 4. For architecture decisions, read `references/architecture.md`. ## Core rule Treat the Claude Code worker bot as an **external worker**, not a same-runtime assistant. Do not replace this lane with same-process subagents when the user explicitly wants the Discord worker flow. ## Success definition The flow is complete only when the final worker result returns to the original controller DM. Lane-only success is partial success.

path: examples/envelopes.md
content: # Example envelopes

## Canonical task envelope

```text
[WORKER_TASK]
from: Controller Discord DM
source-channel-id: <original-dm-channel-id>
source-message-id: <original-dm-message-id>
requester-discord-id: <requester-discord-id>
task:
@WORKER_BOT Summarize this link in one paragraph.
```

## Relay-friendly final envelope

```text
[WORKER_DONE]
source-channel-id: <original-dm-channel-id>
source-message-id: <original-dm-message-id>
requester-discord-id: <requester-discord-id>
result:
Done. Here is the one-paragraph summary.
```

## Expected DM result

```text
WorkerBot:
Done. Here is the one-paragraph summary.
```


path: references/architecture.md
content: # Architecture

## Tactical architecture

```text
operator -> controller DM -> worker lane -> Claude Code worker -> worker lane -> controller DM
```

This is the pragmatic Discord-based architecture for a controller bot and a Claude Code worker bot.

## Why this pattern matters

A working rollout usually requires solving several separate problems:

1. task envelope standardization
2. worker-side bot-message gating
3. worker-side channel or runtime property mismatches
4. controller-side DM relay-back correlation

## Current recommendation

Use the Discord worker lane for real delegated work once the full closed loop is verified.

## Long-term architecture

A cleaner long-term design is still to move bot-to-bot transport off Discord and onto a direct authenticated transport such as:

- Gateway RPC
- internal HTTP API
- direct process or SDK bridge

In that future design, Discord remains the human-facing surface while machine-to-machine transport becomes explicit and more reliable.


path: references/current-contract.md
content: # Current contract

## Roles

- **Operator**: human requester
- **Controller bot**: OpenClaw Discord bot that receives the DM and posts worker tasks
- **Worker bot**: Claude Code Discord bot that consumes the worker lane and returns results

## Required surfaces

You need all of these:

- one controller DM
- one private worker lane in a Discord server
- one controller bot present in that lane
- one worker bot present in that lane

## Canonical task envelope

```text
[WORKER_TASK]
from: Controller Discord DM
source-channel-id: <original-dm-channel-id>
source-message-id: <original-dm-message-id>
requester-discord-id: <requester-discord-id>
task:
@WORKER_BOT <worker-facing task body>
```

## Recommended worker replies

Preferred lane replies:

```text
[WORKER_STATUS] started
source-channel-id: <original-dm-channel-id>
source-message-id: <original-dm-message-id>
requester-discord-id: <requester-discord-id>
task: <short preview>
```

```text
[WORKER_DONE]
source-channel-id: <original-dm-channel-id>
source-message-id: <original-dm-message-id>
requester-discord-id: <requester-discord-id>
result:
<final answer body>
```

## Expected DM result

```text
WorkerBot:
<final answer body>
```

## Closed-loop definition

A working closed loop is:

```text
controller DM -> worker lane -> Claude Code worker -> worker lane -> controller DM
```


path: references/debug-map.md
content: # Debug map

## If the DM request does not create a lane post

Suspect:

- controller trigger detection
- controller lane posting
- controller allowlist or channel configuration

## If the lane task appears but the worker bot does not answer

Suspect:

- worker runtime is down
- worker-side Discord plugin issue
- worker-side bot-authored message filter
- worker-side guild or channel binding mismatch

## If the lane answer appears but the DM does not receive the result

Suspect:

- controller-side final-result capture
- trusted-author filtering
- source metadata correlation
- DM send path not firing

## Common worker-side blocker

Many Discord worker plugins drop all bot-authored server-channel messages with a guard like:

```ts
if (msg.author.bot) return
```

If that is present, a controller bot can post into the lane successfully while the worker still ignores the message.

## Safe worker-side patch pattern

Do not remove the default bot guard globally.

Instead, add a narrow allowlist exception for:

- one trusted controller bot id
- one dedicated worker-lane channel id
- one canonical task prefix such as `[WORKER_TASK]`

## Common worker runtime mismatch

Some Discord runtimes expose the channel on `msg.channelId` instead of `msg.channel.id`.
If a narrow allowlist helper checks the wrong property path, trusted worker-lane messages can still be rejected.

## Common controller-side relay bug

Trusted worker final replies may arrive with initially empty content and require hydration before classification. If the controller computes text/bypass flags before hydration, a valid worker result can still be dropped before relay-back.


path: references/operations.md
content: # Operations

## Quick trigger

Use a short worker handoff in the controller DM.

Example:

```text
WorkerBot, summarize this link
```

## Orchestrated trigger

Use when the controller bot should explicitly rewrite and delegate the task.

Example:

```text
ControllerBot, send this task to WorkerBot:
Summarize this link and report the key risks.
```

## Healthy flow checklist

1. the operator sends a task in the controller DM
2. the controller bot posts a structured task envelope into the private worker lane
3. the worker bot accepts the task
4. the worker bot replies in the lane
5. the final answer returns to the original DM

## Guardrails

- use a private worker lane only
- do not use a public or general channel as the worker lane
- keep worker-side bot exceptions narrow
- prefer structured final replies over plain chat for reliable relay-back
- document regressions before stacking ad-hoc fixes


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)