[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BXTJBP32CYYH0BXYDEFZZ6":3,"skill-same:01M6BXTJBP32CYYH0BXYDEFZZ6":60},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":15,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":28,"linkOnly":29,"markdownContent":30,"markdownBody":31,"frontMatter":32,"refName":33,"commitSha":34,"skillDirectory":35,"forksCount":13,"repositoryHtmlUrl":36,"repositoryHomepageUrl":37,"ownerHtmlUrl":38,"ownerBlogUrl":39,"ownerDescription":40,"updatedAt":41,"install":42,"resources":55},"01M6BXTJBP32CYYH0BXYDEFZZ6","cratis-release-notes",null,"Draft or review developer-facing release notes and migration guidance from verified changes for a specific Cratis product version. Use for GitHub releases, upgrade guides, and release announcements; not for deciding release authority, publishing, or selecting a version label.","Cratis\u002FSpecifications","Cratis","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F16456213?v=4","01M6BXRH290K4C8RS4PTKK3HXQ","01M6BXRH6YXJMJ3140T8TVBSB4",1,"MIT","https:\u002F\u002Fgithub.com\u002FCratis\u002FSpecifications\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Fcratis-release-notes\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FCratis\u002FSpecifications\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Fcratis-release-notes\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27],"notes","release notes","release","cratis","cratis release notes","review","github","product","developer","2026-11-10 10:12:30",false,"---\nname: cratis-release-notes\ndescription: Draft or review developer-facing release notes and migration guidance from verified changes for a specific Cratis product version. Use for GitHub releases, upgrade guides, and release announcements; not for deciding release authority, publishing, or selecting a version label.\nlicense: MIT\n---\n\u003C!-- cratis-ai-managed: skills\u002Fcratis-release-notes\u002FSKILL.md -->\n\n# Release notes for the person upgrading\n\nAn upgrader wants to know whether their application changes, what will break,\nand what to do before installing. A feature list and a list of pull request\ntitles cannot answer that. This skill writes the *communication*, not the\nrelease decision. The repository's release workflow owns version intent,\ngates, publication and recovery; drafting never authorizes publishing or\nediting a release. If the task also includes release planning, select the\nseparate `cratis\u002Fmethodology\u002Fgoverned-releases` profile as needed; that is not\nrequired to draft notes.\n\n## Establish the exact subject\n\nBefore writing, identify product, tag or candidate version, previous version,\nartifact\u002Fpackage names, supported platforms, and the audience. Inventory\nobservable changes from the diff, specs, linked issues\u002FPRs, and authoritative\nproduct source at that revision. A PR description is published verbatim as\nrelease notes in a Cratis repository; follow its current template and the\npull-request contract, and confirm that behavior before drafting. Do not turn\na draft into a claim about shipped behavior.\n\nFor each change, ask: who uses this path, what happened before, what happens\nnow, is action required, and how would they notice? Check changed defaults,\nserialization\u002Fschema\u002Fdata migrations, runtime and dependency compatibility,\ndeploy ordering, deprecations\u002Fremovals, and upgrade\u002Frollback limits. Report\nwhat was not verified to the requester or in a PR comment; the published note\nstates only verified facts and never says 'not verified'.\n\nCratis products move together at their seams: the Chronicle kernel and its\nclients, Arc and Chronicle, Components and Arc. When a change touches a\nseam, state supported pairings as facts the reader can act on ('Requires\nChronicle kernel 19.25 or later'). Which pairings were tested, and against\nwhich branch or commit, is evidence for the PR comment. There is no central\ncompatibility matrix to defer to, so the release note may be the only place\na reader learns the supported pairings. Where a measurement drove the change,\nsuch as how many deployments hit a failure, give the number; never estimate\none to add weight.\n\n## Write for the right channel\n\n- **Exact-version release note (GitHub\u002FPR):** in a Cratis repository this is\n  the merged PR description, published verbatim, so it follows the contract in\n  [pull-requests.md](..\u002F..\u002Frules\u002Fpull-requests.md), which holds the full\n  rules. The ones most often broken: no development write-up (no Overview,\n  Verification or Test plan headings, no review or provenance notes; those go\n  in a PR comment); `(#n)` at the end of the bullet that delivers an issue and\n  `(part of #n)` for anything that stays open (in repositories released by\n  `cratis\u002Frelease-action`, `(#n)` is what closes the issue), never `Closes`, `Fixes` or\n  `Refs` before a number (also in bold or a link), and no issue reference\n  inside an HTML comment (release-action removes comments before publishing,\n  so the issue is silently not closed; a body that is only a comment counts as\n  empty and GitHub generates the notes); and absolute\n  `https:\u002F\u002F` links only. Sections are in\n  a fixed order (Added, Changed, Fixed, Removed, Security, Deprecated); within\n  a section, put changes requiring action first, then new capabilities and\n  fixes. State impact and the user's next action in plain language: state an\n  upgrade action in its `## Changed` or `## Removed` bullet (a first\n  `## Summary` section or an unheaded lead paragraph, not both, may mention it\n  too). Do not list internal\n  refactors or specs that change nothing users observe. For a\n  user-visible fix, a sentence of root cause and of what now guards against a\n  regression, stated as observable behavior rather than a list of specs, is\n  user-facing: it tells the reader whether to trust the fix. Credit an\n  external contributor by name or handle and say what they did, unless they\n  asked not to be named.\n- **Migration guide (durable product docs):** a compact *old behavior → new\n  behavior → required action* table for each affected upgrade path, followed\n  by source-verified before\u002Fafter code or commands. Distinguish required\n  migration from optional cleanup, name sequencing for schema\u002Fdata changes,\n  and explain escape hatches with their cost or expiry. If no action is needed,\n  state why and for whom, rather than implying it for everyone. State the\n  table's scope and its known exclusions, so a reader who does not find their\n  API knows whether it was assessed. Do not infer backward compatibility for\n  APIs or configurations that were not assessed.\n- **Announcement or blog post:** explain the motivation and show a small\n  realistic success, then link to the exact-version note and migration guide.\n  It is not a second independent changelog. Do not claim personal experience\n  on behalf of a named author without their review.\n\nKeep the release note concise enough to scan, but do not compress away the\nboundary that makes a change safe to adopt. One item can follow this shape:\n\n> Applications that run **[workflow]** on **[affected versions]** may observe\n> **[symptom]**. In **[new version]**, **[new behavior]**. **[Action]** before\n> upgrading; **[unaffected path]** does not need to change. [Migration guide].\n\nThat is a checklist for facts, not a template to repeat word-for-word across\nitems. Use descriptive headings, meaningful links, and natural sentence rhythm.\n\n## Repair an already-published release\n\nOnly when asked to fix a release that violates the contract:\n\n1. Read the published body (`gh release view TAG --json body`) and the merged\n   PR. Keep the facts; remove headings, review and verification lines,\n   internal status and closing keywords, and turn relative links into\n   `https:\u002F\u002F` URLs. Do not invent changes, versions or issue numbers.\n2. Publish the corrected text with `gh release edit TAG --notes-file FILE`,\n   only when the request authorizes editing that release.\n   Read back the body with `gh release view TAG --json body` and compare it with the corrected text. If it differs, correct and repeat the authorized edit and readback, or report the blocker rather than claiming the repair succeeded.\n3. In a repository released by `cratis\u002Frelease-action`, editing a release\n   does not re-run release-action, so an issue that a `(#n)` would have\n   closed stays open. For each one, confirm the release\n   actually delivered it. Close it by hand with a comment naming the release\n   only when the request covers closing issues; otherwise list the issues as a\n   proposal. Leave an issue open when the release only partly delivered it.\n\n## Verify before handing over\n\n1. Reconcile every version, affected range, capability and API against the\n   release tag or exact candidate and published artifact when available; verify\n   each reference and link. A blog post or release summary is a pointer to\n   source, not proof that a compatibility issue is resolved.\n2. Have a reader of the affected integration check that the instructions are\n   actionable. Exercise upgrade commands and compile before\u002Fafter examples\n   with stated versions when feasible; use **cratis-technical-examples** for\n   the example workflow.\n3. Recheck the evergreen migration guide after release. Remove 'upcoming',\n   prerelease pins and obsolete workaround language only after verifying the\n   final tag. Separate live guidance from a historically accurate note for an\n   older release. Preserve the owning site's machine-consumed guide format:\n   Cratis's upgrade picker reads `upgrading\u002Fmajor-versions.md` headings such as\n   `### 18 to 19`, linked at-a-glance rows, `**Title** — released YYYY-MM-DD`\n   metadata, and explicit `**You do:**` actions.\n   Check `sync-upgrade-paths.mjs` and an existing guide before changing that\n   structure, then verify the generated picker as well as the page.\n4. Name the checks actually run and the combinations not checked to the\n   requester or in a PR comment, never in the published note. Do not imply\n   that a green docs build proved an upgrade safe.\n\nThe pattern is informed by [Wolverine's migration guide](https:\u002F\u002Fwolverinefx.io\u002Fguide\u002Fmigration.html)\nand [Marten's migration guide](https:\u002F\u002Fmartendb.io\u002Fmigration-guide.html),\nwhich separate concrete upgrade actions from version-specific release notes.\nTheir current wording is not authority for Cratis versions or APIs.\n","\u003C!-- cratis-ai-managed: skills\u002Fcratis-release-notes\u002FSKILL.md -->\n\n# Release notes for the person upgrading\n\nAn upgrader wants to know whether their application changes, what will break,\nand what to do before installing. A feature list and a list of pull request\ntitles cannot answer that. This skill writes the *communication*, not the\nrelease decision. The repository's release workflow owns version intent,\ngates, publication and recovery; drafting never authorizes publishing or\nediting a release. If the task also includes release planning, select the\nseparate `cratis\u002Fmethodology\u002Fgoverned-releases` profile as needed; that is not\nrequired to draft notes.\n\n## Establish the exact subject\n\nBefore writing, identify product, tag or candidate version, previous version,\nartifact\u002Fpackage names, supported platforms, and the audience. Inventory\nobservable changes from the diff, specs, linked issues\u002FPRs, and authoritative\nproduct source at that revision. A PR description is published verbatim as\nrelease notes in a Cratis repository; follow its current template and the\npull-request contract, and confirm that behavior before drafting. Do not turn\na draft into a claim about shipped behavior.\n\nFor each change, ask: who uses this path, what happened before, what happens\nnow, is action required, and how would they notice? Check changed defaults,\nserialization\u002Fschema\u002Fdata migrations, runtime and dependency compatibility,\ndeploy ordering, deprecations\u002Fremovals, and upgrade\u002Frollback limits. Report\nwhat was not verified to the requester or in a PR comment; the published note\nstates only verified facts and never says 'not verified'.\n\nCratis products move together at their seams: the Chronicle kernel and its\nclients, Arc and Chronicle, Components and Arc. When a change touches a\nseam, state supported pairings as facts the reader can act on ('Requires\nChronicle kernel 19.25 or later'). Which pairings were tested, and against\nwhich branch or commit, is evidence for the PR comment. There is no central\ncompatibility matrix to defer to, so the release note may be the only place\na reader learns the supported pairings. Where a measurement drove the change,\nsuch as how many deployments hit a failure, give the number; never estimate\none to add weight.\n\n## Write for the right channel\n\n- **Exact-version release note (GitHub\u002FPR):** in a Cratis repository this is\n  the merged PR description, published verbatim, so it follows the contract in\n  [pull-requests.md](..\u002F..\u002Frules\u002Fpull-requests.md), which holds the full\n  rules. The ones most often broken: no development write-up (no Overview,\n  Verification or Test plan headings, no review or provenance notes; those go\n  in a PR comment); `(#n)` at the end of the bullet that delivers an issue and\n  `(part of #n)` for anything that stays open (in repositories released by\n  `cratis\u002Frelease-action`, `(#n)` is what closes the issue), never `Closes`, `Fixes` or\n  `Refs` before a number (also in bold or a link), and no issue reference\n  inside an HTML comment (release-action removes comments before publishing,\n  so the issue is silently not closed; a body that is only a comment counts as\n  empty and GitHub generates the notes); and absolute\n  `https:\u002F\u002F` links only. Sections are in\n  a fixed order (Added, Changed, Fixed, Removed, Security, Deprecated); within\n  a section, put changes requiring action first, then new capabilities and\n  fixes. State impact and the user's next action in plain language: state an\n  upgrade action in its `## Changed` or `## Removed` bullet (a first\n  `## Summary` section or an unheaded lead paragraph, not both, may mention it\n  too). Do not list internal\n  refactors or specs that change nothing users observe. For a\n  user-visible fix, a sentence of root cause and of what now guards against a\n  regression, stated as observable behavior rather than a list of specs, is\n  user-facing: it tells the reader whether to trust the fix. Credit an\n  external contributor by name or handle and say what they did, unless they\n  asked not to be named.\n- **Migration guide (durable product docs):** a compact *old behavior → new\n  behavior → required action* table for each affected upgrade path, followed\n  by source-verified before\u002Fafter code or commands. Distinguish required\n  migration from optional cleanup, name sequencing for schema\u002Fdata changes,\n  and explain escape hatches with their cost or expiry. If no action is needed,\n  state why and for whom, rather than implying it for everyone. State the\n  table's scope and its known exclusions, so a reader who does not find their\n  API knows whether it was assessed. Do not infer backward compatibility for\n  APIs or configurations that were not assessed.\n- **Announcement or blog post:** explain the motivation and show a small\n  realistic success, then link to the exact-version note and migration guide.\n  It is not a second independent changelog. Do not claim personal experience\n  on behalf of a named author without their review.\n\nKeep the release note concise enough to scan, but do not compress away the\nboundary that makes a change safe to adopt. One item can follow this shape:\n\n> Applications that run **[workflow]** on **[affected versions]** may observe\n> **[symptom]**. In **[new version]**, **[new behavior]**. **[Action]** before\n> upgrading; **[unaffected path]** does not need to change. [Migration guide].\n\nThat is a checklist for facts, not a template to repeat word-for-word across\nitems. Use descriptive headings, meaningful links, and natural sentence rhythm.\n\n## Repair an already-published release\n\nOnly when asked to fix a release that violates the contract:\n\n1. Read the published body (`gh release view TAG --json body`) and the merged\n   PR. Keep the facts; remove headings, review and verification lines,\n   internal status and closing keywords, and turn relative links into\n   `https:\u002F\u002F` URLs. Do not invent changes, versions or issue numbers.\n2. Publish the corrected text with `gh release edit TAG --notes-file FILE`,\n   only when the request authorizes editing that release.\n   Read back the body with `gh release view TAG --json body` and compare it with the corrected text. If it differs, correct and repeat the authorized edit and readback, or report the blocker rather than claiming the repair succeeded.\n3. In a repository released by `cratis\u002Frelease-action`, editing a release\n   does not re-run release-action, so an issue that a `(#n)` would have\n   closed stays open. For each one, confirm the release\n   actually delivered it. Close it by hand with a comment naming the release\n   only when the request covers closing issues; otherwise list the issues as a\n   proposal. Leave an issue open when the release only partly delivered it.\n\n## Verify before handing over\n\n1. Reconcile every version, affected range, capability and API against the\n   release tag or exact candidate and published artifact when available; verify\n   each reference and link. A blog post or release summary is a pointer to\n   source, not proof that a compatibility issue is resolved.\n2. Have a reader of the affected integration check that the instructions are\n   actionable. Exercise upgrade commands and compile before\u002Fafter examples\n   with stated versions when feasible; use **cratis-technical-examples** for\n   the example workflow.\n3. Recheck the evergreen migration guide after release. Remove 'upcoming',\n   prerelease pins and obsolete workaround language only after verifying the\n   final tag. Separate live guidance from a historically accurate note for an\n   older release. Preserve the owning site's machine-consumed guide format:\n   Cratis's upgrade picker reads `upgrading\u002Fmajor-versions.md` headings such as\n   `### 18 to 19`, linked at-a-glance rows, `**Title** — released YYYY-MM-DD`\n   metadata, and explicit `**You do:**` actions.\n   Check `sync-upgrade-paths.mjs` and an existing guide before changing that\n   structure, then verify the generated picker as well as the page.\n4. Name the checks actually run and the combinations not checked to the\n   requester or in a PR comment, never in the published note. Do not imply\n   that a green docs build proved an upgrade safe.\n\nThe pattern is informed by [Wolverine's migration guide](https:\u002F\u002Fwolverinefx.io\u002Fguide\u002Fmigration.html)\nand [Marten's migration guide](https:\u002F\u002Fmartendb.io\u002Fmigration-guide.html),\nwhich separate concrete upgrade actions from version-specific release notes.\nTheir current wording is not authority for Cratis versions or APIs.\n",{"name":5,"license":14,"description":7},"main","c392076c8b3fae3b8b31e7d5684d71f9be75e8bb",".cratis\u002Fai\u002Fskills\u002Fcratis-release-notes","https:\u002F\u002Fgithub.com\u002FCratis\u002FSpecifications","https:\u002F\u002Fwww.cratis.io\u002Fspecifications\u002F","https:\u002F\u002Fgithub.com\u002FCratis","https:\u002F\u002Fwww.cratis.io","Open-source (MIT) event sourcing and CQRS for .NET and beyond: Chronicle, Arc, Components and Screenplay.","2026-11-14 15:53:54",{"source":8,"skillName":5,"commands":43,"prompt":53,"zipAvailable":54},[44,47,50],{"tool":45,"command":46},"npx","npx skills add Cratis\u002FSpecifications --skill cratis-release-notes",{"tool":48,"command":49},"bunx","bunx skills add Cratis\u002FSpecifications --skill cratis-release-notes",{"tool":51,"command":52},"pnpm","pnpm dlx skills add Cratis\u002FSpecifications --skill cratis-release-notes","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FCratis\u002FSpecifications\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Fcratis-release-notes\u002FSKILL.md",true,[56],{"path":57,"resourceType":57,"resourceTypeDesc":58,"sizeBytes":59,"sourceHtmlUrl":15},"LICENSE","许可证",199,[61,87,102,126,147,161],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":65,"sourceHtmlUrl":66,"categories":67,"keywords":78,"publishedAt":28},"01M6BXWPJZ1W4FTAZ7N0B718XQ","vectorization","Designs, implements, optimizes, and reviews SIMD code in .NET: vectorizing scalar loops with TensorPrimitives, Vector64, Vector128, Vector256, Vector512, or hardware intrinsics, and reviewing existing SIMD code, including the generic Vector type, for contract equivalence, tail handling, memory safety, portability, fallbacks, and measured performance. Use when a .NET loop or SIMD routine is being written or reviewed. Not for performance work unrelated to SIMD.","https:\u002F\u002Fgithub.com\u002FCratis\u002FSpecifications\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Fvectorization\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FCratis\u002FSpecifications\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Fvectorization\u002FSKILL.md",[68,73],{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[63,79,80,81,82,83,84,85,86],"loop","Safety","simd","vector","code","performance","memory safety","memory",{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":91,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":28},"01M6BXWKDP8VKEXE9WN5R8R1E0","target-authoring","Canonical patterns for writing custom MSBuild targets: DependsOnTargets versus BeforeTargets and AfterTargets, the Build-to-CoreBuild three-level pattern, and the XxxDependsOn chain-extension pattern. Use when diagnosing or fixing custom-target anti-patterns: Directory.Build.targets redefining SDK targets, targets that replace CompileDependsOn instead of extending it, Outputs versus Returns misuse that returns stale results, missing Inputs\u002FOutputs causing needless rebuilds, or missing FileWrites registration. Not for incremental build tuning or general anti-pattern review (use the msbuild skill), or non-MSBuild build systems.","https:\u002F\u002Fgithub.com\u002FCratis\u002FSpecifications\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Ftarget-authoring\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FCratis\u002FSpecifications\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Ftarget-authoring\u002FSKILL.md",[],[95,96,97,98,99,24,100,101],"target authoring","msbuild","tuning","incremental build","sdk","directory","writing",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":106,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":28},"01M6BXWG0724RVJDEE4SQBEF8P","run-tests","Chooses and runs the repository-compatible .NET test command: classic, VSTest, bridged MTP, or native MTP syntax for MSTest, xUnit, NUnit, and TUnit. Use before running .NET tests or answering with a test command or flags: run the tests, one test, class, category, trait or target framework, combined filters, --filter-query, --no-build, --diag, TRX, coverage collection, crash or hang dumps, filter errors, or unrecognized options. Not for platform identification alone (use platform-detection), writing or debugging test code, interpreting a coverage report (use coverage-analysis), CI investigation, migration, or a persistent hot-reload loop.","https:\u002F\u002Fgithub.com\u002FCratis\u002FSpecifications\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Frun-tests\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FCratis\u002FSpecifications\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Frun-tests\u002FSKILL.md",[],[110,111,112,113,114,115,116,117,83,118,119,120,121,101,122,123,124,79,125],"run tests","run","collection","detection","ci","repository","framework","report","debugging","mtp","mstest","test","analysis","xunit","nunit","investigation",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":130,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":28},"01M6BXWCTS8TECDKSYFJT9C445","profiling","Uses the free official .NET diagnostics CLI tools for profiling and runtime investigation in a repository: CPU, GC pressure, allocation growth, exception storms, lock contention, and slow code. Use when a .NET application needs performance or runtime profiling. Not for replacing realistic performance or load tests with ad-hoc tracing, production heap collection without a pause-risk plan, crash dumps (use dump-collect), or benchmark design (use microbenchmarking).","https:\u002F\u002Fgithub.com\u002FCratis\u002FSpecifications\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Fprofiling\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FCratis\u002FSpecifications\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Fprofiling\u002FSKILL.md",[],[128,112,134,135,125,136,84,137,138,115,139,140,141,83,142,143,144,145,146],"microbenchmarking","plan","Tools","risk","Production","collect","tracing","benchmark","diagnostics","official","first","cli","design",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":151,"sourceHtmlUrl":152,"categories":153,"keywords":155,"publishedAt":28},"01M6BXW9N4G1NTMKNVBECTM2GM","platform-detection","Identifies a .NET project's test platform, framework, command mode, and SDK-style versus classic project system, resolving global.json, project, packages.config, Directory.Build.props, and Directory.Packages.props precedence for MSTest, xUnit, NUnit, and TUnit. Use when asking \"which test platform or framework?\", \"VSTest or MTP?\", or \"what runner does this project use?\", including bridge settings, UseVSTest opt-outs, and conflicting VSTest\u002FMTP configuration. Not for running or filtering tests, commands, flags, TRX, dumps, or test-command errors (use run-tests), or for hot-reload or migration requests.","https:\u002F\u002Fgithub.com\u002FCratis\u002FSpecifications\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Fplatform-detection\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FCratis\u002FSpecifications\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Fplatform-detection\u002FSKILL.md",[154],{"categoryNo":69,"categoryName":70,"taxonomyType":71,"taxonomyTypeDesc":72},[156,113,119,120,121,99,100,157,123,124,158,159,116,111,160],"platform detection","config","json","system","packages",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":165,"sourceHtmlUrl":166,"categories":167,"keywords":171,"publishedAt":28},"01M6BXW4VVFJH0WDPATWMFE9TY","orleans","Designs Microsoft Orleans systems from each primitive's purpose and failure model: grains, digital twins, state versus databases, transactions, messaging, streams, timers, reminders, Durable Jobs, stateless workers, grain services, startup, and hosting. Use when a task needs an Orleans design decision: inspect version and topology, choose the primitive, implement, and validate. Not for other actor stacks, batch processing, relational-only CRUD, or advice without an Orleans decision.","https:\u002F\u002Fgithub.com\u002FCratis\u002FSpecifications\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Forleans\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FCratis\u002FSpecifications\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Forleans\u002FSKILL.md",[168],{"categoryNo":169,"categoryName":170,"taxonomyType":71,"taxonomyTypeDesc":72},"01JBSEEDCAT000000000000010","后端与接口",[163,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,146],"startup","decision","choose","model","crud","transactions","services","topology","messaging","batch","state","reminders","validate","microsoft","implement"]