agentleFS
amirkiarafieiamirkiarafiei/subagent-cli-skills/skills/claude-code/SKILL.md

claude-code

Skill14 starsChanged 10 days agoMITView on GitHub

Use Claude Code CLI as a subagent. Lets the main agent prompt Claude Code CLI from the terminal in headless mode with the `claude` command, and send the goal, the decisions and the scope with the task. Use when the user asks to delegate work to Claude Code CLI, when a task needs a second independent agent, or when a plan needs a fresh perspective.

  • Pipes a download into a shell
  • Reads credentials
  • Installs packages

51 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use Problem-Solving Techniques, minecraft-modpack-server and 9 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • truongtv22Skill

    Problem-Solving Techniques

    Apply systematic problem-solving techniques for complexity spirals (simplification cascades), innovation blocks (collision-zone thinking), recurring patterns (meta-pattern recognition), assumption constraints (inversion exercise), scale uncertainty (scale game), and dispatch when stuck. Techniques derived from Microsoft Amplifier project patterns adapted for immediate application.

    Also in 4 projects that use this

  • math-incSkill

    minecraft-modpack-server

    Set up a modded Minecraft server from a CurseForge/Modrinth server pack zip. Covers NeoForge/Forge install, Java version, JVM tuning, firewall, LAN config, backups, and launch scripts.

    Also in 4 projects that use this

  • math-incSkill

    pokemon-player

    Play Pokemon games autonomously via headless emulation. Starts a game server, reads structured game state from RAM, makes strategic decisions, and sends button inputs — all from the terminal.

    Also in 4 projects that use this

  • truongtv22Skill

    mobile-development

    Build modern mobile applications with React Native, Flutter, Swift/SwiftUI, and Kotlin/Jetpack Compose. Covers mobile-first design principles, performance optimization (battery, memory, network), offline-first architecture, platform-specific guidelines (iOS HIG, Material Design), testing strategies, security best practices, accessibility, app store deployment, and mobile development mindset. Use when building mobile apps, implementing mobile UX patterns, optimizing for mobile constraints, or making native vs cross-platform decisions.

    Also in 4 projects that use this

  • aivrarSkill

    grounded-citations

    Ground answers and documents in cited, verifiable sources.

    Also in 4 projects that use this

  • aivrarSkill

    sdlc-review

    Review Kanban handoffs and route verified outcomes.

    Also in 3 projects that use this

  • +4 more from math-inc

The file

We split this skill into the rules it gives an agent

11 rules. 0 are common, 10 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 43 edited versions we read keep these.

  • 10

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Secrets or policy-sensitive work: Do not pipe credentials into a subagent.

    line 48
  2. Distinctive:

    Low return on investment: If writing the handoff costs more than doing the edit, do the edit.

    line 50
  3. Distinctive:

    Treat every call as stateless delegation: the subagent keeps nothing between calls, so each command must carry its own state.

    line 61
  4. Distinctive:

    Write the prompt as a transfer of shared state, not as a title.

    line 71
  5. Distinctive:

    Prefer sequential delegations with explicit carry-over.

    line 82
  6. Distinctive:

    After the subagent returns:

    line 96
  7. Distinctive:

    Every vendor has its own terminal rules.

    line 104
  8. Distinctive:

    Exit code 0 is not success: If stdout is empty, treat the run as failed and read stderr.

    line 108
  9. Very specific:

    Keep all seven sub-headings, in this order, even if the answer is "none".

    line 119
  10. Distinctive:

    No CLI subcommand to list models is confirmed in the official docs.

    line 167
  11. Distinctive:

    If the user names a model, use it.

    line 174

“Common” is measured: kept by at least 6 in 10 of the 43 edited versions of this file we could read. “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

Claude Code CLI (subagent / task delegation)

<!-- ============================================================================= GLOBAL HALF — sections 1 to 5. These sections are identical in every skill in this repository. Copy them without any change. Do not put a vendor name or a flag in them. A change here must be made in all skills at the same time. ============================================================================= -->

What is it

This skill teaches your agent to use an agent from another vendor as a subagent.

Almost every coding agent has a headless mode. Headless mode runs the agent from the terminal with one command and returns the answer to stdout. This skill gives the command pattern for one such agent, and the protocol to transfer enough context with the task.

You stay the main agent. You keep the plan, the decisions and the conversation with the user. The subagent does one bounded task and reports back.

When to delegate

  • The user asks for it. The user names another agent, or asks for a second opinion.
  • Large or multi-step work. The task covers several files, phases or checkpoints.
  • Code review with a fresh mind. Another agent reviews the work with a different lens and no memory of the decisions that produced it.
  • Planning that needs different ideas. A second agent proposes options that you did not consider.
  • An internal council. Several subagents answer the same question, and you compare the answers.
  • Deep research. The other CLI has web search, web extraction or browser automation.
  • Background investigation. A long task runs in the background while you continue in the foreground.

When not to delegate

  • Small or single-step tasks. One or two edits, or a short explanation, are faster in this thread.
  • Tight feedback loops. The user wants quick back-and-forth in one conversation.
  • Secrets or policy-sensitive work. Do not pipe credentials into a subagent. Redact first.
  • Context you already hold. Repeating the whole plan in a prompt adds no value.
  • Low return on investment. If writing the handoff costs more than doing the edit, do the edit.
  • Work that needs high precision and full judgement. A subagent without your context will break a task that depends on a detail only this session knows.

Delegation and context transfer protocol

An isolated subagent saves tokens, but it splits the story. The subagent does not see this conversation. It has no memory of the goal you agreed with the user, the decisions you already made, or the paths you agreed not to touch. A poor handoff causes misread tasks, wrong assumptions about the stack or the style, and wasted edits.

Treat every call as stateless delegation: the subagent keeps nothing between calls, so each command must carry its own state. A good handoff happens when you keep these practices in mind:

  • Shared state handoff. The prompt carries the original goal, the decisions already made, and the explicit scope, to bridge the subagent's missing session history.
  • Contextual preservation. The high-volume work stays in the isolated process, so the bulk never enters this conversation and no "split story" forms from missing history.
  • Result reconciliation. What comes back is folded into this thread afterwards, so there is a single source of truth.

Write the prompt as a transfer of shared state, not as a title. Include all six fields:

IncludeWhy
GoalThe same objective as the user, not only the immediate micro-task.
DecisionsFramework, patterns, naming, "use X not Y" — anything that would otherwise be guessed wrong.
ScopeThe absolute paths and modules to touch, and the areas to leave alone. A relative path may not resolve where you expect.
ConstraintsPerformance, accessibility, compatibility, review gates, "no new dependencies".
VerificationThe exact command the subagent must run and pass before it returns.
OutputFor example: "report only, no edits", "apply edits with a minimal diff", "list the files changed".

Prefer sequential delegations with explicit carry-over. Parallel runs diverge unless every run gets the same briefing.

Run the subagent in the mode that does the work without asking for approval. Headless mode has nobody to answer a permission prompt. Any mode that stops to ask will stall, or return an empty answer with a success exit code. Each CLI names this mode differently — take the flag from the vendor card below.

Never call a subagent in plan mode. Many CLIs have a plan or read-only mode. That mode makes the other agent write a plan for itself, which is not what you asked for: you want its work or its answer, and you keep the planning. Plan mode also waits for someone to approve that plan, so the run comes back with nothing. If you want no file changes, keep the auto-approving mode and write "report only, no edits" in the Output field. Do not use plan mode to make a run read-only.

After the subagent returns:

  • Report to the user. Give a short summary. Do not paste long logs unless the user asks.
  • Reconcile the context. Record the decisions it made, the files it changed, and the open risks, so this session stays the single source of truth.

CLI failure modes

Every vendor has its own terminal rules. A headless run fails quietly more often than it fails loudly.

  • Wrap the call in an external timeout. A headless CLI can stall before its own timeout starts.
  • Exit code 0 is not success. If stdout is empty, treat the run as failed and read stderr. A permission the CLI could not ask for, and a prompt that never arrived, both look like success.
  • Never carry a flag habit from one CLI to another. The same short flag means different things in different tools. In OpenCode, -p is --password: passing a prompt to it empties the message and the run waits on stdin forever. Confirm every flag against the CLI's own --help.
  • An unrecognized-flag error means this skill is stale, not that the task is impossible. Read --help, continue with the flags that exist, and tell the user which line in this file is wrong.
<!-- ============================================================================= VENDOR HALF — section 6. Everything below is specific to this CLI. Keep all seven sub-headings, in this order, even if the answer is "none". Take every flag from the installed binary (`<cli> --help`), not from memory and not from another skill in this repository. ============================================================================= -->

Vendor card

Binary and prompt form

  • Binary: claude
  • Install: curl -fsSL https://claude.ai/install.sh | bash (macOS, Linux, WSL). The npm package also works: npm install -g @anthropic-ai/claude-code.
  • Prompt form: positional (or stdin). -p / --print is a mode flag that switches the CLI to non-interactive "print and exit" behavior — it does not itself carry the prompt text. The prompt is the plain string that follows on the command line, e.g. claude -p "prompt text", or it can be piped over stdin. A bare claude with no -p opens the interactive TUI and never returns.

Headless and output flags

NeedFlag
Run once and exit-p, --print
Minimal startup (skips hooks, LSP, plugin sync, auto-memory, keychain, CLAUDE.md auto-discovery)--bare
Output format--output-format text (default), json, or stream-json
Cap agentic turns--max-turns <n> (hidden from --help but accepted; the 2.1.318 binary defines it)
Scope tool grants without a full bypass--allowedTools "Bash,Read,Edit", --disallowedTools

--bare changes auth: Anthropic auth becomes strictly ANTHROPIC_API_KEY or apiKeyHelper via --settings — OAuth/keychain are never read, so a subscription-authenticated run fails under --bare. Bedrock/Vertex/Foundry auth is unaffected. Since CLAUDE.md is not loaded under --bare, pass context explicitly via --add-dir, --system-prompt, --settings, --agents.

Approvals and permissions

  • --permission-mode accepts acceptEdits, auto, bypassPermissions, manual, dontAsk or plan. default is not a valid value in 2.1.318. --permission-mode auto runs unattended with a classifier-backed safety check. --permission-mode bypassPermissions is equivalent to --dangerously-skip-permissions and bypasses every confirmation.
  • What happens with nobody to answer: in a -p run with no permission host attached, requests that would prompt are denied by default — there is nothing to stall on. If you do attach a permission host (an Agent SDK canUseTool callback, or an MCP tool via --permission-prompt-tool), that host is consulted and the run waits on it unless you also pass --permission-prompts none (Claude Code v2.1.259+), which denies anything that would prompt instead of waiting, and tells Claude not to retry. With --output-format stream-json, each denial appears as a permission_denied system message.

Models and how to list them

No CLI subcommand to list models is confirmed in the official docs. Anthropic ships short family aliases (fast/cheap, balanced-default, flagship, and a highest-capability tier, plus long-context variants) that resolve to the current generation and a default value that clears any override — prefer an alias over a dated snapshot ID so a pinned command doesn't go stale. Select with --model <alias-or-id>; switch mid-session with the /model slash command. Note: which model an alias resolves to can differ by provider (direct API vs. Bedrock vs. Vertex vs. Foundry).

If the user names a model, use it. Otherwise consult Artificial Analysis and the model-configuration docs below for current alias behavior before picking one.

Command pattern

claude -p "GOAL: [goal] | DECISIONS: [decisions] | SCOPE: [paths] | CONSTRAINTS: [constraints] | VERIFICATION: [test_command] | OUTPUT: [format]" \
  --permission-mode auto --model <alias-or-id> 2>&1

Prompt examples

  • Implement: claude -p "GOAL: [goal] | DECISIONS: [decisions] | SCOPE: [paths] | VERIFICATION: [test_command] | OUTPUT: files changed" --permission-mode auto
  • Review: claude -p "GOAL: Review [scope] for [concerns] | CONSTRAINTS: report only, no edits | OUTPUT: findings with severity" --permission-mode auto
  • Investigate: claude -p "GOAL: Map how [feature] works | SCOPE: [paths] | CONSTRAINTS: report only, no edits | OUTPUT: file:line map" --permission-mode auto

Docs and reference

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.