manage-discord-sessions

Files (99)

• SKILL.md
• openai.yaml · agents/
• adapters.mjs · helper/
• agent-context.mjs · helper/
• artifact-operation-lock-holder.mjs · helper/
• backend-child-environment.mjs · helper/
• backend-owned-process.mjs · helper/
• backend-runner.mjs · helper/
• cli.mjs · helper/
• constants.mjs · helper/
• credential-profiles.mjs · helper/
• cutover-artifact-lock.mjs · helper/
• cutover-artifacts.mjs · helper/
• cutover-bundle.mjs · helper/
• cutover-canary.mjs · helper/
• cutover-managed-runtime.mjs · helper/
• cutover-rollback.mjs · helper/
• discord-admission.mjs · helper/
• discord-attachments.mjs · helper/
• discord-config.mjs · helper/
• discord-conversation.mjs · helper/
• discord-delivery.mjs · helper/
• discord-failure.mjs · helper/
• discord-gateway.mjs · helper/
• discord-history.mjs · helper/
• discord-projection.mjs · helper/
• discord-prompt.mjs · helper/
• discord-router.mjs · helper/
• discord-routing.mjs · helper/
• discord-scope.mjs · helper/
• execution-profile.mjs · helper/
• grok-cost-profile.mjs · helper/
• instance-paths.mjs · helper/
• mutation-window.mjs · helper/
• native-command-contract.mjs · helper/
• platform-security.mjs · helper/
• projector.mjs · helper/
• recovery-crypto.mjs · helper/
• sanitize.mjs · helper/
• service-cutover-controller.mjs · helper/
• service-manager-launcher.mjs · helper/
• service-manager-linux.mjs · helper/
• service-manager-shared.mjs · helper/
• service-manager-windows.mjs · helper/
• service-manager.mjs · helper/
• service-runtime.mjs · helper/
• service.mjs · helper/
• store-conversation-writer.mjs · helper/
• store-database.mjs · helper/
• store-event-writer.mjs · helper/
• store-job-writer.mjs · helper/
• store-reader.mjs · helper/
• store.mjs · helper/
• supervisor-entry.mjs · helper/
• supervisor.mjs · helper/
• systemd.mjs · helper/
• token-owner-lock.mjs · helper/
• unattended-health.mjs · helper/
• manage-discord-sessions.sh · scripts/
• agent-context.test.mjs · tests/
• …and 39 more

SKILL.md (first lines)

# Manage Discord Sessions

Use this skill as the shared Codex, Claude, OpenCode, and Grok operator surface. Do not create a separate product CLI. The deterministic script below reads durable state without launching another AI or requiring `naia-agent` or `naia-shell`.

## What this provides

The implementation is usable with `naia-adk` alone from Codex, Claude, OpenCode, or Grok:

- append-only SQLite job and safe-event history;
- service freshness and job activity-health projection;
- predeclared completion checks and trusted evidence;
- `status`, `jobs`, `job`, durable `logs --follow`, per-instance `monitor`, bounded job controls, `history`, `latest`, verified
  `attachment` recovery, and explicit `reply` commands.
- independent Codex `exec --json`, Claude `-p --output-format stream-json`, OpenCode `run --format json`, and Grok `--output-format streaming-messages-json` adapters; Grok children keep subagents enabled;
- isolated per-attempt child homes, minimum authentication copies, safe event normalization, timeout, cancellation, and signal-aware exit handling.
- fresh permission-profile checks that replace stale child settings, force no-prompt child execution, and reject an approval UI instead of waiting unattended;
- a bounded no-progress watchdog plus a Discord channel-response deadline that creates an explicit operator handoff;
- a best-effort immediate acknowledgement that never gates accepted model work;
- Discord Gateway receive with durable sequence/resume state; no REST message polling;
- explicit, read-only Discord REST history lookup for one uniquely authorized
  binding, plus exact-message attachment recovery with size and SHA-256 checks;
- exact DM, guild-channel, and thread bindings with default-deny users, configured participant profiles, and operator actions;
- schema-v2 binding profiles that snapshot each bounded mandatory context prefix at service start, verify the selected profile again before every backend spawn, and run the child in the exact project directory selected by the admitted Discord binding;
- one process-lifetime token-owner lock shared by named instances under the same OS user on one host, preventing two local Gateways from using the same bot token;
- user-systemd startup, reconnect with bounded backoff, and single-service locking;
- reboot recovery that preserves job IDs and marks interrupted work `recovery_review` without replaying private prompts or uncertain deliveries;
- scoped Discord commands: `!naia status`, `!naia jobs`, and `!naia job <id>`.

## Natural-language operations

Translate requests such as these into the same script for both clients:

```text
Show Discord session status.
List active background jobs.
What is job <id> doing?
Watch job <id> live.
Show the evidence for job <id>.
```

Run from the skill directory or use the absolute skill path:

```bash
scripts/manage-discord-sessions.sh status [--json]
scripts/manage-discord-sessions.sh health-check [--json]
scripts/manage-discord-sessions.sh jobs [--active|--failed] [--json]
scripts/manage-discord-sessions.sh job <job-id> [--events] [--json]
scripts/manage-discord-sessions.sh watch [--job <job-id>] [--jsonl]
scripts/manage-discord-sessions.sh logs --follow [--job <job-id>] [--jsonl]
scripts/manage-discord-sessions.sh monitor
scripts/manage-discord-sessions.sh cancel --job <job-id>
scripts/manage-discord-sessions.sh restart --job <job-id>
scripts/manage-discord-sessions.sh amend --job <job-id> --content-file <owner-only-path>
scripts/manage-discord-sessions.sh submit --channel <channel-id> --author <operator-user-id> --content-file <owner-only-path>
scripts/manage-discord-sessions.sh history --channel <channel-id> [--author <user-id>] [--limit 20] [--json]
scripts/manage-discord-sessions.sh latest --channel <channel-id> [--author <user-id>] [--json]
scripts/manage-discord-sessions.sh attachment --channel <channel-id> --message <message-id> --attachment <attachment-id> --output <absolute-path> [--expected-sha256 <hex>]
scripts/manage-discord-sessions.sh reply --channel <channel-id> --content-file <owner-only-absolute-path> [--json]
scripts/manage-discord-sessions.sh service install
scripts/manage-discord-sessions.sh service status
scripts/manage-discord-sessions.sh service restart
```

After `service install`, the same deterministic script is available on the
interactive user `PATH` as `naia-dcg`, for example `naia-dcg status`, `naia-dcg jobs
--active`, and `naia-dcg job <job-id> --events`. This is a generated launcher for
the skill script, not a separate runtime or product CLI. The `naia-dcg` launcher
name is the local operator entry point and is distinct from the `!naia` Discord
chat command handled inside Discord itself.

Run more than one bot or persona from the same ADK with a named instance. The
default instance keeps the commands and paths above; a named instance is placed
between `naia-dcg` and the command:

```bash
naia-dcg alpha status
naia-dcg alpha jobs --active
naia-dcg alpha job <job-id> --events
naia-dcg alpha watch --job <job-id>
naia-dcg alpha service install
naia-dcg alpha service restart
```

Each instance has an independent config, SQLite ledger, Gateway resume state,
recovery key, runtime directory, instance lock, and service registration.
Credentials remain in the shared owner-only credential directory and are
selected by `credentialRef`. Managed Linux units derive one kernel-lock name
from the credential bytes, so the same token reaches the same lock across bot-ID
configuration mistakes and ADK roots. The service verifies that fingerprint
again after loading the credential and rejects a mismatched READY bot identity.
Every launch also acquires the same fail-closed owner-record lock, so managed,
direct, and Windows launches cannot split token ownership. A complete record
from this host and boot is atomically quarantined and reclaimed only when its
recorded PID is objectively absent. Incomplete records, identity conflicts,
permission-denied process checks, and PID reuse remain fail-closed. The default
non-XDG Unix `/tmp` fallback uses a boot-scoped directory, so an owner record
from a completed boot cannot permanently obstruct the next boot. Explicitly
configured shared directories and same-directory records from another boot or
host remain fail-closed.

`submit` is a local owner-only recovery ingress. It re-admits a bounded request
through one exact configured operator and channel binding; it cannot impersonate
an arbitrary Discord user or bypass participant authority.
`watch` polls only the local SQLite event ledger. It is not Discord REST receive polling. Stop an interactive watch with `Ctrl-C`.
`history` and `latest` are explicit operator reads, never a receive loop: they
require exactly one `operatorActions` binding, the `read` role, and an optional
author already allowed by that binding. `attachment` first re-reads the exact
authorized message, accepts Discord CDN hosts only, enforces the advertised
size, and can require an expected SHA-256 before creating an owner-only file.
`reply` requires the `reply` role and exactly one operator binding. It reads an
owner-only local content file, suppresses mentions, and returns a confirmed,
failed, or unknown delivery receipt. Never automatically retry an unknown
receipt.

When a message asks someone to check or do something, name that person. A
channel has several participants, and an unaddressed "please confirm" is picked
up by nobody, so finished work stalls waiting on a confirmation nobody owns.
Say who, what, where exactly, and where to report back, and say why you could
not check it yourself. Because `reply` suppresses mentions, write the person's

From nextain/naia-adk, Apache-2.0.

More from nextain/naia-adk