[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CF5C8RCTB41NF7NXVJ3ME5":3,"skill-same:01M6CF5C8RCTB41NF7NXVJ3ME5":68},{"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":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":6,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M6CF5C8RCTB41NF7NXVJ3ME5","compose",null,"Decide when to publish a new skill, when to compose existing skills, and how to declare the contracts that make that composition coherent.","usurobor\u002Fcnos","usurobor","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F182342826?v=4","01M6CEXJCRMYD8HB2315FGB1Q8","Peter Lisovin","01M6CEXJH2RW04GQ2SNXY40F5S",9,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.core\u002Fskills\u002Fcompose\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31],"publish","Composition","how","decide","behavior","embedded","contracts","coherent","2026-11-10 10:12:30",false,"---\nname: compose\ndescription: Decide when to publish a new skill, when to compose existing skills, and how to declare the contracts that make that composition coherent.\nartifact_class: skill\nkata_surface: embedded\ngoverning_question: How do we compose skills without overlap, drift, or hidden order?\ntriggers:\n  - designing a new skill\n  - deciding whether behavior belongs in a neighbor skill\n  - resolving overlap between skills\n  - declaring skill order for a task\n  - reviewing whether a proposal should be a composition instead\nscope: task-local\n---\n\n# Composition\n\n## Core Principle\n\nCoherent composition keeps axis, contract, trigger, order, and ownership aligned so each skill changes one thing, loads at the right time, hands off cleanly, and shares no silent source of truth.\n\nThis skill teaches how to decide whether behavior belongs in a new skill or in a composition of existing skills, then declare the contracts and order that make that decision executable.\n\nThis skill transforms a skill proposal or skill set along the axis of compositional fitness.\n\nComposition fails through overlap and hidden order.\n\nThe skill skill governs whether an artifact is a skill and how skill artifacts are structured. The write skill governs prose coherence and shared house style. This skill adds only what compose adds.\n\n## Algorithm\n\n1. Define — classify the artifact, name the parts, state the formula, the governing question, and the failure mode.\n2. Unfold — declare axis, contracts, trigger, order, ownership, exclusions, and the publish-or-compose verdict.\n3. Rules — write imperative rules with stable IDs and contrastive ❌\u002F✅ examples.\n4. Verify — check that the skill composes cleanly and can be practiced.\n\n---\n\n## 1. Define\n\n### 1.0. Classify the artifact first\n\nComposition is itself a skill because it has a domain-specific formula, teaches judgment about skill boundaries and order, benefits from Define → Unfold → Rules, and exposes a kata.\n\nApply the same test to the artifact under review. Valid classes:\n\n- skill — teaches repeatable judgment in a domain\n- runbook — teaches ordered operational steps\n- reference — provides lookup-oriented material\n- deprecated — is superseded and should not remain live\n\nUse this skill only for artifacts of class skill. Reclassify everything else before you continue.\n\n- ❌ Treat a reference as if it were a skill\n- ✅ Reclassify first, then compose only true skills\n\n### 1.1. Identify the parts\n\nComposition has six parts:\n\n- skill — the unit being composed\n- axis — what it changes\n- contract — what it assumes and guarantees\n- trigger — when it should load\n- order — what runs before or after it\n- owner — where each shared rule or stable fact lives\n\nIf one part is missing, the composition decision is vague. If two parts blur together, skills overlap.\n\n- ❌ Talk about composition in generalities\n- ✅ Name the axis, contract, trigger, order, and owner before deciding to publish\n\n### 1.2. Articulate how they fit\n\nSkills compose when each one owns one axis, declares entry and exit contracts, loads on a distinct trigger, runs in explicit order, and points shared rules to one owner.\n\nIf axis, contract, trigger, order, or ownership is missing, the composition overlaps, drifts, or misfires.\n\n- ❌ \"Coherent composition is combining related skills well\"\n- ✅ \"Coherent composition keeps axis, contract, trigger, order, and ownership aligned so each skill changes one thing and hands off cleanly\"\n\n### 1.3. Name the governing question\n\n> This skill teaches how to decide whether work belongs in one skill, several composed skills, or no skill at all, and how to declare the composition once chosen.\n\n- ❌ One artifact teaching composition, release policy, and versioning at once\n- ✅ One artifact teaching composition judgment and declaration\n\n### 1.4. Name the failure mode\n\nComposition fails through overlap and hidden order.\n\nTypical signs:\n\n- two skills own the same rule\n- one skill assumes another ran first but does not say so\n- two skills trigger on the same situation without a clear distinction\n- a proposed skill duplicates a viable composition\n- one skill changes two axes\n- a shared fact has two homes\n\n- ❌ Generic: \"doing it wrong\"\n- ✅ Specific: \"composition fails through overlap and hidden order\"\n\n---\n\n## 2. Unfold\n\n### 2.1. Keep one skill on one axis\n\nA skill that changes two axes is two skills sharing a file. Split it.\n\n- ❌ A single skill that changes structure, voice, and format\n- ✅ Separate skills for structure, voice, and format, composed in order\n\n### 2.2. Declare the axis in one sentence\n\nState the axis with this sentence:\n\n> This skill transforms \u003Cartifact> along the axis of \u003Caxis>.\n\nIf the sentence needs an \"and,\" the skill probably has two axes.\n\n- ❌ \"This skill transforms a draft along the axis of coherence and tone\"\n- ✅ \"This skill transforms a draft along the axis of structural coherence\"\n\n### 2.3. Declare entry and exit contracts\n\nA contract says what must be true on entry and what will be true on exit. Use this shape:\n\n- Input:\n- Output:\n\nThis skill's own contract is:\n\n- Input: a skill proposal, skill pair, or load plan with neighboring authorities available\n- Output: a composition verdict with explicit axis, trigger, contract, order, and ownership decisions\n\n- ❌ \"Takes a document and makes it better\"\n- ✅ \"Input: prose with a governing question. Output: sections align to sub-questions and stable facts have one home\"\n\n### 2.4. Declare the trigger\n\nA trigger distinguishes this skill from its neighbors. If the trigger is vague, the skill will be double-loaded or loaded too late.\n\nUse this shape:\n\n> Use when...\n\n- ❌ \"Use when writing matters\"\n- ✅ \"Use when deciding whether new behavior belongs in a new skill or in a composition of existing skills\"\n\n### 2.5. Declare pipeline order\n\nState what runs before, what runs after, what the skill assumes, and what it leaves true. Use this shape:\n\n- Runs after:\n- Runs before:\n- Assumes:\n- Produces:\n\nThis skill itself composes like this:\n\n- Runs after: skill\n- Runs before: publication, bundling, or co-load decisions\n- Assumes: candidate artifacts are already classified or are being classified now\n- Produces: a composition verdict, declared contracts, and ownership decisions\n\n- ❌ Assume a neighbor skill ran first without saying so\n- ✅ Declare the handoff explicitly\n\n### 2.6. Assign one owner to every shared rule\n\nWhen two skills appear to share a rule, choose one owner and replace the other copy with a pointer.\n\nUse write for prose rules. Use skill for skill-form rules. Add a new owner only when neither existing skill owns the rule.\n\n- ❌ Restate \"front-load the point\" in three skills with slight wording drift\n- ✅ Let write own the rule; point to it from neighboring skills\n\n### 2.7. Declare exclusions on both sides\n\nIf two skills should not run together, both skills should say so.\n\n- ❌ Discover the conflict only when outputs disagree\n- ✅ Declare the exclusion in both artifacts\n\n### 2.8. Prefer composition before publication\n\nBefore publishing a new skill, name the best alternative composition and the specific gap it leaves. Publish only when that gap is real and owned by no existing skill.\n\n- ❌ Publish blog because it feels different from essay\n- ✅ Compare essay + voice(casual) + write to the proposed skill, then publish only if a specific transformation is still missing\n\n### 2.9. Expose a kata surface\n\nEvery true skill must be practice-ready. The kata appears below.\n\n---\n\n## 3. Rules\n\n### 3.1. Classify before composing\n\nDecide whether the artifact is a skill, runbook, reference, or deprecated artifact before you write composition logic.\n\n- ❌ Add composition language to a lookup page\n- ✅ Reclassify the artifact, then compose only true skills\n\n### 3.2. State one axis\n\nWrite the axis in one sentence and reject any skill that needs two axes to explain itself.\n\n- ❌ \"Improves drafts in many ways\"\n- ✅ \"Transforms a draft along the axis of structural coherence\"\n\n### 3.3. Declare both contracts\n\nState what the skill needs on entry and what it guarantees on exit.\n\n- ❌ \"Takes a draft and improves it\"\n- ✅ \"Input: prose with a governing question. Output: each section answers one sub-question\"\n\n### 3.4. State the trigger sharply\n\nWrite a trigger that distinguishes the skill from its neighbors.\n\n- ❌ \"Use when writing\"\n- ✅ \"Use when revising expository prose for structural coherence\"\n\n### 3.5. Declare order explicitly\n\nName the handoff. Do not make neighboring skills infer it.\n\n- ❌ Order inferred from file names or habit\n- ✅ \"Runs after write. Runs before naturalize.\"\n\n### 3.6. Move shared rules to one owner\n\nGive each shared rule or stable fact one home, then point to that home elsewhere.\n\n- ❌ The same authority rule restated in multiple skills with drift\n- ✅ One owner, named directly, with pointers from the rest\n\n### 3.7. Declare exclusions in both skills\n\nIf A conflicts with B, A names B and B names A.\n\n- ❌ Only one side declares the conflict\n- ✅ Both skills name the exclusion\n\n### 3.8. Name the alternative composition before publishing\n\nA new skill must say which existing composition it replaces and what that composition cannot do.\n\n- ❌ Publish a new skill because the topic feels distinct\n- ✅ Name the missing transformation that no existing composition owns\n\n### 3.9. Compose, do not extend\n\nNever express skill relationships as inheritance.\n\n- ❌ \"`newsletter` extends `write`\"\n- ✅ \"`newsletter` composes with write and adds newsletter-specific form rules\"\n\n### 3.10. Test the skill in isolation\n\nA skill should show its effect on a sample artifact without needing the whole pipeline to make sense.\n\n- ❌ \"Its effect only appears after three other skills run\"\n- ✅ A before\u002Fafter example shows the axis it changes\n\n### 3.11. Keep authority explicit\n\nSay which surface governs on disagreement.\n\n- ❌ Let the reader infer whether skill or write governs\n- ✅ \"design governs system decomposition. skill governs skill form. write governs prose rules. compose applies design to artifacts of class skill, adding triggers, classification, and the publish-or-compose verdict.\"\n\n---\n\n## 4. Verify\n\n### 4.1. Classification check\n\nIs the artifact really a skill? If not, reclassify it before composing.\n\n### 4.2. Parts check\n\nAre axis, contract, trigger, order, and owner all named?\n\n### 4.3. Overlap check\n\nDoes any rule, stable fact, or decision have two homes?\n\n### 4.4. Trigger check\n\nDoes the trigger distinguish this skill from every neighbor, or would two skills fire on the same situation without a declared difference?\n\n### 4.5. Pipeline check\n\nAre runs-before, runs-after, assumptions, and products explicit?\n\n### 4.6. Publish-or-compose check\n\nDoes the proposal name the best existing composition and the specific gap it leaves? If not, default to composition, not publication.\n\n### 4.7. Isolation check\n\nCan the skill's effect be shown on a sample artifact without the full pipeline?\n\n### 4.8. Kata check\n\nDoes the kata exercise composition judgment rather than only within-skill editing?\n\n---\n\n## 5. Final Test\n\nA skill composes well when:\n\n- its class is explicit\n- its axis is singular\n- its entry and exit contracts are declared\n- its trigger distinguishes it from neighboring skills\n- its order is explicit\n- each shared rule has one owner\n- its existence is justified against a named alternative composition\n- it can be tested in isolation\n- its kata exercises the composition decision\n\nIf a proposed skill cannot name a gap beyond the best existing composition, compose instead of publishing.\n\n---\n\n## 6. Kata\n\n### Scenario\n\nYou are reviewing a proposed new skill called blog. The author argues that blog posts need a casual register, looser pacing, and a stronger hook than essays.\n\n### Task\n\nDecide whether blog should be published as a new skill, composed from existing skills, or refused.\n\n### Governing skills\n\n- skill\n- write\n- compose\n\n### Inputs\n\n- the proposed blog skill draft\n- the existing write skill\n- a hypothetical essay skill with form rules\n- a hypothetical voice skill that applies a voice profile\n\n### Expected artifacts\n\n- a short composition note naming what essay + voice(casual) + write already produces\n- a short gap note naming what blog would add that the composition does not produce\n- a verdict: publish, compose, or refuse\n- if publish, a frontmatter draft plus axis, contract, trigger, and order\n- if compose, a documented composition recipe\n- if refuse, a note added to the proposal explaining why\n\n### Verification\n\n- the alternative composition is named explicitly\n- the gap is specific, not atmospheric\n- if the gap is empty or vague, the verdict is compose or refuse\n- if the verdict is publish, the new skill passes the Final Test\n\n### Common failures\n\n- calling blog distinct because the topic feels distinct\n- publishing blog while it silently overlaps with essay on openings or pacing\n- refusing blog without documenting the composition recipe\n- modeling blog as a child of essay instead of a peer that composes\n\n### Reflection\n\nThe judgment under test is: when is a new skill warranted? The default should be composition. Publication must earn itself with a specific missing transformation.\n","# Composition\n\n## Core Principle\n\nCoherent composition keeps axis, contract, trigger, order, and ownership aligned so each skill changes one thing, loads at the right time, hands off cleanly, and shares no silent source of truth.\n\nThis skill teaches how to decide whether behavior belongs in a new skill or in a composition of existing skills, then declare the contracts and order that make that decision executable.\n\nThis skill transforms a skill proposal or skill set along the axis of compositional fitness.\n\nComposition fails through overlap and hidden order.\n\nThe skill skill governs whether an artifact is a skill and how skill artifacts are structured. The write skill governs prose coherence and shared house style. This skill adds only what compose adds.\n\n## Algorithm\n\n1. Define — classify the artifact, name the parts, state the formula, the governing question, and the failure mode.\n2. Unfold — declare axis, contracts, trigger, order, ownership, exclusions, and the publish-or-compose verdict.\n3. Rules — write imperative rules with stable IDs and contrastive ❌\u002F✅ examples.\n4. Verify — check that the skill composes cleanly and can be practiced.\n\n---\n\n## 1. Define\n\n### 1.0. Classify the artifact first\n\nComposition is itself a skill because it has a domain-specific formula, teaches judgment about skill boundaries and order, benefits from Define → Unfold → Rules, and exposes a kata.\n\nApply the same test to the artifact under review. Valid classes:\n\n- skill — teaches repeatable judgment in a domain\n- runbook — teaches ordered operational steps\n- reference — provides lookup-oriented material\n- deprecated — is superseded and should not remain live\n\nUse this skill only for artifacts of class skill. Reclassify everything else before you continue.\n\n- ❌ Treat a reference as if it were a skill\n- ✅ Reclassify first, then compose only true skills\n\n### 1.1. Identify the parts\n\nComposition has six parts:\n\n- skill — the unit being composed\n- axis — what it changes\n- contract — what it assumes and guarantees\n- trigger — when it should load\n- order — what runs before or after it\n- owner — where each shared rule or stable fact lives\n\nIf one part is missing, the composition decision is vague. If two parts blur together, skills overlap.\n\n- ❌ Talk about composition in generalities\n- ✅ Name the axis, contract, trigger, order, and owner before deciding to publish\n\n### 1.2. Articulate how they fit\n\nSkills compose when each one owns one axis, declares entry and exit contracts, loads on a distinct trigger, runs in explicit order, and points shared rules to one owner.\n\nIf axis, contract, trigger, order, or ownership is missing, the composition overlaps, drifts, or misfires.\n\n- ❌ \"Coherent composition is combining related skills well\"\n- ✅ \"Coherent composition keeps axis, contract, trigger, order, and ownership aligned so each skill changes one thing and hands off cleanly\"\n\n### 1.3. Name the governing question\n\n> This skill teaches how to decide whether work belongs in one skill, several composed skills, or no skill at all, and how to declare the composition once chosen.\n\n- ❌ One artifact teaching composition, release policy, and versioning at once\n- ✅ One artifact teaching composition judgment and declaration\n\n### 1.4. Name the failure mode\n\nComposition fails through overlap and hidden order.\n\nTypical signs:\n\n- two skills own the same rule\n- one skill assumes another ran first but does not say so\n- two skills trigger on the same situation without a clear distinction\n- a proposed skill duplicates a viable composition\n- one skill changes two axes\n- a shared fact has two homes\n\n- ❌ Generic: \"doing it wrong\"\n- ✅ Specific: \"composition fails through overlap and hidden order\"\n\n---\n\n## 2. Unfold\n\n### 2.1. Keep one skill on one axis\n\nA skill that changes two axes is two skills sharing a file. Split it.\n\n- ❌ A single skill that changes structure, voice, and format\n- ✅ Separate skills for structure, voice, and format, composed in order\n\n### 2.2. Declare the axis in one sentence\n\nState the axis with this sentence:\n\n> This skill transforms \u003Cartifact> along the axis of \u003Caxis>.\n\nIf the sentence needs an \"and,\" the skill probably has two axes.\n\n- ❌ \"This skill transforms a draft along the axis of coherence and tone\"\n- ✅ \"This skill transforms a draft along the axis of structural coherence\"\n\n### 2.3. Declare entry and exit contracts\n\nA contract says what must be true on entry and what will be true on exit. Use this shape:\n\n- Input:\n- Output:\n\nThis skill's own contract is:\n\n- Input: a skill proposal, skill pair, or load plan with neighboring authorities available\n- Output: a composition verdict with explicit axis, trigger, contract, order, and ownership decisions\n\n- ❌ \"Takes a document and makes it better\"\n- ✅ \"Input: prose with a governing question. Output: sections align to sub-questions and stable facts have one home\"\n\n### 2.4. Declare the trigger\n\nA trigger distinguishes this skill from its neighbors. If the trigger is vague, the skill will be double-loaded or loaded too late.\n\nUse this shape:\n\n> Use when...\n\n- ❌ \"Use when writing matters\"\n- ✅ \"Use when deciding whether new behavior belongs in a new skill or in a composition of existing skills\"\n\n### 2.5. Declare pipeline order\n\nState what runs before, what runs after, what the skill assumes, and what it leaves true. Use this shape:\n\n- Runs after:\n- Runs before:\n- Assumes:\n- Produces:\n\nThis skill itself composes like this:\n\n- Runs after: skill\n- Runs before: publication, bundling, or co-load decisions\n- Assumes: candidate artifacts are already classified or are being classified now\n- Produces: a composition verdict, declared contracts, and ownership decisions\n\n- ❌ Assume a neighbor skill ran first without saying so\n- ✅ Declare the handoff explicitly\n\n### 2.6. Assign one owner to every shared rule\n\nWhen two skills appear to share a rule, choose one owner and replace the other copy with a pointer.\n\nUse write for prose rules. Use skill for skill-form rules. Add a new owner only when neither existing skill owns the rule.\n\n- ❌ Restate \"front-load the point\" in three skills with slight wording drift\n- ✅ Let write own the rule; point to it from neighboring skills\n\n### 2.7. Declare exclusions on both sides\n\nIf two skills should not run together, both skills should say so.\n\n- ❌ Discover the conflict only when outputs disagree\n- ✅ Declare the exclusion in both artifacts\n\n### 2.8. Prefer composition before publication\n\nBefore publishing a new skill, name the best alternative composition and the specific gap it leaves. Publish only when that gap is real and owned by no existing skill.\n\n- ❌ Publish blog because it feels different from essay\n- ✅ Compare essay + voice(casual) + write to the proposed skill, then publish only if a specific transformation is still missing\n\n### 2.9. Expose a kata surface\n\nEvery true skill must be practice-ready. The kata appears below.\n\n---\n\n## 3. Rules\n\n### 3.1. Classify before composing\n\nDecide whether the artifact is a skill, runbook, reference, or deprecated artifact before you write composition logic.\n\n- ❌ Add composition language to a lookup page\n- ✅ Reclassify the artifact, then compose only true skills\n\n### 3.2. State one axis\n\nWrite the axis in one sentence and reject any skill that needs two axes to explain itself.\n\n- ❌ \"Improves drafts in many ways\"\n- ✅ \"Transforms a draft along the axis of structural coherence\"\n\n### 3.3. Declare both contracts\n\nState what the skill needs on entry and what it guarantees on exit.\n\n- ❌ \"Takes a draft and improves it\"\n- ✅ \"Input: prose with a governing question. Output: each section answers one sub-question\"\n\n### 3.4. State the trigger sharply\n\nWrite a trigger that distinguishes the skill from its neighbors.\n\n- ❌ \"Use when writing\"\n- ✅ \"Use when revising expository prose for structural coherence\"\n\n### 3.5. Declare order explicitly\n\nName the handoff. Do not make neighboring skills infer it.\n\n- ❌ Order inferred from file names or habit\n- ✅ \"Runs after write. Runs before naturalize.\"\n\n### 3.6. Move shared rules to one owner\n\nGive each shared rule or stable fact one home, then point to that home elsewhere.\n\n- ❌ The same authority rule restated in multiple skills with drift\n- ✅ One owner, named directly, with pointers from the rest\n\n### 3.7. Declare exclusions in both skills\n\nIf A conflicts with B, A names B and B names A.\n\n- ❌ Only one side declares the conflict\n- ✅ Both skills name the exclusion\n\n### 3.8. Name the alternative composition before publishing\n\nA new skill must say which existing composition it replaces and what that composition cannot do.\n\n- ❌ Publish a new skill because the topic feels distinct\n- ✅ Name the missing transformation that no existing composition owns\n\n### 3.9. Compose, do not extend\n\nNever express skill relationships as inheritance.\n\n- ❌ \"`newsletter` extends `write`\"\n- ✅ \"`newsletter` composes with write and adds newsletter-specific form rules\"\n\n### 3.10. Test the skill in isolation\n\nA skill should show its effect on a sample artifact without needing the whole pipeline to make sense.\n\n- ❌ \"Its effect only appears after three other skills run\"\n- ✅ A before\u002Fafter example shows the axis it changes\n\n### 3.11. Keep authority explicit\n\nSay which surface governs on disagreement.\n\n- ❌ Let the reader infer whether skill or write governs\n- ✅ \"design governs system decomposition. skill governs skill form. write governs prose rules. compose applies design to artifacts of class skill, adding triggers, classification, and the publish-or-compose verdict.\"\n\n---\n\n## 4. Verify\n\n### 4.1. Classification check\n\nIs the artifact really a skill? If not, reclassify it before composing.\n\n### 4.2. Parts check\n\nAre axis, contract, trigger, order, and owner all named?\n\n### 4.3. Overlap check\n\nDoes any rule, stable fact, or decision have two homes?\n\n### 4.4. Trigger check\n\nDoes the trigger distinguish this skill from every neighbor, or would two skills fire on the same situation without a declared difference?\n\n### 4.5. Pipeline check\n\nAre runs-before, runs-after, assumptions, and products explicit?\n\n### 4.6. Publish-or-compose check\n\nDoes the proposal name the best existing composition and the specific gap it leaves? If not, default to composition, not publication.\n\n### 4.7. Isolation check\n\nCan the skill's effect be shown on a sample artifact without the full pipeline?\n\n### 4.8. Kata check\n\nDoes the kata exercise composition judgment rather than only within-skill editing?\n\n---\n\n## 5. Final Test\n\nA skill composes well when:\n\n- its class is explicit\n- its axis is singular\n- its entry and exit contracts are declared\n- its trigger distinguishes it from neighboring skills\n- its order is explicit\n- each shared rule has one owner\n- its existence is justified against a named alternative composition\n- it can be tested in isolation\n- its kata exercises the composition decision\n\nIf a proposed skill cannot name a gap beyond the best existing composition, compose instead of publishing.\n\n---\n\n## 6. Kata\n\n### Scenario\n\nYou are reviewing a proposed new skill called blog. The author argues that blog posts need a casual register, looser pacing, and a stronger hook than essays.\n\n### Task\n\nDecide whether blog should be published as a new skill, composed from existing skills, or refused.\n\n### Governing skills\n\n- skill\n- write\n- compose\n\n### Inputs\n\n- the proposed blog skill draft\n- the existing write skill\n- a hypothetical essay skill with form rules\n- a hypothetical voice skill that applies a voice profile\n\n### Expected artifacts\n\n- a short composition note naming what essay + voice(casual) + write already produces\n- a short gap note naming what blog would add that the composition does not produce\n- a verdict: publish, compose, or refuse\n- if publish, a frontmatter draft plus axis, contract, trigger, and order\n- if compose, a documented composition recipe\n- if refuse, a note added to the proposal explaining why\n\n### Verification\n\n- the alternative composition is named explicitly\n- the gap is specific, not atmospheric\n- if the gap is empty or vague, the verdict is compose or refuse\n- if the verdict is publish, the new skill passes the Final Test\n\n### Common failures\n\n- calling blog distinct because the topic feels distinct\n- publishing blog while it silently overlaps with essay on openings or pacing\n- refusing blog without documenting the composition recipe\n- modeling blog as a child of essay instead of a peer that composes\n\n### Reflection\n\nThe judgment under test is: when is a new skill warranted? The default should be composition. Publication must earn itself with a specific missing transformation.\n",{"name":5,"scope":37,"triggers":38,"description":7,"kata_surface":29,"artifact_class":44,"governing_question":45},"task-local",[39,40,41,42,43],"designing a new skill","deciding whether behavior belongs in a neighbor skill","resolving overlap between skills","declaring skill order for a task","reviewing whether a proposal should be a composition instead","skill","How do we compose skills without overlap, drift, or hidden order?","main","fb527e6c4bfb75c71fa75d6471b3aa3da32106d4","src\u002Fpackages\u002Fcnos.core\u002Fskills\u002Fcompose",0,"https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos","https:\u002F\u002Fgithub.com\u002Fusurobor","Coherence engineer. Building git-CN.","2026-11-07 14:25:44",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add usurobor\u002Fcnos --skill compose",{"tool":60,"command":61},"bunx","bunx skills add usurobor\u002Fcnos --skill compose",{"tool":63,"command":64},"pnpm","pnpm dlx skills add usurobor\u002Fcnos --skill compose","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.core\u002Fskills\u002Fcompose\u002FSKILL.md",true,[],[69,87,103,129,146,166],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":32},"01M6CF8RWQPM0VXZG06XMR0FFX","issues\u002Ftriage","Issue triage doctrine pointer. Use when classifying a new issue, deciding dispatch eligibility, or deciding whether to close\u002Fsupersede\u002Fdefer.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002Fskills\u002Ftriage\u002FSKILL.md",[],[76,77,78,79,80,26,81,82,83,84,85,86],"triage","issues","issues triage","issue triage","SET","decision","public","use","dispatch","issue","doctrine",{"skillNo":88,"name":89,"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":93,"publishedAt":32},"01M6CF8PJ812DD4APZ3WE8X67B","issues\u002Ftaxonomy","Issue label taxonomy pointer. Use when classifying an issue's kind\u002Farea\u002Fpriority\u002Feffort\u002Fstatus\u002Fprotocol\u002Fdispatch labels, or when the board needs to interpret them.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002Fskills\u002Ftaxonomy\u002FSKILL.md",[],[77,94,95,96,97,98,80,99,82,100,83,84,101,85,102],"taxonomy","issues taxonomy","github","status","protocol","open","board","github issue","issue labels",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":117,"publishedAt":32},"01M6CF8KBMZ4D0CDJQ3PF1YVTP","issues\u002Fmap","Issue-board (Issue Pivot) generation domain. Use when reasoning about `cn issues map`'s fetch, taxonomy-parse, effort-computation, and render pipeline, or about the board's JSON\u002FHTML output contract.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002Fskills\u002Fmap\u002FSKILL.md",[109,112],{"categoryNo":110,"categoryName":111,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":113,"categoryName":114,"taxonomyType":115,"taxonomyTypeDesc":116},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[77,118,96,119,120,121,80,122,94,99,26,123,124,100,125,126,127,128,83,85],"issues map","reasoning","data","pipeline","api","json","README","edit","interactive","fetch","generated",{"skillNo":130,"name":77,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":32},"01M6CF8CZQH7G7B7RZPANQWR4G","cnos.issues package entrypoint. Use when reasoning about issue taxonomy, the Issue Pivot \u002F issue-board (`cn issues map`), the read-only CDS issue-state evaluator (`cn issues fsm evaluate`), or the current command-dispatch disposition of issue tooling.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002FSKILL.md",[],[77,96,135,136,137,138,139,140,141,94,99,26,81,142,124,143,83,144,84,145],"pr","current state","run","artifacts","state","package","boundary","branch","command","only","cds",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":32},"01M6CF896XKSRQVB1CSHY8GSXB","receipt-stream","Cross-cycle receipt-stream doctrine for protocol-iteration. Use when γ closes a cycle and writes the per-cycle iteration artifact (`cdd-iteration.md`), when γ updates the cross-cycle aggregator at `.cdd\u002Fiterations\u002FINDEX.md`, when ε reads the receipt stream across cycles to surface protocol-gap patterns, when a finding's disposition lands a cross-repo patch and the cross-repo trace bundle attaches, or when a courtesy empty-findings stub is written for a `protocol_gap_count == 0` cycle.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.handoff\u002Fskills\u002Fhandoff\u002Freceipt-stream\u002FSKILL.md",[],[153,154,138,98,155,26,156,157,158,82,159,160,161,162,83,29,163,164,165,86],"receipt stream","handoff","index","learning","format","trace","repo","closeout","read","channel","patch","shape","cdd",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":172,"publishedAt":32},"01M6CF84VCBME6RK8V6HAVDM8Z","mid-flight","Mid-flight γ→in-flight-α rescue channel. Use when γ needs to change a load-bearing fact (pinned axis, scope, AC, blocker) after α has begun coding, when γ edits the cycle's GitHub issue body mid-cycle, or when a spec change lands on origin\u002Fmain while α\u002Fβ polling sessions are in-flight.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.handoff\u002Fskills\u002Fhandoff\u002Fmid-flight\u002FSKILL.md",[],[173,96,174,175,176,177,26,178,179,142,159,161,83,144,84,180,101,181,182,183],"mid flight","change","sessions","file","cache","pin","coordination","up","Legacy","gamma","artifact channel"]