command-development

The entire skill is dedicated to teaching how to create slash commands, which inherently involve executing shell commands. The [BANG] syntax is explicitly described for pre-executing bash commands to gather context. Numerous examples across SKILL.md, examples/plugin-commands.md, examples/simple-commands.md, references/advanced-workflows.md, references/marketplace-considerations.md, references/plugin-features-reference.md, and references/plugin-integration.md demonstrate the use of various system commands (git, npm, node, bash, kubectl, gh, test, echo, cat, grep, sed, awk, cut, tr, mktemp, rm, mv, find, wc, dd, ps, watch, chmod, head, tail, python, uname, pbcopy, xclip, clip.exe, command -v, date, exit, false, yes).

COMMAND_EXECUTION (HIGH): The allowed-tools frontmatter field is frequently set to Bash(*) in examples. The references/frontmatter-reference.md explicitly warns that Bash(*) is "not recommended" and "very permissive." This permissive setting allows arbitrary command execution, posing a significant security risk if a skill developer were to implement it without proper sanitization or restriction. The validation scripts (scripts/check-frontmatter.sh, scripts/validate-command.sh) themselves are bash scripts that perform various system commands for their intended purpose of validating other files.

**DATA_EXFILTRATION (LOW

• Potential):** While no direct data exfiltration to external domains is demonstrated, the extensive use of cat, grep, and read on local files like package.json, config.json, version.txt, and plugin-internal files (via ${CLAUDE_PLUGIN_ROOT}) creates a potential vector. If a malicious command were to combine these file-reading capabilities with network operations (e.g., curl to an attacker-controlled server), sensitive local data could be exfiltrated. The documentation does not explicitly warn against this combination, though it does discuss allowed-tools for Bash.

**PERSISTENCE (LOW

• Expected Behavior):** The documentation describes patterns for writing state to local files within the .claude/ directory (e.g., .claude/deployment-state.local.md, .claude/feature-complete.flag, .claude/command-initialized, .claude/operation-completed.flag, .claude/plugin-name.local.md). This is a legitimate mechanism for managing agent-specific state and is not considered a malicious persistence mechanism in the traditional sense (e.g., modifying ~/.bashrc or crontab).

UNVERIFIABLE_DEPENDENCY (INFO): The documentation mentions npm install, pip install, yarn add as patterns to detect, but the examples provided do not directly execute these commands. They refer to scripts within the plugin (${CLAUDE_PLUGIN_ROOT}/scripts/script.js) or already installed tools (npm test). The CLAUDE_PLUGIN_ROOT variable ensures references are to local plugin files, not external downloads at runtime.

Recommendation: Skill developers using this guidance should be extremely cautious with allowed-tools: Bash(*), preferring more restrictive patterns like Bash(git:*) or Bash(node:*) where possible. All inputs to commands that use Bash should be thoroughly sanitized to prevent command injection. The documentation could be enhanced with explicit warnings about the risks of combining file-reading with network operations when Bash(*) is enabled.