[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7EB6KYYHHA79Z5CP3B97JSJ":3,"skill-same:01M7EB6KYYHHA79Z5CP3B97JSJ":47},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":6,"ownerHtmlUrl":30,"ownerBlogUrl":6,"ownerDescription":31,"updatedAt":32,"install":33,"resources":46},"01M7EB6KYYHHA79Z5CP3B97JSJ","batch",null,"Research and plan a large-scale change, then execute it in parallel across 5–30 isolated worktree agents that each open a PR.","lza6\u002FArmor-piercing-system-prompts","lza6","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F128880206?v=4","01M7EB3K7WPX5T28EJ2NVHE6EG","Chinese-tingfeng","01M7EB3K97E1KQ16QWKJMFNGX8",11,"MIT","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F02-厂商系统提示词\u002Fsystem_prompts_leaks\u002FAnthropic\u002Fclaude-code\u002Fskills\u002Fbatch\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: batch\ndescription: Research and plan a large-scale change, then execute it in parallel across 5–30 isolated worktree agents that each open a PR.\nwhen_to_use: 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.\n---\n\n# Batch: Parallel Work Orchestration\n\nYou are orchestrating a large, parallelizable change across this codebase.\n\n## User Instruction\n\n$ARGUMENTS\n\n## Phase 1: Research and Plan (Plan Mode)\n\nCall the `EnterPlanMode` tool now to enter plan mode, then:\n\n1. **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.\n\n2. **Decompose into independent units.** Break the work into 5–30 self-contained units. Each unit must:\n   - Be independently implementable in an isolated git worktree (no shared state with sibling units)\n   - Be mergeable on its own without depending on another unit's PR landing first\n   - Be roughly uniform in size (split large units, merge trivial ones)\n\n   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.\n\n3. **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:\n   - A `claude-in-chrome` skill or browser-automation tool (for UI changes: click through the affected flow, screenshot the result)\n   - A `tmux` or CLI-verifier skill (for CLI changes: launch the app interactively, exercise the changed behavior)\n   - A dev-server + curl pattern (for API changes: start the server, hit the affected endpoints)\n   - An existing e2e\u002Fintegration test suite the worker can run\n\n   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.\n\n   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\u002Finteraction to verify.\n\n4. **Write the plan.** In your plan file, include:\n   - A summary of what you found during research\n   - A numbered list of work units — for each: a short title, the list of files\u002Fdirectories it covers, and a one-line description of the change\n   - The e2e test recipe (or \"skip e2e because …\" if the user chose that)\n   - The exact worker instructions you will give each agent (the shared template)\n\n5. Call `ExitPlanMode` to present the plan for approval.\n\n## Phase 2: Spawn Workers (After Plan Approval)\n\nOnce 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.\n\nFor each agent, the prompt must be fully self-contained. Include:\n- The overall goal (the user's instruction)\n- This unit's specific task (title, file list, change description — copied verbatim from your plan)\n- Any codebase conventions you discovered that the worker needs to follow\n- The e2e test recipe from your plan (or \"skip e2e because …\")\n- The worker instructions below, copied verbatim:\n\n```\nAfter you finish implementing the change:\n1. **Code review** — Invoke the `Skill` tool with `skill: \"code-review\"` to find correctness bugs (it reports findings; it does not edit code). Fix any findings it surfaces before continuing.\n2. **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.\n3. **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.\n4. **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.\n5. **Report** — End with a single line: `PR: \u003Curl>` so the coordinator can track it. If no PR was created, end with `PR: none — \u003Creason>`.\n```\n\nUse `subagent_type: \"general-purpose\"` unless a more specific agent type fits.\n\n## Phase 3: Track Progress\n\nAfter launching all workers, render an initial status table:\n\n| # | Unit | Status | PR |\n|---|------|--------|----|\n| 1 | \u003Ctitle> | running | — |\n| 2 | \u003Ctitle> | running | — |\n\nAs background-agent completion notifications arrive, parse the `PR: \u003Curl>` line from each agent's result and re-render the table with updated status (`done` \u002F `failed`) and PR links. Keep a brief failure note for any agent that did not produce a PR.\n\nWhen all agents have reported, render the final table and a one-line summary (e.g., \"22\u002F24 units landed as PRs\").\n","# Batch: Parallel Work Orchestration\n\nYou are orchestrating a large, parallelizable change across this codebase.\n\n## User Instruction\n\n$ARGUMENTS\n\n## Phase 1: Research and Plan (Plan Mode)\n\nCall the `EnterPlanMode` tool now to enter plan mode, then:\n\n1. **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.\n\n2. **Decompose into independent units.** Break the work into 5–30 self-contained units. Each unit must:\n   - Be independently implementable in an isolated git worktree (no shared state with sibling units)\n   - Be mergeable on its own without depending on another unit's PR landing first\n   - Be roughly uniform in size (split large units, merge trivial ones)\n\n   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.\n\n3. **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:\n   - A `claude-in-chrome` skill or browser-automation tool (for UI changes: click through the affected flow, screenshot the result)\n   - A `tmux` or CLI-verifier skill (for CLI changes: launch the app interactively, exercise the changed behavior)\n   - A dev-server + curl pattern (for API changes: start the server, hit the affected endpoints)\n   - An existing e2e\u002Fintegration test suite the worker can run\n\n   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.\n\n   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\u002Finteraction to verify.\n\n4. **Write the plan.** In your plan file, include:\n   - A summary of what you found during research\n   - A numbered list of work units — for each: a short title, the list of files\u002Fdirectories it covers, and a one-line description of the change\n   - The e2e test recipe (or \"skip e2e because …\" if the user chose that)\n   - The exact worker instructions you will give each agent (the shared template)\n\n5. Call `ExitPlanMode` to present the plan for approval.\n\n## Phase 2: Spawn Workers (After Plan Approval)\n\nOnce 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.\n\nFor each agent, the prompt must be fully self-contained. Include:\n- The overall goal (the user's instruction)\n- This unit's specific task (title, file list, change description — copied verbatim from your plan)\n- Any codebase conventions you discovered that the worker needs to follow\n- The e2e test recipe from your plan (or \"skip e2e because …\")\n- The worker instructions below, copied verbatim:\n\n```\nAfter you finish implementing the change:\n1. **Code review** — Invoke the `Skill` tool with `skill: \"code-review\"` to find correctness bugs (it reports findings; it does not edit code). Fix any findings it surfaces before continuing.\n2. **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.\n3. **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.\n4. **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.\n5. **Report** — End with a single line: `PR: \u003Curl>` so the coordinator can track it. If no PR was created, end with `PR: none — \u003Creason>`.\n```\n\nUse `subagent_type: \"general-purpose\"` unless a more specific agent type fits.\n\n## Phase 3: Track Progress\n\nAfter launching all workers, render an initial status table:\n\n| # | Unit | Status | PR |\n|---|------|--------|----|\n| 1 | \u003Ctitle> | running | — |\n| 2 | \u003Ctitle> | running | — |\n\nAs background-agent completion notifications arrive, parse the `PR: \u003Curl>` line from each agent's result and re-render the table with updated status (`done` \u002F `failed`) and PR links. Keep a brief failure note for any agent that did not produce a PR.\n\nWhen all agents have reported, render the final table and a one-line summary (e.g., \"22\u002F24 units landed as PRs\").\n",{"name":5,"description":7,"when_to_use":24},"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.","main","d69096e239f2a89aabc2cd078c47664a9d3b1e11","02-厂商系统提示词\u002Fsystem_prompts_leaks\u002FAnthropic\u002Fclaude-code\u002Fskills\u002Fbatch",3,"https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts","https:\u002F\u002Fgithub.com\u002Flza6","个人vx：Tf00798\r\n个人✈：@TFGY999","2026-10-08 14:29:22",{"source":8,"skillName":5,"commands":34,"prompt":44,"zipAvailable":45},[35,38,41],{"tool":36,"command":37},"npx","npx skills add lza6\u002FArmor-piercing-system-prompts --skill batch",{"tool":39,"command":40},"bunx","bunx skills add lza6\u002FArmor-piercing-system-prompts --skill batch",{"tool":42,"command":43},"pnpm","pnpm dlx skills add lza6\u002FArmor-piercing-system-prompts --skill batch","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F02-厂商系统提示词\u002Fsystem_prompts_leaks\u002FAnthropic\u002Fclaude-code\u002Fskills\u002Fbatch\u002FSKILL.md",true,[],[48,55,62,69,77,84],{"skillNo":49,"name":50,"nameZh":6,"description":51,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":52,"categories":53,"keywords":54,"publishedAt":19},"01M7EXRM12046G0GM1WGMMFXCN","ci-cd-and-automation","Automates CI\u002FCD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fci-cd-and-automation\u002FSKILL.md",[],[],{"skillNo":56,"name":57,"nameZh":6,"description":58,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":59,"categories":60,"keywords":61,"publishedAt":19},"01M7EXRFYYSJ3Y15AGPDDEWWQD","chrome-devtools","Uses Chrome DevTools via MCP for efficient debugging, troubleshooting and browser automation. Use when debugging web pages, automating browser interactions, analyzing performance, or inspecting network requests. This skill does not apply to `--slim` mode (MCP configuration).","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fchrome-devtools\u002FSKILL.md",[],[],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":68,"publishedAt":19},"01M7EXR6EYPE4X5X1BTAE6QJRV","chrome-cdp","Drive a real Chrome via the Chrome DevTools Protocol (CDP). Ensures a\ndebuggable Chrome is running (launching it if needed) so the agent can\nnavigate, read page content, inspect the DOM, run JavaScript, and take\nscreenshots — without the user typing any launch command. Includes a\nfirst-class \"review a live running app\" flow: point Chrome at the app under\ndevelopment and inspect\u002Fscreenshot the REAL page (what a static-artifact tool\ncannot do). Backed by Glimpse and the chrome-devtools MCP server. Use when\nasked to \"use chrome\", \"open chrome\", \"drive my browser\", \"read the page in\nchrome\", \"review the running app\", \"screenshot the app\", or \"\u002Fchrome-cdp\".","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fchrome-cdp\u002FSKILL.md",[],[],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":73,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":19},"01M7EXR1Y7E79KQKG4J798XGH6","check-identity-pack","Run an AFP 100-point or AUSTRAC safe-harbour identity check over a set of documents, and report exactly what's missing. Use when the user asks to check identity documents, verify someone's ID for onboarding, or assess whether a document pack satisfies Australian identity requirements.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fcheck-identity-pack\u002FSKILL.md",[],[],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":19},"01M7EXQXW7C7PGREJW9ZZTZ16H","changelog","Auto-generates a changelog from git commits, sprint data, and design documents. Produces both internal and player-facing versions.","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fchangelog\u002FSKILL.md",[],[],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":19},"01M7EXQMH2ZME3ANN8Q8MEWPFB","cellxgene-census","Query the CZ CELLxGENE Census programmatically for versioned public single-cell and spatial transcriptomics data. Use when you need population-scale cell metadata, gene expression slices, Census summary counts, source H5AD URIs\u002Fdownloads, embeddings, spatial Census data, or reference atlas comparisons across organisms, tissues, diseases, assays, and cell types. For analyzing your own local single-cell data use scanpy, anndata, or scvi-tools.","https:\u002F\u002Fgithub.com\u002Flza6\u002FArmor-piercing-system-prompts\u002Fblob\u002Fmain\u002F05-技能与代理开发\u002Fcellxgene-census\u002FSKILL.md",[],[]]