[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CF62MG49Y6923DAY8KBZF6":3,"skill-same:01M6CF62MG49Y6923DAY8KBZF6":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":18,"publishedAt":33,"linkOnly":34,"markdownContent":35,"markdownBody":36,"frontMatter":37,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":6,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M6CF62MG49Y6923DAY8KBZF6","write",null,"Write so the reader understands the point on the first pass. Use for docs, issues, specs, READMEs, essays, reviews, and status updates.","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\u002Fwrite\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32],"docs","architecture","status","issues","quickstart","compression","first","how","reader","README","use","status updates","files","prose","2026-11-10 10:12:30",false,"---\nname: write\ndescription: Write so the reader understands the point on the first pass. Use for docs, issues, specs, READMEs, essays, reviews, and status updates.\ngoverning_question: How do we make prose carry the point on the first pass without losing meaning to compression or sprawl?\ntriggers:\n  - drafting new docs\n  - rewriting unclear docs\n  - fixing repetition across files\n  - tightening README \u002F architecture \u002F quickstart splits\n  - reducing clutter without losing meaning\nscope: task-local\n---\n\n# Writing\n\n## Core Principle\n\nCoherent writing moves understanding forward with the minimum text required.\n\nNothing can be removed without loss. Nothing should be repeated without gain. Each file should answer one governing question.\n\nIf a document argues with itself, it usually has too many jobs, repeats stable facts, or explains what something is not instead of what it is.\n\n## Algorithm\n\n1. Define — name the governing question, the reader, the stable facts, and the failure mode.\n2. Unfold — organize from document → section → paragraph → sentence → word.\n3. Rules — state imperative rules with direct ❌\u002F✅ examples and revise in that same order.\n\n---\n\n## 1. Define\n\n### 1.1. Identify the parts\n\nA coherent text has five levels:\n\n- Document — one governing question\n- Section — one sub-question\n- Paragraph — one move\n- Sentence — one main claim\n- Word — one job\n\n- ❌ Start at the sentence level and hope the document works\n- ✅ Name the document's job first, then make every lower level serve it\n\n### 1.2. Articulate how they fit\n\nThe document sets the question. Each section answers part of it. Each paragraph advances one step. Each sentence makes one move. Each word earns its place.\n\n- ❌ One file explains purpose, architecture, roadmap, and usage at once\n- ✅ One file answers one question and points elsewhere for the rest\n\n### 1.3. Name the governing question\n\nState the file's job in one sentence beginning with:\n\n> This document explains...\n\nIf you need two different governing sentences, you probably have two files.\n\n- ❌ \"This document explains the repo, the architecture, how to run it, and the roadmap\"\n- ✅ \"This document explains how the repo is organized\"\n- ✅ \"This guide explains the current runnable path\"\n\n### 1.4. Name the stable facts\n\nStable facts are the facts that should be stated once, then pointed to elsewhere.\n\nExamples:\n\n- what the repo is\n- where authority lives\n- what config is live\n- what the current implementation is\n- what path is canonical\n\n- ❌ Restate the same stable fact in README, ARCHITECTURE, and QUICKSTART\n- ✅ Give the fact one home and link or point to it from other files\n\n### 1.5. Name the failure mode\n\nWriting fails through clutter and drift. Typical signs:\n\n- the file has two jobs\n- the point appears late\n- the same fact appears in multiple files\n- transitions compensate for weak logic\n- abstractions replace specifics\n- the reader must infer authority or scope\n\n- ❌ \"This repo is not X, not Y, not Z\"\n- ✅ \"This repo is X\"\n\n---\n\n## 2. Unfold\n\n### 2.1. Document\n\nStart with the point. The first sentence should orient the reader immediately. The first paragraph should commit to the file's job.\n\n- ❌ Three paragraphs of setup before the point appears\n- ✅ \"TSC is a theory, a target model, and a verifier for triadic coherence.\"\n- ✅ \"This guide explains the current runnable path.\"\n\n### 2.2. Section\n\nEach section should answer one sub-question only. Name sections by what they do, not by vague themes.\n\n- ❌ \"Additional Notes\"\n- ❌ \"Overview and Miscellaneous\"\n- ✅ \"Targets\"\n- ✅ \"Implementation\"\n- ✅ \"Generated state\"\n\nIf a section answers a different question, move it to another file.\n\n### 2.3. Paragraph\n\nOne paragraph, one move. A paragraph may:\n\n- state a claim\n- explain a mechanism\n- compare two options\n- give one example\n- close one implication\n\nIt should not do several unrelated things because they are nearby in your head.\n\n- ❌ One paragraph defines the repo, explains the current CLI, and previews future implementation plans\n- ✅ One paragraph for current implementation, one for future direction\n\n### 2.4. Sentence\n\nLead with the point. Put stable context first. Put the new or important information at the end.\n\nWhen a claim depends on an example, number, quote, or case, put the instance before or immediately adjacent to the abstraction. Do not make the reader hold a generic claim while waiting for the evidence.\n\n- ❌ \"The current executable path is the Python implementation under reference\u002Fpython\u002F.\"\n- ✅ \"Python runs the current CLI.\"\n- ❌ \"The target model lives in project.tsc and targets\u002F.\"\n- ✅ \"`project.tsc` is the live config. targets\u002F defines the named-target model.\"\n- ❌ \"The system improved significantly after the change. Response times dropped from 800 ms to 120 ms.\"\n- ✅ \"Response times dropped from 800 ms to 120 ms after the change.\"\n- ❌ \"Several users hit the same bug. This showed the retry path was broken.\"\n- ✅ \"Several users hit the same bug, which showed the retry path was broken.\"\n\n### 2.5. Word\n\nEvery word must do new work. Prefer:\n\n- short words over long words\n- plain words over jargon\n- active verbs over abstract nouns\n- concrete nouns over vague labels\n\n- ❌ \"utilize\"\n- ✅ \"use\"\n- ❌ \"current executable implementation\"\n- ✅ \"current implementation\"\n- ❌ \"named target declarations\"\n- ✅ \"targets\"\n\n---\n\n## 3. Rules\n\n### 3.1. State what it is\n\nDefine the thing positively. Use contrast only when the distinction is truly load-bearing.\n\n- ❌ \"This is not a platform, not a chat UI, not a product surface\"\n- ✅ \"This is a protocol\"\n- ✅ \"This is the current runnable path\"\n- ✅ \"This is the canonical spec\"\n\n### 3.2. One file, one governing question\n\nDo not let one file do several jobs.\n\n- ❌ README also doing architecture, roadmap, quickstart, and manifesto\n- ✅ README gives identity, map, and pointers\n- ✅ ARCHITECTURE owns structure and authority\n- ✅ QUICKSTART owns the runnable path\n\n### 3.3. Say a fact once, then point to it\n\nStable facts should have one home.\n\n- ❌ \"Python is the current implementation\" stated in three files with slightly different wording\n- ✅ State it once clearly; elsewhere point to the file that owns it\n\n### 3.4. Front-load the point\n\nThe first sentence must orient. The second may qualify. The third may expand.\n\n- ❌ \"It is important to understand the broader context before...\"\n- ✅ \"This document explains how the repo is organized.\"\n\n### 3.5. Cut throat-clearing\n\nRemove self-introduction, permission slips, and commentary on the act of writing.\n\n- ❌ \"It is worth noting that...\"\n- ❌ \"This section describes...\"\n- ✅ say the thing\n\n### 3.6. Cut filler transitions\n\nUse transitions only when they add logic:\n\n- But for contrast\n- So for consequence\n- Because for cause\n- Then for sequence\n\n- ❌ \"Additionally, furthermore, moreover\"\n- ✅ next sentence or next paragraph\n\n### 3.7. Prefer active voice when agency matters\n\n- ❌ \"The file was updated by the user\"\n- ✅ \"The user updated the file\"\n\nUse passive only when the actor is irrelevant or unknown.\n\n### 3.8. Replace abstractions with specifics\n\nDo not write \"better,\" \"clean,\" \"robust,\" or \"flexible\" without evidence.\n\n- ❌ \"This design is cleaner\"\n- ✅ \"This removes one duplicate source of truth\"\n- ❌ \"The system is fast\"\n- ✅ \"The response arrives in under 50 ms\"\n\n### 3.9. Replace opinion with source or reason\n\n- ❌ \"This is the best approach\"\n- ✅ \"This matches the current runtime contract\"\n- ✅ \"This removes two dead links and one duplicate fact\"\n\n### 3.10. Keep stable context before new information\n\nReaders follow best when the sentence starts from what they already know and ends on what matters.\n\n- ❌ \"In the target model declared by the repo, project.tsc...\"\n- ✅ \"`project.tsc` is the live config.\"\n\n### 3.11. Use lists only when they reveal structure\n\nUse a list when:\n\n- order matters\n- the items are parallel\n- scanning helps\n\n- ❌ Three bullets that are really one sentence\n- ✅ Three bullets naming three distinct categories\n\n### 3.12. Keep examples small and contrastive\n\nShow one mistake and one fix.\n\n- ❌ One giant before\u002Fafter block with five changes at once\n- ✅ One bad line and one better line\n\n### 3.13. Keep authority explicit\n\nIf a document depends on another document, say so directly.\n\n- ❌ Let the reader infer which file governs\n- ✅ \"Theory is canonical.\"\n- ✅ \"`project.tsc` is the live config.\"\n- ✅ \"This file is a guide, not the spec.\"\n\n### 3.14. Brevity is earned, not chopped\n\nShorter is better only when meaning survives.\n\nCut:\n\n- repetition\n- filler\n- duplicate facts\n- vague intensifiers\n- decorative contrast\n\nDo not cut:\n\n- distinctions that prevent error\n- definitions that carry authority\n- examples that disambiguate a rule\n\n- ❌ Remove the only sentence that explains which file governs\n- ✅ Remove the second and third restatement of it\n\n### 3.15. End when the point is delivered\n\nThe ending should close the document's job. It should not restart the argument.\n\n- ❌ Final paragraph that restates the whole file in softer language\n- ✅ Final line that closes the last open question\n\n---\n\n## 4. Revision Pass\n\nDo not mix passes. Finish the current level before moving to the next. Line-editing while restructuring is the most common violation.\n\nRevise in this order.\n\n### 4.1. File pass\n\n- What is the one governing question?\n- Does every section serve it?\n- Which stable facts belong here, and which belong elsewhere?\n\n### 4.2. Section pass\n\n- Does each section answer one sub-question?\n- Can any section be cut, merged, or moved?\n\n### 4.3. Paragraph pass\n\n- One move per paragraph?\n- Any paragraph doing two jobs?\n\n### 4.4. Sentence pass\n\n- Point first?\n- Stable context before new information?\n- When a claim depends on an instance, is the instance adjacent to it?\n- Active voice where agency matters?\n\n### 4.5. Word pass\n\n- Can this word be cut?\n- Can this phrase be shorter?\n- Can this abstraction be made concrete?\n\n---\n\n## 5. Final Test\n\nA text is coherent when:\n\n- the reader knows what the file is for by the first sentence\n- each section answers one question\n- each paragraph makes one move\n- each sentence lands its point early\n- each word does new work\n- no stable fact is duplicated without gain\n\nIf a word, sentence, paragraph, or section can be removed without loss, remove it.\n\nIf a fact appears twice, choose one home and point to it.\n\nIf the file has two jobs, split it.\n","# Writing\n\n## Core Principle\n\nCoherent writing moves understanding forward with the minimum text required.\n\nNothing can be removed without loss. Nothing should be repeated without gain. Each file should answer one governing question.\n\nIf a document argues with itself, it usually has too many jobs, repeats stable facts, or explains what something is not instead of what it is.\n\n## Algorithm\n\n1. Define — name the governing question, the reader, the stable facts, and the failure mode.\n2. Unfold — organize from document → section → paragraph → sentence → word.\n3. Rules — state imperative rules with direct ❌\u002F✅ examples and revise in that same order.\n\n---\n\n## 1. Define\n\n### 1.1. Identify the parts\n\nA coherent text has five levels:\n\n- Document — one governing question\n- Section — one sub-question\n- Paragraph — one move\n- Sentence — one main claim\n- Word — one job\n\n- ❌ Start at the sentence level and hope the document works\n- ✅ Name the document's job first, then make every lower level serve it\n\n### 1.2. Articulate how they fit\n\nThe document sets the question. Each section answers part of it. Each paragraph advances one step. Each sentence makes one move. Each word earns its place.\n\n- ❌ One file explains purpose, architecture, roadmap, and usage at once\n- ✅ One file answers one question and points elsewhere for the rest\n\n### 1.3. Name the governing question\n\nState the file's job in one sentence beginning with:\n\n> This document explains...\n\nIf you need two different governing sentences, you probably have two files.\n\n- ❌ \"This document explains the repo, the architecture, how to run it, and the roadmap\"\n- ✅ \"This document explains how the repo is organized\"\n- ✅ \"This guide explains the current runnable path\"\n\n### 1.4. Name the stable facts\n\nStable facts are the facts that should be stated once, then pointed to elsewhere.\n\nExamples:\n\n- what the repo is\n- where authority lives\n- what config is live\n- what the current implementation is\n- what path is canonical\n\n- ❌ Restate the same stable fact in README, ARCHITECTURE, and QUICKSTART\n- ✅ Give the fact one home and link or point to it from other files\n\n### 1.5. Name the failure mode\n\nWriting fails through clutter and drift. Typical signs:\n\n- the file has two jobs\n- the point appears late\n- the same fact appears in multiple files\n- transitions compensate for weak logic\n- abstractions replace specifics\n- the reader must infer authority or scope\n\n- ❌ \"This repo is not X, not Y, not Z\"\n- ✅ \"This repo is X\"\n\n---\n\n## 2. Unfold\n\n### 2.1. Document\n\nStart with the point. The first sentence should orient the reader immediately. The first paragraph should commit to the file's job.\n\n- ❌ Three paragraphs of setup before the point appears\n- ✅ \"TSC is a theory, a target model, and a verifier for triadic coherence.\"\n- ✅ \"This guide explains the current runnable path.\"\n\n### 2.2. Section\n\nEach section should answer one sub-question only. Name sections by what they do, not by vague themes.\n\n- ❌ \"Additional Notes\"\n- ❌ \"Overview and Miscellaneous\"\n- ✅ \"Targets\"\n- ✅ \"Implementation\"\n- ✅ \"Generated state\"\n\nIf a section answers a different question, move it to another file.\n\n### 2.3. Paragraph\n\nOne paragraph, one move. A paragraph may:\n\n- state a claim\n- explain a mechanism\n- compare two options\n- give one example\n- close one implication\n\nIt should not do several unrelated things because they are nearby in your head.\n\n- ❌ One paragraph defines the repo, explains the current CLI, and previews future implementation plans\n- ✅ One paragraph for current implementation, one for future direction\n\n### 2.4. Sentence\n\nLead with the point. Put stable context first. Put the new or important information at the end.\n\nWhen a claim depends on an example, number, quote, or case, put the instance before or immediately adjacent to the abstraction. Do not make the reader hold a generic claim while waiting for the evidence.\n\n- ❌ \"The current executable path is the Python implementation under reference\u002Fpython\u002F.\"\n- ✅ \"Python runs the current CLI.\"\n- ❌ \"The target model lives in project.tsc and targets\u002F.\"\n- ✅ \"`project.tsc` is the live config. targets\u002F defines the named-target model.\"\n- ❌ \"The system improved significantly after the change. Response times dropped from 800 ms to 120 ms.\"\n- ✅ \"Response times dropped from 800 ms to 120 ms after the change.\"\n- ❌ \"Several users hit the same bug. This showed the retry path was broken.\"\n- ✅ \"Several users hit the same bug, which showed the retry path was broken.\"\n\n### 2.5. Word\n\nEvery word must do new work. Prefer:\n\n- short words over long words\n- plain words over jargon\n- active verbs over abstract nouns\n- concrete nouns over vague labels\n\n- ❌ \"utilize\"\n- ✅ \"use\"\n- ❌ \"current executable implementation\"\n- ✅ \"current implementation\"\n- ❌ \"named target declarations\"\n- ✅ \"targets\"\n\n---\n\n## 3. Rules\n\n### 3.1. State what it is\n\nDefine the thing positively. Use contrast only when the distinction is truly load-bearing.\n\n- ❌ \"This is not a platform, not a chat UI, not a product surface\"\n- ✅ \"This is a protocol\"\n- ✅ \"This is the current runnable path\"\n- ✅ \"This is the canonical spec\"\n\n### 3.2. One file, one governing question\n\nDo not let one file do several jobs.\n\n- ❌ README also doing architecture, roadmap, quickstart, and manifesto\n- ✅ README gives identity, map, and pointers\n- ✅ ARCHITECTURE owns structure and authority\n- ✅ QUICKSTART owns the runnable path\n\n### 3.3. Say a fact once, then point to it\n\nStable facts should have one home.\n\n- ❌ \"Python is the current implementation\" stated in three files with slightly different wording\n- ✅ State it once clearly; elsewhere point to the file that owns it\n\n### 3.4. Front-load the point\n\nThe first sentence must orient. The second may qualify. The third may expand.\n\n- ❌ \"It is important to understand the broader context before...\"\n- ✅ \"This document explains how the repo is organized.\"\n\n### 3.5. Cut throat-clearing\n\nRemove self-introduction, permission slips, and commentary on the act of writing.\n\n- ❌ \"It is worth noting that...\"\n- ❌ \"This section describes...\"\n- ✅ say the thing\n\n### 3.6. Cut filler transitions\n\nUse transitions only when they add logic:\n\n- But for contrast\n- So for consequence\n- Because for cause\n- Then for sequence\n\n- ❌ \"Additionally, furthermore, moreover\"\n- ✅ next sentence or next paragraph\n\n### 3.7. Prefer active voice when agency matters\n\n- ❌ \"The file was updated by the user\"\n- ✅ \"The user updated the file\"\n\nUse passive only when the actor is irrelevant or unknown.\n\n### 3.8. Replace abstractions with specifics\n\nDo not write \"better,\" \"clean,\" \"robust,\" or \"flexible\" without evidence.\n\n- ❌ \"This design is cleaner\"\n- ✅ \"This removes one duplicate source of truth\"\n- ❌ \"The system is fast\"\n- ✅ \"The response arrives in under 50 ms\"\n\n### 3.9. Replace opinion with source or reason\n\n- ❌ \"This is the best approach\"\n- ✅ \"This matches the current runtime contract\"\n- ✅ \"This removes two dead links and one duplicate fact\"\n\n### 3.10. Keep stable context before new information\n\nReaders follow best when the sentence starts from what they already know and ends on what matters.\n\n- ❌ \"In the target model declared by the repo, project.tsc...\"\n- ✅ \"`project.tsc` is the live config.\"\n\n### 3.11. Use lists only when they reveal structure\n\nUse a list when:\n\n- order matters\n- the items are parallel\n- scanning helps\n\n- ❌ Three bullets that are really one sentence\n- ✅ Three bullets naming three distinct categories\n\n### 3.12. Keep examples small and contrastive\n\nShow one mistake and one fix.\n\n- ❌ One giant before\u002Fafter block with five changes at once\n- ✅ One bad line and one better line\n\n### 3.13. Keep authority explicit\n\nIf a document depends on another document, say so directly.\n\n- ❌ Let the reader infer which file governs\n- ✅ \"Theory is canonical.\"\n- ✅ \"`project.tsc` is the live config.\"\n- ✅ \"This file is a guide, not the spec.\"\n\n### 3.14. Brevity is earned, not chopped\n\nShorter is better only when meaning survives.\n\nCut:\n\n- repetition\n- filler\n- duplicate facts\n- vague intensifiers\n- decorative contrast\n\nDo not cut:\n\n- distinctions that prevent error\n- definitions that carry authority\n- examples that disambiguate a rule\n\n- ❌ Remove the only sentence that explains which file governs\n- ✅ Remove the second and third restatement of it\n\n### 3.15. End when the point is delivered\n\nThe ending should close the document's job. It should not restart the argument.\n\n- ❌ Final paragraph that restates the whole file in softer language\n- ✅ Final line that closes the last open question\n\n---\n\n## 4. Revision Pass\n\nDo not mix passes. Finish the current level before moving to the next. Line-editing while restructuring is the most common violation.\n\nRevise in this order.\n\n### 4.1. File pass\n\n- What is the one governing question?\n- Does every section serve it?\n- Which stable facts belong here, and which belong elsewhere?\n\n### 4.2. Section pass\n\n- Does each section answer one sub-question?\n- Can any section be cut, merged, or moved?\n\n### 4.3. Paragraph pass\n\n- One move per paragraph?\n- Any paragraph doing two jobs?\n\n### 4.4. Sentence pass\n\n- Point first?\n- Stable context before new information?\n- When a claim depends on an instance, is the instance adjacent to it?\n- Active voice where agency matters?\n\n### 4.5. Word pass\n\n- Can this word be cut?\n- Can this phrase be shorter?\n- Can this abstraction be made concrete?\n\n---\n\n## 5. Final Test\n\nA text is coherent when:\n\n- the reader knows what the file is for by the first sentence\n- each section answers one question\n- each paragraph makes one move\n- each sentence lands its point early\n- each word does new work\n- no stable fact is duplicated without gain\n\nIf a word, sentence, paragraph, or section can be removed without loss, remove it.\n\nIf a fact appears twice, choose one home and point to it.\n\nIf the file has two jobs, split it.\n",{"name":5,"scope":38,"triggers":39,"description":7,"governing_question":45},"task-local",[40,41,42,43,44],"drafting new docs","rewriting unclear docs","fixing repetition across files","tightening README \u002F architecture \u002F quickstart splits","reducing clutter without losing meaning","How do we make prose carry the point on the first pass without losing meaning to compression or sprawl?","main","fb527e6c4bfb75c71fa75d6471b3aa3da32106d4","src\u002Fpackages\u002Fcnos.core\u002Fskills\u002Fwrite",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 write",{"tool":60,"command":61},"bunx","bunx skills add usurobor\u002Fcnos --skill write",{"tool":63,"command":64},"pnpm","pnpm dlx skills add usurobor\u002Fcnos --skill write","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.core\u002Fskills\u002Fwrite\u002FSKILL.md",true,[],[69,85,100,127,144,165],{"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":33},"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,22,77,78,79,26,80,81,29,82,83,84],"triage","issues triage","issue triage","SET","decision","public","dispatch","issue","doctrine",{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":33},"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",[],[22,92,93,94,21,95,79,96,81,97,29,82,98,83,99],"taxonomy","issues taxonomy","github","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":116,"publishedAt":33},"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,111],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[22,117,94,118,119,120,79,121,92,96,26,122,28,97,123,124,125,126,29,83],"issues map","reasoning","data","pipeline","api","json","edit","interactive","fetch","generated",{"skillNo":128,"name":22,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":33},"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",[],[22,94,133,134,135,136,137,138,139,92,96,26,80,140,28,141,29,142,82,143],"pr","current state","run","artifacts","state","package","boundary","branch","command","only","cds",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":150,"publishedAt":33},"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",[],[151,152,136,95,153,26,154,155,156,81,157,158,159,160,29,161,162,163,164,84],"receipt stream","handoff","index","learning","format","trace","repo","closeout","read","channel","embedded","patch","shape","cdd",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":33},"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",[],[172,94,173,174,175,176,26,177,178,140,157,159,29,142,82,179,98,180,181,182],"mid flight","change","sessions","file","cache","pin","coordination","up","Legacy","gamma","artifact channel"]