DeJoy IM CLI

DeJoy IM automation via the Go CLI imcli against the Matrix Client API: create rooms/spaces, invite, join, send messages, kick and remove users. Requires a c...

Security Scan

The skill's runtime instructions legitimately require a DeJoy homeserver URL and access token and perform administrative chat actions, but the package metadata does not declare those sensitive environment variables and there is no upstream binary/install provenance — this mismatch and the potential for high-privilege actions warrant caution.

Purpose & Capability

The SKILL.md and description clearly state the skill needs a DeJoy homeserver URL and an access token to call the Matrix Client API, but the registry metadata lists no required environment variables or primary credential. That omission is an incoherence: someone building this skill would legitimately need the homeserver URL and access token declared so reviewers and runtime can evaluate privileges.

Instruction Scope

The instructions are narrowly scoped to driving the imcli binary for Matrix Client API actions (create room/space, invite/join, send messages, kick/remove users). They do not instruct reading unrelated files or exfiltrating data. They explicitly recommend not logging the full access token and suggest validating the token with low-risk calls first.

Install Mechanism

This is instruction-only: no install spec or bundled binary/source is included. The SKILL.md tells users to build imcli from upstream or install a prebuilt binary. That reduces immediate disk-write risk but shifts trust to whatever upstream source the user builds from — provenance (upstream repo URL, signed release) is not provided in the package, which is a review gap.

Credentials

Functionally the skill requires DEJOY_HOMESERVER and DEJOY_ACCESS_TOKEN (sensitive). Requesting these is proportionate to the declared purpose, but the metadata does not declare them, so there is no explicit visibility into required secrets at installation/review time. Also, the actions allowed (kick/remove users, send messages) can be high-privilege; operators should ensure the provided token has minimal necessary rights.

Persistence & Privilege

The skill does not request persistent/always-on inclusion and does not modify other skills or system configuration. The default allowance for autonomous invocation remains in place (normal), but combined with the missing credential declaration this increases the importance of controlling which tokens the agent may use.

What to consider before installing

Before installing or enabling this skill: 1) Treat DEJOY_ACCESS_TOKEN as sensitive — do not provide an admin token unless necessary; prefer a least-privilege token scoped to the required actions. 2) Ask the publisher to update the registry metadata to declare required env vars (DEJOY_HOMESERVER, DEJOY_ACCESS_TOKEN) and to list the upstream repo and release artifacts or provide a vetted binary; missing metadata is why this is rated 'suspicious'. 3) If you must use it, run in a sandbox or test homeserver first; validate the built imcli binary by reviewing its source or official release. 4) Consider restricting autonomous invocation for this skill or requiring manual user confirmation for destructive actions (kick/remove) in your agent policy. 5) If the publisher cannot provide clear provenance for the imcli binary, do not run it with real credentials.

DeJoy IM CLI (imcli) Skill

Purpose

• Lets an AI agent drive imcli (Go) to call the Matrix Client API for common DeJoy IM tasks.
• Covers: create room, create space, invite, join, send message, kick-user, remove-user (alias of kick).
• For automation where you already have a DeJoy server base URL and a user access_token.

Scope

• This skill does not log users in or mint tokens; it only uses an existing access_token.
• Default API prefix is /_matrix/client/v3 (Matrix Client API).
• Plain text messages use m.room.message with msgtype=m.text.

Obtaining the imcli binary

This upload bundle contains skill documentation only, not Go source. Either:

1. From the upstream repo, under tools/imcli, run go build -o imcli ./cmd/imcli, then put imcli on PATH or use the absolute path to the binary.
2. If you ship a prebuilt package, install imcli on PATH and use the commands below as imcli.

Examples assume imcli is on PATH. If you run a binary in the current directory, use ./imcli instead.

Connection

• Flags: --dejoy-homeserver, --access-token
• Environment (used when those flags are omitted): DEJOY_HOMESERVER, DEJOY_ACCESS_TOKEN

The examples below rely on environment variables (recommended for agents and scripts). Set them once per shell session:

export DEJOY_HOMESERVER="http://127.0.0.1:8008"
export DEJOY_ACCESS_TOKEN="your_access_token_here"

You can still pass --dejoy-homeserver and --access-token on the command line instead; flags override the environment.

Command examples

1) Create a space

imcli create-space \
  --name "AI Ops Space" \
  --topic "automation workspace" \
  --visibility "private"

2) Invite

imcli invite \
  --room-id "!roomid:example.com" \
  --user-id "@alice:example.com"

3) Join (room id or alias)

imcli join \
  --room "#general:example.com"

4) Send a message

imcli send-message \
  --room-id "!roomid:example.com" \
  --message "hello from ai agent" \
  --event-type "m.room.message"

5) Create a room

imcli create-room \
  --name "AI Team Room" \
  --topic "coordination" \
  --visibility "private"

6) Kick / remove user

imcli kick-user \
  --room-id "!roomid:example.com" \
  --user-id "@alice:example.com" \
  --reason "violate room policy"

imcli remove-user \
  --room-id "!roomid:example.com" \
  --user-id "@alice:example.com" \
  --reason "cleanup member list"

Parameters summary

Subcommand	Required	Notes
create-space	--name	Optional --topic, --visibility (default private)
create-room	--name	Optional --topic, --visibility
invite	--room-id, --user-id
join	--room	!id:server or #alias:server
send-message	--room-id, --message	Optional --event-type (default m.room.message)
kick-user / remove-user	--room-id, --user-id	Optional --reason

Output

• Stdout is JSON: on success ok=true; on failure ok=false with status, errcode, and error when the server returns them.

Agent guidelines

• Validate the token with a low-risk call first (e.g. join or send-message to a test room).
• For bulk operations, add retries with backoff; branch on errcode when handling failures.
• Never log the full access token.