Claude Code Headless Mode
Use this skill when the job should be executed through Claude Code itself, not solved inline. Focus on commands and workflows that match current stable Claude Code behavior.
Use this skill when the job should be executed through Claude Code itself, not solved inline. Focus on commands and workflows that match current stable Claude Code behavior.
--- name: claude-skill description: Use when work should be delegated to Claude Code CLI, especially headless `claude -p` runs, automation scripts, CI jobs, resumable sessions, or requests to use Claude/Claude Code for a task. compatibility: Requires Claude Code CLI (`claude`) installed and authenticated on the target machine. ---
Use this skill when the job should be executed through Claude Code itself, not solved inline. Focus on commands and workflows that match current stable Claude Code behavior.
Run these checks before giving advanced advice:
claude --version
claude auth status --text
claude --helpIf installation or updates look odd, use:
claude doctorUse `-p` / `--print` for non-interactive execution:
claude -p "summarize the repository architecture"Add `--output-format json` when the caller needs machine-readable output:
claude -p "review the auth layer for risks" --output-format jsonClaude Code supports these permission modes:
| Mode | Use | | --- | --- | | `default` | Interactive exploration. Prompts on first use of write/bash-style tools. | | `acceptEdits` | Recommended starting point for coding automation. Auto-accepts edits, but command execution can still prompt. | | `plan` | Analysis only. No file changes or command execution. | | `dontAsk` | Auto-denies anything not already approved by permission rules. Good for unattended-but-constrained runs. | | `bypassPermissions` | Skips prompts entirely. Only for strong sandbox / container / VM isolation. |
Important clarifications:
Do not mix these up:
Permission rules follow `Tool` or `Tool(specifier)` syntax.
Use wildcard rules when the command will include arguments:
If the local CLI help shows colon syntax such as `Bash(find:*)`, use that form on that machine. The important part is to allow an argument-aware rule rather than an exact literal command.
If the user wants Claude limited to a narrow tool family, you should usually use both `--tools` and `--allowedTools`: `--tools` defines the hard boundary, `--allowedTools` removes prompts inside that boundary.
Do not promise a fixed JSON schema unless you have validated it on the target version. Prefer wording like "returns a final result object with response text, timing, and session metadata."
These are appropriate starting points on current stable builds:
Published docs sometimes mention flags that are absent from the installed binary on a given machine. Before emitting less-common flags, verify them with `claude --help`.
claude -p "count the total lines of code in this repo, grouped by language" \
--permission-mode default \
--tools "Bash,Read" \
--allowedTools "Read" "Bash(find:*)" "Bash(wc:*)"claude -p "fix the failing login test and rerun the relevant test command" \
--permission-mode acceptEdits \
--tools "Bash,Read,Edit,Write" \
--allowedTools "Read" "Edit" "Write" "Bash(npm test *)"claude -p "review the repository for security issues and produce a concise report" \
--output-format json \
--append-system-prompt "Focus on concrete findings, exploitability, and mitigations."claude -r "$session_id" -p "continue by updating the tests and summarizing what changed"claude -c -p "continue with the next step"claude -p "investigate the API latency spike" \
--permission-mode acceptEdits \
--mcp-config monitoring-tools.json \
--allowedTools "Read" "mcp__datadog__*" "mcp__prometheus__*"Use only when the environment is already sandboxed:
claude -p "run the migration and fix the resulting type errors" \
--permission-mode bypassPermissions \
--tools "Bash,Read,Edit,Write"Pause only when one of these is materially unclear:
Otherwise, proceed and give the best current command.
When using this skill, the output should usually include: