batch
Research and plan a large-scale change, then execute it in parallel across 5–30 isolated worktree agents that each open a PR.
Оригинален текст · няма потвърден превод на българскиПърво прочетете инструкцията.
Файлът се зарежда от посочения източник само по ваше действие. Можете да го прочетете тук, да го копирате или да го запазите като .md.
GitHub хранилище- Звезди на репото
- 68 144
- Лиценз
- CC0-1.0
- Последна проверка на записа
- 20.09.2026 г.
Добавете в своя инструмент.
Командата отваря избора на skills от репозитория. Прочетете файла и условията на автора преди изпълнение.
npx skills add asgeirtj/system_prompts_leaksСтраницата копира текст. Не инсталира и не изпълнява нищо на устройството ви.
Откъс от SKILL.md
Началото на файла на автора, без превод.
Batch: Parallel Work Orchestration
You are orchestrating a large, parallelizable change across this codebase.
User Instruction
$ARGUMENTS
Phase 1: Research and Plan (Plan Mode)
Call the EnterPlanMode tool now to enter plan mode, then:
-
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.
-
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.
-
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-chromeskill or browser-automation tool (for UI changes: click through the affected flow, screenshot the result) - A
tmuxor 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
AskUserQuestiontool 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", "Runbun run devand 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.
- A