[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71J671EDMQNZS2K3DGV80V2":3,"skill-same:01M71J671EDMQNZS2K3DGV80V2":70},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":53,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M71J671EDMQNZS2K3DGV80V2","decompose",null,"Sizing and decomposition policy for chipping-orchestrator issues. Use when you decompose an issue or adjudicate an oversized, already-implemented change: size it, decide single versus split, plan child issues and their dependencies, and emit the manifest the active prompt requires.","chippingway\u002Fchipping-orchestrator","chippingway","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F323052646?v=4","01M71J5ZFF9SY17XFHJ5C41BVZ","Chipping Way","01M71J5ZG5294QYTVYZJ2RHADZ",18,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fchippingway\u002Fchipping-orchestrator\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fdecompose\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"active","manifest","split","prompt","use","single","oversized","policy","for","issue","orchestrator","decomposition","child","change","plan","you","when","issues","decide","2026-11-10 10:12:30",false,"---\nname: decompose\ndescription: >-\n  Sizing and decomposition policy for chipping-orchestrator issues. Use when you\n  decompose an issue or adjudicate an oversized, already-implemented change:\n  size it, decide single versus split, plan child issues and their dependencies,\n  and emit the manifest the active prompt requires.\n---\n\n# Decomposer skill — chipping-orchestrator\n\nTwo stages ask the same question — can this work be cut into child issues that each deliver something of their own?\n— and answer it under different contracts:\n\n- **Initial decomposition** sizes an issue before any code exists and ends in an `orchestrator-manifest` block.\n- **Late adjudication** assesses a change a developer already wrote that measured past the addition ceiling, and ends\n  in an `orchestrator-late-manifest` block.\n\nThe prompt you were spawned with is the contract. Its output fence, decision values, child limit, lineage rules, and\nclarification format win over anything here; this skill tells you how to plan children this repository can land.\n\n## You plan; the orchestrator acts\n\nInspection and planning are read-only. Read the tree, grep, and use `git log`, `git diff`, or `wc -l` — never edit a\nfile, commit, push, fetch, or run anything that writes. You do not open issues either: the orchestrator reads your\nmanifest and creates the child issues itself, allocating their numbers, which is why `depends_on` indexes into your\nown children array.\n\n## A child's complete scope\n\nSize and describe each child by everything its normal pull-request lifecycle will require of it, not by its code\nalone:\n\n- the implementation;\n- the tests that prove it;\n- mechanically consequent documentation, inventories, and owner docstrings for every symbol or module it moves,\n  renames, or deletes — the pages the `develop` skill's [Documentation drift](..\u002Fdevelop\u002FSKILL.md#documentation-drift)\n  section lists;\n- the format and integration work repository policy requires — workflow labels, pinned-state fields, comment\n  markers, and event payloads keep their current formats under\n  [C-03](..\u002F..\u002F..\u002Fdocs\u002Fcontracts.md#c-03-persisted-and-externally-consumed-formats), so a child that deliberately\n  changes one updates the affected contracts, specifications, and tests with it, and one that removes a historical\n  format owes no migration or compatibility reader;\n- the final documentation pass every implementation PR receives after reviewer approval\n  ([documenting stage](..\u002F..\u002F..\u002Fdocs\u002Fstate-machine.md#_handle_documenting-label-workflowdocumenting)).\n\nPoint a child body at those sections rather than restating them. Two kinds of child follow from this closure and must\nnot be proposed:\n\n- a **checks-only** child — \"run the suite\", \"confirm lint passes\", \"verify nothing broke\" — because every child\n  already owes its own checks;\n- a **mechanical documentation cleanup** child for work a prerequisite already owes — updating names, inventories,\n  counts, diagrams, or descriptions because another child moved, renamed, or removed something. That child's own\n  scope and its final documentation pass cover it.\n\n## Sizing by scope and effort\n\nThe sizing question is whether the complete deliverable — everything in the scope above — fits one coding-agent\ncontext: one implementer investigates it, builds it, proves it, documents it, and carries it through review without\nlosing the thread. Judge that from:\n\n- the number and complexity of the distinct behaviors it delivers;\n- how tightly the changes are coupled — whether one can be built or verified without the others;\n- the context an implementer has to read and hold: the owners, contracts, specifications, and tests around them;\n- the effort needed to verify the result — new fixtures, failure and recovery paths, integration tests.\n\nFile and commit counts can guide inspection, but neither decides single versus split on its own, and no other count\nstands in for them as a cutoff. A coherent, manageable change stays one child however many files its completion\ntouches; a change concentrated in one or two files can still hold several substantial behaviors that each deserve a\nchild of their own.\n\nWhen the complete work is too large, split it at meaningful deliverable boundaries: each child delivers a behavior a\nreviewer can accept on its own, carries its own acceptance criteria and verification, and is manageable in one\ncontext. Before committing to a split, compare it with the plausible coarser groupings:\n\n- Prefer fewer complete children while their combined scope stays manageable. Every extra child repeats\n  investigation, adds integration work, and puts another dependency handoff — a whole implement, review, and merge\n  cycle — between the parent and its completion.\n- A different file, owner, layer, or display is not on its own a reason for another child. Merge adjacent slices that\n  read the same context and share their verification unless the merged child would no longer be manageable.\n- The prompt's child limit is a ceiling, not a target. A split that reaches it, or a long serial chain of\n  dependencies, is a reason to re-check the coarser groupings, though neither alone proves the split wrong.\n- A residual parent implementation is sized by the same rule: once every child has landed, what the parent keeps must\n  fit one context by itself.\n\nExplain the decision in the `rationale` by concrete scope and dependencies — the behaviors, their coupling, the\nboundaries kept and why — rather than by a raw count.\n\n## The residual test\n\nBefore emitting any split, run this for every proposed child B:\n\n1. Collect every **direct and transitive** prerequisite of B.\n2. Assume they have all landed **completely** on the base: implementation, tests, consequent documentation,\n   format and integration work, and their final documentation pass.\n3. Re-read B against that repository.\n4. B survives only if it keeps at least one **unique acceptance criterion** and a **predicted non-empty diff** that\n   delivers it.\n5. A B whose criteria one prerequisite already delivers, or several deliver between them, has no residual work: fold\n   its requirements into the children that own them, or redraw the split.\n\nEvaluate the prerequisites as one completed set, never edge by edge. If A delivers X and C delivers Y, a B that depends\non both and promises only X and Y has nothing left, even though neither A nor C alone contains it. Dependencies order\nwork; they do not make overlapping scopes independent.\n\nAlso compare siblings with no dependency edge between them for **duplicate semantic ownership**: two children that\npromise the same behavior are a defect whatever files they list. File overlap is a hint, not a verdict, in either\ndirection — children editing the same file can each own distinct behavior, and file-disjoint children can still\nduplicate one requirement. Never require each child to own a file no sibling touches.\n\n## Worked cases\n\n- **Many files, one change.** Requiring one new manifest field touches the shared validator, the prompts that state\n  the field, the readers of recorded manifests, their tests, and the state-machine, workflow, and architecture pages\n  that describe the refusal — a dozen files for one rule with one acceptance criterion and one set of tests. When an\n  implementer can hold that context, it stays `single`. Splitting the prompt wording, the validator, or the pages apart\n  would leave children that each half-land the rule or have no residual work.\n- **Few files, several deliverables.** One stage module gaining a park with its resume path, a reworked retry budget,\n  and recovery for a new crash window holds three behaviors, each with its own failure paths, fixtures, and\n  documentation. If together they exceed one context, children that each edit that module are a valid split when each\n  carries its own acceptance criterion and tests: the shared file is not a conflict to split around. If together they\n  stay manageable, they stay one child. The small file count decides neither way.\n- **Many candidate slices.** An issue spanning several contracts or subsystems — accounting, capture, recovery, and\n  route integrations, say — offers more boundaries than it needs. Start from the coarsest grouping whose children each\n  stay manageable. Keep a boundary only where the two sides deliver and verify different behavior, or where one must\n  land first for the other to be built or proven, and merge slices that read the same owners and share their tests.\n  Before emitting a split at the child limit with nearly every child waiting on another, check whether adjacent links\n  in that chain can share one implementation pass.\n- **Removal.** The child that deletes a helper or module also owns the inventory entries, prose, and docstrings that\n  name it. Put likely grep targets in its body — for example the entry under `docs\u002Farchitecture\u002F`, the stage page under\n  `docs\u002Fstate-machine\u002F`, and the owner module's docstring — so its implementer knows where to look. A separate \"remove\n  the documentation for X\" child has no residual work.\n- **Dormant prerequisite, then activation.** A prerequisite may land dormant — built, directly tested, documented, and\n  reached by nothing in production — when that is safe. Its scope is its declared slice, not every future consumer.\n  The child that wires it into the tick, prompt, or handler owns real activation work: the call site, the recovery and\n  failure paths, the integration tests, and the documentation of the live behavior.\n- **Docs-only child.** Valid only for an independently valuable deliverable that still remains once every prerequisite\n  has landed — a migration guide, an operator runbook, a tutorial, a cross-cutting conceptual page. Its whole diff may\n  then be documentation. Re-describing what another child changed is not such a deliverable.\n\n## Child bodies\n\nEvery child body states:\n\n- its **unique deliverable** and the **acceptance criteria** that prove it;\n- the **likely owners and files**, including the documentation pages and docstrings it must update;\n- its **verification** — the tests it adds or updates and the checks it runs;\n- its **dependencies**, matching `depends_on`, and what it assumes they delivered.\n\n## Stage contracts\n\n### Initial decomposition\n\n- **Coverage.** Assign every parent requirement exactly once, to one child or to an explicitly named residual parent\n  diff. Then re-read the parent as if every child had landed completely. When nothing remains, set `\"umbrella\": true`.\n  Use `\"umbrella\": false` only when the parent keeps a named, non-empty deliverable of its own, and describe that\n  residual in the `rationale` so the parent's later implementation run has a clear handoff.\n- **Sizing.** Size each child, and any residual parent work, by its complete scope as\n  [Sizing by scope and effort](#sizing-by-scope-and-effort) describes. Keep coupled documentation attached to the\n  change that forces it: detaching it to make a child look smaller creates exactly the cleanup child rejected above.\n- **Single.** When the complete scope is manageable in one context, or cannot be cut without an empty or overlapping\n  child, return `\"single\"` in the `orchestrator-manifest` block, and hand the implementer your groundwork through\n  `affected_files` and `notes`.\n- **Clarification.** End with a question for the human and emit no manifest, as the prompt says.\n\n### Late adjudication\n\n- **Coverage.** Partition the declared scope completely among the children, each part owned by exactly one. There is\n  no `umbrella` field here and no parent coding pass to reserve work for.\n- **Slicing.** Before answering `single`, consider dependency-ordered slices, dormant prerequisites included, as the\n  prompt requires.\n- **Sizing.** Each child's `estimated_added_lines` counts the lines it adds over every path in its diff —\n  implementation, tests, documentation, fixtures, generated files — stays strictly below the ceiling the prompt\n  supplies, and leaves headroom for review fixes. The scope-and-effort judgment above shapes where slices fall but\n  never replaces or loosens this budget: a slice that fits one context still has to clear it, and a coarser grouping\n  is viable only while every child still clears it with that headroom.\n- **No safe split.** Answer `\"single\"` in the `orchestrator-late-manifest` block with a `split_blocker` naming what\n  makes a safe split unavailable. That verdict publishes nothing: it hands the publication decision to a human.\n- **Clarification.** Ask through the `\"question\"` decision inside the block; prose alone is not an outcome here.\n\nIn both stages keep the prompt's child limit, lineage rules, decision semantics, and clarification format, and never\ncarry one stage's fence, fields, or meaning of `single` into the other.\n\n## Before you emit the manifest\n\nValid JSON is not a valid manifest. A reply that parses but leaves out a field its decision requires is refused even\nthough your run exited cleanly — a split whose children all omit `depends_on` is the failure this check exists for.\nAn initial decomposition's refused manifest is handed back to your session once, with the exact error, for one\ncomplete corrected manifest; a second refusal, and any refusal in late adjudication, parks the issue for a human.\nRe-read the block against the active prompt's schema, field by field:\n\n- the fence the prompt names, one block, and nothing after its closing line;\n- a `decision` value the prompt allows, and every field that decision requires there;\n- on a split, an explicit `depends_on` array on **every** child — `[]` for none, never omitted or `null` — naming\n  exactly the prerequisites that child's body and your `rationale` describe, with no self-dependency or cycle;\n- the child limit, and in late adjudication each child's `estimated_added_lines` and a `single`'s `split_blocker`.\n","# Decomposer skill — chipping-orchestrator\n\nTwo stages ask the same question — can this work be cut into child issues that each deliver something of their own?\n— and answer it under different contracts:\n\n- **Initial decomposition** sizes an issue before any code exists and ends in an `orchestrator-manifest` block.\n- **Late adjudication** assesses a change a developer already wrote that measured past the addition ceiling, and ends\n  in an `orchestrator-late-manifest` block.\n\nThe prompt you were spawned with is the contract. Its output fence, decision values, child limit, lineage rules, and\nclarification format win over anything here; this skill tells you how to plan children this repository can land.\n\n## You plan; the orchestrator acts\n\nInspection and planning are read-only. Read the tree, grep, and use `git log`, `git diff`, or `wc -l` — never edit a\nfile, commit, push, fetch, or run anything that writes. You do not open issues either: the orchestrator reads your\nmanifest and creates the child issues itself, allocating their numbers, which is why `depends_on` indexes into your\nown children array.\n\n## A child's complete scope\n\nSize and describe each child by everything its normal pull-request lifecycle will require of it, not by its code\nalone:\n\n- the implementation;\n- the tests that prove it;\n- mechanically consequent documentation, inventories, and owner docstrings for every symbol or module it moves,\n  renames, or deletes — the pages the `develop` skill's [Documentation drift](..\u002Fdevelop\u002FSKILL.md#documentation-drift)\n  section lists;\n- the format and integration work repository policy requires — workflow labels, pinned-state fields, comment\n  markers, and event payloads keep their current formats under\n  [C-03](..\u002F..\u002F..\u002Fdocs\u002Fcontracts.md#c-03-persisted-and-externally-consumed-formats), so a child that deliberately\n  changes one updates the affected contracts, specifications, and tests with it, and one that removes a historical\n  format owes no migration or compatibility reader;\n- the final documentation pass every implementation PR receives after reviewer approval\n  ([documenting stage](..\u002F..\u002F..\u002Fdocs\u002Fstate-machine.md#_handle_documenting-label-workflowdocumenting)).\n\nPoint a child body at those sections rather than restating them. Two kinds of child follow from this closure and must\nnot be proposed:\n\n- a **checks-only** child — \"run the suite\", \"confirm lint passes\", \"verify nothing broke\" — because every child\n  already owes its own checks;\n- a **mechanical documentation cleanup** child for work a prerequisite already owes — updating names, inventories,\n  counts, diagrams, or descriptions because another child moved, renamed, or removed something. That child's own\n  scope and its final documentation pass cover it.\n\n## Sizing by scope and effort\n\nThe sizing question is whether the complete deliverable — everything in the scope above — fits one coding-agent\ncontext: one implementer investigates it, builds it, proves it, documents it, and carries it through review without\nlosing the thread. Judge that from:\n\n- the number and complexity of the distinct behaviors it delivers;\n- how tightly the changes are coupled — whether one can be built or verified without the others;\n- the context an implementer has to read and hold: the owners, contracts, specifications, and tests around them;\n- the effort needed to verify the result — new fixtures, failure and recovery paths, integration tests.\n\nFile and commit counts can guide inspection, but neither decides single versus split on its own, and no other count\nstands in for them as a cutoff. A coherent, manageable change stays one child however many files its completion\ntouches; a change concentrated in one or two files can still hold several substantial behaviors that each deserve a\nchild of their own.\n\nWhen the complete work is too large, split it at meaningful deliverable boundaries: each child delivers a behavior a\nreviewer can accept on its own, carries its own acceptance criteria and verification, and is manageable in one\ncontext. Before committing to a split, compare it with the plausible coarser groupings:\n\n- Prefer fewer complete children while their combined scope stays manageable. Every extra child repeats\n  investigation, adds integration work, and puts another dependency handoff — a whole implement, review, and merge\n  cycle — between the parent and its completion.\n- A different file, owner, layer, or display is not on its own a reason for another child. Merge adjacent slices that\n  read the same context and share their verification unless the merged child would no longer be manageable.\n- The prompt's child limit is a ceiling, not a target. A split that reaches it, or a long serial chain of\n  dependencies, is a reason to re-check the coarser groupings, though neither alone proves the split wrong.\n- A residual parent implementation is sized by the same rule: once every child has landed, what the parent keeps must\n  fit one context by itself.\n\nExplain the decision in the `rationale` by concrete scope and dependencies — the behaviors, their coupling, the\nboundaries kept and why — rather than by a raw count.\n\n## The residual test\n\nBefore emitting any split, run this for every proposed child B:\n\n1. Collect every **direct and transitive** prerequisite of B.\n2. Assume they have all landed **completely** on the base: implementation, tests, consequent documentation,\n   format and integration work, and their final documentation pass.\n3. Re-read B against that repository.\n4. B survives only if it keeps at least one **unique acceptance criterion** and a **predicted non-empty diff** that\n   delivers it.\n5. A B whose criteria one prerequisite already delivers, or several deliver between them, has no residual work: fold\n   its requirements into the children that own them, or redraw the split.\n\nEvaluate the prerequisites as one completed set, never edge by edge. If A delivers X and C delivers Y, a B that depends\non both and promises only X and Y has nothing left, even though neither A nor C alone contains it. Dependencies order\nwork; they do not make overlapping scopes independent.\n\nAlso compare siblings with no dependency edge between them for **duplicate semantic ownership**: two children that\npromise the same behavior are a defect whatever files they list. File overlap is a hint, not a verdict, in either\ndirection — children editing the same file can each own distinct behavior, and file-disjoint children can still\nduplicate one requirement. Never require each child to own a file no sibling touches.\n\n## Worked cases\n\n- **Many files, one change.** Requiring one new manifest field touches the shared validator, the prompts that state\n  the field, the readers of recorded manifests, their tests, and the state-machine, workflow, and architecture pages\n  that describe the refusal — a dozen files for one rule with one acceptance criterion and one set of tests. When an\n  implementer can hold that context, it stays `single`. Splitting the prompt wording, the validator, or the pages apart\n  would leave children that each half-land the rule or have no residual work.\n- **Few files, several deliverables.** One stage module gaining a park with its resume path, a reworked retry budget,\n  and recovery for a new crash window holds three behaviors, each with its own failure paths, fixtures, and\n  documentation. If together they exceed one context, children that each edit that module are a valid split when each\n  carries its own acceptance criterion and tests: the shared file is not a conflict to split around. If together they\n  stay manageable, they stay one child. The small file count decides neither way.\n- **Many candidate slices.** An issue spanning several contracts or subsystems — accounting, capture, recovery, and\n  route integrations, say — offers more boundaries than it needs. Start from the coarsest grouping whose children each\n  stay manageable. Keep a boundary only where the two sides deliver and verify different behavior, or where one must\n  land first for the other to be built or proven, and merge slices that read the same owners and share their tests.\n  Before emitting a split at the child limit with nearly every child waiting on another, check whether adjacent links\n  in that chain can share one implementation pass.\n- **Removal.** The child that deletes a helper or module also owns the inventory entries, prose, and docstrings that\n  name it. Put likely grep targets in its body — for example the entry under `docs\u002Farchitecture\u002F`, the stage page under\n  `docs\u002Fstate-machine\u002F`, and the owner module's docstring — so its implementer knows where to look. A separate \"remove\n  the documentation for X\" child has no residual work.\n- **Dormant prerequisite, then activation.** A prerequisite may land dormant — built, directly tested, documented, and\n  reached by nothing in production — when that is safe. Its scope is its declared slice, not every future consumer.\n  The child that wires it into the tick, prompt, or handler owns real activation work: the call site, the recovery and\n  failure paths, the integration tests, and the documentation of the live behavior.\n- **Docs-only child.** Valid only for an independently valuable deliverable that still remains once every prerequisite\n  has landed — a migration guide, an operator runbook, a tutorial, a cross-cutting conceptual page. Its whole diff may\n  then be documentation. Re-describing what another child changed is not such a deliverable.\n\n## Child bodies\n\nEvery child body states:\n\n- its **unique deliverable** and the **acceptance criteria** that prove it;\n- the **likely owners and files**, including the documentation pages and docstrings it must update;\n- its **verification** — the tests it adds or updates and the checks it runs;\n- its **dependencies**, matching `depends_on`, and what it assumes they delivered.\n\n## Stage contracts\n\n### Initial decomposition\n\n- **Coverage.** Assign every parent requirement exactly once, to one child or to an explicitly named residual parent\n  diff. Then re-read the parent as if every child had landed completely. When nothing remains, set `\"umbrella\": true`.\n  Use `\"umbrella\": false` only when the parent keeps a named, non-empty deliverable of its own, and describe that\n  residual in the `rationale` so the parent's later implementation run has a clear handoff.\n- **Sizing.** Size each child, and any residual parent work, by its complete scope as\n  [Sizing by scope and effort](#sizing-by-scope-and-effort) describes. Keep coupled documentation attached to the\n  change that forces it: detaching it to make a child look smaller creates exactly the cleanup child rejected above.\n- **Single.** When the complete scope is manageable in one context, or cannot be cut without an empty or overlapping\n  child, return `\"single\"` in the `orchestrator-manifest` block, and hand the implementer your groundwork through\n  `affected_files` and `notes`.\n- **Clarification.** End with a question for the human and emit no manifest, as the prompt says.\n\n### Late adjudication\n\n- **Coverage.** Partition the declared scope completely among the children, each part owned by exactly one. There is\n  no `umbrella` field here and no parent coding pass to reserve work for.\n- **Slicing.** Before answering `single`, consider dependency-ordered slices, dormant prerequisites included, as the\n  prompt requires.\n- **Sizing.** Each child's `estimated_added_lines` counts the lines it adds over every path in its diff —\n  implementation, tests, documentation, fixtures, generated files — stays strictly below the ceiling the prompt\n  supplies, and leaves headroom for review fixes. The scope-and-effort judgment above shapes where slices fall but\n  never replaces or loosens this budget: a slice that fits one context still has to clear it, and a coarser grouping\n  is viable only while every child still clears it with that headroom.\n- **No safe split.** Answer `\"single\"` in the `orchestrator-late-manifest` block with a `split_blocker` naming what\n  makes a safe split unavailable. That verdict publishes nothing: it hands the publication decision to a human.\n- **Clarification.** Ask through the `\"question\"` decision inside the block; prose alone is not an outcome here.\n\nIn both stages keep the prompt's child limit, lineage rules, decision semantics, and clarification format, and never\ncarry one stage's fence, fields, or meaning of `single` into the other.\n\n## Before you emit the manifest\n\nValid JSON is not a valid manifest. A reply that parses but leaves out a field its decision requires is refused even\nthough your run exited cleanly — a split whose children all omit `depends_on` is the failure this check exists for.\nAn initial decomposition's refused manifest is handed back to your session once, with the exact error, for one\ncomplete corrected manifest; a second refusal, and any refusal in late adjudication, parks the issue for a human.\nRe-read the block against the active prompt's schema, field by field:\n\n- the fence the prompt names, one block, and nothing after its closing line;\n- a `decision` value the prompt allows, and every field that decision requires there;\n- on a split, an explicit `depends_on` array on **every** child — `[]` for none, never omitted or `null` — naming\n  exactly the prerequisites that child's body and your `rationale` describe, with no self-dependency or cycle;\n- the child limit, and in late adjudication each child's `estimated_added_lines` and a `single`'s `split_blocker`.\n",{"name":5,"description":7},"main","987be97a68d2e55b8d0fd5b36c9a0775588fa552",".agents\u002Fskills\u002Fdecompose",4,"https:\u002F\u002Fgithub.com\u002Fchippingway\u002Fchipping-orchestrator","https:\u002F\u002Fchippingway.github.io\u002Fchipping-orchestrator\u002F","https:\u002F\u002Fgithub.com\u002Fchippingway","2026-11-15 03:17:36",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add chippingway\u002Fchipping-orchestrator --skill decompose",{"tool":62,"command":63},"bunx","bunx skills add chippingway\u002Fchipping-orchestrator --skill decompose",{"tool":65,"command":66},"pnpm","pnpm dlx skills add chippingway\u002Fchipping-orchestrator --skill decompose","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fchippingway\u002Fchipping-orchestrator\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fdecompose\u002FSKILL.md",true,[],[71,77,83,88,112],{"skillNo":72,"name":73,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":43},"01M71J6GGHE6K199YSB0ZKM3HQ","review","https:\u002F\u002Fgithub.com\u002Fchippingway\u002Fchipping-orchestrator\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Freview\u002FSKILL.md",[],[73],{"skillNo":78,"name":79,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":43},"01M71J6FBNDZBQF3AF05RGGNTT","develop","https:\u002F\u002Fgithub.com\u002Fchippingway\u002Fchipping-orchestrator\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fdevelop\u002FSKILL.md",[],[79],{"skillNo":84,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":43},"01M71J6EEGDDQY8QMDPW335XBQ","https:\u002F\u002Fgithub.com\u002Fchippingway\u002Fchipping-orchestrator\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fdecompose\u002FSKILL.md",[],[5],{"skillNo":89,"name":73,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":102,"publishedAt":43},"01M71J6CH051SZX156VGGCSVBQ","Review checklist for reviewer agents on chipping-orchestrator PRs. Use when evaluating a developer-produced branch before approval or change-requests.","https:\u002F\u002Fgithub.com\u002Fchippingway\u002Fchipping-orchestrator\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Freview\u002FSKILL.md",[93,96,97],{"categoryNo":94,"categoryName":95,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":98,"categoryName":99,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[73,40,103,104,105,28,106,32,107,34,37,108,109,110,111],"approval","checklist","requests","prs","developer","review checklist","reviewer","change-requests","branch",{"skillNo":113,"name":79,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":119,"publishedAt":43},"01M71J6AC1EDHXYVA3TGBBFY13","Project conventions and recurring gotchas for implementer agents working on chipping-orchestrator. Use before committing any change in orchestrator\u002F, tests\u002F, or docs\u002F.","https:\u002F\u002Fgithub.com\u002Fchippingway\u002Fchipping-orchestrator\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fdevelop\u002FSKILL.md",[117,118],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":98,"categoryName":99,"taxonomyType":100,"taxonomyTypeDesc":101},[79,120,121,28,122,32,123,34,124,37,125,126],"docs","conventions","tests","recurring","project conventions","project","implementer"]