[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71SC0H4QYYZD9THQZ5VAB02":3,"skill-same:01M71SC0H4QYYZD9THQZ5VAB02":86},{"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":22,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":56,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":71},"01M71SC0H4QYYZD9THQZ5VAB02","subagents",null,"Use this skill when Pioneer should delegate current-turn work to attached task-backed subagents, coordinate parallel child agents, wait for child results, review\u002Frevise\u002Faccept\u002Fcancel\u002Fdetach attached work, or synthesize accepted child results into the parent answer.","pioneerdotai\u002Fpioneer","pioneerdotai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F267592302?v=4","01M71SB358NQ2T40CJFEXCAZKV","01M71SB35YBM3GPT0PWWSPMPF7",21,"MIT","https:\u002F\u002Fgithub.com\u002Fpioneerdotai\u002Fpioneer\u002Fblob\u002Fmain\u002Fresources\u002Fskills\u002Fpioneer\u002Fsubagents\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"wait","task","cancel","accept","use","true","answer","for","parallel","revise","child","work","review","synthesize","when","false","delegate","wait for","coordinate","2026-11-10 13:02:02",false,"---\nname: subagents\nslug: subagents\nowner: pioneer\ndescription: \"Use this skill when Pioneer should delegate current-turn work to attached task-backed subagents, coordinate parallel child agents, wait for child results, review\u002Frevise\u002Faccept\u002Fcancel\u002Fdetach attached work, or synthesize accepted child results into the parent answer.\"\nversion: \"0.2.3\"\nuser-invocable: true\ndisable-model-invocation: false\nimplicit-invocation: required\ncatalog-hide: true\n---\n\n# Pioneer Attached Subagents\n\nAttached subagents are task-backed child agents created to help with the current user turn. They do focused work in hidden child threads, but the parent agent owns the user-facing outcome.\n\nA child result is evidence, not the final user answer, until the parent reviews it, accepts it, integrates it, or deliberately rejects\u002Froutes it elsewhere.\n\nThe initiating thread is the original user-facing conversation. A subagent executes in an internal child thread; its parent may also be a child. The parent inspects child results before using them in the user-facing answer. Formal Task acceptance is required only when requireReview:true was selected.\n\n## Product Model\n\nUse this skill for immediate delegation only:\n\n- parallel investigation;\n- independent verification;\n- focused review;\n- independent file\u002Fsystem\u002Fhypothesis inspection;\n- work that should block the parent answer until reviewed.\n\nDo not use this skill for scheduled, recurring, future, or long-running background work. For durable future\u002Fbackground tasks, read `system:pioneer\u002Ftasks`.\n\n## Communication Boundary\n\nInter-agent chat is not currently supported. Do not use `thread_message_send`, `threads_turn_start`, or equivalent conversation writes to exchange instructions, progress, questions, blockers, or results between parent, child, or sibling agents.\n\nA child returns its result and blockers in its own execution thread. With requireReview:false it completes automatically; the parent reads the terminal result through task_wait\u002Ftask_get. With requireReview:true it submits a review candidate; the parent reads task_wait\u002Ftask_result and uses task_accept\u002Ftask_revise. Do not send an additional message to announce or duplicate the result.\n\n## Quick Start\n\nBefore delegating, decide whether attached subagents improve the current answer.\n\n1. If the user needs one direct answer and the work is small, tightly coupled, or sequential, do it in the parent turn.\n2. If independent focused work improves speed, coverage, verification, or auditability, use `task_create` to create attached subagents.\n3. Create independent child tasks first. Use requireReview:false normally; explicitly select true when the assignment needs formal acceptance and same-worker revisions.\n4. Call `task_wait` until the next child result is terminal or requires review.\n5. Inspect each returned terminal result. For review-required candidates, read complete reviewContent, paging through task_result when necessary.\n6. For review-required candidates, accept good work or request revisions. Automatically completed results need no task_accept and cannot be reopened with task_revise. Cancel or detach active work only when appropriate.\n7. Call `task_wait` again for the remaining active runs and repeat the review cycle until all child work is resolved.\n8. Synthesize the parent answer from accepted results and direct parent work.\n\nDo not finish the parent turn while attached subagents created by this turn are pending, running, waiting for review, or producing unreviewed candidates.\n\n## Load References When Needed\n\nKeep this file in context for the normal attached-subagent flow. Load detailed references only when the matching situation appears:\n\n- Read `references\u002Ftool-schemas.md` before constructing non-trivial attached-subagent `task_*` payloads, after schema errors, or when exact field names matter.\n- Read `references\u002Fworkflows-and-examples.md` for concrete attached-subagent examples: parallel investigation, independent review, parent synthesis, revision, cancel, and detach.\n- Read `references\u002Ftroubleshooting.md` after bad child results, missing evidence, review confusion, parent finished too early, schema errors, or stuck attached work.\n\nFor scheduled task delivery, cron, recurring runs, task updates, or delivery troubleshooting, read `system:pioneer\u002Ftasks` instead.\n\n## CLI Runtime Binding\n\nWhen Pioneer provides these operations through its CLI MCP facade, use the callable names in the current CLI tool catalog. The turn instructions bind the canonical task names to those callables. The catalog is fixed for that turn; use only the operations it contains. No `request_tools` call is needed in this environment.\n\nIn CLI runtimes, `system:pioneer\u002Ftasks` means the exported `pioneer-system-tasks` skill and `system:pioneer\u002Fsubagents` means the exported `pioneer-system-subagents` skill. Load them using the runtime's skill mechanism or read their exported `SKILL.md` files. Resolve `references\u002F` relative to the loaded skill directory. Other system skill references do not imply that a CLI export or tool is available. Use artifact tools only when the current catalog provides them.\n\n## Tool Visibility\n\nOnly call task tools that are visible in the current turn.\n\nIf a needed task tool is hidden and `request_tools` is visible, request the task domain:\n\n```json\n{\n  \"domains\": [\"task\"],\n  \"reason\": \"Need task tools to create, wait for, review, revise, accept, cancel, detach, or inspect attached subagent work.\"\n}\n```\n\nDo not request individual task tool names. Request the `task` domain.\n\nThe `task` domain also exposes `threads_start_options`; opening `threads` separately is unnecessary to inspect task launch options. Call it when you need to choose an identity, execution profile, or permitted destination explicitly. For an ordinary attached task that inherits the parent's identity and profile, omit `launch` and `targetOptionId`; no preliminary options call is required. Options list permitted selections but do not grant execution rights. See `references\u002Ftool-schemas.md` for the exact fields.\n\nIf the task domain cannot be opened, do not pretend a subagent was created, waited on, accepted, revised, cancelled, or detached.\n\n## When To Delegate\n\nCreate attached subagents when at least one is true:\n\n- the user explicitly asks for subagents, agents, parallel work, independent workers, or review;\n- the task naturally splits into independent parts;\n- separate agents can inspect different files, systems, tools, or hypotheses in parallel;\n- the parent needs independent verification before committing to an answer;\n- the work is large enough that one parent timeline would be hard to audit.\n\nPrefer parent-only work when:\n\n- the task is small, obvious, or single-step;\n- each next step depends on one previous result;\n- delegation would add coordination overhead without improving quality;\n- the user asks not to delegate.\n\n## Create Good Attached Subagents\n\nFor immediate attached subagents, omit `trigger` and normally set `requireReview:false`. Set true before launching work that requires formal acceptance or revisions.\n\nGood child tasks are narrow and auditable:\n\n- `title`: short label visible in the parent timeline.\n- `goal`: one concrete outcome.\n- `instructions`: behavior, constraints, and what not to do.\n- `inputText` or `input`: data, paths, ids, dates, examples, and scope.\n- `outputInstructions`: exact result shape, evidence requirements, and language.\n\nUse self-contained wording. Do not rely on hidden parent reasoning, invisible local assumptions, or tool names that might not exist in the child turn.\n\nAsk for file:line references when code claims matter. Ask children to register user-visible files with `artifact_register` when they create files.\n\nDo not pass runtime-owned fields such as `workspaceId`, `ownerKind`, `parentTaskId`, `rootTaskId`, `depth`, `model`, `modelProvider`, or `trigger.spec`.\n\nRead `references\u002Ftool-schemas.md` for exact payload examples.\n\n## Wait And Review\n\nTask reading, control, and review follow the authorized root-thread capsule and current action grants\u002Fcapabilities, including in later turns or independent executions. Reading full candidate content requires permitted result reading, not final-review authority. Accept\u002Frevise additionally enforce UserFinal, required advisory\u002Fquorum policy, authentic actor binding, and the prohibition on self-acceptance. Creator identity and execution graph do not grant exclusive review rights.\n\nAn access or runtime error is not proof that a child stopped. Do not recreate work or claim cancellation on that basis; report the unresolved state and avoid duplicate work. See `system:pioneer\u002Ftasks` for durable task access and failure handling.\n\nFor independent attached subagents, create them all first, then call `task_wait` with `taskIds` or `runIds`. Prefer `runIds` when available. By default, `task_wait` returns as soon as any target is terminal or requires review. Handle every returned result before calling `task_wait` again for the remaining active runs.\n\nThe parent may also keep working and check a child with `task_get`. A `running` run has not finished; a missing result or unchanged `updatedAt` does not show that it is stuck. In `task_get`, `execution.heartbeatAt` is a liveness signal, while `execution.lastActivityAt` records confirmed task activity when available. Missing activity data is unknown. Do not cancel or repeat a child's work solely because time passed or repeated observations look the same. A `task_wait` `timedOut` result ends only that wait window; wait again for active attached work when needed.\n\n`task_wait` can return terminal results, pending work, or `reviewRequired`. A review-required candidate is not final. Inspect every candidate and accept only when it satisfies:\n\n- the original user request;\n- the child task goal;\n- the requested output shape;\n- evidence and artifact requirements;\n- safety, scope, and write constraints.\n\nFor an authorized result reader, `reviewRequired.reviewContent` contains the reviewer-safe child result for that exact candidate. Do not decide from `summary` alone; summary is only a preview and may be just the first heading. If `reviewContent.truncated` is true, call `task_result` with the candidate's `candidateId`, then continue with each returned `nextCursor` until the complete content has been inspected. Use the same `task_result(candidateId)` flow to re-read a candidate after recovery or context compaction.\n\nAlways read by `candidateId`, not by `taskId`: a task may have several immutable revision rounds, and the review decision must apply to the exact content that was inspected.\n\nUse `task_revise` when the result is close but incomplete or incorrectly shaped. Give concrete feedback: what is wrong, what to add\u002Fremove\u002Fcorrect, and what the revised output must look like.\n\nUse `task_accept` only after the candidate is good enough to use. Use accepted child results in the parent synthesis.\n\nAfter accepting, revising, or cancelling the returned candidates, call `task_wait` again for unresolved active runs. Continue this wait-review cycle until no attached child work remains unresolved.\n\nUse `task_cancel` when the child is irrelevant, unsafe, duplicate, or no longer needed.\n\nUse `task_detach` only when the work should continue in the background and no longer block the parent turn. Do not detach review-required work; accept, revise, or cancel the active candidate first.\n\n## Before Finalizing\n\nValidate the attached-subagent state before answering the user:\n\n- every relevant child is terminal, accepted, revised, cancelled, or deliberately detached;\n- review-required candidates are inspected;\n- accepted candidates are the only candidates treated as final evidence;\n- failures, cancellations, detached work, and uncertainty are accounted for.\n\n## Final Parent Answer\n\nThe final user-facing answer comes from the parent.\n\nInclude only what matters:\n\n- which subagents ran, when useful;\n- which results were accepted or revised, when relevant;\n- any failures, cancellations, or detached work;\n- the integrated answer;\n- links or artifacts created by parent or children.\n\nDo not paste raw child outputs blindly. Combine duplicate findings, preserve important evidence, and write one coherent parent response.\n\n## Gotchas\n\n- Attached subagents are for current-turn delegation, not scheduled future work.\n- `task_wait` uses arrays: `taskIds` or `runIds`, not singular `taskId` or `runId`.\n- A `pending_review` candidate is not accepted work.\n- A candidate `summary` is a preview, not sufficient review evidence; inspect `reviewContent` or call `task_result`.\n- Do not quote rejected candidates as final results.\n- Do not finish while attached child work from this turn is unresolved.\n- Do not claim a child was created, accepted, revised, cancelled, or detached unless the relevant tool succeeded.\n\n## Review choice and later executions\n\nUse `requireReview:false` for ordinary task\u002Fsubagent work; it is the default for\nall types and attachment modes, including scheduled, interval, cron and webhook.\nSet `requireReview:true` explicitly when each run result must wait for acceptance\nand may need same-worker revisions. The meaning does not depend on the trigger.\nEnabled review has no timeout acceptance. The saved policy supplies the revision\nbudget (normally five); acceptance is final. Detaching a task or changing its\nschedule does not silently change its saved review choice.\n\nLater authorized executions in the same capsule can inspect and review saved\nworkers under current grants, without creator\u002Fgraph ownership or adoption.\n`task_get.reviewRequired` exposes current candidate references and available\nactions; read full content through `task_result(candidateId)` and all pages.\nFor recurring\u002Fwebhook work, decisions target the exact run and candidate, even\nwhen another run is queued or running. Read access does not require TaskReview;\nself-review, policy eligibility, finality and stale-candidate guards still apply.\n\nBackground work without review defaults to origin_thread delivery. For\n`background:true` plus `requireReview:true`, omitted deliveryPolicy selects none;\nan explicit permitted policy wins. Results, errors and blocked\u002Fexhausted outcomes\nfollow that same policy. None keeps results\u002Fhistory available without delivery.\nScheduled work retains its existing delivery defaults and requires self-contained\ninstructions and available Skills\u002FMCP; capability inheritance is not promised.\n","# Pioneer Attached Subagents\n\nAttached subagents are task-backed child agents created to help with the current user turn. They do focused work in hidden child threads, but the parent agent owns the user-facing outcome.\n\nA child result is evidence, not the final user answer, until the parent reviews it, accepts it, integrates it, or deliberately rejects\u002Froutes it elsewhere.\n\nThe initiating thread is the original user-facing conversation. A subagent executes in an internal child thread; its parent may also be a child. The parent inspects child results before using them in the user-facing answer. Formal Task acceptance is required only when requireReview:true was selected.\n\n## Product Model\n\nUse this skill for immediate delegation only:\n\n- parallel investigation;\n- independent verification;\n- focused review;\n- independent file\u002Fsystem\u002Fhypothesis inspection;\n- work that should block the parent answer until reviewed.\n\nDo not use this skill for scheduled, recurring, future, or long-running background work. For durable future\u002Fbackground tasks, read `system:pioneer\u002Ftasks`.\n\n## Communication Boundary\n\nInter-agent chat is not currently supported. Do not use `thread_message_send`, `threads_turn_start`, or equivalent conversation writes to exchange instructions, progress, questions, blockers, or results between parent, child, or sibling agents.\n\nA child returns its result and blockers in its own execution thread. With requireReview:false it completes automatically; the parent reads the terminal result through task_wait\u002Ftask_get. With requireReview:true it submits a review candidate; the parent reads task_wait\u002Ftask_result and uses task_accept\u002Ftask_revise. Do not send an additional message to announce or duplicate the result.\n\n## Quick Start\n\nBefore delegating, decide whether attached subagents improve the current answer.\n\n1. If the user needs one direct answer and the work is small, tightly coupled, or sequential, do it in the parent turn.\n2. If independent focused work improves speed, coverage, verification, or auditability, use `task_create` to create attached subagents.\n3. Create independent child tasks first. Use requireReview:false normally; explicitly select true when the assignment needs formal acceptance and same-worker revisions.\n4. Call `task_wait` until the next child result is terminal or requires review.\n5. Inspect each returned terminal result. For review-required candidates, read complete reviewContent, paging through task_result when necessary.\n6. For review-required candidates, accept good work or request revisions. Automatically completed results need no task_accept and cannot be reopened with task_revise. Cancel or detach active work only when appropriate.\n7. Call `task_wait` again for the remaining active runs and repeat the review cycle until all child work is resolved.\n8. Synthesize the parent answer from accepted results and direct parent work.\n\nDo not finish the parent turn while attached subagents created by this turn are pending, running, waiting for review, or producing unreviewed candidates.\n\n## Load References When Needed\n\nKeep this file in context for the normal attached-subagent flow. Load detailed references only when the matching situation appears:\n\n- Read `references\u002Ftool-schemas.md` before constructing non-trivial attached-subagent `task_*` payloads, after schema errors, or when exact field names matter.\n- Read `references\u002Fworkflows-and-examples.md` for concrete attached-subagent examples: parallel investigation, independent review, parent synthesis, revision, cancel, and detach.\n- Read `references\u002Ftroubleshooting.md` after bad child results, missing evidence, review confusion, parent finished too early, schema errors, or stuck attached work.\n\nFor scheduled task delivery, cron, recurring runs, task updates, or delivery troubleshooting, read `system:pioneer\u002Ftasks` instead.\n\n## CLI Runtime Binding\n\nWhen Pioneer provides these operations through its CLI MCP facade, use the callable names in the current CLI tool catalog. The turn instructions bind the canonical task names to those callables. The catalog is fixed for that turn; use only the operations it contains. No `request_tools` call is needed in this environment.\n\nIn CLI runtimes, `system:pioneer\u002Ftasks` means the exported `pioneer-system-tasks` skill and `system:pioneer\u002Fsubagents` means the exported `pioneer-system-subagents` skill. Load them using the runtime's skill mechanism or read their exported `SKILL.md` files. Resolve `references\u002F` relative to the loaded skill directory. Other system skill references do not imply that a CLI export or tool is available. Use artifact tools only when the current catalog provides them.\n\n## Tool Visibility\n\nOnly call task tools that are visible in the current turn.\n\nIf a needed task tool is hidden and `request_tools` is visible, request the task domain:\n\n```json\n{\n  \"domains\": [\"task\"],\n  \"reason\": \"Need task tools to create, wait for, review, revise, accept, cancel, detach, or inspect attached subagent work.\"\n}\n```\n\nDo not request individual task tool names. Request the `task` domain.\n\nThe `task` domain also exposes `threads_start_options`; opening `threads` separately is unnecessary to inspect task launch options. Call it when you need to choose an identity, execution profile, or permitted destination explicitly. For an ordinary attached task that inherits the parent's identity and profile, omit `launch` and `targetOptionId`; no preliminary options call is required. Options list permitted selections but do not grant execution rights. See `references\u002Ftool-schemas.md` for the exact fields.\n\nIf the task domain cannot be opened, do not pretend a subagent was created, waited on, accepted, revised, cancelled, or detached.\n\n## When To Delegate\n\nCreate attached subagents when at least one is true:\n\n- the user explicitly asks for subagents, agents, parallel work, independent workers, or review;\n- the task naturally splits into independent parts;\n- separate agents can inspect different files, systems, tools, or hypotheses in parallel;\n- the parent needs independent verification before committing to an answer;\n- the work is large enough that one parent timeline would be hard to audit.\n\nPrefer parent-only work when:\n\n- the task is small, obvious, or single-step;\n- each next step depends on one previous result;\n- delegation would add coordination overhead without improving quality;\n- the user asks not to delegate.\n\n## Create Good Attached Subagents\n\nFor immediate attached subagents, omit `trigger` and normally set `requireReview:false`. Set true before launching work that requires formal acceptance or revisions.\n\nGood child tasks are narrow and auditable:\n\n- `title`: short label visible in the parent timeline.\n- `goal`: one concrete outcome.\n- `instructions`: behavior, constraints, and what not to do.\n- `inputText` or `input`: data, paths, ids, dates, examples, and scope.\n- `outputInstructions`: exact result shape, evidence requirements, and language.\n\nUse self-contained wording. Do not rely on hidden parent reasoning, invisible local assumptions, or tool names that might not exist in the child turn.\n\nAsk for file:line references when code claims matter. Ask children to register user-visible files with `artifact_register` when they create files.\n\nDo not pass runtime-owned fields such as `workspaceId`, `ownerKind`, `parentTaskId`, `rootTaskId`, `depth`, `model`, `modelProvider`, or `trigger.spec`.\n\nRead `references\u002Ftool-schemas.md` for exact payload examples.\n\n## Wait And Review\n\nTask reading, control, and review follow the authorized root-thread capsule and current action grants\u002Fcapabilities, including in later turns or independent executions. Reading full candidate content requires permitted result reading, not final-review authority. Accept\u002Frevise additionally enforce UserFinal, required advisory\u002Fquorum policy, authentic actor binding, and the prohibition on self-acceptance. Creator identity and execution graph do not grant exclusive review rights.\n\nAn access or runtime error is not proof that a child stopped. Do not recreate work or claim cancellation on that basis; report the unresolved state and avoid duplicate work. See `system:pioneer\u002Ftasks` for durable task access and failure handling.\n\nFor independent attached subagents, create them all first, then call `task_wait` with `taskIds` or `runIds`. Prefer `runIds` when available. By default, `task_wait` returns as soon as any target is terminal or requires review. Handle every returned result before calling `task_wait` again for the remaining active runs.\n\nThe parent may also keep working and check a child with `task_get`. A `running` run has not finished; a missing result or unchanged `updatedAt` does not show that it is stuck. In `task_get`, `execution.heartbeatAt` is a liveness signal, while `execution.lastActivityAt` records confirmed task activity when available. Missing activity data is unknown. Do not cancel or repeat a child's work solely because time passed or repeated observations look the same. A `task_wait` `timedOut` result ends only that wait window; wait again for active attached work when needed.\n\n`task_wait` can return terminal results, pending work, or `reviewRequired`. A review-required candidate is not final. Inspect every candidate and accept only when it satisfies:\n\n- the original user request;\n- the child task goal;\n- the requested output shape;\n- evidence and artifact requirements;\n- safety, scope, and write constraints.\n\nFor an authorized result reader, `reviewRequired.reviewContent` contains the reviewer-safe child result for that exact candidate. Do not decide from `summary` alone; summary is only a preview and may be just the first heading. If `reviewContent.truncated` is true, call `task_result` with the candidate's `candidateId`, then continue with each returned `nextCursor` until the complete content has been inspected. Use the same `task_result(candidateId)` flow to re-read a candidate after recovery or context compaction.\n\nAlways read by `candidateId`, not by `taskId`: a task may have several immutable revision rounds, and the review decision must apply to the exact content that was inspected.\n\nUse `task_revise` when the result is close but incomplete or incorrectly shaped. Give concrete feedback: what is wrong, what to add\u002Fremove\u002Fcorrect, and what the revised output must look like.\n\nUse `task_accept` only after the candidate is good enough to use. Use accepted child results in the parent synthesis.\n\nAfter accepting, revising, or cancelling the returned candidates, call `task_wait` again for unresolved active runs. Continue this wait-review cycle until no attached child work remains unresolved.\n\nUse `task_cancel` when the child is irrelevant, unsafe, duplicate, or no longer needed.\n\nUse `task_detach` only when the work should continue in the background and no longer block the parent turn. Do not detach review-required work; accept, revise, or cancel the active candidate first.\n\n## Before Finalizing\n\nValidate the attached-subagent state before answering the user:\n\n- every relevant child is terminal, accepted, revised, cancelled, or deliberately detached;\n- review-required candidates are inspected;\n- accepted candidates are the only candidates treated as final evidence;\n- failures, cancellations, detached work, and uncertainty are accounted for.\n\n## Final Parent Answer\n\nThe final user-facing answer comes from the parent.\n\nInclude only what matters:\n\n- which subagents ran, when useful;\n- which results were accepted or revised, when relevant;\n- any failures, cancellations, or detached work;\n- the integrated answer;\n- links or artifacts created by parent or children.\n\nDo not paste raw child outputs blindly. Combine duplicate findings, preserve important evidence, and write one coherent parent response.\n\n## Gotchas\n\n- Attached subagents are for current-turn delegation, not scheduled future work.\n- `task_wait` uses arrays: `taskIds` or `runIds`, not singular `taskId` or `runId`.\n- A `pending_review` candidate is not accepted work.\n- A candidate `summary` is a preview, not sufficient review evidence; inspect `reviewContent` or call `task_result`.\n- Do not quote rejected candidates as final results.\n- Do not finish while attached child work from this turn is unresolved.\n- Do not claim a child was created, accepted, revised, cancelled, or detached unless the relevant tool succeeded.\n\n## Review choice and later executions\n\nUse `requireReview:false` for ordinary task\u002Fsubagent work; it is the default for\nall types and attachment modes, including scheduled, interval, cron and webhook.\nSet `requireReview:true` explicitly when each run result must wait for acceptance\nand may need same-worker revisions. The meaning does not depend on the trigger.\nEnabled review has no timeout acceptance. The saved policy supplies the revision\nbudget (normally five); acceptance is final. Detaching a task or changing its\nschedule does not silently change its saved review choice.\n\nLater authorized executions in the same capsule can inspect and review saved\nworkers under current grants, without creator\u002Fgraph ownership or adoption.\n`task_get.reviewRequired` exposes current candidate references and available\nactions; read full content through `task_result(candidateId)` and all pages.\nFor recurring\u002Fwebhook work, decisions target the exact run and candidate, even\nwhen another run is queued or running. Read access does not require TaskReview;\nself-review, policy eligibility, finality and stale-candidate guards still apply.\n\nBackground work without review defaults to origin_thread delivery. For\n`background:true` plus `requireReview:true`, omitted deliveryPolicy selects none;\nan explicit permitted policy wins. Results, errors and blocked\u002Fexhausted outcomes\nfollow that same policy. None keeps results\u002Fhistory available without delivery.\nScheduled work retains its existing delivery defaults and requires self-contained\ninstructions and available Skills\u002FMCP; capability inheritance is not promised.\n",{"name":5,"slug":5,"owner":47,"version":48,"description":7,"catalog-hide":49,"user-invocable":49,"implicit-invocation":50,"disable-model-invocation":43},"pioneer","0.2.3",true,"required","main","26d7a9ea1ada362743a95dc3c09243d1fc23bad2","resources\u002Fskills\u002Fpioneer\u002Fsubagents",3,"https:\u002F\u002Fgithub.com\u002Fpioneerdotai\u002Fpioneer","https:\u002F\u002Fgetpioneer.dev","https:\u002F\u002Fgithub.com\u002Fpioneerdotai","2026-11-13 02:27:16",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":49},[61,64,67],{"tool":62,"command":63},"npx","npx skills add pioneerdotai\u002Fpioneer --skill subagents",{"tool":65,"command":66},"bunx","bunx skills add pioneerdotai\u002Fpioneer --skill subagents",{"tool":68,"command":69},"pnpm","pnpm dlx skills add pioneerdotai\u002Fpioneer --skill subagents","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpioneerdotai\u002Fpioneer\u002Fblob\u002Fmain\u002Fresources\u002Fskills\u002Fpioneer\u002Fsubagents\u002FSKILL.md",[72,78,82],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Ftool-schemas.md","REFERENCE","参考文档",7864,"https:\u002F\u002Fgithub.com\u002Fpioneerdotai\u002Fpioneer\u002Fblob\u002Fmain\u002Fresources\u002Fskills\u002Fpioneer\u002Fsubagents\u002Freferences\u002Ftool-schemas.md",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Ftroubleshooting.md",3961,"https:\u002F\u002Fgithub.com\u002Fpioneerdotai\u002Fpioneer\u002Fblob\u002Fmain\u002Fresources\u002Fskills\u002Fpioneer\u002Fsubagents\u002Freferences\u002Ftroubleshooting.md",{"path":83,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fworkflows-and-examples.md",4500,"https:\u002F\u002Fgithub.com\u002Fpioneerdotai\u002Fpioneer\u002Fblob\u002Fmain\u002Fresources\u002Fskills\u002Fpioneer\u002Fsubagents\u002Freferences\u002Fworkflows-and-examples.md",[87,108,128,152,174,197],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":94,"publishedAt":42},"01M71SC6J236HF21HBM63EBPYJ","threads","Use this skill to find and read accessible conversations, follow saved sources and child threads, read saved tool results, create a conversation, send a message, or start a permitted thread turn.","https:\u002F\u002Fgithub.com\u002Fpioneerdotai\u002Fpioneer\u002Fblob\u002Fmain\u002Fresources\u002Fskills\u002Fpioneer\u002Fthreads\u002FSKILL.md",[93],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[89,95,96,97,98,38,99,33,100,101,102,103,28,27,104,105,106,107],"conversation","sources","conversations","send","create","message","read","start","tool","thread","saved","results","find",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":115,"publishedAt":42},"01M71SC3B8PGF9J54B4N1R1NR5","tasks","Use this skill when Pioneer should create, inspect, update, reschedule, pause, resume, finish, cancel, troubleshoot, or configure delivery for durable tasks, scheduled tasks, recurring tasks, interval tasks, cron jobs, background work, or existing task state.","https:\u002F\u002Fgithub.com\u002Fpioneerdotai\u002Fpioneer\u002Fblob\u002Fmain\u002Fresources\u002Fskills\u002Fpioneer\u002Ftasks\u002FSKILL.md",[114],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[110,116,117,38,37,118,99,34,119,120,121,122,123,124,125,126,30,28,27,127],"inspect","scheduled","configure","delivery","update","troubleshoot","finish","cron","cron jobs","recurring","pause","Existing",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":135,"publishedAt":42},"01M71SBXY8K4DRC54QVE4P9VMS","runtime-diagnostics","Investigate Pioneer Gateway or desktop CPU, memory, slow work, queues, and runtime stalls using process metrics, local snapshots, bounded native profiles, and exact release symbols. Use for Pioneer performance diagnosis and interpreting its diagnostic artifacts.","https:\u002F\u002Fgithub.com\u002Fpioneerdotai\u002Fpioneer\u002Fblob\u002Fmain\u002Fresources\u002Fskills\u002Fpioneer\u002Fruntime-diagnostics\u002FSKILL.md",[134],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[136,137,138,139,140,141,38,142,34,143,144,145,146,147,148,149,150,30,151,28],"diagnostics","runtime","runtime diagnostics","memory","performance","local","snapshots","native","CPU","diagnosis","release","queues","bounded","metrics","gateway","profiles",{"skillNo":153,"name":139,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":158,"publishedAt":42},"01M71SBV7Q5A9QZCHKK66W7R9J","Use this skill when Pioneer should proactively use durable memory or recalled context: decide whether memory can improve a turn, answer from remembered user\u002Fproject facts, request memory tools, search\u002Flist\u002Fget stored memories, save durable preferences or project decisions, forget memories, audit or clean up memory, or recover from memory tool failures.","https:\u002F\u002Fgithub.com\u002Fpioneerdotai\u002Fpioneer\u002Fblob\u002Fmain\u002Fresources\u002Fskills\u002Fpioneer\u002Fmemory\u002FSKILL.md",[157],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[139,159,160,161,162,163,164,165,166,38,37,167,168,169,170,171,172,173,29,103],"get","project","decide","search","up","clean","improve","memory tools","audit","request","list","Tools","context","save","memories",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":178,"sourceHtmlUrl":179,"categories":180,"keywords":185,"publishedAt":42},"01M71SBRZTY2Q7QDYG1SNBHJDV","html","Create inline HTML documents with CSS and embedded JavaScript in Pioneer messages, including interactive calculators, charts, and small working interfaces. Do not use for ordinary application edits merely involving HTML.","https:\u002F\u002Fgithub.com\u002Fpioneerdotai\u002Fpioneer\u002Fblob\u002Fmain\u002Fresources\u002Fskills\u002Fpioneer\u002Fhtml\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fpioneerdotai\u002Fpioneer\u002Fblob\u002Fmain\u002Fresources\u002Fskills\u002Fpioneer\u002Fhtml\u002FSKILL.md",[181,184],{"categoryNo":182,"categoryName":183,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[176,186,187,188,38,189,99,190,191,30,28,27,192,193,194,195,196],"css","Charts","messages","documents","inline","do","interactive","javascript","with","embedded","application",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":201,"licenseFileUrl":202,"sourceHtmlUrl":203,"categories":204,"keywords":206,"publishedAt":42},"01M71SBNVQPVE7XH2Q50VPJQ3S","browser","Use agent-browser to interact with websites, inspect rendered pages, fill forms, extract data, capture screenshots or PDFs, and test web interfaces. Includes browser-backed QA and CDP-enabled Electron app workflows.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fpioneerdotai\u002Fpioneer\u002Fblob\u002Fmain\u002Fresources\u002Fskills\u002Fpioneer\u002Fbrowser\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fpioneerdotai\u002Fpioneer\u002Fblob\u002Fmain\u002Fresources\u002Fskills\u002Fpioneer\u002Fbrowser\u002FSKILL.md",[205],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[199,207,208,209,116,210,38,211,212,213,214,215,216,217,218,219,28,220,27,221],"app","cdp","agent-browser","qa","workflows","references","cli","test web","forms","data","screenshots","target","pdfs","pages","electron"]