[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CF5RATE75YQPNW4RNRSQR3":3,"skill-same:01M6CF5RATE75YQPNW4RNRSQR3":67},{"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":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":6,"ownerHtmlUrl":50,"ownerBlogUrl":6,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6CF5RATE75YQPNW4RNRSQR3","inbox",null,"Process one inbound peer message at a time without silent drop, escalation leak, or loop noise.","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\u002Fops\u002Finbox\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31],"review","triage","state","messages","escalation","how","loop","coordination","heartbeat","question","process","embedded","ping","2026-11-10 10:12:30",false,"---\nname: inbox\ndescription: Process one inbound peer message at a time without silent drop, escalation leak, or loop noise.\nartifact_class: skill\nkata_surface: embedded\ngoverning_question: How do we triage and handle one inbound peer message so it gets exactly one verb, one action, and one visible close?\ntriggers:\n  - heartbeat detects new inbox messages\n  - cn agent invoked with state\u002Finput.md present\n  - peer sends review request, question, ping, or coordination message\n  - inbox backlog needs clearing\nscope: task-local\n---\n\n# Inbox\n\n## Core Principle\n\n**One message, one verb, one action, one visible close. The runtime delivers; you decide and act.**\n\nThe inbox skill governs triage. Downstream skills govern the work that triage selects.\n\n## Algorithm\n\n1. Define — identify the message, the triage verbs, the closing artifact, and the failure mode.\n2. Unfold — receive, triage, act, and close the message.\n3. Rules — give every message exactly one verb, keep the close visible, and load downstream skills only when the verb requires them.\n4. Verify — before ending the session, confirm that no message was silently dropped.\n\n---\n\n## 1. Define\n\n### 1.1. Identify the parts\n\nInbox processing has five parts:\n\n- **Message** — the one inbound item delivered by the runtime\n- **Verb** — Delete, Defer, Delegate, or Do\n- **Rationale** — one sentence saying why that verb was chosen\n- **Closing artifact** — the artifact that makes the message visibly handled\n- **Downstream skill** — the skill loaded if the message requires further work\n\n- ❌ Treat the message as \"noted\" without deciding what it is\n- ✅ Name the verb, state the rationale, and leave a visible close\n\n### 1.2. Articulate how they fit\n\nThe runtime delivers one message. You assign one verb. That verb determines one action. That action must leave one visible closing artifact.\n\n- ❌ Read a message, think about it, and move on\n- ✅ Read → choose verb → act → leave a visible close\n\n### 1.3. Name the failure mode\n\nInbox processing fails through:\n\n- **Silent drop** — message read but never closed\n- **Escalation leak** — operator asked to decide something already in the agent's scope\n- **Stale backlog** — messages sit untriaged across sessions\n- **Loop noise** — duplicates or rejected copies are handled as if they were new work\n- **Verb drift** — more than one verb implied, or no verb stated at all\n\n- ❌ \"Interesting message from Pi, noted\"\n- ✅ \"Do — Pi asked where to track feature requests. Answerable now. Responding.\"\n\n---\n\n## 2. Unfold\n\n### 2.1. Receive\n\n#### 2.1.1. Actor model\n\nYour repo is your mailbox. The runtime delivers exactly one message at a time via `state\u002Finput.md`. You process that one message. You do not loop, poll, or pick from the queue yourself.\n\n- ❌ Scan `threads\u002Fmail\u002Finbox\u002F` and choose messages manually\n- ✅ Read `state\u002Finput.md`; if it is absent, there is no inbox work\n\n#### 2.1.2. Input shape\n\n```yaml\n# state\u002Finput.md\n---\nid: alice-review-request\ntype: inbox\nfrom: alice\nsubject: Review request\ndate: 2026-02-06\npath: threads\u002Finbox\u002Falice-review-request.md\n---\n\n\u003Cmessage content>\n```\n\n#### 2.1.3. Pull-only transport\n\nAgents push only to their own repo. Peers fetch from you.\n\n```\nAlice → Bob:\n1. Alice pushes bob\u002Ftopic to cn-alice\n2. Bob runs cn sync\n3. Bob materializes one message to state\u002Finput.md\n4. Bob handles it\n```\n\nThe branch prefix names the recipient. The repo it is pushed to is always the sender's own repo. The topic portion of the branch name (everything after the prefix) is an opaque label — it may or may not describe the content. Do not triage from the branch topic name.\n\nTriage from the frontmatter envelope (`from`, `to`, `subject`, `date`) and the message body. The branch name is for routing only.\n\n- ❌ Push a branch directly to the peer's repo\n- ❌ Infer message intent from the branch topic name (`axiom-says-hi` ≠ “Axiom is involved”)\n- ✅ Push `peer\u002Ftopic` to your own repo and let the peer fetch it\n- ✅ Read the frontmatter `from:` and `to:` fields to identify sender and recipient\n- ✅ Read the message body to determine triage verb\n\nIf your reply is not reaching a peer, first suspect the peer's fetch side, not your push side.\n\n---\n\n### 2.2. Triage\n\n#### 2.2.1. One verb per message\n\nEvery message gets exactly one verb.\n\n| Verb | When | Action |\n|------|------|--------|\n| **Delete** | Noise, spam, duplicate, rejected copy, or overtaken content | Archive. No reply needed. |\n| **Defer** | Actionable, but blocked or lower priority | Record blocker and revisit trigger. |\n| **Delegate** | Someone else's responsibility or outside current authority | Route with enough context to avoid re-triage. |\n| **Do** | Actionable now and inside current scope | Handle now. |\n\n- ❌ \"Noted\"\n- ✅ \"Defer — blocked on external repo permissions; revisit after operator answer\"\n\n#### 2.2.2. State one-sentence rationale\n\nThe rationale is the audit trail.\n\n- ❌ Silently archive a message\n- ✅ \"Delete — duplicate of message already triaged on 2026-04-01\"\n- ✅ \"Do — review request for thread-structure-v2; loading review skill\"\n- ✅ \"Delegate — force-push request belongs to the operator because it is an external destructive action\"\n\n#### 2.2.3. Distinguish coordination from external action\n\nPeer-to-peer CN mail is internal coordination. Replying to a peer does not require operator confirmation. External actions do:\n\n- GitHub issue\u002Fcomment creation\n- posting on human-facing surfaces\n- destructive repo operations outside delegated scope\n- money, credentials, or irreversible actions\n\n- ❌ Ask the operator whether to answer Pi's routine coordination message\n- ✅ Answer Pi directly; escalate only if the reply requires external action\n\n#### 2.2.4. Reject duplicate and loop noise\n\nDuplicate and rejection loops are noise. Triage verb: Delete. If the loop is active, diagnose the transport problem. Do not keep triaging the same content as new work.\n\n- ❌ Process fourteen rejected copies as fourteen messages\n- ✅ \"Delete — 14 rejected copies of the same message; diagnose transport issue\"\n\n---\n\n### 2.3. Act\n\n#### 2.3.1. Do\n\nHandle the message in the same session. Common cases:\n\n| Message type | Action |\n|-------------|--------|\n| Question | Answer directly if you can. Say what is missing if you cannot. |\n| Review request | Load review skill. Perform the review. |\n| Ping \u002F connectivity test | Reply with current status. |\n| Coordination proposal | Evaluate and respond with a position. |\n| Bug or issue | Triage severity and respond or route by scope. |\n\nWrite the reply to `state\u002Foutput.md`. The runtime delivers it.\n\n- ❌ \"I'll look into this later\" when nothing is blocked\n- ✅ Respond in the same session if the verb is Do\n\n#### 2.3.2. Delete\n\nArchive and move on. No reply is needed.\n\n- ❌ Leave dead messages sitting in active inbox state\n- ✅ Archive with a visible rationale in the closing artifact\n\n#### 2.3.3. Defer\n\nRecord:\n\n- the blocker\n- the revisit trigger\n\n- ❌ \"Deferred\"\n- ✅ \"Defer — blocked on PR #47 merge; revisit after next cn sync\"\n\n#### 2.3.4. Delegate\n\nName:\n\n- who should handle it\n- why\n- enough context that they do not need to reconstruct the message from zero\n\n- ❌ \"Forwarding to operator\"\n- ✅ \"Delegate to operator — Pi requests force-push permission on cn-pi, which is an external destructive action\"\n\n---\n\n### 2.4. Close visibly\n\nEvery message must leave one visible closing artifact.\n\nAllowed closing artifacts:\n\n- a reply in `state\u002Foutput.md`\n- a defer note with blocker + revisit trigger\n- a delegate note with recipient + reason\n- an archive note \u002F rationale for delete\n\nThe artifact may be small. It must be visible. Suggested shape:\n\n```\nVerb: Do | Delete | Defer | Delegate\nRationale: ...\nLoaded Skill: review | testing | none\nClosing Artifact: state\u002Foutput.md | defer note | delegate note | archive note\nNext Step: ...\n```\n\n- ❌ Message leaves triage with no visible close\n- ✅ The verb, rationale, and next step are visible in the artifact that closes the message\n\n---\n\n## 3. Rules\n\n3.1. **Every message gets exactly one verb.** No \"noted.\" No \"maybe later.\" No silent ambiguity.\n\n3.2. **Keep the close visible.** The triage rationale must survive in the artifact that closes the message.\n\n3.3. **Act before escalating.** If the agent has enough context to act within scope, act. Do not ask the operator to rubber-stamp ordinary peer coordination.\n\n3.4. **Do not manually simulate transport.** Inbox processing is not message routing. The runtime delivers. You triage and act.\n\n3.5. **Stale still needs a verb.** Age does not exempt a message from closure. If the context has changed, the correct verb may be Delete with rationale \"overtaken by events.\" It still gets a verb.\n\n3.6. **Load the right downstream skill.** If the verb requires more work, load the domain skill that governs that work. Examples:\n\n- review request → review\n- code change → relevant engineering skill\n- release-impacting request → release\n- operator-profile change → configure-agent\n\nInbox owns triage. It does not replace downstream work.\n\n---\n\n## 4. Verify\n\nBefore ending inbox processing:\n\n- [ ] Exactly one verb for the message\n- [ ] One-sentence rationale present\n- [ ] Closing artifact visible\n- [ ] Do completed or replied in the same session\n- [ ] Defer has blocker + revisit trigger\n- [ ] Delegate names recipient + reason\n- [ ] Duplicates \u002F loops treated as noise, not new work\n- [ ] No silent drop\n\n---\n\n## 5. Kata\n\n### 5.1. Kata A — review request\n\n**Scenario:** Pi sends a review request on a docs\u002Fprocess change.\n\n**Task:** Triage the message and complete the correct close.\n\n**Governing skills:** inbox, review\n\n**Inputs:**\n- `state\u002Finput.md` containing a review request\n- linked thread path\n\n**Expected artifacts:**\n- Verb: Do\n- rationale naming why it is actionable now\n- `state\u002Foutput.md` reply or review artifact\n- review skill loaded\n\n**Verification:**\n- one verb only\n- no escalation leak\n- visible close exists\n\n**Common failures:**\n- asking the operator whether to reply\n- deferring without blocker\n- answering casually without loading review\n\n**Reflection:**\n- Did the triage verb match the actual scope?\n- Was the downstream skill loaded soon enough?\n\n### 5.2. Kata B — duplicate rejection loop\n\n**Scenario:** The same rejected message appears repeatedly across heartbeats.\n\n**Task:** Stop treating the duplicates as new work.\n\n**Governing skills:** inbox\n\n**Inputs:**\n- repeated copies of one rejected message\n\n**Expected artifacts:**\n- Verb: Delete\n- rationale naming loop noise\n- one visible closing artifact\n- diagnostic note that transport needs attention\n\n**Verification:**\n- duplicates are not re-triaged individually\n- the rationale identifies the loop\n- the message exits the active inbox path\n\n**Common failures:**\n- processing every copy separately\n- escalating to operator without need\n- leaving duplicates in active state\n\n**Reflection:**\n- Did the close reduce noise?\n- Did the handling make the transport issue more visible?\n\n---\n\n## 6. Runtime loop\n\n```bash\n# cron: every 5 min\ncd cn-\u003Cname> && cn sync && cn agent\n```\n\n`cn sync` fetches from peers and pushes your outbox. `cn agent` materializes one message to `state\u002Finput.md` and invokes the agent. Repeat until the queue is empty.\n","# Inbox\n\n## Core Principle\n\n**One message, one verb, one action, one visible close. The runtime delivers; you decide and act.**\n\nThe inbox skill governs triage. Downstream skills govern the work that triage selects.\n\n## Algorithm\n\n1. Define — identify the message, the triage verbs, the closing artifact, and the failure mode.\n2. Unfold — receive, triage, act, and close the message.\n3. Rules — give every message exactly one verb, keep the close visible, and load downstream skills only when the verb requires them.\n4. Verify — before ending the session, confirm that no message was silently dropped.\n\n---\n\n## 1. Define\n\n### 1.1. Identify the parts\n\nInbox processing has five parts:\n\n- **Message** — the one inbound item delivered by the runtime\n- **Verb** — Delete, Defer, Delegate, or Do\n- **Rationale** — one sentence saying why that verb was chosen\n- **Closing artifact** — the artifact that makes the message visibly handled\n- **Downstream skill** — the skill loaded if the message requires further work\n\n- ❌ Treat the message as \"noted\" without deciding what it is\n- ✅ Name the verb, state the rationale, and leave a visible close\n\n### 1.2. Articulate how they fit\n\nThe runtime delivers one message. You assign one verb. That verb determines one action. That action must leave one visible closing artifact.\n\n- ❌ Read a message, think about it, and move on\n- ✅ Read → choose verb → act → leave a visible close\n\n### 1.3. Name the failure mode\n\nInbox processing fails through:\n\n- **Silent drop** — message read but never closed\n- **Escalation leak** — operator asked to decide something already in the agent's scope\n- **Stale backlog** — messages sit untriaged across sessions\n- **Loop noise** — duplicates or rejected copies are handled as if they were new work\n- **Verb drift** — more than one verb implied, or no verb stated at all\n\n- ❌ \"Interesting message from Pi, noted\"\n- ✅ \"Do — Pi asked where to track feature requests. Answerable now. Responding.\"\n\n---\n\n## 2. Unfold\n\n### 2.1. Receive\n\n#### 2.1.1. Actor model\n\nYour repo is your mailbox. The runtime delivers exactly one message at a time via `state\u002Finput.md`. You process that one message. You do not loop, poll, or pick from the queue yourself.\n\n- ❌ Scan `threads\u002Fmail\u002Finbox\u002F` and choose messages manually\n- ✅ Read `state\u002Finput.md`; if it is absent, there is no inbox work\n\n#### 2.1.2. Input shape\n\n```yaml\n# state\u002Finput.md\n---\nid: alice-review-request\ntype: inbox\nfrom: alice\nsubject: Review request\ndate: 2026-02-06\npath: threads\u002Finbox\u002Falice-review-request.md\n---\n\n\u003Cmessage content>\n```\n\n#### 2.1.3. Pull-only transport\n\nAgents push only to their own repo. Peers fetch from you.\n\n```\nAlice → Bob:\n1. Alice pushes bob\u002Ftopic to cn-alice\n2. Bob runs cn sync\n3. Bob materializes one message to state\u002Finput.md\n4. Bob handles it\n```\n\nThe branch prefix names the recipient. The repo it is pushed to is always the sender's own repo. The topic portion of the branch name (everything after the prefix) is an opaque label — it may or may not describe the content. Do not triage from the branch topic name.\n\nTriage from the frontmatter envelope (`from`, `to`, `subject`, `date`) and the message body. The branch name is for routing only.\n\n- ❌ Push a branch directly to the peer's repo\n- ❌ Infer message intent from the branch topic name (`axiom-says-hi` ≠ “Axiom is involved”)\n- ✅ Push `peer\u002Ftopic` to your own repo and let the peer fetch it\n- ✅ Read the frontmatter `from:` and `to:` fields to identify sender and recipient\n- ✅ Read the message body to determine triage verb\n\nIf your reply is not reaching a peer, first suspect the peer's fetch side, not your push side.\n\n---\n\n### 2.2. Triage\n\n#### 2.2.1. One verb per message\n\nEvery message gets exactly one verb.\n\n| Verb | When | Action |\n|------|------|--------|\n| **Delete** | Noise, spam, duplicate, rejected copy, or overtaken content | Archive. No reply needed. |\n| **Defer** | Actionable, but blocked or lower priority | Record blocker and revisit trigger. |\n| **Delegate** | Someone else's responsibility or outside current authority | Route with enough context to avoid re-triage. |\n| **Do** | Actionable now and inside current scope | Handle now. |\n\n- ❌ \"Noted\"\n- ✅ \"Defer — blocked on external repo permissions; revisit after operator answer\"\n\n#### 2.2.2. State one-sentence rationale\n\nThe rationale is the audit trail.\n\n- ❌ Silently archive a message\n- ✅ \"Delete — duplicate of message already triaged on 2026-04-01\"\n- ✅ \"Do — review request for thread-structure-v2; loading review skill\"\n- ✅ \"Delegate — force-push request belongs to the operator because it is an external destructive action\"\n\n#### 2.2.3. Distinguish coordination from external action\n\nPeer-to-peer CN mail is internal coordination. Replying to a peer does not require operator confirmation. External actions do:\n\n- GitHub issue\u002Fcomment creation\n- posting on human-facing surfaces\n- destructive repo operations outside delegated scope\n- money, credentials, or irreversible actions\n\n- ❌ Ask the operator whether to answer Pi's routine coordination message\n- ✅ Answer Pi directly; escalate only if the reply requires external action\n\n#### 2.2.4. Reject duplicate and loop noise\n\nDuplicate and rejection loops are noise. Triage verb: Delete. If the loop is active, diagnose the transport problem. Do not keep triaging the same content as new work.\n\n- ❌ Process fourteen rejected copies as fourteen messages\n- ✅ \"Delete — 14 rejected copies of the same message; diagnose transport issue\"\n\n---\n\n### 2.3. Act\n\n#### 2.3.1. Do\n\nHandle the message in the same session. Common cases:\n\n| Message type | Action |\n|-------------|--------|\n| Question | Answer directly if you can. Say what is missing if you cannot. |\n| Review request | Load review skill. Perform the review. |\n| Ping \u002F connectivity test | Reply with current status. |\n| Coordination proposal | Evaluate and respond with a position. |\n| Bug or issue | Triage severity and respond or route by scope. |\n\nWrite the reply to `state\u002Foutput.md`. The runtime delivers it.\n\n- ❌ \"I'll look into this later\" when nothing is blocked\n- ✅ Respond in the same session if the verb is Do\n\n#### 2.3.2. Delete\n\nArchive and move on. No reply is needed.\n\n- ❌ Leave dead messages sitting in active inbox state\n- ✅ Archive with a visible rationale in the closing artifact\n\n#### 2.3.3. Defer\n\nRecord:\n\n- the blocker\n- the revisit trigger\n\n- ❌ \"Deferred\"\n- ✅ \"Defer — blocked on PR #47 merge; revisit after next cn sync\"\n\n#### 2.3.4. Delegate\n\nName:\n\n- who should handle it\n- why\n- enough context that they do not need to reconstruct the message from zero\n\n- ❌ \"Forwarding to operator\"\n- ✅ \"Delegate to operator — Pi requests force-push permission on cn-pi, which is an external destructive action\"\n\n---\n\n### 2.4. Close visibly\n\nEvery message must leave one visible closing artifact.\n\nAllowed closing artifacts:\n\n- a reply in `state\u002Foutput.md`\n- a defer note with blocker + revisit trigger\n- a delegate note with recipient + reason\n- an archive note \u002F rationale for delete\n\nThe artifact may be small. It must be visible. Suggested shape:\n\n```\nVerb: Do | Delete | Defer | Delegate\nRationale: ...\nLoaded Skill: review | testing | none\nClosing Artifact: state\u002Foutput.md | defer note | delegate note | archive note\nNext Step: ...\n```\n\n- ❌ Message leaves triage with no visible close\n- ✅ The verb, rationale, and next step are visible in the artifact that closes the message\n\n---\n\n## 3. Rules\n\n3.1. **Every message gets exactly one verb.** No \"noted.\" No \"maybe later.\" No silent ambiguity.\n\n3.2. **Keep the close visible.** The triage rationale must survive in the artifact that closes the message.\n\n3.3. **Act before escalating.** If the agent has enough context to act within scope, act. Do not ask the operator to rubber-stamp ordinary peer coordination.\n\n3.4. **Do not manually simulate transport.** Inbox processing is not message routing. The runtime delivers. You triage and act.\n\n3.5. **Stale still needs a verb.** Age does not exempt a message from closure. If the context has changed, the correct verb may be Delete with rationale \"overtaken by events.\" It still gets a verb.\n\n3.6. **Load the right downstream skill.** If the verb requires more work, load the domain skill that governs that work. Examples:\n\n- review request → review\n- code change → relevant engineering skill\n- release-impacting request → release\n- operator-profile change → configure-agent\n\nInbox owns triage. It does not replace downstream work.\n\n---\n\n## 4. Verify\n\nBefore ending inbox processing:\n\n- [ ] Exactly one verb for the message\n- [ ] One-sentence rationale present\n- [ ] Closing artifact visible\n- [ ] Do completed or replied in the same session\n- [ ] Defer has blocker + revisit trigger\n- [ ] Delegate names recipient + reason\n- [ ] Duplicates \u002F loops treated as noise, not new work\n- [ ] No silent drop\n\n---\n\n## 5. Kata\n\n### 5.1. Kata A — review request\n\n**Scenario:** Pi sends a review request on a docs\u002Fprocess change.\n\n**Task:** Triage the message and complete the correct close.\n\n**Governing skills:** inbox, review\n\n**Inputs:**\n- `state\u002Finput.md` containing a review request\n- linked thread path\n\n**Expected artifacts:**\n- Verb: Do\n- rationale naming why it is actionable now\n- `state\u002Foutput.md` reply or review artifact\n- review skill loaded\n\n**Verification:**\n- one verb only\n- no escalation leak\n- visible close exists\n\n**Common failures:**\n- asking the operator whether to reply\n- deferring without blocker\n- answering casually without loading review\n\n**Reflection:**\n- Did the triage verb match the actual scope?\n- Was the downstream skill loaded soon enough?\n\n### 5.2. Kata B — duplicate rejection loop\n\n**Scenario:** The same rejected message appears repeatedly across heartbeats.\n\n**Task:** Stop treating the duplicates as new work.\n\n**Governing skills:** inbox\n\n**Inputs:**\n- repeated copies of one rejected message\n\n**Expected artifacts:**\n- Verb: Delete\n- rationale naming loop noise\n- one visible closing artifact\n- diagnostic note that transport needs attention\n\n**Verification:**\n- duplicates are not re-triaged individually\n- the rationale identifies the loop\n- the message exits the active inbox path\n\n**Common failures:**\n- processing every copy separately\n- escalating to operator without need\n- leaving duplicates in active state\n\n**Reflection:**\n- Did the close reduce noise?\n- Did the handling make the transport issue more visible?\n\n---\n\n## 6. Runtime loop\n\n```bash\n# cron: every 5 min\ncd cn-\u003Cname> && cn sync && cn agent\n```\n\n`cn sync` fetches from peers and pushes your outbox. `cn agent` materializes one message to `state\u002Finput.md` and invokes the agent. Repeat until the queue is empty.\n",{"name":5,"scope":37,"triggers":38,"description":7,"kata_surface":30,"artifact_class":43,"governing_question":44},"task-local",[39,40,41,42],"heartbeat detects new inbox messages","cn agent invoked with state\u002Finput.md present","peer sends review request, question, ping, or coordination message","inbox backlog needs clearing","skill","How do we triage and handle one inbound peer message so it gets exactly one verb, one action, and one visible close?","main","fb527e6c4bfb75c71fa75d6471b3aa3da32106d4","src\u002Fpackages\u002Fcnos.core\u002Fskills\u002Fops\u002Finbox",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":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add usurobor\u002Fcnos --skill inbox",{"tool":59,"command":60},"bunx","bunx skills add usurobor\u002Fcnos --skill inbox",{"tool":62,"command":63},"pnpm","pnpm dlx skills add usurobor\u002Fcnos --skill inbox","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.core\u002Fskills\u002Fops\u002Finbox\u002FSKILL.md",true,[],[68,85,101,129,145,165],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"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",[],[20,75,76,77,78,24,79,80,81,82,83,84],"issues","issues triage","issue triage","SET","decision","public","use","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":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,92,93,94,95,96,78,97,80,98,81,82,99,83,100],"taxonomy","issues taxonomy","github","status","protocol","open","board","github issue","issue labels",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":117,"publishedAt":32},"01M6CF8KBMZ4D0CDJQ3PF1YVTP","issues\u002Fmap","Issue-board (Issue Pivot) generation domain. Use when reasoning about `cn issues map`'s fetch, taxonomy-parse, effort-computation, and render pipeline, or about the board's JSON\u002FHTML output contract.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002Fskills\u002Fmap\u002FSKILL.md",[107,112],{"categoryNo":108,"categoryName":109,"taxonomyType":110,"taxonomyTypeDesc":111},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":113,"categoryName":114,"taxonomyType":115,"taxonomyTypeDesc":116},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[75,118,94,119,120,121,78,122,92,97,24,123,124,98,125,126,127,128,81,83],"issues map","reasoning","data","pipeline","api","json","README","edit","interactive","fetch","generated",{"skillNo":130,"name":75,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":32},"01M6CF8CZQH7G7B7RZPANQWR4G","cnos.issues package entrypoint. Use when reasoning about issue taxonomy, the Issue Pivot \u002F issue-board (`cn issues map`), the read-only CDS issue-state evaluator (`cn issues fsm evaluate`), or the current command-dispatch disposition of issue tooling.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002FSKILL.md",[],[75,94,135,136,137,138,21,139,140,92,97,24,79,141,124,142,81,143,82,144],"pr","current state","run","artifacts","package","boundary","branch","command","only","cds",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"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",[],[152,153,138,96,154,24,155,156,157,80,158,159,160,161,81,30,162,163,164,84],"receipt stream","handoff","index","learning","format","trace","repo","closeout","read","channel","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":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",[],[172,94,173,174,175,176,24,177,26,141,158,160,81,143,82,178,99,179,180,181],"mid flight","change","sessions","file","cache","pin","up","Legacy","gamma","artifact channel"]