[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CF5ZGSJN39SC53M6YGJB7J":3,"skill-same:01M6CF5ZGSJN39SC53M6YGJB7J":66},{"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":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6CF5ZGSJN39SC53M6YGJB7J","skill",null,"Write coherent skills. Use when creating, rewriting, classifying, or reviewing any artifact under src\u002Fagent\u002Fskills\u002F.","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\u002Fskill\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31],"Meta","verify","how","src","write","use","embedded","coherent","2026-11-10 10:12:30",false,"---\nname: skill\ndescription: Write coherent skills. Use when creating, rewriting, classifying, or reviewing any artifact under src\u002Fagent\u002Fskills\u002F.\nartifact_class: skill\nkata_surface: embedded\ngoverning_question: How do we write, classify, and verify coherent skills?\ntriggers:\n  - creating a new skill\n  - rewriting an old skill\n  - deciding whether an artifact is really a skill\n  - normalizing a skill to the meta-skill standard\nscope: task-local\n---\n\n# Skill\n\n## Core Principle\n\nCoherent skill: a true skill teaches repeatable judgment in one domain through a domain-specific coherence formula, unfolded into necessary sections, enforced by imperative rules, and made trainable through a kata surface.\n\nA skill is not a pile of advice. A skill is not a lookup page. A skill is not a runbook with a nicer title.\n\nIf the formula is generic, the artifact is not ready. If the artifact is really a runbook or reference, reclassify it instead of forcing skill form onto it.\n\n## Algorithm\n\nSkills are written top-down. Start with the governing question and coherence formula. Structure follows from purpose. Details serve structure. Rules are evidence for the formula, not the formula itself.\n\n1. Define — classify the artifact, name the domain formula, the governing question, the parts, and the failure mode.\n2. Unfold — organize the artifact so each section serves the formula in a necessary order.\n3. Rules — write imperative rules with stable IDs and contrastive ❌\u002F✅ examples.\n4. Verify — check that the artifact, its classification, and its kata surface all match.\n\n- ❌ Start with a list of rules and try to find a formula that justifies them\n- ✅ Start with the formula; rules exist to make it executable\n\n---\n\n## 1. Define\n\n### 1.0. Classify the artifact first\n\nEvery artifact under src\u002Fagent\u002Fskills\u002F must declare its class. 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** — superseded, merged, or no longer authoritative\n\nUse these tests:\n\nA skill:\n\n- has a domain-specific coherence formula\n- teaches judgment, not just sequence\n- benefits from Define → Unfold → Rules\n- should expose a kata surface\n\nA runbook:\n\n- is mainly ordered steps\n- depends on sequence and preconditions\n- may have a drill or checklist, but does not need a coherence formula\n\nA reference:\n\n- is mainly conventions, APIs, commands, templates, or examples\n- is lookup-oriented\n- should be declarative, not artificially \"skill-shaped\"\n\nA deprecated artifact:\n\n- is superseded\n- belongs inside another artifact\n- should not silently remain live\n\n- ❌ Force every low-scoring artifact into skill form\n- ✅ Reclassify first, then rewrite only true skills\n\n### 1.1. Identify the parts\n\nAsk:\n\n- what are the parts in this domain?\n- what must stay distinct?\n- what must fit together?\n\n- ❌ Skip straight to bullet rules\n- ✅ \"Review has: contract, evidence, verdict\"\n- ✅ \"Writing has: document, section, paragraph, sentence, word\"\n\n### 1.2. Articulate how they fit\n\nState the coherence formula in one sentence. The formula must explain:\n\n- how the parts serve the whole\n- what makes the domain coherent\n- what is lost if one part is missing\n\n- ❌ \"Coherent writing: follow best practices\"\n- ✅ \"Coherent writing moves understanding forward with the minimum text required\"\n- ❌ \"Coherent review: be thorough\"\n- ✅ \"Coherent review resolves terms, pointer, and exit to the same gap\"\n\n### 1.3. Name the governing question\n\nEvery true skill should answer one governing question. Use a sentence like:\n\n> This skill teaches how to...\n\n- ❌ One artifact teaching two or three domains at once\n- ✅ \"This skill teaches how to design a change before implementing it\"\n- ✅ \"This skill teaches how to review a change against its declared contract\"\n\n### 1.4. Name the failure mode\n\nA good skill names what incoherence looks like in its domain.\n\n- ❌ Generic: \"doing it wrong\"\n- ✅ Specific: \"Design fails through incomplete impact tracing\"\n- ✅ Specific: \"Writing fails through clutter and drift\"\n- ✅ Specific: \"Review fails when evidence and verdict drift apart\"\n\nIf you cannot name the failure mode, the formula is probably still vague.\n\n---\n\n## 2. Unfold\n\n### 2.1. One skill, one domain\n\nDo not let one skill do several jobs.\n\n- ❌ A skill that mixes theory, operations, and style guidance\n- ✅ A skill that owns one domain and points to adjacent artifacts when needed\n\n### 2.2. Order sections by dependency\n\nSections should build on one another. Common progressions:\n\n- small → large\n- simple → complex\n- gather → process → act\n- observe → interpret → decide → act\n\n- ❌ Random ordering of advice\n- ✅ Each section depends on the one before it\n\n### 2.3. Make the artifact demonstrate its own formula\n\nA coherent skill should obey its own rules.\n\n- ❌ A writing skill that rambles\n- ❌ A design skill with no impact graph\n- ❌ A review skill with no clear verdict structure\n- ✅ The artifact itself is the first proof that the formula works\n\n### 2.4. Provide a kata surface for every true skill\n\nA true skill must be kata-compatible. Allowed values:\n\n- **kata_surface: embedded** — the skill contains its own kata section\n- **kata_surface: external** — the skill points to a sibling kata.md\n- **kata_surface: none** — allowed only for runbook, reference, or deprecated artifacts\n\nA kata surface must define:\n\n- scenario\n- task\n- governing skills\n- inputs\n- expected artifacts\n- verification\n- common failures\n- reflection\n\n- ❌ A true skill with no practice surface\n- ✅ A skill with an embedded or external kata that proves it can be exercised\n\n### 2.5. Use output formats only when the artifact produces recurring outputs\n\nIf the artifact regularly produces:\n\n- design docs\n- review requests\n- self-coherence reports\n- release notes\n\nprovide a stable output format.\n\nDo not force templates into artifacts that do not need them.\n\n- ❌ Add output templates to every artifact\n- ✅ Add them only when the artifact produces recurring structured outputs\n\n---\n\n## 3. Rules\n\n### 3.1. Require frontmatter\n\nEvery artifact should declare what it is. Minimum frontmatter:\n\n- name\n- description\n- artifact_class\n- kata_surface\n- governing_question\n\n- ❌ Leave classification implicit\n- ✅ Make the artifact say what it is\n\n### 3.2. State what the artifact is\n\nName the artifact positively and concretely.\n\n- ❌ \"This is not just a checklist\"\n- ✅ \"This skill teaches how to...\"\n- ✅ \"This runbook explains how to...\"\n- ✅ \"This reference lists...\"\n\n### 3.3. Write imperative rules\n\nEach rule should start with a verb.\n\n- ❌ \"Impact graphs are important\"\n- ✅ \"Trace the impact graph\"\n- ❌ \"Filler phrases are bad\"\n- ✅ \"Cut filler phrases\"\n\n### 3.4. Add one line of context only when it helps\n\nA rule may have one short line explaining why it matters or when it applies.\n\n- ❌ Three sentences of background before the rule starts\n- ✅ \"Vague observations do not produce action.\"\n\n### 3.5. Pair ❌ and ✅ on the same failure\n\nThe fix must answer the same situation as the failure.\n\n- ❌ Failure example about one thing, fix example about something else\n- ✅ Same situation, corrected\n\n### 3.6. Keep IDs stable\n\nUse numbered IDs such as:\n\n- 1.2.\n- 2.4.\n- 3.7.\n\nDo not renumber casually.\n\n- ❌ \"See above\"\n- ✅ \"See 2.3.\"\n\n### 3.7. Keep authority explicit\n\nIf the artifact depends on another surface, say so directly.\n\n- ✅ \"Canonical doc governs on disagreement.\"\n- ✅ \"This is a reference profile, not the method.\"\n- ✅ \"This skill is the executable summary.\"\n\nDo not make the reader infer authority from tone.\n\n### 3.8. Say stable facts once, then point to them\n\nStable facts should have one home. State them once. Elsewhere, point back.\n\n- ❌ Restate the same authority rule in multiple artifacts with slight drift\n- ✅ Name the owning artifact once and point to it\n\n### 3.9. Do not force skill form onto the wrong artifact\n\nIf the artifact is really a runbook or reference, reclassify it.\n\n- ❌ Add fake coherence language to a command cheat sheet\n- ✅ Keep lookup docs declarative and let skills teach judgment\n\n### 3.10. Sync source and packaged copies\n\nIf you edit anything under src\u002Fagent\u002Fskills\u002F, keep packaged copies in sync.\n\n- ❌ Update only the source artifact and leave the packaged copy stale\n- ✅ Run the build\u002Fsync path before claiming the change is complete\n\n---\n\n## 4. Verify\n\n### 4.1. Classification check\n\nAsk:\n\n- is this really a skill?\n- if not, should it be runbook, reference, or deprecated?\n\n### 4.2. Formula check\n\nAsk:\n\n- is the formula domain-specific?\n- is the failure mode named?\n- does the artifact answer one governing question?\n\n### 4.3. Structure check\n\nAsk:\n\n- does each section serve the formula?\n- are sections ordered by dependency?\n- does the artifact obey the rules it teaches?\n\n### 4.4. Kata check\n\nAsk:\n\n- does every true skill expose a kata surface?\n- is the kata embedded or external?\n- does the kata define scenario, task, governing skills, inputs, expected artifacts, verification, failures, and reflection?\n\n### 4.5. Corpus check\n\nAsk:\n\n- is frontmatter present?\n- is the artifact class explicit?\n- is the package copy synced if needed?\n\n---\n\n## 5. Final Test\n\nAn artifact is coherent when:\n\n- its class is explicit\n- its governing question is singular\n- its formula is domain-specific\n- its failure mode is named\n- its sections unfold in a necessary order\n- its rules are imperative\n- its examples show one failure and one fix\n- its authority is explicit\n- every true skill has a kata surface\n- it demonstrates its own formula\n\nIf the formula is generic, sharpen it. If the artifact is not a skill, reclassify it. If the skill cannot be practiced, add a kata surface.\n","# Skill\n\n## Core Principle\n\nCoherent skill: a true skill teaches repeatable judgment in one domain through a domain-specific coherence formula, unfolded into necessary sections, enforced by imperative rules, and made trainable through a kata surface.\n\nA skill is not a pile of advice. A skill is not a lookup page. A skill is not a runbook with a nicer title.\n\nIf the formula is generic, the artifact is not ready. If the artifact is really a runbook or reference, reclassify it instead of forcing skill form onto it.\n\n## Algorithm\n\nSkills are written top-down. Start with the governing question and coherence formula. Structure follows from purpose. Details serve structure. Rules are evidence for the formula, not the formula itself.\n\n1. Define — classify the artifact, name the domain formula, the governing question, the parts, and the failure mode.\n2. Unfold — organize the artifact so each section serves the formula in a necessary order.\n3. Rules — write imperative rules with stable IDs and contrastive ❌\u002F✅ examples.\n4. Verify — check that the artifact, its classification, and its kata surface all match.\n\n- ❌ Start with a list of rules and try to find a formula that justifies them\n- ✅ Start with the formula; rules exist to make it executable\n\n---\n\n## 1. Define\n\n### 1.0. Classify the artifact first\n\nEvery artifact under src\u002Fagent\u002Fskills\u002F must declare its class. 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** — superseded, merged, or no longer authoritative\n\nUse these tests:\n\nA skill:\n\n- has a domain-specific coherence formula\n- teaches judgment, not just sequence\n- benefits from Define → Unfold → Rules\n- should expose a kata surface\n\nA runbook:\n\n- is mainly ordered steps\n- depends on sequence and preconditions\n- may have a drill or checklist, but does not need a coherence formula\n\nA reference:\n\n- is mainly conventions, APIs, commands, templates, or examples\n- is lookup-oriented\n- should be declarative, not artificially \"skill-shaped\"\n\nA deprecated artifact:\n\n- is superseded\n- belongs inside another artifact\n- should not silently remain live\n\n- ❌ Force every low-scoring artifact into skill form\n- ✅ Reclassify first, then rewrite only true skills\n\n### 1.1. Identify the parts\n\nAsk:\n\n- what are the parts in this domain?\n- what must stay distinct?\n- what must fit together?\n\n- ❌ Skip straight to bullet rules\n- ✅ \"Review has: contract, evidence, verdict\"\n- ✅ \"Writing has: document, section, paragraph, sentence, word\"\n\n### 1.2. Articulate how they fit\n\nState the coherence formula in one sentence. The formula must explain:\n\n- how the parts serve the whole\n- what makes the domain coherent\n- what is lost if one part is missing\n\n- ❌ \"Coherent writing: follow best practices\"\n- ✅ \"Coherent writing moves understanding forward with the minimum text required\"\n- ❌ \"Coherent review: be thorough\"\n- ✅ \"Coherent review resolves terms, pointer, and exit to the same gap\"\n\n### 1.3. Name the governing question\n\nEvery true skill should answer one governing question. Use a sentence like:\n\n> This skill teaches how to...\n\n- ❌ One artifact teaching two or three domains at once\n- ✅ \"This skill teaches how to design a change before implementing it\"\n- ✅ \"This skill teaches how to review a change against its declared contract\"\n\n### 1.4. Name the failure mode\n\nA good skill names what incoherence looks like in its domain.\n\n- ❌ Generic: \"doing it wrong\"\n- ✅ Specific: \"Design fails through incomplete impact tracing\"\n- ✅ Specific: \"Writing fails through clutter and drift\"\n- ✅ Specific: \"Review fails when evidence and verdict drift apart\"\n\nIf you cannot name the failure mode, the formula is probably still vague.\n\n---\n\n## 2. Unfold\n\n### 2.1. One skill, one domain\n\nDo not let one skill do several jobs.\n\n- ❌ A skill that mixes theory, operations, and style guidance\n- ✅ A skill that owns one domain and points to adjacent artifacts when needed\n\n### 2.2. Order sections by dependency\n\nSections should build on one another. Common progressions:\n\n- small → large\n- simple → complex\n- gather → process → act\n- observe → interpret → decide → act\n\n- ❌ Random ordering of advice\n- ✅ Each section depends on the one before it\n\n### 2.3. Make the artifact demonstrate its own formula\n\nA coherent skill should obey its own rules.\n\n- ❌ A writing skill that rambles\n- ❌ A design skill with no impact graph\n- ❌ A review skill with no clear verdict structure\n- ✅ The artifact itself is the first proof that the formula works\n\n### 2.4. Provide a kata surface for every true skill\n\nA true skill must be kata-compatible. Allowed values:\n\n- **kata_surface: embedded** — the skill contains its own kata section\n- **kata_surface: external** — the skill points to a sibling kata.md\n- **kata_surface: none** — allowed only for runbook, reference, or deprecated artifacts\n\nA kata surface must define:\n\n- scenario\n- task\n- governing skills\n- inputs\n- expected artifacts\n- verification\n- common failures\n- reflection\n\n- ❌ A true skill with no practice surface\n- ✅ A skill with an embedded or external kata that proves it can be exercised\n\n### 2.5. Use output formats only when the artifact produces recurring outputs\n\nIf the artifact regularly produces:\n\n- design docs\n- review requests\n- self-coherence reports\n- release notes\n\nprovide a stable output format.\n\nDo not force templates into artifacts that do not need them.\n\n- ❌ Add output templates to every artifact\n- ✅ Add them only when the artifact produces recurring structured outputs\n\n---\n\n## 3. Rules\n\n### 3.1. Require frontmatter\n\nEvery artifact should declare what it is. Minimum frontmatter:\n\n- name\n- description\n- artifact_class\n- kata_surface\n- governing_question\n\n- ❌ Leave classification implicit\n- ✅ Make the artifact say what it is\n\n### 3.2. State what the artifact is\n\nName the artifact positively and concretely.\n\n- ❌ \"This is not just a checklist\"\n- ✅ \"This skill teaches how to...\"\n- ✅ \"This runbook explains how to...\"\n- ✅ \"This reference lists...\"\n\n### 3.3. Write imperative rules\n\nEach rule should start with a verb.\n\n- ❌ \"Impact graphs are important\"\n- ✅ \"Trace the impact graph\"\n- ❌ \"Filler phrases are bad\"\n- ✅ \"Cut filler phrases\"\n\n### 3.4. Add one line of context only when it helps\n\nA rule may have one short line explaining why it matters or when it applies.\n\n- ❌ Three sentences of background before the rule starts\n- ✅ \"Vague observations do not produce action.\"\n\n### 3.5. Pair ❌ and ✅ on the same failure\n\nThe fix must answer the same situation as the failure.\n\n- ❌ Failure example about one thing, fix example about something else\n- ✅ Same situation, corrected\n\n### 3.6. Keep IDs stable\n\nUse numbered IDs such as:\n\n- 1.2.\n- 2.4.\n- 3.7.\n\nDo not renumber casually.\n\n- ❌ \"See above\"\n- ✅ \"See 2.3.\"\n\n### 3.7. Keep authority explicit\n\nIf the artifact depends on another surface, say so directly.\n\n- ✅ \"Canonical doc governs on disagreement.\"\n- ✅ \"This is a reference profile, not the method.\"\n- ✅ \"This skill is the executable summary.\"\n\nDo not make the reader infer authority from tone.\n\n### 3.8. Say stable facts once, then point to them\n\nStable facts should have one home. State them once. Elsewhere, point back.\n\n- ❌ Restate the same authority rule in multiple artifacts with slight drift\n- ✅ Name the owning artifact once and point to it\n\n### 3.9. Do not force skill form onto the wrong artifact\n\nIf the artifact is really a runbook or reference, reclassify it.\n\n- ❌ Add fake coherence language to a command cheat sheet\n- ✅ Keep lookup docs declarative and let skills teach judgment\n\n### 3.10. Sync source and packaged copies\n\nIf you edit anything under src\u002Fagent\u002Fskills\u002F, keep packaged copies in sync.\n\n- ❌ Update only the source artifact and leave the packaged copy stale\n- ✅ Run the build\u002Fsync path before claiming the change is complete\n\n---\n\n## 4. Verify\n\n### 4.1. Classification check\n\nAsk:\n\n- is this really a skill?\n- if not, should it be runbook, reference, or deprecated?\n\n### 4.2. Formula check\n\nAsk:\n\n- is the formula domain-specific?\n- is the failure mode named?\n- does the artifact answer one governing question?\n\n### 4.3. Structure check\n\nAsk:\n\n- does each section serve the formula?\n- are sections ordered by dependency?\n- does the artifact obey the rules it teaches?\n\n### 4.4. Kata check\n\nAsk:\n\n- does every true skill expose a kata surface?\n- is the kata embedded or external?\n- does the kata define scenario, task, governing skills, inputs, expected artifacts, verification, failures, and reflection?\n\n### 4.5. Corpus check\n\nAsk:\n\n- is frontmatter present?\n- is the artifact class explicit?\n- is the package copy synced if needed?\n\n---\n\n## 5. Final Test\n\nAn artifact is coherent when:\n\n- its class is explicit\n- its governing question is singular\n- its formula is domain-specific\n- its failure mode is named\n- its sections unfold in a necessary order\n- its rules are imperative\n- its examples show one failure and one fix\n- its authority is explicit\n- every true skill has a kata surface\n- it demonstrates its own formula\n\nIf the formula is generic, sharpen it. If the artifact is not a skill, reclassify it. If the skill cannot be practiced, add a kata surface.\n",{"name":5,"scope":37,"triggers":38,"description":7,"kata_surface":30,"artifact_class":5,"governing_question":43},"task-local",[39,40,41,42],"creating a new skill","rewriting an old skill","deciding whether an artifact is really a skill","normalizing a skill to the meta-skill standard","How do we write, classify, and verify coherent skills?","main","fb527e6c4bfb75c71fa75d6471b3aa3da32106d4","src\u002Fpackages\u002Fcnos.core\u002Fskills\u002Fskill",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":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add usurobor\u002Fcnos --skill skill",{"tool":58,"command":59},"bunx","bunx skills add usurobor\u002Fcnos --skill skill",{"tool":61,"command":62},"pnpm","pnpm dlx skills add usurobor\u002Fcnos --skill skill","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.core\u002Fskills\u002Fskill\u002FSKILL.md",true,[],[67,84,100,126,143,163],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"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",[],[74,75,76,77,78,26,79,80,29,81,82,83],"triage","issues","issues triage","issue triage","SET","decision","public","dispatch","issue","doctrine",{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"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",[],[75,91,92,93,94,95,78,96,80,97,29,81,98,82,99],"taxonomy","issues taxonomy","github","status","protocol","open","board","github issue","issue labels",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":114,"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",[106,109],{"categoryNo":107,"categoryName":108,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":110,"categoryName":111,"taxonomyType":112,"taxonomyTypeDesc":113},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[75,115,93,116,117,118,78,119,91,96,26,120,121,97,122,123,124,125,29,82],"issues map","reasoning","data","pipeline","api","json","README","edit","interactive","fetch","generated",{"skillNo":127,"name":75,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"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",[],[75,93,132,133,134,135,136,137,138,91,96,26,79,139,121,140,29,141,81,142],"pr","current state","run","artifacts","state","package","boundary","branch","command","only","cds",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":149,"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",[],[150,151,135,95,152,26,153,154,155,80,156,157,158,159,29,30,160,161,162,83],"receipt stream","handoff","index","learning","format","trace","repo","closeout","read","channel","patch","shape","cdd",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"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",[],[170,93,171,172,173,174,26,175,176,139,156,158,29,141,81,177,98,178,179,180],"mid flight","change","sessions","file","cache","pin","coordination","up","Legacy","gamma","artifact channel"]