Claude Code bundled skills — /batch and /simplify prompts extracted from binary (v2.1.87)

batch-command.md

Claude Code /batch Command — Extracted from Binary

Source: /home/oruc/.local/share/claude/versions/2.1.87 (compiled ELF, JS bundle embedded) Extracted: 2026-03-29

---

Command Registration

{
  name: "batch",
  description: "Research and plan a large-scale change, then execute it in parallel across 5-30 isolated worktree agents that each open a PR.",
  whenToUse: "Use when the user wants to make a sweeping, mechanical change across many files (migrations, refactors, bulk renames) that can be decomposed into independent parallel units.",
  argumentHint: "<instruction>",
  userInvocable: true,
  disableModelInvocation: true  // only user can invoke, model cannot
}

Usage Examples (shown when no argument provided)

Provide an instruction describing the batch change you want to make.
Examples:
  /batch migrate from react to vue
  /batch replace all uses of lodash with native equivalents
  /batch add type annotations to all untyped function parameters

Not-a-git-repo Message

This is not a git repository. The /batch command requires a git repo because it spawns agents in isolated git worktrees and creates PRs from each. Initialize a repo first, or run this from inside an existing one.

---

Full Orchestration Prompt

# Batch: Parallel Work Orchestration
You are orchestrating a large, parallelizable change across this codebase.

## User Instruction
<the user's instruction is inserted here>

## Phase 1: Research and Plan (Plan Mode)
Call the `EnterPlanMode` tool now to enter plan mode, then:

1. **Understand the scope.** Launch one or more subagents (in the foreground -- you need
   their results) to deeply research what this instruction touches. Find all the files,
   patterns, and call sites that need to change. Understand the existing conventions so
   the migration is consistent.

2. **Decompose into independent units.** Break the work into 5-30 self-contained units.
   Each unit must:
   - Be independently implementable in an isolated git worktree (no shared state with
     sibling units)
   - Be mergeable on its own without depending on another unit's PR landing first
   - Be roughly uniform in size (split large units, merge trivial ones)

   Scale the count to the actual work: few files -> closer to 5; hundreds of files ->
   closer to 30. Prefer per-directory or per-module slicing over arbitrary file lists.

3. **Determine the e2e test recipe.** Figure out how a worker can verify its change
   actually works end-to-end -- not just that unit tests pass. Look for:
   - A `claude-in-chrome` skill or browser-automation tool (for UI changes: click through
     the affected flow, screenshot the result)
   - A `tmux` or CLI-verifier skill (for CLI changes: launch the app interactively,
     exercise the changed behavior)
   - A dev-server + curl pattern (for API changes: start the server, hit the affected
     endpoints)
   - An existing e2e/integration test suite the worker can run

   If you cannot find a concrete e2e path, use the `AskUserQuestion` tool to ask the user
   how to verify this change end-to-end. Offer 2-3 specific options based on what you
   found (e.g., "Screenshot via chrome extension", "Run `bun run dev` and curl the
   endpoint", "No e2e -- unit tests are sufficient"). Do not skip this -- the workers
   cannot ask the user themselves.

   Write the recipe as a short, concrete set of steps that a worker can execute
   autonomously. Include any setup (start a dev server, build first) and the exact
   command/interaction to verify.

4. **Write the plan.** In your plan file, include:
   - A summary of what you found during research
   - A numbered list of work units -- for each: a short title, the list of
     files/directories it covers, and a one-line description of the change
   - The e2e test recipe (or "skip e2e because ..." if the user chose that)
   - The exact worker instructions you will give each agent (the shared template)

5. Call `ExitPlanMode` to present the plan for approval.

## Phase 2: Spawn Workers (After Plan Approval)
Once the plan is approved, spawn one background agent per work unit using the `Agent`
tool. **All agents must use `isolation: "worktree"` and `run_in_background: true`.**
Launch them all in a single message block so they run in parallel.

For each agent, the prompt must be fully self-contained. Include:
- The overall goal (the user's instruction)
- This unit's specific task (title, file list, change description -- copied verbatim
  from your plan)
- Any codebase conventions you discovered that the worker needs to follow
- The e2e test recipe from your plan (or "skip e2e because ...")
- The worker instructions below, copied verbatim:

<worker instructions - see below>

Use `subagent_type: "general-purpose"` unless a more specific agent type fits.

## Phase 3: Track Progress
After launching all workers, render an initial status table:

| # | Unit | Status | PR |
|---|------|--------|----|
| 1 | <title> | running | -- |
| 2 | <title> | running | -- |

As background-agent completion notifications arrive, parse the `PR: <url>` line from
each agent's result and re-render the table with updated status (`done` / `failed`) and
PR links. Keep a brief failure note for any agent that did not produce a PR.

When all agents have reported, render the final table and a one-line summary
(e.g., "22/24 units landed as PRs").

---

Worker Instructions (appended to each spawned agent's prompt)

After you finish implementing the change:
1. **Simplify** -- Invoke the `Skill` tool with `skill: "simplify"` to review and clean
   up your changes.
2. **Run unit tests** -- Run the project's test suite (check for package.json scripts,
   Makefile targets, or common commands like `npm test`, `bun test`, `pytest`, `go test`).
   If tests fail, fix them.
3. **Test end-to-end** -- Follow the e2e test recipe from the coordinator's prompt
   (below). If the recipe says to skip e2e for this unit, skip it.
4. **Commit and push** -- Commit all changes with a clear message, push the branch, and
   create a PR with `gh pr create`. Use a descriptive title. If `gh` is not available or
   the push fails, note it in your final message.
5. **Report** -- End with a single line: `PR: <url>` so the coordinator can track it. If
   no PR was created, end with `PR: none -- <reason>`.

---

Key Design Details

Aspect	Value
Min work units	5
Max work units	30
Isolation	worktree (git worktree per agent)
Execution	run_in_background: true (all launched in parallel)
Agent tool	Agent with subagent_type: "general-purpose"
Plan mode	Uses EnterPlanMode / ExitPlanMode tools for approval gate
User clarification	Uses AskUserQuestion tool for e2e test recipe decisions
Post-implementation	Each worker runs /simplify skill, tests, then gh pr create
Progress tracking	Markdown status table re-rendered as workers complete

Architecture Summary

One coordinator agent plans and decomposes, then fans out to N worktree-isolated background agents that each independently implement, test, and PR their slice. The coordinator tracks completion via background-agent notifications and renders a summary table.

simplify-command.md

Claude Code /simplify Command — Extracted from Binary

Source: /home/oruc/.local/share/claude/versions/2.1.87 (compiled ELF, JS bundle embedded) Extracted: 2026-03-29

---

Command Registration

{
  name: "simplify",
  description: "Review changed code for reuse, quality, and efficiency, then fix any issues found.",
  userInvocable: true,
  // No disableModelInvocation — defaults to false
  // No whenToUse — model won't auto-invoke without it
  // No argumentHint — no placeholder shown
  // No allowedTools — inherits full tool access
  // No context/agent — runs inline (not forked)
  // Arguments are optional — appended as "## Additional Focus\n<text>" if provided
}

Usage

/simplify                          # review all changed files
/simplify focus on memory efficiency   # review with specific focus

---

Full Orchestration Prompt

# Simplify: Code Review and Cleanup

Review all changed files for reuse, quality, and efficiency. Fix any issues found.

## Phase 1: Identify Changes

Run `git diff` (or `git diff HEAD` if there are staged changes) to see what changed.
If there are no git changes, review the most recently modified files that the user
mentioned or that you edited earlier in this conversation.

## Phase 2: Launch Three Review Agents in Parallel

Use the Agent tool to launch all three agents concurrently in a single message.
Pass each agent the full diff so it has the complete context.

### Agent 1: Code Reuse Review

For each change:
1. **Search for existing utilities and helpers** that could replace newly written code.
   Look for similar patterns elsewhere in the codebase -- common locations are utility
   directories, shared modules, and files adjacent to the changed ones.
2. **Flag any new function that duplicates existing functionality.** Suggest the
   existing function to use instead.
3. **Flag any inline logic that could use an existing utility** -- hand-rolled string
   manipulation, manual path handling, custom environment checks, ad-hoc type guards,
   and similar patterns are common candidates.

### Agent 2: Code Quality Review

Review the same changes for hacky patterns:
1. **Redundant state**: state that duplicates existing state, cached values that could
   be derived, observers/effects that could be direct calls
2. **Parameter sprawl**: adding new parameters to a function instead of generalizing
   or restructuring existing ones
3. **Copy-paste with slight variation**: near-duplicate code blocks that should be
   unified with a shared abstraction
4. **Leaky abstractions**: exposing internal details that should be encapsulated,
   or breaking existing abstraction boundaries
5. **Stringly-typed code**: using raw strings where constants, enums (string unions),
   or branded types already exist in the codebase
6. **Unnecessary JSX nesting**: wrapper Boxes/elements that add no layout value --
   check if inner component props (flexShrink, alignItems, etc.) already provide
   the needed behavior
7. **Unnecessary comments**: comments explaining WHAT the code does (well-named
   identifiers already do that), narrating the change, or referencing the task/caller
   -- delete; keep only non-obvious WHY (hidden constraints, subtle invariants,
   workarounds)

### Agent 3: Efficiency Review

Review the same changes for efficiency:
1. **Unnecessary work**: redundant computations, repeated file reads, duplicate
   network/API calls, N+1 patterns
2. **Missed concurrency**: independent operations run sequentially when they could
   run in parallel
3. **Hot-path bloat**: new blocking work added to startup or per-request/per-render
   hot paths
4. **Recurring no-op updates**: state/store updates inside polling loops, intervals,
   or event handlers that fire unconditionally -- add a change-detection guard so
   downstream consumers aren't notified when nothing changed. Also: if a wrapper
   function takes an updater/reducer callback, verify it honors same-reference
   returns (or whatever the "no change" signal is) -- otherwise callers' early-return
   no-ops are silently defeated
5. **Unnecessary existence checks**: pre-checking file/resource existence before
   operating (TOCTOU anti-pattern) -- operate directly and handle the error
6. **Memory**: unbounded data structures, missing cleanup, event listener leaks
7. **Overly broad operations**: reading entire files when only a portion is needed,
   loading all items when filtering for one

## Phase 3: Fix Issues

Wait for all three agents to complete. Aggregate their findings and fix each issue
directly. If a finding is a false positive or not worth addressing, note it and move
on -- do not argue with the finding, just skip it.

When done, briefly summarize what was fixed (or confirm the code was already clean).

---

Architecture Summary

Aspect	Value
Phases	3: Identify changes → Fan out 3 parallel agents → Aggregate & fix
Agent 1	Code Reuse — searches for existing utilities, flags duplicates
Agent 2	Code Quality — 7-point checklist (redundant state, parameter sprawl, copy-paste, leaky abstractions, stringly-typed, unnecessary JSX nesting, unnecessary comments)
Agent 3	Efficiency — 7-point checklist (unnecessary work, missed concurrency, hot-path bloat, no-op updates, TOCTOU, memory leaks, overly broad operations)
Execution	All 3 agents launched concurrently in a single message
Input	Full git diff passed to each agent
Fix strategy	Aggregates findings, fixes directly, skips false positives without argument
Optional focus	/simplify <text> appends ## Additional Focus section
Cross-reference	/batch workers invoke /simplify as step 1 post-implementation