S2G - General Purpose Workflow Engine

The name/description match the code: it is a WebSocket bridge that discovers S2G workflow nodes and exposes them as local tools. However the included docs and reference material also show REST management operations (X-API-Key examples) and many node types (databases, cloud connectors, Knowledge Base, AI providers). While these capabilities are consistent with an S2G bridge, they mean the agent will be able to trigger workflow nodes that can access external systems and potentially sensitive data — this is expected functionally but elevates risk and should be intentionally limited in workflows.

SKILL.md instructs the agent / operator to copy and run a local Node.js bridge which: (a) maintains an outbound WSS connection to s2g.run and auto-discovers nodes; (b) accepts pushed data from workflows (Input Forwarding), which can contain arbitrary upstream data; and (c) exposes a local HTTP API that allows executing arbitrary nodes by name or ID. The docs also include examples that encourage reading local credential files (e.g., ~/.config/s2g/credentials.json) for X-API-Key use. These instructions do not ask for unrelated system credentials, but they explicitly enable workflows to push data into the agent and to run nodes that may perform DB queries, cloud access, or file operations — all of which can surface sensitive data. Additionally, the bridge logs incoming messages, which may persist sensitive payloads.

There is no remote download/install: the skill is instruction-only and bundles the bridge script. Installation steps are local (copy script, npm install ws). This is low-to-moderate risk from an install perspective because nothing is fetched from an untrusted URL in the install spec; the only external install is the standard 'ws' npm module.

The skill declares no required env vars but supports optional S2G_SECRET, S2G_NODE_ID, S2G_WS_HOST and allows S2G API usage elsewhere in docs (X-API-Key). The reference docs include snippets that read a local credentials file, which could encourage access to user secrets not required by the bridge runtime. Requested environment access (node id, optional secret) is proportionate to the bridge function, but the broader documentation implicitly expects API keys for REST management — review and limit where those keys live and who/what can read them.

The skill does not force 'always: true'; it runs on demand. However the documentation explicitly recommends running the bridge as a long-lived service (systemd/pm2/nohup), which gives it persistent presence and automatic reconnection. Persistent autostart is normal for a bridge, but combined with the local HTTP API and the potential to expose many powerful remote nodes, persistence increases the blast radius if misconfigured or if local network access is not restricted.