Sysclaw Ops

SysClaw operator skill for processing agent requests and managing the cross-agent communication system. Use when SysClaw needs to check for pending agent req...

Do not enable this skill in production until you confirm the missing pieces and harden privileges. Specific checks: (1) Ask the publisher why registry metadata declares no required env vars while SKILL.md requires DB creds and a Telegram token. (2) Require a dedicated DB role with the minimal GRANTS listed, verify those grants in your DB, and ensure the role cannot run arbitrary SQL beyond the intended updates. (3) Confirm how SSH/command execution is performed — prefer ephemeral jump-host sessions or human-approved runbooks rather than automatic execution based on DB payloads. (4) Require OpenClaw cron job creation to be approved by an operator and limit its session capabilities. (5) Verify secure storage/rotation of the Telegram token and that escalations require human approval for high-risk actions. (6) Ask for the concrete implementation (code or agent session policy) to audit parameterized queries, input validation (avoid executing commands derived from untrusted payloads), and logging/immutable audit trails. The presence of leftover 'virus' strings and metadata mismatches is a quality signal — request publisher clarification before trusting the skill.

Type: OpenClaw Skill Name: sysclaw-ops Version: 1.6.2 The sysclaw-ops skill implements a centralized management system where an agent processes requests to execute high-privilege actions, such as SSH commands and software deployments, across a network. This architecture is inherently risky as it creates a single point of failure for remote code execution and lateral movement. Notably, references/db-schema.md and CHANGELOG.md reveal the use of 'virus' as a synonym for the human operator; the fact that these references remain in the schema despite changelog claims of their removal suggests either deceptive documentation or significant oversight in a high-privilege tool.