Dependency Guard#

Use this skill when dependency changes are in scope for npm, pnpm, yarn, Python packages, or other package ecosystems supported by Socket.

Prerequisites#

• The socket CLI must be installed and on PATH ( npm install -g socket).
• Authentication is required for CLI-based reviews. See the Authentication section below.

Workflow#

1. Confirm the exact dependency change being proposed.

2. Check whether the feature can be implemented with the standard library or an existing project dependency.

3. Prefer MCP depscore if the host agent exposes it.

4. Otherwise run scripts/check_dependency.sh <ecosystem> <package> [version].

5. Apply the policy in references/policy.md.

6. Apply the decision rules in references/decision-matrix.md.

7. Before making the change, report:

   • why the package is needed
   • whether an existing alternative exists
   • what Socket reported
   • whether install scripts, risky capabilities, or transitive risk are present

8. If the decision is allow_with_warning, present the warning clearly before making the change. If the decision is block_pending_human_review or block, stop and propose either:

   • a safer dependency
   • a no-dependency implementation
   • explicit human review

Authentication#

Three authentication paths are supported, in order of preference:

1. MCP depscore — no local credentials needed; works through the host agent's MCP connection.

2. socket login — interactive CLI login; stores auth locally.

   • If your CLI supports it, pressing Enter at the token prompt uses limited public access.
   • To use a private token, paste it at the prompt instead.

3. SOCKET_SECURITY_API_TOKEN env var — set this for CI or headless environments.

Security: Never paste private tokens into agent prompts. Use the env var or socket login instead.

CI note: GitHub Actions workflows use SOCKET_SECURITY_API_KEY (a separate GitHub-integration key), not SOCKET_SECURITY_API_TOKEN. See examples/github/dependency-guard.yml.

Reporting Contract#

Use the short response template in references/examples.md when presenting the package review to the user.

References#

• Read references/policy.md for the canonical guardrail.
• Read references/decision-matrix.md for allow/block criteria.
• Read references/examples.md for user-facing review examples.

Notes#

• Keep SKILL.md lean; do not duplicate the full policy here.
• OpenClaw and ClawHub expect metadata to be a single-line JSON object in frontmatter, so keep the OpenClaw metadata compact.
• The version field in frontmatter is the single source of truth; use publish_clawhub.sh --bump patch|minor|major to auto-increment.
• Do not assume system-wide wrapper enforcement or shell-completion setup is desirable; keep CLI setup minimal.
• If Socket tooling is unavailable, require human review before adding the dependency.
• Review manifest and lockfile changes together.