[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CRPDMQKXNFS38M3BV0JJEK":3,"skill-same:01M6CRPDMQKXNFS38M3BV0JJEK":73},{"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":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":50,"ownerHtmlUrl":51,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M6CRPDMQKXNFS38M3BV0JJEK","task-splitting",null,"Decompose requirement, design, or brainstorming documents into reviewable task drafts with one function per task and one file per task, then create `agent-team` task packages only after explicit approval. Use when turning a document into tasks, splitting oversized tasks, validating task boundaries, or preparing approved task files for `agent-team task create`.","JsonLee12138\u002Fagent-team","JsonLee12138","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160690954?v=4","01M6CRKT8H8MA8W638P9440WRV","01M6CRKTCSZEJGJSE7X4X8JZHT",33,"MIT","https:\u002F\u002Fgithub.com\u002FJsonLee12138\u002Fagent-team\u002Fblob\u002Fmain\u002Fskills\u002Ftask-splitting\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"task splitting","task","approval","document","files","oversized","decompose","only","use","design","team","file","create","packages","tasks","brainstorming","documents","2026-11-10 10:12:30",false,"---\nname: task-splitting\ndescription: \"Decompose requirement, design, or brainstorming documents into reviewable task drafts with one function per task and one file per task, then create `agent-team` task packages only after explicit approval. Use when turning a document into tasks, splitting oversized tasks, validating task boundaries, or preparing approved task files for `agent-team task create`.\"\n---\n\n# Task Splitting\n\nTurn source documents into explicit task boundaries. Keep decomposition separate from creation: draft and validate first, create `agent-team` tasks only after explicit user approval.\n\n## Workflow\n\n1. Intake the source document.\n2. Extract goals, constraints, deliverables, non-goals, and ambiguities.\n3. Decide whether `brainstorming` is needed.\n4. Draft tasks by function boundary.\n5. Validate every task boundary.\n6. Write one task file per task.\n7. Ask for confirmation.\n8. Create `agent-team` task packages from the approved files.\n\n## 1. Intake the source\n\n- Accept either raw document content or a local document path.\n- Read only the files needed for decomposition.\n- If the document is missing the goal, deliverable, or target output location for task files, ask before drafting.\n- If the user did not specify where task files should go, ask once. If they do not care, place them in a sibling directory next to the source document named `\u003Cdocument-stem>-tasks\u002F`.\n- Treat the source document plus user clarifications as the only authority for task scope.\n\n## 2. Decide whether to use `brainstorming`\n\nInvoke `brainstorming` before drafting tasks when any of these are true:\n\n- the document goal is ambiguous\n- scope conflicts exist\n- several decomposition strategies are equally reasonable\n- multiple functions are tangled together\n- the user wants discussion before task drafting\n\nDo not force `brainstorming` for a clear, well-bounded document.\n\n## 3. Decompose by function boundary\n\nApply these rules strictly:\n\n- Prefer one user-visible function or one clear sub-function per task.\n- Keep exactly one primary responsibility per task.\n- Keep task boundaries explicit.\n- Prefer one function per task, not one paragraph per task.\n- Reject grouping by document section when that creates mixed scope.\n- Do not merge multiple functions just because the document narrates them together.\n\nSplit a task when any of these are true:\n\n- it contains multiple peer functions\n- it contains more than one acceptance target\n- it mixes build and validation responsibilities\n- its dependency chain makes independent execution unclear\n\n## 4. Validate every task boundary\n\nA valid task must include all of the following:\n\n- exactly one function or sub-function\n- exactly one primary responsibility\n- a clear completion condition\n- an explicit in-scope section\n- an explicit out-of-scope section\n- explicit acceptance criteria\n- manageable dependencies\n\nIf a task fails any check, split or rewrite it before writing files.\n\n## 5. Write one task file per task\n\n- One task must map to one task definition file.\n- Treat the task file as the authoritative boundary definition.\n- Keep naming stable and reviewable, for example `01-auth-login.md`, `02-auth-session-check.md`.\n- Use the template in [references\u002Ftask-file-template.md](references\u002Ftask-file-template.md).\n- Do not create a combined summary file in place of per-task files.\n\n## 6. Request confirmation before creation\n\n- Present the drafted task set for review.\n- Surface ambiguities and unresolved questions.\n- Ask for explicit confirmation before creating any `agent-team` tasks.\n- If the user asks for changes, update the task files first. Do not redefine scope during the creation phase.\n\n## 7. Create `agent-team` tasks from approved files\n\nWhen the project exposes the `agent-team` CLI, create one task package per approved task file.\n\nConfirmed command surface:\n\n```bash\nagent-team task create --role \u003Crole> \"\u003Ctitle>\" --design \"\u003Ctask-file>\"\n```\n\nRules:\n\n- Do not create tasks before approval.\n- Preserve title, scope, dependencies, and acceptance exactly from the task file.\n- Do not reinterpret or expand scope during creation.\n- `--role` is required. Use the role named in the document or task file; otherwise ask the user instead of guessing.\n- Report exact success and failure results.\n- If creation partially fails, stop and return the created tasks plus the failures explicitly.\n\n## Output contract\n\n### Draft phase output\n\nReturn:\n\n- a short summary of the decomposition\n- the list of drafted task titles\n- the file path for each task file\n- any unresolved boundary questions\n- an explicit approval request\n\n### Creation phase output\n\nReturn:\n\n- each created task title\n- its source task file\n- the created task identifier if available\n- any failure with the exact file that failed\n\n## Guardrails\n\n- Do not implement code changes.\n- Do not let the creation phase rewrite scope.\n- Do not merge analysis, implementation, and testing into one task.\n- Do not force `brainstorming` when the boundaries are already clear.\n","# Task Splitting\n\nTurn source documents into explicit task boundaries. Keep decomposition separate from creation: draft and validate first, create `agent-team` tasks only after explicit user approval.\n\n## Workflow\n\n1. Intake the source document.\n2. Extract goals, constraints, deliverables, non-goals, and ambiguities.\n3. Decide whether `brainstorming` is needed.\n4. Draft tasks by function boundary.\n5. Validate every task boundary.\n6. Write one task file per task.\n7. Ask for confirmation.\n8. Create `agent-team` task packages from the approved files.\n\n## 1. Intake the source\n\n- Accept either raw document content or a local document path.\n- Read only the files needed for decomposition.\n- If the document is missing the goal, deliverable, or target output location for task files, ask before drafting.\n- If the user did not specify where task files should go, ask once. If they do not care, place them in a sibling directory next to the source document named `\u003Cdocument-stem>-tasks\u002F`.\n- Treat the source document plus user clarifications as the only authority for task scope.\n\n## 2. Decide whether to use `brainstorming`\n\nInvoke `brainstorming` before drafting tasks when any of these are true:\n\n- the document goal is ambiguous\n- scope conflicts exist\n- several decomposition strategies are equally reasonable\n- multiple functions are tangled together\n- the user wants discussion before task drafting\n\nDo not force `brainstorming` for a clear, well-bounded document.\n\n## 3. Decompose by function boundary\n\nApply these rules strictly:\n\n- Prefer one user-visible function or one clear sub-function per task.\n- Keep exactly one primary responsibility per task.\n- Keep task boundaries explicit.\n- Prefer one function per task, not one paragraph per task.\n- Reject grouping by document section when that creates mixed scope.\n- Do not merge multiple functions just because the document narrates them together.\n\nSplit a task when any of these are true:\n\n- it contains multiple peer functions\n- it contains more than one acceptance target\n- it mixes build and validation responsibilities\n- its dependency chain makes independent execution unclear\n\n## 4. Validate every task boundary\n\nA valid task must include all of the following:\n\n- exactly one function or sub-function\n- exactly one primary responsibility\n- a clear completion condition\n- an explicit in-scope section\n- an explicit out-of-scope section\n- explicit acceptance criteria\n- manageable dependencies\n\nIf a task fails any check, split or rewrite it before writing files.\n\n## 5. Write one task file per task\n\n- One task must map to one task definition file.\n- Treat the task file as the authoritative boundary definition.\n- Keep naming stable and reviewable, for example `01-auth-login.md`, `02-auth-session-check.md`.\n- Use the template in [references\u002Ftask-file-template.md](references\u002Ftask-file-template.md).\n- Do not create a combined summary file in place of per-task files.\n\n## 6. Request confirmation before creation\n\n- Present the drafted task set for review.\n- Surface ambiguities and unresolved questions.\n- Ask for explicit confirmation before creating any `agent-team` tasks.\n- If the user asks for changes, update the task files first. Do not redefine scope during the creation phase.\n\n## 7. Create `agent-team` tasks from approved files\n\nWhen the project exposes the `agent-team` CLI, create one task package per approved task file.\n\nConfirmed command surface:\n\n```bash\nagent-team task create --role \u003Crole> \"\u003Ctitle>\" --design \"\u003Ctask-file>\"\n```\n\nRules:\n\n- Do not create tasks before approval.\n- Preserve title, scope, dependencies, and acceptance exactly from the task file.\n- Do not reinterpret or expand scope during creation.\n- `--role` is required. Use the role named in the document or task file; otherwise ask the user instead of guessing.\n- Report exact success and failure results.\n- If creation partially fails, stop and return the created tasks plus the failures explicitly.\n\n## Output contract\n\n### Draft phase output\n\nReturn:\n\n- a short summary of the decomposition\n- the list of drafted task titles\n- the file path for each task file\n- any unresolved boundary questions\n- an explicit approval request\n\n### Creation phase output\n\nReturn:\n\n- each created task title\n- its source task file\n- the created task identifier if available\n- any failure with the exact file that failed\n\n## Guardrails\n\n- Do not implement code changes.\n- Do not let the creation phase rewrite scope.\n- Do not merge analysis, implementation, and testing into one task.\n- Do not force `brainstorming` when the boundaries are already clear.\n",{"name":5,"description":7},"main","4418944aaff7696bfb2cec18db747ade50817966","skills\u002Ftask-splitting",3,"https:\u002F\u002Fgithub.com\u002FJsonLee12138\u002Fagent-team","https:\u002F\u002Frole-hub.vercel.app\u002F","https:\u002F\u002Fgithub.com\u002FJsonLee12138","2026-03-30 10:24:45",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add JsonLee12138\u002Fagent-team --skill task-splitting",{"tool":59,"command":60},"bunx","bunx skills add JsonLee12138\u002Fagent-team --skill task-splitting",{"tool":62,"command":63},"pnpm","pnpm dlx skills add JsonLee12138\u002Fagent-team --skill task-splitting","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FJsonLee12138\u002Fagent-team\u002Fblob\u002Fmain\u002Fskills\u002Ftask-splitting\u002FSKILL.md",true,[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Ftask-file-template.md","REFERENCE","参考文档",1282,"https:\u002F\u002Fgithub.com\u002FJsonLee12138\u002Fagent-team\u002Fblob\u002Fmain\u002Fskills\u002Ftask-splitting\u002Freferences\u002Ftask-file-template.md",[74,93,107,120,131,141],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":81,"publishedAt":40},"01M6CRPTZHE0ZXSGTNJR4R2M5R","workflow-orchestrator","Governance-only workflow plan entry for controller and human sessions. Use when the user asks to generate, approve, activate, or close workflow plans through `agent-team workflow plan`.","https:\u002F\u002Fgithub.com\u002FJsonLee12138\u002Fagent-team\u002Fblob\u002Fmain\u002Fskills\u002Fworkflow-orchestrator\u002FSKILL.md",[80],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},[82,83,84,85,86,33,30,31,87,88,89,90,91,92],"workflow","orchestrator","workflow orchestrator","workflow plan","activate","user","plan","sessions","governance","generate","controller",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":40},"01M6CRPS54Q5XSN409CR0RPZQ7","worker-reply-main","Worker-first reporting entry for sending completion, blocker, or decision-needed messages back to main through `agent-team reply-main`.","https:\u002F\u002Fgithub.com\u002FJsonLee12138\u002Fagent-team\u002Fblob\u002Fmain\u002Fskills\u002Fworker-reply-main\u002FSKILL.md",[],[100,45,101,102,103,104,33,105,106],"reply","worker reply main","messages","reporting","first","decision","back",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":40},"01M6CRPQBDAQ7147TTNJ99DDMM","worker-recovery","Worker-first recovery entry for resuming the current assignment from file artifacts. Use when a worker needs to recover task context, continue work, or re-anchor after a pause.","https:\u002F\u002Fgithub.com\u002FJsonLee12138\u002Fagent-team\u002Fblob\u002Fmain\u002Fskills\u002Fworker-recovery\u002FSKILL.md",[],[114,115,116,117,118,31,24,104,119,34],"recovery","worker recovery","continue","work","context","artifacts",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":40},"01M6CRPNF2SKS2MQXFDZHXXGCM","worker-inspector","Read-only worker inspection skill for controller and human sessions. Use when the user wants to view worker status without opening a worker or sending a reply.","https:\u002F\u002Fgithub.com\u002FJsonLee12138\u002Fagent-team\u002Fblob\u002Fmain\u002Fskills\u002Fworker-inspector\u002FSKILL.md",[],[127,89,128,92,129,130,87,31,30,100],"worker inspector","status","read","view",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":137,"publishedAt":40},"01M6CRPKRNYGB80NN30TBKYCDJ","worker-dispatch","Controller-side worker dispatch entry for opening workers, checking targeted worker status, and replying to workers with existing `agent-team worker` and `agent-team reply` commands.","https:\u002F\u002Fgithub.com\u002FJsonLee12138\u002Fagent-team\u002Fblob\u002Fmain\u002Fskills\u002Fworker-dispatch\u002FSKILL.md",[],[138,139,92,128,33,140,100],"worker dispatch","dispatch","workers",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":147,"publishedAt":40},"01M6CRPH4EWCKQ9CD8JR5G5Z6Z","tdd","Acceptance-first TDD workflow for solo implementation work. Use when handling a coding change directly and you want to follow a disciplined sequence: read context, define acceptance criteria, write failing tests when feasible, implement, verify, and conclude with passed, failed, or skipped with reason.","https:\u002F\u002Fgithub.com\u002FJsonLee12138\u002Fagent-team\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002FSKILL.md",[],[143,148,82,149,150,151,104,152,153,117,129,154,118,31,155,156],"implement","change","acceptance","tdd workflow","verify","coding","write","implementation","acceptance criteria"]