Situation Monitor

Triages Discord activity and Kubernetes incidents into ranked situation reports with fixture-first demos, live Discord and Apify intake, Contextual-grounded...

Security Scan

The repo and SKILL instructions clearly need several sensitive environment variables, additional system binaries (node, kubectl, gcloud), and can run destructive cluster commands, but the published skill metadata declares none of that — the mismatch is suspicious and worth human review before installation.

Purpose & Capability

The skill claims to triage Discord and Kubernetes incidents (reasonable), but the bundle actually contains both a Python OpenClaw skill and a Node.js Apify actor, plus a cluster incident trigger script (02-incidents.sh) that runs kubectl and gcloud. The registry metadata only lists bash and python3 as required binaries and declares no env vars, yet the README and docs require many sensitive env vars (REDIS_URL, FRIENDLI_TOKEN, APIFY_TOKEN, APIFY_ACTOR_ID, CONTEXTUAL_API_KEY, CONTEXTUAL_AGENT_ID, KUBECONFIG, DISCORD_BOT_TOKEN, etc.) and Node. That discrepancy is not proportionate to the published requirements.

Instruction Scope

SKILL.md and the README instruct the operator/agent to run scripts/mts (bootstraps a Python venv and installs the package), run npm install/node main.js for the Apify actor, upload runbooks to Contextual, and optionally run 02-incidents.sh which intentionally injects failures (OOM, bad image) and can delete a GKE cluster. These instructions reference reading local files (KUBECONFIG, runbooks), calling external services (Apify, GCP, GitHub, FriendliAI, Contextual, Discord), and performing destructive cluster operations — all outside what the registry metadata indicated.

Install Mechanism

No formal install spec is published for OpenClaw, yet the repo expects two installation flows: Python package install (handled by scripts/mts) and an npm install for the Apify actor. The metadata didn't declare Node/npm as required, and there's no automated, vetted install step for the Node actor. The lack of a clear, whitelisted install mechanism for the Node actor and its many npm deps increases operational risk.

Credentials

The code and docs require multiple sensitive credentials and config paths (API tokens for Apify, Friendli, Contextual, Discord bot token, REDIS_URL, and KUBECONFIG) and expect cluster admin actions via kubectl/gcloud. None of these are declared in the skill's registry metadata. Requesting KUBECONFIG and running kubectl/gcloud is high-privilege and must be explicit; the current omission is disproportionate and risky.

Persistence & Privilege

The skill is not marked always:true, but it contains scripts capable of destructive actions (applying deployments that cause OOMs, rolling back, and a destroy command that deletes a GKE cluster). Those actions are part of the demo but could be executed if the agent or an operator runs the script against a real cluster. The skill does not declare or limit required privileges (e.g., recommends 'hackathon-only' cluster but does not enforce it).

What to consider before installing

Before installing or enabling this skill: - Treat it as high-risk until the maintainer clarifies requirements. The published metadata lists only bash and python3, but the repo and docs also require node/npm, kubectl, gcloud, and many sensitive API tokens (Apify, Friendli, Contextual, Redis, Discord). Ask the author to update SKILL metadata to list all required binaries, env vars, and config paths. - Do NOT run demo trigger commands (02-incidents.sh trigger* or destroy) against any real/production cluster. Those scripts intentionally inject failures and can delete a GKE cluster. - If you need to evaluate safely, run the skill in an isolated environment: a disposable hackathon-only cluster and a sandboxed gateway with least-privilege service accounts (KUBECONFIG referencing a limited-access account), and network egress controlled for third-party tokens. - Ensure a formal install step is added (or follow author instructions) that documents npm install for the Apify actor and Python venv creation so dependencies are reproducible and auditable. - Verify who will have access to the listed tokens and whether the OpenClaw host will store them securely; treat REDIS_URL, FRIENDLI_TOKEN, APIFY_TOKEN, CONTEXTUAL_API_KEY, and DISCORD_BOT_TOKEN as sensitive secrets. - If the skill will run in a hosted OpenClaw instance, require an admin review and a configuration checklist: (1) KUBECONFIG points to a non-production, limited account; (2) Node/npm are installed in a controlled environment; (3) required env vars are added intentionally; (4) destructive demo commands are disabled or removed. If the author provides corrected metadata (declare all env vars and binaries), an explicit non-destructive default config, and an install spec for Node, this assessment could move toward 'benign'.

Use this skill when the user wants to catch up on Discord traffic, monitor a few noisy channels, triage Kubernetes incidents, produce a digest, or draft a safe follow-up.

Use the helper wrapper at scripts/mts for all commands. It bootstraps .venv and installs the package on first run, which makes hosted OpenClaw installs far more reliable than calling python3 -m monitoring_the_situation.cli directly.

Guardrails

• Never use a user token or self-bot. Live mode requires a Discord bot token.
• Prefer fixture mode when a live Discord bot is not configured yet.
• Do not ingest personal or private account history for demos.
• Prefer public status pages, public incident feeds, and synthetic cluster incidents for KubeWatch unless the user explicitly provides other sources.
• Treat outbound posting as sensitive. Drafts are allowed; sending stays blocked until Civic approval is configured.

Working modes

1. Discord fixture mode for a safe demo:

bash scripts/mts fixture \
  --input examples/demo_messages.json \
  --save-path .local/demo_report.md

2. Live Discord snapshot mode after bot setup:

bash scripts/mts discord-fetch \
  --hours 24 \
  --limit-per-channel 75 \
  --save-path .local/live_report.md

3. Draft a reply for a specific report item:

bash scripts/mts draft-reply \
  --bucket urgent \
  --channel api-alerts

4. KubeWatch fixture mode for the SRE lane:

bash scripts/mts kubewatch-fixture \
  --input examples/kubewatch_incidents.json \
  --save-path .local/kubewatch_report.md

5. KubeWatch live intake from Apify after sponsor setup:

bash scripts/mts kubewatch-apify \
  --actor-id "$APIFY_ACTOR_ID" \
  --actor-input examples/apify_actor_input.json \
  --save-path .local/kubewatch_live_report.md

6. KubeWatch live cluster scan against the demo namespace:

bash scripts/mts kubewatch-cluster \
  --namespace production \
  --save-path .local/kubewatch_cluster_report.md

7. Rebuild and sanity-check the Apify actor when the repo changes:

cd /Users/sarahhatcher/Documents/monitoring-the-situation-openclaw
npm install
node main.js

The actor lives at the repo root, so Apify should stay pointed at the root with no folder override.

Expected output

Produce a report with:

• An executive summary
• Urgent threads
• Direct asks
• Decisions and deadlines
• FYI items
• Source citations by channel/message
• Incident priorities and grounded remediation steps for KubeWatch

If the user asks to send a message instead of drafting one, explain that the repo is intentionally fail-closed until Civic-backed approvals are wired.