[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CF59AR0GC1AF2J4QWRNNNX":3,"skill-same:01M6CF59AR0GC1AF2J4QWRNNNX":72},{"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":18,"publishedAt":27,"linkOnly":28,"markdownContent":29,"markdownBody":30,"frontMatter":31,"refName":40,"commitSha":41,"skillDirectory":42,"forksCount":43,"repositoryHtmlUrl":44,"repositoryHomepageUrl":6,"ownerHtmlUrl":45,"ownerBlogUrl":6,"ownerDescription":46,"updatedAt":47,"install":48,"resources":61},"01M6CF59AR0GC1AF2J4QWRNNNX","audit",null,"Assess whether a package is coherent as a whole — does it have one job, do its parts serve that job, and do its parts agree with each other and with reality?","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\u002Faudit\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26],"release","produce","package","health","how","work","embedded","coherent","2026-11-10 10:12:30",false,"---\nname: audit\ndescription: Assess whether a package is coherent as a whole — does it have one job, do its parts serve that job, and do its parts agree with each other and with reality?\nartifact_class: skill\nkata_surface: embedded\ngoverning_question: How do we judge whether a package is coherent — and produce the smallest convergence path to make it so?\ntriggers:\n  - auditing a package for coherence\n  - assessing whether a package's parts agree\n  - preparing convergence work for a package\n  - evaluating package health before a release or restructure\nscope: task-local\n---\n\n# Coherence Audit\n\n## Core Principle\n\n**Coherent audit judges a package top-down: purpose first, then structure, then agreement, then reality — and produces a convergence path that closes the governing gaps.**\n\nA package is coherent when it has one job, every part serves that job, every part agrees with every other part about how the job is done, and what the parts claim matches what actually exists.\n\n## Algorithm\n\n1. Define — name the parts of a coherence audit, state the formula, and name the failure mode.\n2. Unfold — execute the audit top-down: purpose → structure → agreement → reality → judgment.\n3. Rules — imperative constraints on how audits are conducted.\n4. Verify — check that the audit artifact is itself coherent.\n\n---\n\n## 1. Define\n\n### 1.1. Identify the parts\n\nA coherence audit has five parts:\n\n- **Purpose** — the package's one job\n- **Structure** — whether the shape serves the purpose\n- **Agreement** — whether the parts say the same thing about shared surfaces\n- **Reality** — whether claims match the filesystem and actual usage\n- **Judgment** — the verdict and convergence path\n\nEach part depends on the one before it. Purpose must be named before structure can be assessed. Structure must be understood before agreement findings have context. Agreement findings must exist before reality checks are meaningful. All four inform the judgment.\n\n- ❌ Start with detail cross-checks and hope a picture emerges\n- ✅ Start with purpose; let every subsequent finding serve the coherence question\n\n### 1.2. Articulate how they fit\n\nPurpose sets the standard. Structure reveals whether the package is organized to meet it. Agreement reveals whether the parts believe they're meeting it in the same way. Reality reveals whether what they claim is true. Judgment synthesizes all four into a verdict and a path.\n\nThe coherence formula: **a package is coherent when purpose, structure, agreement, and reality all align.**\n\n### 1.3. Name the governing question\n\n> This skill teaches how to judge whether a package is coherent and produce the smallest convergence path to make it so.\n\n### 1.4. Name the failure mode\n\nAudit fails through **bottom-up drift and ungrounded findings.**\n\nTypical signs:\n\n- detail findings without structural context — a list of nits with no governing judgment\n- findings that can't be verified from their citations\n- severity inflation or deflation — everything is D, or everything is A\n- convergence themes too vague to execute (\"fix naming\")\n- purpose never stated — the audit checks agreement without knowing what the parts should agree about\n- the audit duplicates an existing audit or filed issue (CAP §1.2a)\n\n---\n\n## 2. Unfold\n\n### 2.1. Purpose\n\nState the package's one job in one sentence. What coherence does it provide that wouldn't exist without it?\n\n- ❌ \"cnos.cdd contains CDD skills and tools\" (inventory, not purpose)\n- ✅ \"cnos.cdd makes triadic development cycles executable and verifiable\"\n\nIf the sentence needs \"and\" between unrelated clauses, the package may have two jobs. That's finding zero.\n\nThen check: does every top-level artifact serve this purpose?\n\n- **Yes** — it belongs\n- **No** — it should move or be removed\n- **Unclear** — either the purpose statement is vague or the artifact's role is ambiguous\n\nIf more than a few answer \"unclear,\" sharpen the purpose before continuing.\n\n### 2.2. Structure\n\nDoes the package's shape make the purpose executable?\n\n- Are skills grouped by the right axis?\n- Are roles, phases, or layers clear from the structure?\n- Does the structure create confusion about where something belongs?\n\nStructural anti-patterns:\n\n- **Two things with one name** — different artifacts use the same term for different concepts\n- **One thing with two names** — the same concept has different names in different places\n- **Orphaned artifacts** — files that nothing loads, references, or uses\n- **Circular authority** — A says B governs, B says A governs\n- **Layer smearing** — artifacts that mix concerns that should be separate\n- **Missing parts** — things the purpose clearly requires but the package doesn't provide\n\n### 2.3. Agreement\n\nFor each surface that appears in more than one artifact — a fact, policy, location, naming convention, role boundary, or load order — check: do the artifacts agree?\n\nWhen they disagree, record a finding:\n\n| ID | Sev | Theme | Finding | Evidence |\n|----|-----|-------|---------|----------|\n\nSeverity:\n\n- **D (Critical)** — agents will act wrongly. Behavior-changing contract drift.\n- **C (Significant)** — agents can work around it but shouldn't have to.\n- **B (Minor)** — low impact. Naming drift that doesn't cause confusion.\n- **A (Informational)** — not wrong, could be tighter.\n\nEvery finding must cite specific text from both sides. A finding you can't verify from the citations is not a finding.\n\n- ❌ \"The naming is inconsistent across files\"\n- ✅ \"F3 | C | Role ownership | beta\u002FSKILL.md:22 lists 'post-release assessment' as β-owned; gamma\u002FSKILL.md:35 assigns PRA to γ\"\n\n### 2.4. Reality\n\nVerify artifact claims against the actual system:\n\n- Do referenced paths exist?\n- Do referenced commands work as described?\n- Do artifact location claims match where artifacts actually live?\n- Are there artifacts that exist but are never loaded or referenced?\n\n- ❌ Trust what a skill says about the filesystem\n- ✅ Check the filesystem\n\n### 2.5. Judgment\n\nState the verdict. Three possible outcomes:\n\n- **Coherent** — purpose is clear, structure serves it, parts agree, claims match reality. Minor improvements possible but no convergence work needed.\n- **Locally coherent, globally drifted** — individual artifacts are well-written but they disagree with each other or with the stated purpose. Convergence work needed.\n- **Incoherent** — purpose is unclear or contested, structure doesn't serve it, significant disagreements. Restructuring needed.\n\nThen consolidate findings into convergence themes. A good theme:\n\n- Groups findings that share a root cause\n- Has a clear \"done\" state\n- Maps to a CDD cycle or a set of ACs in one issue\n\nOrder themes by: impact on agent behavior (D first), dependency (what unblocks what), then size (small wins first).\n\nDecide the output path:\n\n- All A\u002FB → note in a close-out or adhoc thread, no issue needed\n- C\u002FD findings → produce a convergence issue\n- Extensive (>15 C\u002FD) → consider splitting by theme into multiple issues\n\n---\n\n## 3. Rules\n\n### 3.1. State purpose before checking details\n\nDo not cross-check artifacts before you can state the package's one job. If you can't state it, that's finding zero.\n\n- ❌ \"F1: beta\u002FSKILL.md and CDD.md disagree on step 9\" (without knowing what the package is for)\n- ✅ \"The package's job is X. Given that, here's where the parts disagree\"\n\n### 3.2. Work top-down\n\nPurpose → structure → agreement → reality → judgment. Each level depends on the one above. Do not invert the order.\n\n- ❌ Start with a line-by-line cross-check and derive structure from the findings\n- ✅ Start with purpose, let structure contextualize the detail findings\n\n### 3.3. Quote, don't summarize\n\nEvery finding must cite the specific text or path that constitutes the disagreement. Summarized findings are uncheckable.\n\n- ❌ \"The load order seems inconsistent\"\n- ✅ \"beta\u002FSKILL.md:35 loads post-release; gamma\u002FSKILL.md:4 says γ owns PRA — load order contradicts ownership\"\n\n### 3.4. Check the filesystem\n\nDo not trust artifact claims about paths, files, or commands. Verify them.\n\n- ❌ \"The skill references cn-cdd-verify, which presumably exists\"\n- ✅ `ls src\u002Fpackages\u002Fcnos.cdd\u002Fcommands\u002Fcdd-verify\u002Fcn-cdd-verify` → exists \u002F does not exist\n\n### 3.5. Grade honestly\n\nD means agents will do the wrong thing. A means improvement opportunity. Don't inflate for urgency theater or deflate to avoid seeming harsh.\n\n- ❌ Everything is C because it \"feels significant\"\n- ✅ D only when the disagreement changes agent behavior; A when it's genuinely informational\n\n### 3.6. Make themes actionable\n\nEach convergence theme must have a clear done state. If you can't say what \"fixed\" looks like, the theme is too vague.\n\n- ❌ \"Fix naming drift\" (which names? fixed how? done when?)\n- ✅ \"Artifact location alignment (F1, F4, F9): all five skills agree on POST-RELEASE-ASSESSMENT.md path. Done when: one canonical path, all references updated.\"\n\n### 3.7. One finding per disagreement\n\nDo not bundle unrelated disagreements. Each finding should be independently fixable and independently verifiable.\n\n### 3.8. Respect the inverse gate\n\nBefore producing an audit, check: does an existing audit already cover this scope? Is there already a filed issue with the same findings? Don't duplicate. (CAP §1.2a)\n\n---\n\n## 4. Verify\n\n### 4.1. Purpose check\n\nWas the purpose stated before detail work began? Does the verdict answer the purpose question?\n\n### 4.2. Coverage check\n\nDid the audit cover all artifacts in scope? Were all five levels (purpose, structure, agreement, reality, judgment) addressed?\n\n### 4.3. Evidence check\n\nDoes every finding cite specific text or paths? Were filesystem claims verified?\n\n### 4.4. Severity check\n\nAre D findings genuinely behavior-changing? Are A findings genuinely informational?\n\n### 4.5. Theme check\n\nDoes every C\u002FD finding belong to a convergence theme? Does every theme have a clear done state?\n\n### 4.6. Self-coherence check\n\nDoes the audit itself follow the top-down principle it demands of the artifacts it audits?\n\n---\n\n## 5. Output\n\nThe audit produces one document:\n\n```markdown\n# Coherence Audit — \u003Cpackage>\n\n## Purpose\nOne sentence: what this package does.\n\n## Verdict\nCoherent \u002F Locally coherent, globally drifted \u002F Incoherent\n\n## Structure\nDoes the shape serve the purpose? What doesn't belong? What's missing?\n\n## Findings\n| ID | Sev | Theme | Finding | Evidence |\n|----|-----|-------|---------|----------|\n\n## Convergence Themes\nFor each theme: the gap, which findings, what \"fixed\" looks like.\n\n## Convergence Path\nOrdered themes with rationale for the order.\n```\n\n---\n\n## 6. Kata\n\n### Scenario\n\nYou are auditing cnos.core — the foundational skills package containing agent\u002F, compose\u002F, design\u002F, naturalize\u002F, skill\u002F, write\u002F, audit\u002F, and ops\u002F.\n\n### Task\n\nJudge whether the package is coherent as a whole.\n\n### Governing skills\n\naudit, skill, compose, design\n\n### Inputs\n\nAll files under src\u002Fpackages\u002Fcnos.core\u002Fskills\u002F and cn.package.json.\n\n### Expected artifacts\n\nA coherence audit document per §5.\n\n### Verification\n\n- Was purpose stated before detail work?\n- Does the verdict match the evidence?\n- Does every finding cite specific text?\n- Were paths verified against the filesystem?\n- Are convergence themes actionable?\n\n### Common failures\n\n- Starting with detail cross-checks before stating purpose\n- Producing a finding list without a structural judgment\n- Citing from memory instead of quoting\n- Themes too vague to execute\n\n### Reflection\n\n- Does the audit tell you whether this package is healthy?\n- Could someone execute the convergence path without re-deriving the analysis?\n- Is the audit itself coherent top-down?\n","# Coherence Audit\n\n## Core Principle\n\n**Coherent audit judges a package top-down: purpose first, then structure, then agreement, then reality — and produces a convergence path that closes the governing gaps.**\n\nA package is coherent when it has one job, every part serves that job, every part agrees with every other part about how the job is done, and what the parts claim matches what actually exists.\n\n## Algorithm\n\n1. Define — name the parts of a coherence audit, state the formula, and name the failure mode.\n2. Unfold — execute the audit top-down: purpose → structure → agreement → reality → judgment.\n3. Rules — imperative constraints on how audits are conducted.\n4. Verify — check that the audit artifact is itself coherent.\n\n---\n\n## 1. Define\n\n### 1.1. Identify the parts\n\nA coherence audit has five parts:\n\n- **Purpose** — the package's one job\n- **Structure** — whether the shape serves the purpose\n- **Agreement** — whether the parts say the same thing about shared surfaces\n- **Reality** — whether claims match the filesystem and actual usage\n- **Judgment** — the verdict and convergence path\n\nEach part depends on the one before it. Purpose must be named before structure can be assessed. Structure must be understood before agreement findings have context. Agreement findings must exist before reality checks are meaningful. All four inform the judgment.\n\n- ❌ Start with detail cross-checks and hope a picture emerges\n- ✅ Start with purpose; let every subsequent finding serve the coherence question\n\n### 1.2. Articulate how they fit\n\nPurpose sets the standard. Structure reveals whether the package is organized to meet it. Agreement reveals whether the parts believe they're meeting it in the same way. Reality reveals whether what they claim is true. Judgment synthesizes all four into a verdict and a path.\n\nThe coherence formula: **a package is coherent when purpose, structure, agreement, and reality all align.**\n\n### 1.3. Name the governing question\n\n> This skill teaches how to judge whether a package is coherent and produce the smallest convergence path to make it so.\n\n### 1.4. Name the failure mode\n\nAudit fails through **bottom-up drift and ungrounded findings.**\n\nTypical signs:\n\n- detail findings without structural context — a list of nits with no governing judgment\n- findings that can't be verified from their citations\n- severity inflation or deflation — everything is D, or everything is A\n- convergence themes too vague to execute (\"fix naming\")\n- purpose never stated — the audit checks agreement without knowing what the parts should agree about\n- the audit duplicates an existing audit or filed issue (CAP §1.2a)\n\n---\n\n## 2. Unfold\n\n### 2.1. Purpose\n\nState the package's one job in one sentence. What coherence does it provide that wouldn't exist without it?\n\n- ❌ \"cnos.cdd contains CDD skills and tools\" (inventory, not purpose)\n- ✅ \"cnos.cdd makes triadic development cycles executable and verifiable\"\n\nIf the sentence needs \"and\" between unrelated clauses, the package may have two jobs. That's finding zero.\n\nThen check: does every top-level artifact serve this purpose?\n\n- **Yes** — it belongs\n- **No** — it should move or be removed\n- **Unclear** — either the purpose statement is vague or the artifact's role is ambiguous\n\nIf more than a few answer \"unclear,\" sharpen the purpose before continuing.\n\n### 2.2. Structure\n\nDoes the package's shape make the purpose executable?\n\n- Are skills grouped by the right axis?\n- Are roles, phases, or layers clear from the structure?\n- Does the structure create confusion about where something belongs?\n\nStructural anti-patterns:\n\n- **Two things with one name** — different artifacts use the same term for different concepts\n- **One thing with two names** — the same concept has different names in different places\n- **Orphaned artifacts** — files that nothing loads, references, or uses\n- **Circular authority** — A says B governs, B says A governs\n- **Layer smearing** — artifacts that mix concerns that should be separate\n- **Missing parts** — things the purpose clearly requires but the package doesn't provide\n\n### 2.3. Agreement\n\nFor each surface that appears in more than one artifact — a fact, policy, location, naming convention, role boundary, or load order — check: do the artifacts agree?\n\nWhen they disagree, record a finding:\n\n| ID | Sev | Theme | Finding | Evidence |\n|----|-----|-------|---------|----------|\n\nSeverity:\n\n- **D (Critical)** — agents will act wrongly. Behavior-changing contract drift.\n- **C (Significant)** — agents can work around it but shouldn't have to.\n- **B (Minor)** — low impact. Naming drift that doesn't cause confusion.\n- **A (Informational)** — not wrong, could be tighter.\n\nEvery finding must cite specific text from both sides. A finding you can't verify from the citations is not a finding.\n\n- ❌ \"The naming is inconsistent across files\"\n- ✅ \"F3 | C | Role ownership | beta\u002FSKILL.md:22 lists 'post-release assessment' as β-owned; gamma\u002FSKILL.md:35 assigns PRA to γ\"\n\n### 2.4. Reality\n\nVerify artifact claims against the actual system:\n\n- Do referenced paths exist?\n- Do referenced commands work as described?\n- Do artifact location claims match where artifacts actually live?\n- Are there artifacts that exist but are never loaded or referenced?\n\n- ❌ Trust what a skill says about the filesystem\n- ✅ Check the filesystem\n\n### 2.5. Judgment\n\nState the verdict. Three possible outcomes:\n\n- **Coherent** — purpose is clear, structure serves it, parts agree, claims match reality. Minor improvements possible but no convergence work needed.\n- **Locally coherent, globally drifted** — individual artifacts are well-written but they disagree with each other or with the stated purpose. Convergence work needed.\n- **Incoherent** — purpose is unclear or contested, structure doesn't serve it, significant disagreements. Restructuring needed.\n\nThen consolidate findings into convergence themes. A good theme:\n\n- Groups findings that share a root cause\n- Has a clear \"done\" state\n- Maps to a CDD cycle or a set of ACs in one issue\n\nOrder themes by: impact on agent behavior (D first), dependency (what unblocks what), then size (small wins first).\n\nDecide the output path:\n\n- All A\u002FB → note in a close-out or adhoc thread, no issue needed\n- C\u002FD findings → produce a convergence issue\n- Extensive (>15 C\u002FD) → consider splitting by theme into multiple issues\n\n---\n\n## 3. Rules\n\n### 3.1. State purpose before checking details\n\nDo not cross-check artifacts before you can state the package's one job. If you can't state it, that's finding zero.\n\n- ❌ \"F1: beta\u002FSKILL.md and CDD.md disagree on step 9\" (without knowing what the package is for)\n- ✅ \"The package's job is X. Given that, here's where the parts disagree\"\n\n### 3.2. Work top-down\n\nPurpose → structure → agreement → reality → judgment. Each level depends on the one above. Do not invert the order.\n\n- ❌ Start with a line-by-line cross-check and derive structure from the findings\n- ✅ Start with purpose, let structure contextualize the detail findings\n\n### 3.3. Quote, don't summarize\n\nEvery finding must cite the specific text or path that constitutes the disagreement. Summarized findings are uncheckable.\n\n- ❌ \"The load order seems inconsistent\"\n- ✅ \"beta\u002FSKILL.md:35 loads post-release; gamma\u002FSKILL.md:4 says γ owns PRA — load order contradicts ownership\"\n\n### 3.4. Check the filesystem\n\nDo not trust artifact claims about paths, files, or commands. Verify them.\n\n- ❌ \"The skill references cn-cdd-verify, which presumably exists\"\n- ✅ `ls src\u002Fpackages\u002Fcnos.cdd\u002Fcommands\u002Fcdd-verify\u002Fcn-cdd-verify` → exists \u002F does not exist\n\n### 3.5. Grade honestly\n\nD means agents will do the wrong thing. A means improvement opportunity. Don't inflate for urgency theater or deflate to avoid seeming harsh.\n\n- ❌ Everything is C because it \"feels significant\"\n- ✅ D only when the disagreement changes agent behavior; A when it's genuinely informational\n\n### 3.6. Make themes actionable\n\nEach convergence theme must have a clear done state. If you can't say what \"fixed\" looks like, the theme is too vague.\n\n- ❌ \"Fix naming drift\" (which names? fixed how? done when?)\n- ✅ \"Artifact location alignment (F1, F4, F9): all five skills agree on POST-RELEASE-ASSESSMENT.md path. Done when: one canonical path, all references updated.\"\n\n### 3.7. One finding per disagreement\n\nDo not bundle unrelated disagreements. Each finding should be independently fixable and independently verifiable.\n\n### 3.8. Respect the inverse gate\n\nBefore producing an audit, check: does an existing audit already cover this scope? Is there already a filed issue with the same findings? Don't duplicate. (CAP §1.2a)\n\n---\n\n## 4. Verify\n\n### 4.1. Purpose check\n\nWas the purpose stated before detail work began? Does the verdict answer the purpose question?\n\n### 4.2. Coverage check\n\nDid the audit cover all artifacts in scope? Were all five levels (purpose, structure, agreement, reality, judgment) addressed?\n\n### 4.3. Evidence check\n\nDoes every finding cite specific text or paths? Were filesystem claims verified?\n\n### 4.4. Severity check\n\nAre D findings genuinely behavior-changing? Are A findings genuinely informational?\n\n### 4.5. Theme check\n\nDoes every C\u002FD finding belong to a convergence theme? Does every theme have a clear done state?\n\n### 4.6. Self-coherence check\n\nDoes the audit itself follow the top-down principle it demands of the artifacts it audits?\n\n---\n\n## 5. Output\n\nThe audit produces one document:\n\n```markdown\n# Coherence Audit — \u003Cpackage>\n\n## Purpose\nOne sentence: what this package does.\n\n## Verdict\nCoherent \u002F Locally coherent, globally drifted \u002F Incoherent\n\n## Structure\nDoes the shape serve the purpose? What doesn't belong? What's missing?\n\n## Findings\n| ID | Sev | Theme | Finding | Evidence |\n|----|-----|-------|---------|----------|\n\n## Convergence Themes\nFor each theme: the gap, which findings, what \"fixed\" looks like.\n\n## Convergence Path\nOrdered themes with rationale for the order.\n```\n\n---\n\n## 6. Kata\n\n### Scenario\n\nYou are auditing cnos.core — the foundational skills package containing agent\u002F, compose\u002F, design\u002F, naturalize\u002F, skill\u002F, write\u002F, audit\u002F, and ops\u002F.\n\n### Task\n\nJudge whether the package is coherent as a whole.\n\n### Governing skills\n\naudit, skill, compose, design\n\n### Inputs\n\nAll files under src\u002Fpackages\u002Fcnos.core\u002Fskills\u002F and cn.package.json.\n\n### Expected artifacts\n\nA coherence audit document per §5.\n\n### Verification\n\n- Was purpose stated before detail work?\n- Does the verdict match the evidence?\n- Does every finding cite specific text?\n- Were paths verified against the filesystem?\n- Are convergence themes actionable?\n\n### Common failures\n\n- Starting with detail cross-checks before stating purpose\n- Producing a finding list without a structural judgment\n- Citing from memory instead of quoting\n- Themes too vague to execute\n\n### Reflection\n\n- Does the audit tell you whether this package is healthy?\n- Could someone execute the convergence path without re-deriving the analysis?\n- Is the audit itself coherent top-down?\n",{"name":5,"scope":32,"triggers":33,"description":7,"kata_surface":25,"artifact_class":38,"governing_question":39},"task-local",[34,35,36,37],"auditing a package for coherence","assessing whether a package's parts agree","preparing convergence work for a package","evaluating package health before a release or restructure","skill","How do we judge whether a package is coherent — and produce the smallest convergence path to make it so?","main","fb527e6c4bfb75c71fa75d6471b3aa3da32106d4","src\u002Fpackages\u002Fcnos.core\u002Fskills\u002Faudit",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":49,"prompt":59,"zipAvailable":60},[50,53,56],{"tool":51,"command":52},"npx","npx skills add usurobor\u002Fcnos --skill audit",{"tool":54,"command":55},"bunx","bunx skills add usurobor\u002Fcnos --skill audit",{"tool":57,"command":58},"pnpm","pnpm dlx skills add usurobor\u002Fcnos --skill audit","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.core\u002Fskills\u002Faudit\u002FSKILL.md",true,[62,68],{"path":63,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":66,"sourceHtmlUrl":67},"scripts\u002Ffind-sessions.sh","SCRIPT","脚本",2945,"https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fplugins\u002Fhot-skills\u002Fskills\u002Ftmux\u002Fscripts\u002Ffind-sessions.sh",{"path":69,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":70,"sourceHtmlUrl":71},"scripts\u002Fwait-for-text.sh",2139,"https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fplugins\u002Fhot-skills\u002Fskills\u002Ftmux\u002Fscripts\u002Fwait-for-text.sh",[73,91,107,135,151,171],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":27},"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",[],[80,81,82,83,84,23,85,86,87,88,89,90],"triage","issues","issues triage","issue triage","SET","decision","public","use","dispatch","issue","doctrine",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":27},"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",[],[81,98,99,100,101,102,84,103,86,104,87,88,105,89,106],"taxonomy","issues taxonomy","github","status","protocol","open","board","github issue","issue labels",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":123,"publishedAt":27},"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",[113,118],{"categoryNo":114,"categoryName":115,"taxonomyType":116,"taxonomyTypeDesc":117},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":119,"categoryName":120,"taxonomyType":121,"taxonomyTypeDesc":122},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[81,124,100,125,126,127,84,128,98,103,23,129,130,104,131,132,133,134,87,89],"issues map","reasoning","data","pipeline","api","json","README","edit","interactive","fetch","generated",{"skillNo":136,"name":81,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":27},"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",[],[81,100,141,142,143,144,145,21,146,98,103,23,85,147,130,148,87,149,88,150],"pr","current state","run","artifacts","state","boundary","branch","command","only","cds",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":27},"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",[],[158,159,144,102,160,23,161,162,163,86,164,165,166,167,87,25,168,169,170,90],"receipt stream","handoff","index","learning","format","trace","repo","closeout","read","channel","patch","shape","cdd",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":177,"publishedAt":27},"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",[],[178,100,179,180,181,182,23,183,184,147,164,166,87,149,88,185,105,186,187,188],"mid flight","change","sessions","file","cache","pin","coordination","up","Legacy","gamma","artifact channel"]