[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CF1TR2QD8ZCJSVP4Q51M6A":3,"skill-same:01M6CF1TR2QD8ZCJSVP4Q51M6A":73},{"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":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M6CF1TR2QD8ZCJSVP4Q51M6A","cdp\u002Fplanning-hierarchy",null,"Structure a body of work so every unit rolls up to an owned workstream through a track, with one canonical source of truth per level. Use when organizing a backlog, defining workstreams\u002Ftracks, assigning ownership, or making a program legible at a glance.","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.cdp\u002Fskills\u002Fcdp\u002Fplanning-hierarchy\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29],"planning","cdp planning hierarchy","tasks","issues","doc","how","owners","clarity","work","use","up","2026-11-10 10:12:30",false,"---\nname: cdp\u002Fplanning-hierarchy\ndescription: Structure a body of work so every unit rolls up to an owned workstream through a track, with one canonical source of truth per level. Use when organizing a backlog, defining workstreams\u002Ftracks, assigning ownership, or making a program legible at a glance.\ngoverning_question: How do we structure a body of work so it reads with extreme clarity — every unit rolling up to an owned workstream through a track, with one canonical source of truth per level?\ntriggers:\n  - organizing a backlog into initiatives\n  - defining workstreams or tracks\n  - assigning single-threaded ownership\n  - deciding where the source of truth for an initiative lives\n  - a program is hard to reason about at a glance\nscope: task-local\nartifact_class: skill\nkata_surface: none\ninputs:\n  - a body of work (backlog of issues or tasks)\n  - current ownership and sources of truth\noutputs:\n  - a `workstream ⊃ track ⊃ unit` structure with single-threaded owners\n  - one canonical doc per level\n---\n\n# Planning Hierarchy\n\n## Core Principle\n\nA body of work is legible when every unit rolls up to one owned workstream, and every level has one canonical source of truth.\n\n`workstream ⊃ track ⊃ unit`. A workstream is a top-level area of work with a single-threaded owner and its own canonical doc. A track is a sub-workstream inside exactly one workstream, also owned. A unit (issue, task) belongs to exactly one track. No orphan work; no diffuse ownership; no scattered truth.\n\nThis adapts Naomi Gleit's practice: workstreams with single-threaded owners, each with its own canonical doc linked from an overall canonical doc, recursively — the discipline she calls Canonical Everything, in service of Extreme Clarity. Source: Naomi Gleit, \"Canonical Everything\" — https:\u002F\u002Fnaomi.com\u002Fcanonical-everything-c85441a84e70; interview context in Lenny's Newsletter — https:\u002F\u002Fwww.lennysnewsletter.com\u002Fp\u002Fmetas-head-of-product-naomi-gleit.\n\n## Algorithm\n\n1. Define — name the workstreams, tracks, units, owners, and canonical docs, and the failure mode.\n2. Unfold — build top-down: workstreams, then tracks, then assign every unit; give each level an owner and a canonical doc.\n3. Rules — one workstream per initiative, one owner per level, one canonical doc per level, no orphan unit.\n\n---\n\n## 1. Define\n\n### 1.1. Identify the parts\n\nA coherent program has these parts:\n\n- **Workstream** — a top-level discrete area of work. Owned. Has its own canonical doc.\n- **Track** — a sub-workstream inside exactly one workstream. Owned.\n- **Unit** — one issue or task, inside exactly one track.\n- **Single-threaded owner** — the one person or agent accountable for a level.\n- **Canonical doc** — the one source of truth for a level.\n- **Nomenclature** — the shared, defined vocabulary the program is described in.\n\n- ❌ \"These issues are roughly about the platform\"\n- ✅ \"`workstream\u002Fplatform`, owned by cn-sigma, canonical doc #452, tracks: wake-runtime, scheduler, trace\"\n\n### 1.2. Articulate how they fit\n\nThe workstream sets the area. Each track answers a sub-area. Each unit does one piece. Each level names one owner and one canonical doc. Reading up from any unit reaches exactly one track, one workstream, one owner, one source of truth.\n\n- ❌ A unit that belongs to two workstreams \"because it touches both\"\n- ✅ A unit in one track; the cross-cutting relationship is a link, not a second parent\n\n### 1.3. Name the governing question\n\nState the program's shape in one sentence:\n\n> This workstream is the discrete area of `\u003CX>`, owned by `\u003Cowner>`, canonical at `\u003Cdoc>`.\n\nIf a workstream needs two owners or two canonical docs, it is two workstreams.\n\n- ❌ \"Substrate-and-platform-and-tooling, owned by the team\"\n- ✅ \"`workstream\u002Fthreads`, owned by cn-sigma, canonical #698\"\n\n### 1.4. Name the canonical doc\n\nThe canonical doc is the one place a level's truth lives; everywhere else points to it.\n\nPer level:\n\n- the overall program has one canonical doc that lists the workstreams\n- each workstream has its own canonical doc, linked from the overall one\n- Canonical Everything recurses: a track large enough to need its own truth gets its own canonical doc, linked from the workstream's\n\n- ❌ The plan restated in three issues that drift apart\n- ✅ One canonical doc per level; the rest link to it\n\n### 1.5. Name the failure mode\n\nPlanning fails through four losses:\n\n- **Orphan work** — a unit belongs to no track, so no one owns it\n- **Diffuse ownership** — a level has zero or many owners, so decisions stall\n- **Scattered truth** — the same plan lives in many places and drifts\n- **Vocabulary drift** — the same word means different things to different people\n\n- ❌ \"Someone will pick it up\"\n- ✅ \"Every unit has a track; every track has an owner\"\n\n---\n\n## 2. Unfold\n\n### 2.1. Name the workstreams (top-down, MECE)\n\nStart at the top. Name the discrete areas of work so they are mutually exclusive and collectively exhaustive — every unit will fit exactly one, and none is left over.\n\nWorkstreams are at **initiative grain**, not theme grain: `generic-cell`, `threads`, `memory` — not one giant `substrate`. Expect roughly a dozen, not three.\n\n- ❌ Five broad buckets that force unrelated work together\n- ✅ ~12 initiatives, each a real area someone can own\n\n### 2.2. Give each workstream one owner and one canonical doc\n\nBefore subdividing, assign the single-threaded owner and the canonical doc. A workstream without an owner is a wish; without a canonical doc it will drift.\n\n- ❌ \"`workstream\u002Fmemory` — we'll sort ownership later\"\n- ✅ \"`workstream\u002Fmemory`, owner cn-sigma, canonical #690\"\n\n### 2.3. Subdivide into tracks\n\nInside each workstream, name the sub-workstreams. A track answers one sub-area of its workstream. Give each track an owner too when the workstream is large enough that one owner cannot hold it all.\n\n- ❌ A workstream with forty loose units and no internal structure\n- ✅ `workstream\u002Fgeneric-cell` → tracks: cell-fsm, cell-classes, planning-cell, claim-dispatch\n\n### 2.4. Assign every unit to exactly one track\n\nWalk the backlog. Each unit gets one track — and therefore one workstream and one owner. A unit that seems to fit two tracks picks its primary; the other relationship is a link.\n\n- ❌ Leave twenty units untriaged \"for now\"\n- ✅ Every unit carries one track; zero orphans\n\n### 2.5. Maintain the overall canonical doc\n\nKeep one overall canonical doc that lists the workstreams, their owners, and their canonical docs. It is the entry point; it recurses into each workstream's doc.\n\n- ❌ Ask three people where the plan is and get three answers\n- ✅ One overall canonical doc; it points to every workstream's canonical doc\n\n### 2.6. Hold the nomenclature fixed\n\nExtreme Clarity needs a shared vocabulary. Define the terms once — what a workstream is, what a track is, what each named workstream means — and use them the same way everywhere.\n\n- ❌ \"Stream\" here, \"track\" there, \"area\" elsewhere, all for the same thing\n- ✅ One glossary of terms; every doc uses them identically\n\n---\n\n## 3. Rules\n\n### 3.1. One workstream per initiative\n\nA workstream is one discrete area with one owner and one canonical doc. If it needs two of either, split it.\n\n- ❌ \"`workstream\u002Fplatform-and-product`\"\n- ✅ \"`workstream\u002Fplatform`\" and \"`workstream\u002Fproduct`\"\n\n### 3.2. Exactly one track per unit\n\nEvery unit belongs to one track, and therefore one workstream. Cross-cutting is a link, not a second parent.\n\n- ❌ A unit filed under two tracks\n- ✅ One primary track; related work referenced by link\n\n### 3.3. Every level has a single-threaded owner\n\nOne accountable owner per workstream, and per track when needed. Not zero. Not a committee.\n\n- ❌ \"The team owns it\"\n- ✅ \"cn-sigma owns `workstream\u002Fthreads`\"\n\n### 3.4. Every level has one canonical doc\n\nOne source of truth per level; everywhere else points to it. Canonical Everything recurses down.\n\n- ❌ The plan duplicated across issues that drift\n- ✅ One canonical doc per level; the rest link\n\n### 3.5. No orphan units\n\nA unit with no track has no owner. Triage it to a track or close it.\n\n- ❌ A backlog of unassigned issues\n- ✅ Every open unit carries a track\n\n### 3.6. Workstreams are MECE\n\nMutually exclusive, collectively exhaustive: every unit fits exactly one, none is left over, none spans two.\n\n- ❌ Overlapping workstreams that argue over the same units\n- ✅ A partition — each unit lands in exactly one\n\n### 3.7. Initiative grain, not theme grain\n\nPrefer a dozen real initiatives over a handful of broad themes. A workstream someone can actually own beats a bucket no one can.\n\n- ❌ Three themes: substrate, platform, everything-else\n- ✅ generic-cell, threads, memory, dematerialization, wake-runtime, …\n\n### 3.8. Keep the vocabulary fixed\n\nDefine the terms once and use them identically. Rename deliberately, everywhere at once, never casually.\n\n- ❌ \"stream\" and \"track\" used interchangeably\n- ✅ `workstream ⊃ track`, stated once, held everywhere\n\n---\n\n## 4. Realization\n\nThis doctrine realizes as issue labels and the board, owned by `cnos.issues` — cite, do not fork:\n\n- `workstream\u002F*` and `track\u002F*` labels are defined in [`docs\u002Fdevelopment\u002Fissues\u002FTAXONOMY.md`](..\u002F..\u002F..\u002F..\u002F..\u002F..\u002Fdocs\u002Fdevelopment\u002Fissues\u002FTAXONOMY.md).\n- The overall canonical doc is `docs\u002Fdevelopment\u002Fissues\u002FWORKSTREAMS.md`; each workstream's canonical doc is its **master issue**.\n- `cn issues map` renders `workstream → track → issue` from the labels and registry.\n\nExtend `TAXONOMY.md` first, then let the board consume it. If this doctrine and the taxonomy disagree, change the taxonomy to match, not the reverse.\n\n---\n\n## 5. Final Test\n\nA program is coherent when:\n\n- every unit rolls up to exactly one track and one workstream\n- every workstream and needed track names one owner\n- every level has one canonical doc, and the overall doc reaches them all\n- the workstreams partition the work — MECE, initiative-grained\n- one vocabulary describes it all\n\nIf a unit has no track, triage it. If a level has no owner, assign one. If the truth lives in two places, pick one home and point to it.\n","# Planning Hierarchy\n\n## Core Principle\n\nA body of work is legible when every unit rolls up to one owned workstream, and every level has one canonical source of truth.\n\n`workstream ⊃ track ⊃ unit`. A workstream is a top-level area of work with a single-threaded owner and its own canonical doc. A track is a sub-workstream inside exactly one workstream, also owned. A unit (issue, task) belongs to exactly one track. No orphan work; no diffuse ownership; no scattered truth.\n\nThis adapts Naomi Gleit's practice: workstreams with single-threaded owners, each with its own canonical doc linked from an overall canonical doc, recursively — the discipline she calls Canonical Everything, in service of Extreme Clarity. Source: Naomi Gleit, \"Canonical Everything\" — https:\u002F\u002Fnaomi.com\u002Fcanonical-everything-c85441a84e70; interview context in Lenny's Newsletter — https:\u002F\u002Fwww.lennysnewsletter.com\u002Fp\u002Fmetas-head-of-product-naomi-gleit.\n\n## Algorithm\n\n1. Define — name the workstreams, tracks, units, owners, and canonical docs, and the failure mode.\n2. Unfold — build top-down: workstreams, then tracks, then assign every unit; give each level an owner and a canonical doc.\n3. Rules — one workstream per initiative, one owner per level, one canonical doc per level, no orphan unit.\n\n---\n\n## 1. Define\n\n### 1.1. Identify the parts\n\nA coherent program has these parts:\n\n- **Workstream** — a top-level discrete area of work. Owned. Has its own canonical doc.\n- **Track** — a sub-workstream inside exactly one workstream. Owned.\n- **Unit** — one issue or task, inside exactly one track.\n- **Single-threaded owner** — the one person or agent accountable for a level.\n- **Canonical doc** — the one source of truth for a level.\n- **Nomenclature** — the shared, defined vocabulary the program is described in.\n\n- ❌ \"These issues are roughly about the platform\"\n- ✅ \"`workstream\u002Fplatform`, owned by cn-sigma, canonical doc #452, tracks: wake-runtime, scheduler, trace\"\n\n### 1.2. Articulate how they fit\n\nThe workstream sets the area. Each track answers a sub-area. Each unit does one piece. Each level names one owner and one canonical doc. Reading up from any unit reaches exactly one track, one workstream, one owner, one source of truth.\n\n- ❌ A unit that belongs to two workstreams \"because it touches both\"\n- ✅ A unit in one track; the cross-cutting relationship is a link, not a second parent\n\n### 1.3. Name the governing question\n\nState the program's shape in one sentence:\n\n> This workstream is the discrete area of `\u003CX>`, owned by `\u003Cowner>`, canonical at `\u003Cdoc>`.\n\nIf a workstream needs two owners or two canonical docs, it is two workstreams.\n\n- ❌ \"Substrate-and-platform-and-tooling, owned by the team\"\n- ✅ \"`workstream\u002Fthreads`, owned by cn-sigma, canonical #698\"\n\n### 1.4. Name the canonical doc\n\nThe canonical doc is the one place a level's truth lives; everywhere else points to it.\n\nPer level:\n\n- the overall program has one canonical doc that lists the workstreams\n- each workstream has its own canonical doc, linked from the overall one\n- Canonical Everything recurses: a track large enough to need its own truth gets its own canonical doc, linked from the workstream's\n\n- ❌ The plan restated in three issues that drift apart\n- ✅ One canonical doc per level; the rest link to it\n\n### 1.5. Name the failure mode\n\nPlanning fails through four losses:\n\n- **Orphan work** — a unit belongs to no track, so no one owns it\n- **Diffuse ownership** — a level has zero or many owners, so decisions stall\n- **Scattered truth** — the same plan lives in many places and drifts\n- **Vocabulary drift** — the same word means different things to different people\n\n- ❌ \"Someone will pick it up\"\n- ✅ \"Every unit has a track; every track has an owner\"\n\n---\n\n## 2. Unfold\n\n### 2.1. Name the workstreams (top-down, MECE)\n\nStart at the top. Name the discrete areas of work so they are mutually exclusive and collectively exhaustive — every unit will fit exactly one, and none is left over.\n\nWorkstreams are at **initiative grain**, not theme grain: `generic-cell`, `threads`, `memory` — not one giant `substrate`. Expect roughly a dozen, not three.\n\n- ❌ Five broad buckets that force unrelated work together\n- ✅ ~12 initiatives, each a real area someone can own\n\n### 2.2. Give each workstream one owner and one canonical doc\n\nBefore subdividing, assign the single-threaded owner and the canonical doc. A workstream without an owner is a wish; without a canonical doc it will drift.\n\n- ❌ \"`workstream\u002Fmemory` — we'll sort ownership later\"\n- ✅ \"`workstream\u002Fmemory`, owner cn-sigma, canonical #690\"\n\n### 2.3. Subdivide into tracks\n\nInside each workstream, name the sub-workstreams. A track answers one sub-area of its workstream. Give each track an owner too when the workstream is large enough that one owner cannot hold it all.\n\n- ❌ A workstream with forty loose units and no internal structure\n- ✅ `workstream\u002Fgeneric-cell` → tracks: cell-fsm, cell-classes, planning-cell, claim-dispatch\n\n### 2.4. Assign every unit to exactly one track\n\nWalk the backlog. Each unit gets one track — and therefore one workstream and one owner. A unit that seems to fit two tracks picks its primary; the other relationship is a link.\n\n- ❌ Leave twenty units untriaged \"for now\"\n- ✅ Every unit carries one track; zero orphans\n\n### 2.5. Maintain the overall canonical doc\n\nKeep one overall canonical doc that lists the workstreams, their owners, and their canonical docs. It is the entry point; it recurses into each workstream's doc.\n\n- ❌ Ask three people where the plan is and get three answers\n- ✅ One overall canonical doc; it points to every workstream's canonical doc\n\n### 2.6. Hold the nomenclature fixed\n\nExtreme Clarity needs a shared vocabulary. Define the terms once — what a workstream is, what a track is, what each named workstream means — and use them the same way everywhere.\n\n- ❌ \"Stream\" here, \"track\" there, \"area\" elsewhere, all for the same thing\n- ✅ One glossary of terms; every doc uses them identically\n\n---\n\n## 3. Rules\n\n### 3.1. One workstream per initiative\n\nA workstream is one discrete area with one owner and one canonical doc. If it needs two of either, split it.\n\n- ❌ \"`workstream\u002Fplatform-and-product`\"\n- ✅ \"`workstream\u002Fplatform`\" and \"`workstream\u002Fproduct`\"\n\n### 3.2. Exactly one track per unit\n\nEvery unit belongs to one track, and therefore one workstream. Cross-cutting is a link, not a second parent.\n\n- ❌ A unit filed under two tracks\n- ✅ One primary track; related work referenced by link\n\n### 3.3. Every level has a single-threaded owner\n\nOne accountable owner per workstream, and per track when needed. Not zero. Not a committee.\n\n- ❌ \"The team owns it\"\n- ✅ \"cn-sigma owns `workstream\u002Fthreads`\"\n\n### 3.4. Every level has one canonical doc\n\nOne source of truth per level; everywhere else points to it. Canonical Everything recurses down.\n\n- ❌ The plan duplicated across issues that drift\n- ✅ One canonical doc per level; the rest link\n\n### 3.5. No orphan units\n\nA unit with no track has no owner. Triage it to a track or close it.\n\n- ❌ A backlog of unassigned issues\n- ✅ Every open unit carries a track\n\n### 3.6. Workstreams are MECE\n\nMutually exclusive, collectively exhaustive: every unit fits exactly one, none is left over, none spans two.\n\n- ❌ Overlapping workstreams that argue over the same units\n- ✅ A partition — each unit lands in exactly one\n\n### 3.7. Initiative grain, not theme grain\n\nPrefer a dozen real initiatives over a handful of broad themes. A workstream someone can actually own beats a bucket no one can.\n\n- ❌ Three themes: substrate, platform, everything-else\n- ✅ generic-cell, threads, memory, dematerialization, wake-runtime, …\n\n### 3.8. Keep the vocabulary fixed\n\nDefine the terms once and use them identically. Rename deliberately, everywhere at once, never casually.\n\n- ❌ \"stream\" and \"track\" used interchangeably\n- ✅ `workstream ⊃ track`, stated once, held everywhere\n\n---\n\n## 4. Realization\n\nThis doctrine realizes as issue labels and the board, owned by `cnos.issues` — cite, do not fork:\n\n- `workstream\u002F*` and `track\u002F*` labels are defined in [`docs\u002Fdevelopment\u002Fissues\u002FTAXONOMY.md`](..\u002F..\u002F..\u002F..\u002F..\u002F..\u002Fdocs\u002Fdevelopment\u002Fissues\u002FTAXONOMY.md).\n- The overall canonical doc is `docs\u002Fdevelopment\u002Fissues\u002FWORKSTREAMS.md`; each workstream's canonical doc is its **master issue**.\n- `cn issues map` renders `workstream → track → issue` from the labels and registry.\n\nExtend `TAXONOMY.md` first, then let the board consume it. If this doctrine and the taxonomy disagree, change the taxonomy to match, not the reverse.\n\n---\n\n## 5. Final Test\n\nA program is coherent when:\n\n- every unit rolls up to exactly one track and one workstream\n- every workstream and needed track names one owner\n- every level has one canonical doc, and the overall doc reaches them all\n- the workstreams partition the work — MECE, initiative-grained\n- one vocabulary describes it all\n\nIf a unit has no track, triage it. If a level has no owner, assign one. If the truth lives in two places, pick one home and point to it.\n",{"name":5,"scope":35,"inputs":36,"outputs":39,"triggers":42,"description":7,"kata_surface":48,"artifact_class":49,"governing_question":50},"task-local",[37,38],"a body of work (backlog of issues or tasks)","current ownership and sources of truth",[40,41],"a `workstream ⊃ track ⊃ unit` structure with single-threaded owners","one canonical doc per level",[43,44,45,46,47],"organizing a backlog into initiatives","defining workstreams or tracks","assigning single-threaded ownership","deciding where the source of truth for an initiative lives","a program is hard to reason about at a glance","none","skill","How do we structure a body of work so it reads with extreme clarity — every unit rolling up to an owned workstream through a track, with one canonical source of truth per level?","main","fb527e6c4bfb75c71fa75d6471b3aa3da32106d4","src\u002Fpackages\u002Fcnos.cdp\u002Fskills\u002Fcdp\u002Fplanning-hierarchy",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":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add usurobor\u002Fcnos --skill cdp\u002Fplanning-hierarchy",{"tool":65,"command":66},"bunx","bunx skills add usurobor\u002Fcnos --skill cdp\u002Fplanning-hierarchy",{"tool":68,"command":69},"pnpm","pnpm dlx skills add usurobor\u002Fcnos --skill cdp\u002Fplanning-hierarchy","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.cdp\u002Fskills\u002Fcdp\u002Fplanning-hierarchy\u002FSKILL.md",true,[],[74,90,106,134,151,172],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":30},"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",[],[81,22,82,83,84,24,85,86,28,87,88,89],"triage","issues triage","issue triage","SET","decision","public","dispatch","issue","doctrine",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":30},"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,97,98,99,100,101,84,102,86,103,28,87,104,88,105],"taxonomy","issues taxonomy","github","status","protocol","open","board","github issue","issue labels",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":122,"publishedAt":30},"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",[112,117],{"categoryNo":113,"categoryName":114,"taxonomyType":115,"taxonomyTypeDesc":116},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[22,123,99,124,125,126,84,127,97,102,24,128,129,103,130,131,132,133,28,88],"issues map","reasoning","data","pipeline","api","json","README","edit","interactive","fetch","generated",{"skillNo":135,"name":22,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":30},"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,99,140,141,142,143,144,145,146,97,102,24,85,147,129,148,28,149,87,150],"pr","current state","run","artifacts","state","package","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":30},"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,143,101,160,24,161,162,163,86,164,165,166,167,28,168,169,170,171,89],"receipt stream","handoff","index","learning","format","trace","repo","closeout","read","channel","embedded","patch","shape","cdd",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":178,"publishedAt":30},"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",[],[179,99,180,181,182,183,24,184,185,147,164,166,28,149,87,29,104,186,187,188],"mid flight","change","sessions","file","cache","pin","coordination","Legacy","gamma","artifact channel"]