[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CHV0XJFGBFG2H78992CFG6":3,"skill-same:01M6CHV0XJFGBFG2H78992CFG6":69},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":52,"ownerHtmlUrl":53,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":54,"install":55,"resources":68},"01M6CHV0XJFGBFG2H78992CFG6","sero-subagent-orchestration",null,"Orchestrate parallel implementation and fresh validation agents safely in the Sero repository. Use when a task asks for pi-subagents, parallel workers, isolated worktrees, review-and-fix loops, or several independent fixes that must be integrated and reviewed without Claude Code.","sero-labs\u002Fsero","sero-labs","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F278893820?v=4","01M6CHSF0GA1ZZSBGVB5ESH37Q","01M6CHSF4WD1EGGY0RNFHQ5R4N",28,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fsero-labs\u002Fsero\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fsero-subagent-orchestration\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"orchestration","subagent","subagent orchestration","sero subagent orchestration","when","review","parallel implementation","fixes","for","loops","fresh","task","worktrees","implementation","workers","use","subagents","pi","fix","parallel","repository","orchestrate","validation","code","2026-11-10 10:12:30",false,"---\nname: sero-subagent-orchestration\ndescription: Orchestrate parallel implementation and fresh validation agents safely in the Sero repository. Use when a task asks for pi-subagents, parallel workers, isolated worktrees, review-and-fix loops, or several independent fixes that must be integrated and reviewed without Claude Code.\n---\n\n# Sero Subagent Orchestration\n\nUse the `pi-subagents` skill as the canonical API guide. Apply this project workflow for reliable Sero implementation.\n\n## 1. Preflight one worker\n\nDo not launch the full fleet first.\n\n1. Call `subagent({ action: \"list\", capabilities: true })`. Use only an executable, non-disabled agent, and read the tool list it resolves to.\n2. Call `subagent({ action: \"models\" })` and select an exact model ID from the active registry.\n3. Run one read-only smoke task with the exact agent, model, context, **launch mode**, and tools planned for the real job. The mode is part of the contract: an agent whose allowlist names extension tools fails a foreground launch before it starts, so smoke-test it the way it will actually run.\n4. Require the smoke task to do the job's **hardest** step, not its easiest. A writer must read a file, run a shell command such as `git status`, read one target source symbol, and apply a patch. A read-only reviewer must read a Markdown file and read a whole source file. Reading one TypeScript symbol alone proves almost nothing — it is the one thing a symbol reader can do without a shell.\n5. Start the real work only after the smoke task proves every capability the job needs.\n\nAn agent can start successfully and still be unable to do the job. A configured model can also differ from the model shown by inherited defaults. Test both.\n\n### A tool name is not a capability\n\n`tools` is a strict allowlist. **An allowlisted name does not load the extension that registers it** (`pi-subagents` `docs\u002Fagents.md:440`). A child listed with `exec` has a tool called `exec` only if something also loads the provider that registers it; otherwise the name resolves to nothing usable and the child runs with supervisor contact and little else.\n\n**An allowlisted name that is not registered also fails the step.** One review round was lost to this: several agents named a diagnostics tool that `pi-lens` does not register at all — the name appeared in pi-lens's own comments but never in its tool registry (`dist\u002Fclients\u002Ftool-config.js:39`), and the correct name sat beside it on the same line. A name that is merely *discussed* somewhere is not a name you can allowlist.\n\nCopy every `tools` entry from the resolved list — `subagent({ action: \"list\", capabilities: true })` — never from prose, a README, or a comment, and spell it exactly. Guessing a plausible tool name is the failure mode, so do not carry a wrong name into a definition or into a task prompt either.\n\nA step rejected this way is reported as **failed with exit code 1 even when the child ran and produced a correct report**. Read the error before discarding the output: the work may be good and only the allowlist wrong.\n\nCheck every name in the allowlist against `subagent({ action: \"list\", capabilities: true })` — its resolved list is the authority, not the prose in an extension's README or comments.\n\nA sandboxed tool can also exist but come up empty. Observed in this repository: an agent whose own prompt told it to use `exec` for `tools.exec_command` reported `exec is restricted JS (Deno undefined, tools {}, ALL_TOOLS [])`. The tool was present and its capability object was not. An agent that depends on it cannot read files, run `git`, or run tests.\n\n### Where a child's extension tools come from\n\n| The child is | Ambient extensions | What reaches it |\n| --- | --- | --- |\n| Foreground (`async: false`) | never loaded | only extensions named in `extensions`, `subagentOnlyExtensions`, or a path-like `tools` entry |\n| Background (`async: true`) | loaded | ambient extensions, unless `extensions` is set — an explicit `extensions` disables normal discovery |\n\nForeground children never load the parent's ambient extensions, because they share the parent process and would start a second copy of every ambient extension (`docs\u002Fagents.md:442`, `docs\u002Fextension-api.md:413`). MCP tools and provider-extension models therefore require `async: true`.\n\nTo make a named extension tool work in a child, load its provider **as well as** naming the tool:\n\n```yaml\ntools: read, fixture_search\nsubagentOnlyExtensions: .\u002Ftools\u002Ffixture-search.ts\n```\n\nA path-like `tools` entry or `extensions` also loads a provider (`docs\u002Fagents.md:459`).\n\n### Match the launch mode to the allowlist\n\nA strict allowlist is resolved **before the child starts**, so the launch mode decides which of its names can resolve. Foreground children never load ambient extensions:\n\n```text\nAgent '\u003Cname>' ran as a foreground child, which never loads the parent's ambient\n  extensions, and these child tools were unavailable: exec, lens_diagnostics, ...\nThe `tools` field is a strict allowlist; it does not load extension code.\n```\n\nSo an agent whose allowlist names extension tools **cannot be smoke-tested in the foreground at all**, and cannot be launched foreground for real work either. It must run as a background child (`async: true`); or have the provider loaded through `extensions`, `subagentOnlyExtensions`, or a path-like `tools` entry; or stop naming tools the job does not need.\n\nAdding native builtins does **not** rescue a foreground launch while extension names remain in the allowlist. Builtins fix a child that would otherwise run without an extension; they do not fix one that cannot start.\n\n### Prefer builtins for the work\n\n`read`, `bash`, `grep`, `find` and `ls` are Pi builtins and need no extension wiring. `tools: \"inherit\"` receives Pi's normal builtins too (`docs\u002Fagents.md:454`).\n\nGive every agent a native fallback for the work it must do, so a missing extension degrades the run instead of ending it. The Sero agents in `~\u002F.agents\u002F` are the worked example: four of them listed no native tools at all, so with the extension absent they had no way to read a file — no `read`, so no Markdown and no whole source file; no `bash`, so no diff and no test run. `sero-test-value-reviewer` already carried `read, bash` and was the one that worked. All five now carry the builtins they need, and because they still name extension tools they must still run as **background** children.\n\nA read-only reviewer is deliberately given `read, grep, find, ls` and **not** `bash`, matching the builtin `reviewer` role: it must read source and the rules unaided, while the parent keeps the mutation risk and runs the suites.\n\n### Fit the agent to the job\n\nAgents are configuration, not fixtures. **Edit or create one for the job.** Run `subagent({ action: \"guide\", topic: \"management-authoring-rpc\" })` for the management actions. Before launching, check the definition against the job:\n\n- `tools` — does every name have a provider loaded, and is there a native fallback for the job's core work?\n- `extensions` \u002F `subagentOnlyExtensions` — is the provider actually loaded?\n- `inheritProjectContext: false` with `inheritSkills: false` strips `AGENTS.md` and the `.agents\u002Fskills\u002F*` catalogue (`docs\u002Fagents.md:276-279`). A child with both false cannot read the review skill or the repository rules, so **the task must inline them**, or set the flags true.\n- `systemPromptMode: replace` means the child does not receive Pi's base prompt.\n- The agent's own prompt may forbid what the job needs. `sero-fresh-reviewer` and `sero-fix-worker` both say \"do not comment on GitHub\", while `sero-code-review` requires each round to be posted. The orchestrator posts it, or the child is not asked to.\n\nIf the model fails, pass an exact model ID returned by the active registry. If tools fail, correct the agent or create a purpose-made one, then re-run the smoke test before spending a real job on it. Run `list` again after any agent change. Do not use the `claude-code` agent.\n\n### Do not press on with a crippled child\n\nA child that stalls asking for things it cannot fetch is an infrastructure problem, not a research task for the orchestrator. Stop at the first signal, report the exact failure, and fix the capability or replace the agent. Fetching diffs and file contents by hand for a child that has no shell is the orchestrator doing the child's job and paying for both.\n\n## 2. Design independent lanes\n\nGroup findings by source seam, not by issue number. Two lanes must not edit the same production file. Give each lane:\n\n- a distinct goal and source seam;\n- exact evidence and acceptance criteria;\n- authority limits: no push, merge, PR comment, publish, or release;\n- functional regression tests and focused validation;\n- the Sero 500 LOC check;\n- a required Conventional Commit and commit SHA report.\n\nUse `context: \"fresh\"` and `worktree: true` for every parallel writer. Keep one writer in each worktree. Use stable `runs.all` keys and an async workflow. Do not edit the parent worktree while writers run.\n\nKeep producer and consumer changes in one lane when they form one runtime contract. A fix is incomplete if planning or approval accepts data that the final runtime cannot load or enforce.\n\n## 3. Run and supervise\n\nUse one `workflowScript` for the implementation wave:\n\n```javascript\nconst results = await runs.all([\n  {\n    key: \"validation\",\n    agent: \"sero-fix-worker\",\n    model: \"\u003Cverified-model-id>\",\n    context: \"fresh\",\n    worktree: true,\n    task: \"Implement the validation lane, test it, commit it, and report the SHA.\"\n  },\n  {\n    key: \"lifecycle\",\n    agent: \"sero-fix-worker\",\n    model: \"\u003Cverified-model-id>\",\n    context: \"fresh\",\n    worktree: true,\n    task: \"Implement the lifecycle lane, test it, commit it, and report the SHA.\"\n  }\n]);\nreturn results.map(({ key, runId, output, handoff }) => ({ key, runId, output, handoff }));\n```\n\nFor an implementation request, supervise workers through integration and\nvalidation unless the user explicitly requests background launch only. Handle\npending supervisor requests before waiting. Use the available wait mechanism\nrather than polling. This does not grant additional push, publish, release,\nor PR authority.\n\nIf a supervisor request needs a product, authority, or security decision:\n\n1. Pause the writer.\n2. Explain the affected user-facing object in plain language before asking for a choice.\n3. Record the user's exact decision.\n4. Resume the same retained session. Do not launch a replacement while the original child can still be live.\n\nIf a detached child needs attention but no pending request is available, interrupt it to a safe paused state, then resume that retained run with the decision. Preserve its worktree and session instead of starting a second writer.\n\n## 4. Integrate through the parent\n\nInspect each handoff and commit before integration. Cherry-pick commits one at a time into the clean parent branch. Resolve overlap centrally, then run:\n\n- proactive diagnostics on touched files;\n- focused tests for every fault class;\n- root `pnpm typecheck`;\n- touched source file line counts;\n- React Doctor when React files changed;\n- documentation and prototype checks required by `AGENTS.md`.\n\nRun the full affected package suite after focused tests. It catches stale assertions that isolated fix tests can miss. Recheck the complete touched-file list after integration because a one-line edit can make an existing file exceed 500 LOC.\n\nManaged worktrees can have incomplete dependency links. Do not run concurrent installs that mutate shared `node_modules`. Use the existing frozen repository install where possible. If the parent links are damaged, restore them once after all writers stop with the frozen lockfile, confirm no lockfile change, then rerun validation in the parent.\n\nCheck whether the integrated range changes `packages\u002F*`. Record the npm republish requirement even when the last fix commit did not touch that package.\n\nDo not push until integrated validation is green.\n\n## 5. Validate with fresh reviewers\n\nLaunch a new read-only `runs.all` wave after integration. Use distinct angles:\n\n- correctness, races, and security boundaries;\n- regression tests, failure injection, and fault-class sweeps;\n- simplicity, Sero constraints, docs, and file size.\n\nReviewers must read the integrated parent HEAD and exact base range, not a worker branch. Give file and line evidence and make no edits. Assign at least one reviewer to trace end-to-end contracts from discovery or planning through approval, persistence, and final runtime use. Tests of only the first half of a contract are not sufficient.\n\nA reviewer earns \"independent\" only if it can do the job unaided. Check its resolved tool list before launch (§1): it must be able to read the Markdown rules it is asked to apply and read whole source files. A reviewer that can only read symbols stalls asking the parent for `AGENTS.md`, the review skill, the diff and the file list, and the parent ends up doing the child's job and paying for both. Running the suites may stay with the parent — read-only reviewers have no shell — but then the round must state that the checks were the parent's.\n\nReconcile all reports in the parent. If a real blocker remains, use one fix worker, integrate it, and repeat with new fresh context. Use a bounded review loop, normally three rounds. Stop when no correctness, data-loss, or security blocker remains. Treat transient aggregate-test failures as evidence to investigate: rerun the affected package and exact test, then report the result without hiding the unstable aggregate run.\n\n## 6. Report and update the PR\n\nFollow the `sero-code-review` skill. Give a green or red code verdict, list the status of every earlier finding, state exact validation, and separate non-code merge blockers. Post the result as a new PR review comment with:\n\n```bash\ngh pr comment \u003Cpr> --body-file \u003Cfile>\n```\n\nThe **orchestrator posts**, because the Sero worker and reviewer agents are configured to refuse GitHub comments. If a round's inputs were supplied by the parent, or the checks were run by the parent rather than the child, say so in the comment. A review that reads as independent when it was not is worse than one that names its limits.\n\nPost a new comment for each review round so PR watchers receive the update and the review history stays visible. Use `--edit-last` only to correct the current round's comment. Push the validated integrated commits before posting so the PR head matches the reviewed SHA. Confirm the remote head, draft checks, and clean local status. Keep the PR a draft unless the user explicitly asks otherwise.\n","# Sero Subagent Orchestration\n\nUse the `pi-subagents` skill as the canonical API guide. Apply this project workflow for reliable Sero implementation.\n\n## 1. Preflight one worker\n\nDo not launch the full fleet first.\n\n1. Call `subagent({ action: \"list\", capabilities: true })`. Use only an executable, non-disabled agent, and read the tool list it resolves to.\n2. Call `subagent({ action: \"models\" })` and select an exact model ID from the active registry.\n3. Run one read-only smoke task with the exact agent, model, context, **launch mode**, and tools planned for the real job. The mode is part of the contract: an agent whose allowlist names extension tools fails a foreground launch before it starts, so smoke-test it the way it will actually run.\n4. Require the smoke task to do the job's **hardest** step, not its easiest. A writer must read a file, run a shell command such as `git status`, read one target source symbol, and apply a patch. A read-only reviewer must read a Markdown file and read a whole source file. Reading one TypeScript symbol alone proves almost nothing — it is the one thing a symbol reader can do without a shell.\n5. Start the real work only after the smoke task proves every capability the job needs.\n\nAn agent can start successfully and still be unable to do the job. A configured model can also differ from the model shown by inherited defaults. Test both.\n\n### A tool name is not a capability\n\n`tools` is a strict allowlist. **An allowlisted name does not load the extension that registers it** (`pi-subagents` `docs\u002Fagents.md:440`). A child listed with `exec` has a tool called `exec` only if something also loads the provider that registers it; otherwise the name resolves to nothing usable and the child runs with supervisor contact and little else.\n\n**An allowlisted name that is not registered also fails the step.** One review round was lost to this: several agents named a diagnostics tool that `pi-lens` does not register at all — the name appeared in pi-lens's own comments but never in its tool registry (`dist\u002Fclients\u002Ftool-config.js:39`), and the correct name sat beside it on the same line. A name that is merely *discussed* somewhere is not a name you can allowlist.\n\nCopy every `tools` entry from the resolved list — `subagent({ action: \"list\", capabilities: true })` — never from prose, a README, or a comment, and spell it exactly. Guessing a plausible tool name is the failure mode, so do not carry a wrong name into a definition or into a task prompt either.\n\nA step rejected this way is reported as **failed with exit code 1 even when the child ran and produced a correct report**. Read the error before discarding the output: the work may be good and only the allowlist wrong.\n\nCheck every name in the allowlist against `subagent({ action: \"list\", capabilities: true })` — its resolved list is the authority, not the prose in an extension's README or comments.\n\nA sandboxed tool can also exist but come up empty. Observed in this repository: an agent whose own prompt told it to use `exec` for `tools.exec_command` reported `exec is restricted JS (Deno undefined, tools {}, ALL_TOOLS [])`. The tool was present and its capability object was not. An agent that depends on it cannot read files, run `git`, or run tests.\n\n### Where a child's extension tools come from\n\n| The child is | Ambient extensions | What reaches it |\n| --- | --- | --- |\n| Foreground (`async: false`) | never loaded | only extensions named in `extensions`, `subagentOnlyExtensions`, or a path-like `tools` entry |\n| Background (`async: true`) | loaded | ambient extensions, unless `extensions` is set — an explicit `extensions` disables normal discovery |\n\nForeground children never load the parent's ambient extensions, because they share the parent process and would start a second copy of every ambient extension (`docs\u002Fagents.md:442`, `docs\u002Fextension-api.md:413`). MCP tools and provider-extension models therefore require `async: true`.\n\nTo make a named extension tool work in a child, load its provider **as well as** naming the tool:\n\n```yaml\ntools: read, fixture_search\nsubagentOnlyExtensions: .\u002Ftools\u002Ffixture-search.ts\n```\n\nA path-like `tools` entry or `extensions` also loads a provider (`docs\u002Fagents.md:459`).\n\n### Match the launch mode to the allowlist\n\nA strict allowlist is resolved **before the child starts**, so the launch mode decides which of its names can resolve. Foreground children never load ambient extensions:\n\n```text\nAgent '\u003Cname>' ran as a foreground child, which never loads the parent's ambient\n  extensions, and these child tools were unavailable: exec, lens_diagnostics, ...\nThe `tools` field is a strict allowlist; it does not load extension code.\n```\n\nSo an agent whose allowlist names extension tools **cannot be smoke-tested in the foreground at all**, and cannot be launched foreground for real work either. It must run as a background child (`async: true`); or have the provider loaded through `extensions`, `subagentOnlyExtensions`, or a path-like `tools` entry; or stop naming tools the job does not need.\n\nAdding native builtins does **not** rescue a foreground launch while extension names remain in the allowlist. Builtins fix a child that would otherwise run without an extension; they do not fix one that cannot start.\n\n### Prefer builtins for the work\n\n`read`, `bash`, `grep`, `find` and `ls` are Pi builtins and need no extension wiring. `tools: \"inherit\"` receives Pi's normal builtins too (`docs\u002Fagents.md:454`).\n\nGive every agent a native fallback for the work it must do, so a missing extension degrades the run instead of ending it. The Sero agents in `~\u002F.agents\u002F` are the worked example: four of them listed no native tools at all, so with the extension absent they had no way to read a file — no `read`, so no Markdown and no whole source file; no `bash`, so no diff and no test run. `sero-test-value-reviewer` already carried `read, bash` and was the one that worked. All five now carry the builtins they need, and because they still name extension tools they must still run as **background** children.\n\nA read-only reviewer is deliberately given `read, grep, find, ls` and **not** `bash`, matching the builtin `reviewer` role: it must read source and the rules unaided, while the parent keeps the mutation risk and runs the suites.\n\n### Fit the agent to the job\n\nAgents are configuration, not fixtures. **Edit or create one for the job.** Run `subagent({ action: \"guide\", topic: \"management-authoring-rpc\" })` for the management actions. Before launching, check the definition against the job:\n\n- `tools` — does every name have a provider loaded, and is there a native fallback for the job's core work?\n- `extensions` \u002F `subagentOnlyExtensions` — is the provider actually loaded?\n- `inheritProjectContext: false` with `inheritSkills: false` strips `AGENTS.md` and the `.agents\u002Fskills\u002F*` catalogue (`docs\u002Fagents.md:276-279`). A child with both false cannot read the review skill or the repository rules, so **the task must inline them**, or set the flags true.\n- `systemPromptMode: replace` means the child does not receive Pi's base prompt.\n- The agent's own prompt may forbid what the job needs. `sero-fresh-reviewer` and `sero-fix-worker` both say \"do not comment on GitHub\", while `sero-code-review` requires each round to be posted. The orchestrator posts it, or the child is not asked to.\n\nIf the model fails, pass an exact model ID returned by the active registry. If tools fail, correct the agent or create a purpose-made one, then re-run the smoke test before spending a real job on it. Run `list` again after any agent change. Do not use the `claude-code` agent.\n\n### Do not press on with a crippled child\n\nA child that stalls asking for things it cannot fetch is an infrastructure problem, not a research task for the orchestrator. Stop at the first signal, report the exact failure, and fix the capability or replace the agent. Fetching diffs and file contents by hand for a child that has no shell is the orchestrator doing the child's job and paying for both.\n\n## 2. Design independent lanes\n\nGroup findings by source seam, not by issue number. Two lanes must not edit the same production file. Give each lane:\n\n- a distinct goal and source seam;\n- exact evidence and acceptance criteria;\n- authority limits: no push, merge, PR comment, publish, or release;\n- functional regression tests and focused validation;\n- the Sero 500 LOC check;\n- a required Conventional Commit and commit SHA report.\n\nUse `context: \"fresh\"` and `worktree: true` for every parallel writer. Keep one writer in each worktree. Use stable `runs.all` keys and an async workflow. Do not edit the parent worktree while writers run.\n\nKeep producer and consumer changes in one lane when they form one runtime contract. A fix is incomplete if planning or approval accepts data that the final runtime cannot load or enforce.\n\n## 3. Run and supervise\n\nUse one `workflowScript` for the implementation wave:\n\n```javascript\nconst results = await runs.all([\n  {\n    key: \"validation\",\n    agent: \"sero-fix-worker\",\n    model: \"\u003Cverified-model-id>\",\n    context: \"fresh\",\n    worktree: true,\n    task: \"Implement the validation lane, test it, commit it, and report the SHA.\"\n  },\n  {\n    key: \"lifecycle\",\n    agent: \"sero-fix-worker\",\n    model: \"\u003Cverified-model-id>\",\n    context: \"fresh\",\n    worktree: true,\n    task: \"Implement the lifecycle lane, test it, commit it, and report the SHA.\"\n  }\n]);\nreturn results.map(({ key, runId, output, handoff }) => ({ key, runId, output, handoff }));\n```\n\nFor an implementation request, supervise workers through integration and\nvalidation unless the user explicitly requests background launch only. Handle\npending supervisor requests before waiting. Use the available wait mechanism\nrather than polling. This does not grant additional push, publish, release,\nor PR authority.\n\nIf a supervisor request needs a product, authority, or security decision:\n\n1. Pause the writer.\n2. Explain the affected user-facing object in plain language before asking for a choice.\n3. Record the user's exact decision.\n4. Resume the same retained session. Do not launch a replacement while the original child can still be live.\n\nIf a detached child needs attention but no pending request is available, interrupt it to a safe paused state, then resume that retained run with the decision. Preserve its worktree and session instead of starting a second writer.\n\n## 4. Integrate through the parent\n\nInspect each handoff and commit before integration. Cherry-pick commits one at a time into the clean parent branch. Resolve overlap centrally, then run:\n\n- proactive diagnostics on touched files;\n- focused tests for every fault class;\n- root `pnpm typecheck`;\n- touched source file line counts;\n- React Doctor when React files changed;\n- documentation and prototype checks required by `AGENTS.md`.\n\nRun the full affected package suite after focused tests. It catches stale assertions that isolated fix tests can miss. Recheck the complete touched-file list after integration because a one-line edit can make an existing file exceed 500 LOC.\n\nManaged worktrees can have incomplete dependency links. Do not run concurrent installs that mutate shared `node_modules`. Use the existing frozen repository install where possible. If the parent links are damaged, restore them once after all writers stop with the frozen lockfile, confirm no lockfile change, then rerun validation in the parent.\n\nCheck whether the integrated range changes `packages\u002F*`. Record the npm republish requirement even when the last fix commit did not touch that package.\n\nDo not push until integrated validation is green.\n\n## 5. Validate with fresh reviewers\n\nLaunch a new read-only `runs.all` wave after integration. Use distinct angles:\n\n- correctness, races, and security boundaries;\n- regression tests, failure injection, and fault-class sweeps;\n- simplicity, Sero constraints, docs, and file size.\n\nReviewers must read the integrated parent HEAD and exact base range, not a worker branch. Give file and line evidence and make no edits. Assign at least one reviewer to trace end-to-end contracts from discovery or planning through approval, persistence, and final runtime use. Tests of only the first half of a contract are not sufficient.\n\nA reviewer earns \"independent\" only if it can do the job unaided. Check its resolved tool list before launch (§1): it must be able to read the Markdown rules it is asked to apply and read whole source files. A reviewer that can only read symbols stalls asking the parent for `AGENTS.md`, the review skill, the diff and the file list, and the parent ends up doing the child's job and paying for both. Running the suites may stay with the parent — read-only reviewers have no shell — but then the round must state that the checks were the parent's.\n\nReconcile all reports in the parent. If a real blocker remains, use one fix worker, integrate it, and repeat with new fresh context. Use a bounded review loop, normally three rounds. Stop when no correctness, data-loss, or security blocker remains. Treat transient aggregate-test failures as evidence to investigate: rerun the affected package and exact test, then report the result without hiding the unstable aggregate run.\n\n## 6. Report and update the PR\n\nFollow the `sero-code-review` skill. Give a green or red code verdict, list the status of every earlier finding, state exact validation, and separate non-code merge blockers. Post the result as a new PR review comment with:\n\n```bash\ngh pr comment \u003Cpr> --body-file \u003Cfile>\n```\n\nThe **orchestrator posts**, because the Sero worker and reviewer agents are configured to refuse GitHub comments. If a round's inputs were supplied by the parent, or the checks were run by the parent rather than the child, say so in the comment. A review that reads as independent when it was not is worse than one that names its limits.\n\nPost a new comment for each review round so PR watchers receive the update and the review history stays visible. Use `--edit-last` only to correct the current round's comment. Push the validated integrated commits before posting so the PR head matches the reviewed SHA. Confirm the remote head, draft checks, and clean local status. Keep the PR a draft unless the user explicitly asks otherwise.\n",{"name":5,"description":7},"main","e91c3c773b84e88a929cae3c36977e892ca4871a",".agents\u002Fskills\u002Fsero-subagent-orchestration",4,"https:\u002F\u002Fgithub.com\u002Fsero-labs\u002Fsero","https:\u002F\u002Fsero-ai.dev\u002F","https:\u002F\u002Fgithub.com\u002Fsero-labs","2026-11-10 06:55:21",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add sero-labs\u002Fsero --skill sero-subagent-orchestration",{"tool":61,"command":62},"bunx","bunx skills add sero-labs\u002Fsero --skill sero-subagent-orchestration",{"tool":64,"command":65},"pnpm","pnpm dlx skills add sero-labs\u002Fsero --skill sero-subagent-orchestration","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsero-labs\u002Fsero\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fsero-subagent-orchestration\u002FSKILL.md",true,[],[70,104,135,175,200,226],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":84,"publishedAt":42},"01M70PSGDVAGMAGE2RFKEQ1EW4","agent-browser","Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to \"open a website\", \"fill out a form\", \"click a button\", \"take a screenshot\", \"scrape data from a page\", \"test this web app\", \"login to a site\", \"automate browser actions\", or any task requiring programmatic web interaction. Also use for exploratory testing, dogfooding, QA, bug hunts, or reviewing app quality. Also use for automating Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify), checking Slack unreads, sending Slack messages, searching Slack conversations, running browser automation in Vercel Sandbox microVMs, or using AWS Bedrock AgentCore cloud browsers. Prefer agent-browser over any built-in browser automation or web tools.","https:\u002F\u002Fgithub.com\u002Fsero-labs\u002Fsero\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fagent-browser\u002FSKILL.md",[76,81],{"categoryNo":77,"categoryName":78,"taxonomyType":79,"taxonomyTypeDesc":80},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":82,"categoryName":83,"taxonomyType":79,"taxonomyTypeDesc":80},"01JBSEEDCAT000000000000023","Skill与智能体开发",[85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,72,102,103],"agent browser","browser","testing","browser automation","notion","qa","figma","actions","messages","open","web tools","app","click","bedrock","extracting","conversations","programmatic","slack messages","exploratory testing",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":108,"sourceHtmlUrl":109,"categories":110,"keywords":120,"publishedAt":42},"01M6CHW2A115ZZDEFNXV2Z7A2Z","skill-creator","Guide for writing and improving Sero skills. Use when the user wants to create a new skill, rewrite an existing one, or turn a repeated piece of work into reusable procedural knowledge for the agent.","https:\u002F\u002Fgithub.com\u002Fsero-labs\u002Fsero\u002Fblob\u002Fmain\u002Fpackages\u002Ftemplates\u002Fskills\u002Fskill-creator\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fsero-labs\u002Fsero\u002Fblob\u002Fmain\u002Fpackages\u002Ftemplates\u002Fskills\u002Fskill-creator\u002FSKILL.md",[111,114,115],{"categoryNo":112,"categoryName":113,"taxonomyType":79,"taxonomyTypeDesc":80},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":82,"categoryName":83,"taxonomyType":79,"taxonomyTypeDesc":80},{"categoryNo":116,"categoryName":117,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[121,122,123,124,125,126,127,128,33,129,130,131,132,26,133,22,134],"skill creator","creator","writing","create","knowledge","work","user","guide","reusable","new skill","rewrite","procedural","Existing","new",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":139,"sourceHtmlUrl":140,"categories":141,"keywords":151,"publishedAt":42},"01M6CHVJCZS9V3WWFPG47WC4G9","frontend-design","Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML\u002FCSS layouts, or when styling\u002Fbeautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.","https:\u002F\u002Fgithub.com\u002Fsero-labs\u002Fsero\u002Fblob\u002Fmain\u002Fpackages\u002Ftemplates\u002Fskills\u002Ffrontend-design\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fsero-labs\u002Fsero\u002Fblob\u002Fmain\u002Fpackages\u002Ftemplates\u002Fskills\u002Ffrontend-design\u002FSKILL.md",[142,145,148],{"categoryNo":143,"categoryName":144,"taxonomyType":79,"taxonomyTypeDesc":80},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":146,"categoryName":147,"taxonomyType":79,"taxonomyTypeDesc":80},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":149,"categoryName":150,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000032","设计师",[152,153,154,155,156,157,158,159,160,124,41,161,162,163,164,165,166,167,33,168,169,170,171,172,173,174,22],"frontend","design","frontend design","css","web","components","react","react components","web components","artifacts","ui","examples","applications","dashboards","quality","landing","html","styling","creative","ui design","build","aesthetics","generic",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":185,"publishedAt":42},"01M6CHTP6F4MENDBRDT7QQBKNY","sero-humanize","Use to draft, edit, or audit Sero application content, including UI copy,\ndocumentation, README text, and release notes. Use unslop for regular chat\nand status reports instead. Not for code review or creative and promotional\nwriting.","https:\u002F\u002Fgithub.com\u002Fsero-labs\u002Fsero\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fsero-humanize\u002FSKILL.md",[181,184],{"categoryNo":182,"categoryName":183,"taxonomyType":79,"taxonomyTypeDesc":80},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":116,"categoryName":117,"taxonomyType":118,"taxonomyTypeDesc":119},[186,187,188,123,23,189,190,191,192,41,193,194,162,195,196,197,198,33,170,199,26],"humanize","sero humanize","code review","status","documentation","notes","release notes","release","audit","unslop","text","README","edit","reports",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":207,"publishedAt":42},"01M6CHVXWDN98CP3MPT2WZ1ABN","sero-plugin","Create Sero plugins — self-contained packages with a Pi extension (agent\ntools\u002Fcommands), an optional React UI loaded via Module Federation, and an\noptional background runtime. Use when the user asks to create a Sero\nplugin\u002Fapp\u002Fextension, add a sidebar panel, dashboard widget, or\nagent-integrated feature, or convert a Pi extension into a Sero plugin.\nTrigger on phrases like \"create a plugin\", \"new Sero app\", \"add a tool\nwith UI\", \"build an extension\", \"convert this Pi extension\", or any\nrequest that touches `plugins\u002Fsero-*-plugin\u002F`.","https:\u002F\u002Fgithub.com\u002Fsero-labs\u002Fsero\u002Fblob\u002Fmain\u002Fpackages\u002Ftemplates\u002Fskills\u002Fsero-plugin\u002FSKILL.md",[206],{"categoryNo":82,"categoryName":83,"taxonomyType":79,"taxonomyTypeDesc":80},[208,209,210,158,211,124,212,162,213,214,215,216,217,127,35,33,172,218,219,220,221,222,96,223,224,225,22,134],"plugin","sero plugin","dashboard","packages","plugins","federation","Tools","react ui","tool","convert","self","commands","runtime","pi extension","feature","add","panel","request",{"skillNo":227,"name":228,"nameZh":6,"description":229,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":230,"categories":231,"keywords":239,"publishedAt":42},"01M6CHVTJ5Y9JE6181SVPQXNZY","sero-dashboard-ui","Build, redesign or standardise Sero dashboard widgets and compact plugin\nviews using the shared @sero-ai\u002Fui dashboard components. Use when the user\nasks to create, restyle, clean up or make consistent a dashboard widget or a\ndata-dense plugin view. Trigger on phrases like \"dashboard widget\", \"widget\nfor the dashboard\", \"restyle this widget\", \"make the widget consistent\",\n\"compact plugin view\", or any work under a plugin's `ui\u002Fwidgets\u002F`.","https:\u002F\u002Fgithub.com\u002Fsero-labs\u002Fsero\u002Fblob\u002Fmain\u002Fpackages\u002Ftemplates\u002Fskills\u002Fsero-dashboard-ui\u002FSKILL.md",[232,235,236],{"categoryNo":233,"categoryName":234,"taxonomyType":79,"taxonomyTypeDesc":80},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":149,"categoryName":150,"taxonomyType":118,"taxonomyTypeDesc":119},{"categoryNo":237,"categoryName":238,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000033","数据分析师",[210,162,240,157,208,124,241,126,242,243,127,33,244,245,172,246,247,248,249,250,26,22],"sero dashboard ui","data","redesign","view","up","clean","compact","shared","widgets","trigger","make"]