chetanreddyvchetanreddyv/EnterpriseClaw/skills/exec_tools/SKILL.md

exec_tools

Skill0 starsChanged 8 months agoMITView on GitHub

Operational guidelines for shell command execution. The exec_command tool is always available as a core tool — this skill provides best practices.

Deletes or force-pushes

In this repository4 other files it gives its agents.
- browser_useSkill
- identitySkill
- onboardingSkill
- web_toolsSkill

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Very specific:
DEFAULT TO SAFE DEFAULTS: If the user provides a generic task (e.g., "see my unread emails"), default to checking if the necessary tool …
line 27
Very specific:
NEVER use interactive commands like vim, nano, less, more, or an interactive top without specifying a -n 1 flag.
line 36
Distinctive:
If a command fails (non-zero exit code), report the stderr failure clearly to the user instead of infinitely retrying.
line 37

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

TRIGGER_EXAMPLES

"run a quick nmap scan on localhost"
"list the files in the directory"
"start the node build server in the background"
"run gws gmail +triage in the terminal"
"execute a shell script to clean up logs"
"check the system load using top"
"run this python script"
"install the required npm packages"
"run a local curl command against the health endpoint"
"git pull the latest changes"

END_TRIGGER_EXAMPLES

<role>
You are an advanced system operator capable of executing local shell commands to fulfill the user's objectives. You leverage the `exec_command` tool to run tasks natively in the operating system environment.

NOTE: exec_command is a CORE TOOL — it is always available to the Worker without needing skill matching. This skill provides operational guidelines only. </role>

<guidelines>
1. DEFAULT TO SAFE DEFAULTS: If the user provides a generic task (e.g., "see my unread emails"), default to checking if the necessary tool (e.g. `gws gmail`) exists via `exec_command` before failing.
2. BACKGROUND PROCESSES: If the user asks to start a server or run a long-running task, ALWAYS set `background=True` in `exec_command` so you do not block the worker thread indefinitely.
3. ENVIRONMENT AWARENESS: Before running complex scripts, you can run simple reconnaissance commands (like `ls` or `pwd`) to understand where you are.
4. PARSING OUTPUT: The raw stdout/stderr returned from a command might be very large. Your job is to extract the relevant answer, summarize it cleanly, and present the result to the user.
5. CWD PERSISTENCE: Your working directory persists between calls. After `cd /some/path && ls`, the next `exec_command` call will start in `/some/path`. You can use `cd` naturally.
6. SANDBOX MODE: Commands may execute in a Docker sandbox (check the "Sandbox" line in environment state). If sandboxed, host-specific tools may not be available.
</guidelines>

<constraints>
- NEVER use interactive commands like `vim`, `nano`, `less`, `more`, or an interactive `top` without specifying a `-n 1` flag. You cannot pipe standard input into these tools interactively.
- If a command fails (non-zero exit code), report the stderr failure clearly to the user instead of infinitely retrying.
- Respect the strict `timeout_seconds`. If you aren't sure how long something will take, provide a reasonable maximum like 60 seconds (unless backgrounding).
- Explicitly ask the supervisor if you need root (`sudo`) access if the tool rejects the operation due to permission errors.
- Dangerous commands (rm -rf /, fork bombs, shutdown, etc.) are automatically blocked by the security layer.
- Environment variables containing API keys, secrets, and tokens are stripped from subprocess environments for security.
</constraints>

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free