ループエンジニアリングで一周回して /simplify で閉じる

---
name: simplify
description: Review recently changed code for reuse, simplification, efficiency, and abstraction, then apply behavior-preserving cleanups. Use after implementing a feature and before opening a PR. Do not hunt bugs.
---

# /simplify

PR に出す前の仕上げ。直近の変更だけを対象に、機能は変えず「どう書くか」を直す。

Claude Code の `/simplify`（v2.1.63 以降。v2.1.154 以降はバグ探しをしない）に相当する。

## How to use

- `/simplify`
  直近の git diff を 4 観点で並列レビューし、妥当な修正を適用する。

- `/simplify <path>`
  指定パス配下の変更だけを対象にする。

- `/simplify <extra focus>`
  4 観点に加えて、引数の観点も見る（例: `/simplify セキュリティ観点も見て`）。バグ探しには使わない。

## Hard rules

- NEVER change behavior: return values, edge cases, side effects, public APIs, serialized field names, and observable output stay the same.
- NEVER hunt correctness bugs. If a likely bug appears, record it and tell the user to run `/review-bugbot` (or Claude Code `/code-review`). Do not silently "fix" it as cleanup.
- NEVER commit, push, or open a PR unless the user explicitly asked.
- NEVER rewrite unrelated files. Stay inside the scoped diff.
- If tests exist, a cleanup that fails them is invalid. Revert that hunk.
- Skip false positives. Prefer doing nothing over a clever rewrite.

## Scope

1. Run `git status` and `git diff` (staged + unstaged). Include untracked files only if they are part of the current work.
2. Choose the target in this order:
   - Dirty working tree → that diff.
   - Clean tree and a path argument → that path vs the default branch (or `HEAD~1` if the path is only in the last commit).
   - Clean tree, no path → `HEAD` vs `HEAD~1` when the last commit looks like the implementation being polished; otherwise diff vs the default branch.
3. If there is no meaningful diff, say so and stop.
4. If the repo is not git, review files changed in this conversation only.

## Procedure

1. Summarize the scoped files in one short list.
2. Launch **four** `Task` subagents in **one** message, in parallel. They are reviewers, not editors.
   - `subagent_type`: `explore` or `generalPurpose`. Prefer `explore` when the diff is small and read-only review is enough; use `generalPurpose` only if they must read many files.
   - `run_in_background`: false (the parent needs the findings before applying).
   - Each agent gets the same file list plus **one** lens below.
   - Extra focus from the user argument is appended to every agent, or given to the closest lens.
3. Wait for all four. Deduplicate findings. Drop anything that would change behavior, touch files outside scope, or looks like a bugfix.
4. Apply remaining fixes **in the parent**, sequentially, to avoid overlapping edits.
5. Re-run the project's cheap checks when they exist (`test`, `typecheck`, `lint`/`format` as the repo already uses them). Do not introduce new toolchains.
6. Show `git diff` of the cleanup. List what changed, what was skipped and why, and any bug suspects for Bugbot.
7. Ask before committing. Preferred message shape: `refactor: /simplify で品質改善`.

## Four review agents

| Agent          | Looks for                                                            | Typical fix                                                                                                   |
| -------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| Reuse          | Duplicated logic, copy-pasted helpers, repeated lookups              | Extract or call an existing helper. Do not invent a new abstraction unless the duplication is real and local. |
| Simplification | Nested ternaries, dead branches, noisy names, over-wrapping          | Flatten control flow. Delete unused code. Keep names that the codebase already uses.                          |
| Efficiency     | Redundant loops, repeated I/O or queries, work done then thrown away | Hoist invariant work. Filter before mapping. Use a stdlib equivalent when it is already the project style.    |
| Abstraction    | Wrong layer (too many wrappers, or a god function)                   | Match the surrounding module's level. Do not introduce a framework.                                           |

Each agent must return:

- file path and a short finding
- why it is cleanup, not a behavior change
- a concrete patch suggestion (or "skip")

## When not to run

- The user asked for a bug hunt, security review, or large migration → `/review-bugbot`, `/review-security`, or `/batch`.
- No diff yet (still designing) → stay in Plan mode.
- One-line typo or comment-only change → just edit it; do not fan out four agents.

---
name: batch
description: Orchestrate large-scale independent code changes in parallel isolated worktrees. Research, split into 5-30 units, wait for approval, then implement, test, and simplify per unit. Use for migrations and bulk refactors, not one-file edits.
---

# /batch

コードベース全体に同じ方針の変更を大量適用する。調査して独立ユニットに分け、承認後に孤立した worktree で並列実行する。

Claude Code の `/batch`（v2.1.63 以降）に相当する。各ユニットの末尾で `/simplify` 相当を必ず走らせる。

## How to use

- `/batch <change>`
  変更方針は必須。例:
  - `/batch lodash を全部ネイティブ JS に置き換えて`
  - `/batch 非推奨 API を現行相当に更新して`
  - `/batch 未型付けの関数パラメータに型を足して`

引数が無いときは、何を一括変更したいかを聞いて止める。推測で走らせない。

## Hard rules

- NEVER start workers before the user approves the unit plan.
- NEVER put two units on files that would conflict. Same file → same unit.
- NEVER run multiple editors in the **current** worktree in parallel. Isolation is mandatory.
- NEVER use `environment: cloud` unless the user explicitly asked for a cloud agent.
- NEVER commit, push, force-push, or open a PR unless the user explicitly asked. Propose PR titles and a split; wait.
- NEVER use `/batch` for exploratory design, a single-file change, or a tightly coupled architecture rewrite.
- If a shared helper must exist first, do that in **this** session before fanning out, or refuse and say so.

## When to refuse

Stop after a short explanation and suggest a normal session (or `/simplify`) when:

- only one file (or a handful of lines) is involved
- the target shape is not decided yet
- unit B needs unit A's result (real dependency, not a fake edge)
- the user actually wants a bug hunt (`/review-bugbot`) or a cleanup of the current diff (`/simplify`)

## Phase 1: Research

1. Confirm this is a git repository. If not, stop. `/batch` needs branches and worktrees.
2. Launch an `explore` Task (`subagent_type: explore`, thoroughness `very thorough` when the tree is large) to find:
   - matching files and call sites
   - shared modules that all units would touch
   - existing tests / how to verify
3. Identify shared work that must land **before** the fan-out (new helper, type, compatibility shim). Do that first, or fold it into unit 0 as a sequential prerequisite.

## Phase 2: Plan (approval gate)

Decompose into **5〜30** independent units. Fewer than 5 is fine if the blast radius is small; do not invent dummy units. More than 30 → merge related folders.

Each unit lists:

- id and one-line goal
- files it owns (exclusive)
- replacements or pattern (a small mapping table when it is a mechanical migrate)
- how to test that unit
- dependencies (must be none, or only "after unit 0 / shared helper")

Show a mermaid or bullet graph of units. Call out collision risks (lockfiles, generated code, protocol registries, README catalogs).

Then **stop and wait**. Do not spawn workers. Ask the user to approve, edit the split, or abort.

## Phase 3: Parallel execution (after approval)

Spawn **one isolated worker per unit** in a single message.

Isolation, in order:

1. Local default: `subagent_type: best-of-n-runner` (own git worktree and branch).
2. Cloud: `environment: cloud` only if the user asked for cloud.
3. Never: multiple `generalPurpose` agents writing the same checkout.

Each worker prompt must include:

- the unit's files and the global mapping / policy
- implement only that unit
- run the unit's tests (or the repo's cheapest equivalent)
- run `/simplify` rules on **that unit's diff** (four lenses: reuse, simplification, efficiency, abstraction; behavior-preserving; no bug hunting)
- do not commit unless the parent said the user asked for commits
- report: files changed, test result, simplify summary, leftover risks

Parent tracks workers. Do not redo a finished worker's research. If one fails, retry that unit once with the error; do not take over its files in the current tree while siblings still run.

## Phase 4: Report

Aggregate:

- landed units vs failed units
- worktree / branch names
- test outcomes
- simplify cleanups applied
- suggested PR split (one PR per independent unit; stack only when the dependency is real)

Ask what to do next: commit, push, open PRs, or leave the worktrees.

If the user asks to open PRs, follow the project's PR rules (`gh pr create`, no force-push, no hooks skipped). Prefer the split-to-prs skill when leftover work is still one pile on the current branch.

## Relationship to /simplify

`/simplify` is the inner quality gate (recent diff, four reviewers).
`/batch` is the outer migration orchestrator. Every worker ends with simplify.
Bugs stay outside both: `/review-bugbot` / `/review-security`.

画像アップロード後に長辺 1600px へリサイズしてから R2 に置け

git add workers/scrap-api/src/index.ts src/components/ScrapImageUpload.tsx
git commit -m "feat: scraps の画像をアップロード時にリサイズする"

git diff
git commit -m "refactor: /simplify で品質改善"

/review-bugbot

/simplify エラーメッセージの重複も見て

/batch lodash を全部ネイティブ JS に置き換えて