Openclaw Skills
PendingStatic analysis audit pending.
Overview
No static analysis result has been recorded yet. Pattern checks will appear here once the artifact has been analyzed.
Findings (0)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A user expecting only process templates may install or expose a large bundle of unrelated code with powerful capabilities.
The artifact is presented as an instruction-only agent-team kit, but it ships many unrelated executable subtrees and sensitive-integration-looking helpers from an unknown source. That mismatch is a supply-chain/provenance concern even without proof that those files auto-run.
Source: unknown ... No install spec — this is an instruction-only skill ... Code file presence 89 code file(s): desktop-control-1.0.0/__init__.py ... gmail-oauth-1.0.0/scripts/gmail-auth.sh ... mcp-ssh-manager-0.1.1/scripts/... openclaw-multi-brain-1.0.0/daemon/install.sh ... vercel-deploy-1.0.0/scripts/vercel_deploy.sh
Split unrelated skills into separate packages, disclose all bundled capabilities, provide provenance/homepage information, and remove code that is not needed for the stated team-process purpose.
Agents could continue creating, selecting, and executing work while the user is not watching.
The skill explicitly instructs recurring autonomous operation and agent spawning without default human approval or clearly bounded authority.
Proactive operation — The team runs itself via heartbeat ... If it's in Ready, any agent can pick it up. No approval needed. ... Team Health (run hourly) ... Spawn Scout ... The heartbeat keeps the loop spinning even when the human isn't watching.
Add explicit user approval gates for new work, define allowed task types, set stop conditions, and make heartbeat operation opt-in with clear pause/disable instructions.
If loaded or invoked, the agent could operate the user's desktop, interact with active apps, and potentially expose sensitive typed content in logs.
The bundled desktop-control code can click, type, and capture screen state, defaults to no per-action approval, and logs typed text. This is a powerful local mutation capability that is not aligned with the top-level team-process purpose.
def __init__(self, failsafe: bool = True, require_approval: bool = False) ... pyautogui.PAUSE = 0 ... def click ... pyautogui.click(...) ... def type_text ... pyautogui.write(text, interval=interval) ... logger.info(f"Typed text: '{text[:50]}Do not bundle desktop automation with this process skill; if offered separately, require explicit opt-in, per-action approval for high-impact actions, and avoid logging typed user content.
A bad or untrusted queue entry could be reused as authoritative context and cause agents to execute unwanted work.
The shared Markdown process files become persistent operational memory that agents are told to trust for task selection, but the artifacts do not define writer trust, validation, or provenance controls.
OPPORTUNITIES.md — Raw discoveries (anyone adds) ... BACKLOG.md — Triaged work queue ... STATUS.md — Who's working on what ... If it's in Ready, any agent can pick it up. No approval needed.
Restrict who can edit process files, record task provenance, require review before Ready status, and instruct agents to treat queue content as untrusted until validated.
Users and agents may over-trust the workflow and skip oversight for tasks that should require approval.
The wording discourages permission checks and asks the user to trust an autonomous workflow, without equally prominent safety limits or review requirements.
❌ Waiting for permission to pick up work → Ready = fair game ... *The system runs itself. Your job is to trust it.*
Reword the guidance to emphasize user control, review for high-impact actions, and clear escalation rules instead of blanket trust.