[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WZJ0SGS82CDMPRRGNS2MAV":3,"skill-same:01M6WZJ0SGS82CDMPRRGNS2MAV":65},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":46,"ownerHtmlUrl":47,"ownerBlogUrl":48,"ownerDescription":49,"updatedAt":50,"install":51,"resources":64},"01M6WZJ0SGS82CDMPRRGNS2MAV","debug",null,"Structured debugging protocol with checkpoints. Load when debugging non-trivial issues — before forming any hypothesis about the cause.","microsoft\u002Fverona","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M6WZHTA01TB3YK5SZM938MTG",3742,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fverona\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fdebug\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[5,24,25,26,27,28,29,30,31,32,33,34,35],"debugging","protocol","issues","hypothesis","structured","false","forming","about","with","checkpoints","load","when","2026-11-10 10:12:30",false,"---\nname: debug\ndescription: Structured debugging protocol with checkpoints. Load when debugging non-trivial issues — before forming any hypothesis about the cause.\ndisable-model-invocation: false\n---\n\n# Debugging Protocol\n\nA structured protocol for debugging non-trivial issues. Each checkpoint requires a visible artifact before proceeding to the next step.\n\n## Overarching principle\n\nDon't assert a cause. State hypotheses explicitly. Prove the execution path with evidence. When evidence contradicts your hypothesis, discard it entirely and form a new one from what the evidence actually shows. Don't shift the same hypothesis upstream — that's defending a theory, not following the evidence.\n\nA hypothesis is not knowledge. If you can test it, test it. This protocol makes that concrete for debugging sessions.\n\n## Verona hard stop: no source-level compiler workarounds\n\nWhen debugging Verona source code, libraries, or examples against `vc` \u002F `vbci`, treat \"this looks like a compiler\u002Fruntime bug\" as a hard stop for workaround-ish repo edits.\n\nBefore editing the source package under investigation, classify each proposed change as one of:\n\n- **Real source bug**: the source is independently wrong with respect to the intended API, language semantics, or external library contract.\n- **Compiler workaround**: the change exists only to dodge compiler\u002Fruntime behavior (for example wrapper methods added only to make lambdas distinct, extra wrapper objects around unions, typed-literal hacks, signature changes added only to appease inference\u002Ftypecheck, or control-flow reshaping that has no source-level justification).\n\nRules:\n\n1. **Do not commit workaround churn into the source tree while debugging.** If a change is in the second category, stop and discuss instead of editing the repo copy.\n2. **Reduce first.** Build a minimal reproduction in `build\u002Ftmp\u002F` that demonstrates the compiler\u002Fruntime bug before touching the real source tree.\n3. **Prove source edits are source fixes.** If you believe a source edit is still warranted, state the independent source-level reason for it and the evidence supporting that reason.\n4. **Scratch before repo.** Hypothesis-testing edits for likely compiler bugs belong in scratch copies under `build\u002Ftmp\u002F`, not in the main worktree.\n5. **If the change list starts to include scaffolding** — wrapper methods, indirection layers, typed match literals, helper closures whose only purpose is to differentiate codegen — back up immediately. That is a sign you are debugging the compiler by mutating the source program.\n\nThis is stricter than the general debugging protocol on purpose: source-level workaround churn is often net negative because it obscures the real bug, dirties the worktree, and increases rollback cost.\n\n## When to use the full protocol\n\nThis protocol is for non-trivial debugging — cases where you don't know the cause, or where your first guess could be wrong. If the cause is immediately obvious and verifiable in one step (a typo, a missing import), just fix it.\n\n## Protocol\n\n### Checkpoint 1: Characterize the failure\n\nWhat's broken? State the expected behavior vs observed behavior. What invariant is violated? Be precise about symptoms — error message, wrong output, crash, hang, intermittent behavior.\n\n**Artifact**: Written failure characterization.\n\n### Checkpoint 2: Gather context\n\nRead the relevant code paths. Understand the execution context, what state is involved, what the entry points are. For intermittent failures, note the reproduction rate and what conditions affect it.\n\n**Artifact**: Summary of relevant code paths and state involved.\n\n### Checkpoint 3: Minimal reproduction\n\nBuild a minimal reproduction — the smallest, simplest case that triggers the failure. Don't just re-run the failing test suite. Strip away everything that isn't necessary to trigger the bug. A minimal reproduction has less surface area, simpler generated code, fewer interacting components, and fewer possible explanations. This makes every subsequent checkpoint easier.\n\nFor intermittent failures, try to increase the rate — stress test in a tight loop, reduce timing margins, run on constrained resources. If reproduction isn't achievable, state why explicitly.\n\n**Artifact**: A minimal reproduction with steps\u002Fcommand and evidence it triggers the failure. If reproduction isn't achievable, an explicit statement of why and what alternative strategy you're using instead.\n\n### Checkpoint 4: Investigation loop\n\nThis is the core of debugging. It's an OODA loop — observe, orient, decide, act — not a linear sequence. You rarely understand the full picture at the start. The goal is to narrow the problem space iteratively until you can explain all symptoms.\n\n**Each iteration:**\n\n1. **Orient**: State a hypothesis about some subset of the problem. It doesn't need to explain everything yet — but be explicit about what it covers and what remains unexplained. \"I think [cause] because [evidence]. This would explain [symptoms A and B] but not [symptom C].\"\n\n2. **Decide**: Design an experiment that would confirm or refute this hypothesis. What would you expect to see if it's right? What would you expect if it's wrong?\n\n3. **Act**: Run the experiment — instrument the code, add logging or assertions, run the reproduction. Report what was observed.\n\n4. **Observe**: What did the evidence show? Did it confirm, refute, or reveal something unexpected? Update your understanding of the problem space.\n\nThen loop. Each iteration should narrow the space — ruling out possibilities, confirming parts of the causal chain, surfacing new information. Keep going until your hypothesis accounts for all observed symptoms.\n\n**Artifact per iteration**: The hypothesis, the experiment, what was observed, and what was learned. Accumulate these — the trail of evidence is how you build toward a complete explanation.\n\n**When evidence refutes a hypothesis**: Form a NEW hypothesis from what the evidence actually shows. Do not shift the old hypothesis — \"maybe it happens earlier\" is the same hypothesis moved upstream. That's defending a theory, not following evidence.\n\n**If stuck after 2-3 iterations without progress**: You are likely anchored to a bad hypothesis. Spawn a fresh-eyes subagent with the original problem, what you've tried, and your current hypothesis. The subagent's job is to verify your assumptions, generate alternative hypotheses, and report back. Act on its findings — don't dismiss them to defend your original theory.\n\n**Exit condition**: You can explain all observed symptoms and have evidence supporting each link in the causal chain. Only then proceed to the fix.\n\n### Checkpoint 5: Fix and verify\n\nFix the root cause, not the symptom. Explain why this addresses the root cause. A sleep, a retry, or a \"just check again\" that masks the problem is not a fix. Run the reproduction to confirm.\n\n**Artifact**: The fix, the rationale for why it addresses the root cause, and evidence it resolves the issue.\n\n## Honest use\n\nThe artifacts should reflect actual investigation, not be written retroactively after you've already decided on a cause. If you find yourself writing the characterization after you've already started coding a fix, you skipped the protocol — back up.\n","# Debugging Protocol\n\nA structured protocol for debugging non-trivial issues. Each checkpoint requires a visible artifact before proceeding to the next step.\n\n## Overarching principle\n\nDon't assert a cause. State hypotheses explicitly. Prove the execution path with evidence. When evidence contradicts your hypothesis, discard it entirely and form a new one from what the evidence actually shows. Don't shift the same hypothesis upstream — that's defending a theory, not following the evidence.\n\nA hypothesis is not knowledge. If you can test it, test it. This protocol makes that concrete for debugging sessions.\n\n## Verona hard stop: no source-level compiler workarounds\n\nWhen debugging Verona source code, libraries, or examples against `vc` \u002F `vbci`, treat \"this looks like a compiler\u002Fruntime bug\" as a hard stop for workaround-ish repo edits.\n\nBefore editing the source package under investigation, classify each proposed change as one of:\n\n- **Real source bug**: the source is independently wrong with respect to the intended API, language semantics, or external library contract.\n- **Compiler workaround**: the change exists only to dodge compiler\u002Fruntime behavior (for example wrapper methods added only to make lambdas distinct, extra wrapper objects around unions, typed-literal hacks, signature changes added only to appease inference\u002Ftypecheck, or control-flow reshaping that has no source-level justification).\n\nRules:\n\n1. **Do not commit workaround churn into the source tree while debugging.** If a change is in the second category, stop and discuss instead of editing the repo copy.\n2. **Reduce first.** Build a minimal reproduction in `build\u002Ftmp\u002F` that demonstrates the compiler\u002Fruntime bug before touching the real source tree.\n3. **Prove source edits are source fixes.** If you believe a source edit is still warranted, state the independent source-level reason for it and the evidence supporting that reason.\n4. **Scratch before repo.** Hypothesis-testing edits for likely compiler bugs belong in scratch copies under `build\u002Ftmp\u002F`, not in the main worktree.\n5. **If the change list starts to include scaffolding** — wrapper methods, indirection layers, typed match literals, helper closures whose only purpose is to differentiate codegen — back up immediately. That is a sign you are debugging the compiler by mutating the source program.\n\nThis is stricter than the general debugging protocol on purpose: source-level workaround churn is often net negative because it obscures the real bug, dirties the worktree, and increases rollback cost.\n\n## When to use the full protocol\n\nThis protocol is for non-trivial debugging — cases where you don't know the cause, or where your first guess could be wrong. If the cause is immediately obvious and verifiable in one step (a typo, a missing import), just fix it.\n\n## Protocol\n\n### Checkpoint 1: Characterize the failure\n\nWhat's broken? State the expected behavior vs observed behavior. What invariant is violated? Be precise about symptoms — error message, wrong output, crash, hang, intermittent behavior.\n\n**Artifact**: Written failure characterization.\n\n### Checkpoint 2: Gather context\n\nRead the relevant code paths. Understand the execution context, what state is involved, what the entry points are. For intermittent failures, note the reproduction rate and what conditions affect it.\n\n**Artifact**: Summary of relevant code paths and state involved.\n\n### Checkpoint 3: Minimal reproduction\n\nBuild a minimal reproduction — the smallest, simplest case that triggers the failure. Don't just re-run the failing test suite. Strip away everything that isn't necessary to trigger the bug. A minimal reproduction has less surface area, simpler generated code, fewer interacting components, and fewer possible explanations. This makes every subsequent checkpoint easier.\n\nFor intermittent failures, try to increase the rate — stress test in a tight loop, reduce timing margins, run on constrained resources. If reproduction isn't achievable, state why explicitly.\n\n**Artifact**: A minimal reproduction with steps\u002Fcommand and evidence it triggers the failure. If reproduction isn't achievable, an explicit statement of why and what alternative strategy you're using instead.\n\n### Checkpoint 4: Investigation loop\n\nThis is the core of debugging. It's an OODA loop — observe, orient, decide, act — not a linear sequence. You rarely understand the full picture at the start. The goal is to narrow the problem space iteratively until you can explain all symptoms.\n\n**Each iteration:**\n\n1. **Orient**: State a hypothesis about some subset of the problem. It doesn't need to explain everything yet — but be explicit about what it covers and what remains unexplained. \"I think [cause] because [evidence]. This would explain [symptoms A and B] but not [symptom C].\"\n\n2. **Decide**: Design an experiment that would confirm or refute this hypothesis. What would you expect to see if it's right? What would you expect if it's wrong?\n\n3. **Act**: Run the experiment — instrument the code, add logging or assertions, run the reproduction. Report what was observed.\n\n4. **Observe**: What did the evidence show? Did it confirm, refute, or reveal something unexpected? Update your understanding of the problem space.\n\nThen loop. Each iteration should narrow the space — ruling out possibilities, confirming parts of the causal chain, surfacing new information. Keep going until your hypothesis accounts for all observed symptoms.\n\n**Artifact per iteration**: The hypothesis, the experiment, what was observed, and what was learned. Accumulate these — the trail of evidence is how you build toward a complete explanation.\n\n**When evidence refutes a hypothesis**: Form a NEW hypothesis from what the evidence actually shows. Do not shift the old hypothesis — \"maybe it happens earlier\" is the same hypothesis moved upstream. That's defending a theory, not following evidence.\n\n**If stuck after 2-3 iterations without progress**: You are likely anchored to a bad hypothesis. Spawn a fresh-eyes subagent with the original problem, what you've tried, and your current hypothesis. The subagent's job is to verify your assumptions, generate alternative hypotheses, and report back. Act on its findings — don't dismiss them to defend your original theory.\n\n**Exit condition**: You can explain all observed symptoms and have evidence supporting each link in the causal chain. Only then proceed to the fix.\n\n### Checkpoint 5: Fix and verify\n\nFix the root cause, not the symptom. Explain why this addresses the root cause. A sleep, a retry, or a \"just check again\" that masks the problem is not a fix. Run the reproduction to confirm.\n\n**Artifact**: The fix, the rationale for why it addresses the root cause, and evidence it resolves the issue.\n\n## Honest use\n\nThe artifacts should reflect actual investigation, not be written retroactively after you've already decided on a cause. If you find yourself writing the characterization after you've already started coding a fix, you skipped the protocol — back up.\n",{"name":5,"description":7,"disable-model-invocation":37},"main","e9256534317bd40707e7e78ba022b8bcd0eb6577",".agents\u002Fskills\u002Fdebug",173,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fverona","https:\u002F\u002Fmicrosoft.github.io\u002Fverona\u002F","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-06 19:53:55",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add microsoft\u002Fverona --skill debug",{"tool":57,"command":58},"bunx","bunx skills add microsoft\u002Fverona --skill debug",{"tool":60,"command":61},"pnpm","pnpm dlx skills add microsoft\u002Fverona --skill debug","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fverona\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fdebug\u002FSKILL.md",true,[],[66,88,107,125,141,162],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":36},"01M6WZM7JFY7GMHE7YTCC4K0ZS","verona-type-inference","Verona compiler type inference model — bidirectional refinement, per-function inference, lambda\u002Fcontext propagation, algebraic and structural typing, generics, and debugging. Use when changing or debugging `vc\u002Fpasses\u002Finfer.cc` or investigating type inference failures.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fverona\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fverona-type-inference\u002FSKILL.md",[],[73,74,75,76,35,77,78,79,80,29,81,82,83,84,85,86,87,24],"verona type inference","type","inference","cc","vc","refinement","typing","infer","propagation","structural","use","context","model","lambda","compiler",{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":36},"01M6WZM48VF2FFX61WFYTD5XVJ","verona-conventions","Verona compiler coding conventions, C++ style, trieste patterns, and project structure. Applies when writing or reviewing Verona compiler code.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fverona\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fverona-conventions\u002FSKILL.md",[],[95,96,97,29,98,99,100,101,102,87,103,104,105,35,106],"verona conventions","conventions","writing","project","c++","structure","patterns","coding","code","project structure","style","coding conventions",{"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":113,"publishedAt":36},"01M6WZM0Z3CTQG1ZRV9V2DZX9W","verona-coding","Patterns, pitfalls, and idioms for writing Verona source code (.v files). Use when writing library code, _builtin types, or user programs.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fverona\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fverona-coding\u002FSKILL.md",[],[114,102,35,115,116,117,118,119,101,120,121,122,83,123,124,103,97],"verona coding","source code","source","for","pitfalls","types","builtin","files","idioms","user","library",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":36},"01M6WZKWW9ZCQ1EXZYR4GZ00YF","vbci-memory","Verona interpreter (vbci) memory management model — regions, reference counting, write barriers, dragging, cowns, and finalization. Use when working on or debugging vbci runtime memory management code.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fverona\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fvbci-memory\u002FSKILL.md",[],[132,133,134,35,135,136,137,138,83,139,140,85,103,24],"vbci memory","memory","runtime","counting","interpreter","memory management","reference","management","write",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":147,"publishedAt":36},"01M6WZKP04VZBWRZ2449FBRDNY","testsuite","Verona compiler test suite infrastructure — running tests, updating golden files, verifying pass completeness, checking error codes. Use when debugging test failures, regenerating golden files, or understanding the test framework.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fverona\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftestsuite\u002FSKILL.md",[],[143,83,35,148,149,150,151,152,153,154,121,155,156,87,157,158,24,159,160,161],"error codes","suite","codes","error","golden","completeness","tests","test suite","running","running tests","framework","infrastructure","test framework","test",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":173,"publishedAt":36},"01M6WZKGQY812K6W0R89Y7HD9T","review","Run a principle-based code review on the current branch. Use when the user asks for a review, or at mandatory review checkpoints (after planning, after implementation before PR).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fverona\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Freview\u002FSKILL.md",[168],{"categoryNo":169,"categoryName":170,"taxonomyType":171,"taxonomyTypeDesc":172},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",[164,174,175,176,177,178,103,35,117,179,123,83,33,180,181],"planning","branch","code review","pr","run","at","implementation","base"]