[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M74EWZPW17ATMMYHS7FZ2EP5":3,"skill-same:01M74EWZPW17ATMMYHS7FZ2EP5":53},{"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":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":26,"commitSha":27,"skillDirectory":28,"forksCount":13,"repositoryHtmlUrl":29,"repositoryHomepageUrl":30,"ownerHtmlUrl":31,"ownerBlogUrl":32,"ownerDescription":33,"updatedAt":34,"install":35,"resources":48},"01M74EWZPW17ATMMYHS7FZ2EP5","cratis-technical-examples",null,"Design and verify developer-facing code samples, tutorial projects, and documentation snippets against real Cratis APIs. Use when adding or reviewing a runnable example, multi-client snippet, sample app, command\u002Foutput pair, or migration before\u002Fafter code. Do not invent API shapes or treat rendering as a compilation check.","Cratis\u002FArchitecture","Cratis","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F16456213?v=4","01M6BXRH290K4C8RS4PTKK3HXQ","01M74ET2PT8TQK44HAHJBABW28",0,"MIT","https:\u002F\u002Fgithub.com\u002FCratis\u002FArchitecture\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Fcratis-technical-examples\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FCratis\u002FArchitecture\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Fcratis-technical-examples\u002FSKILL.md",[],[],"2026-11-11 15:11:14",false,"---\nname: cratis-technical-examples\ndescription: Design and verify developer-facing code samples, tutorial projects, and documentation snippets against real Cratis APIs. Use when adding or reviewing a runnable example, multi-client snippet, sample app, command\u002Foutput pair, or migration before\u002Fafter code. Do not invent API shapes or treat rendering as a compilation check.\nlicense: MIT\nmetadata:\n  cratis-hint-paths: \"**\u002FSamples\u002F**\u002F*.{cs,ts,tsx}\"\n---\n\u003C!-- cratis-ai-managed: skills\u002Fcratis-technical-examples\u002FSKILL.md -->\n\n# Technical examples readers can trust\n\nA reader will paste the example before they read its explanation. Make that\nfirst attempt work, and show how to tell. A substantial tutorial should have a\nreal project behind it; a five-line illustration need not become a new sample\nrepository. This skill owns the example workflow, not the owning product's\nlanguage-tab layout or documentation site implementation.\n\n## Choose the right source\n\n- **Short illustration:** use the smallest self-contained block that proves one\n  point. Verify every framework type, import, signature, and option against\n  first-party source at the supported version. State any domain types or setup\n  the excerpt assumes; do not present a partial excerpt as a standalone app.\n- **Multi-step tutorial or long example:** write or find a buildable sample or\n  spec maintained with the product. Extract the displayed snippet from that\n  source when tooling supports it. Otherwise keep a reproducible extraction or\n  snippet-equality check beside the sample and run it with the sample build in\n  CI. Manual comparison alone is a one-time review, not a drift guard; name\n  that limitation when automation is unavailable. Do not copy once and let\n  the page drift. Link each extracted block to its source file so a reader\n  can follow it to the fuller example; that link is navigation, not a\n  verification receipt. The Cratis site adds these links automatically to\n  client-language tabs, so don't add them by hand there.\n- **Multi-language client example:** keep one explanation; use the established\n  client-owned snippet mechanism, compile each client against its own SDK, and\n  offer only implementations that exist. Do not translate a C# call by guess.\n  Use the same domain type names in every tab; if the prose has to explain\n  which name each tab uses, fix the snippets instead. State each backend's id\n  and command-response wire type (for example `Guid` versus `string`) and keep\n  one id type per concept across every page of a series. Shared frontend code\n  that depends on those types must be backend-neutral or tabbed per backend.\n- **Sample application:** one realistic domain, explicit prerequisites and\n  package versions, a documented run command, a reproducible state to start\n  from, and a visible result. Keep it minimal enough for a new reader to finish.\n  Link from the documentation step to the precise sample file, not just the\n  repository root. State how to reset sample state safely, what resources the\n  example creates, and any costs or security shortcuts that make it unsuitable\n  for production. Never use real credentials or personal data.\n\nFor Cratis-specific API traps and source-location guidance, read\n[Writing Correct Code Examples](..\u002F..\u002Frules\u002Fwriting-correct-examples.md).\nA local Chronicle client documentation workflow takes precedence for shared\nlanguage tabs. Never hand-edit a generated proxy or a synchronized docs copy.\n\n## Build the example as a reader would\n\n1. Decide what the example demonstrates and what it deliberately omits. Check\n   the version the page targets, not an arbitrary sibling checkout at HEAD.\n2. Start with a working program, spec, or focused use of the public API. Model\n   the product's intended idioms, not just a way that happens to compile. Name\n   a common non-idiomatic trap where it helps the reader avoid a likely mistake.\n   Check\n   packages, imports, namespaces, required attributes, method receivers and\n   overloads against product source. Invented *domain* names are fine;\n   invented framework APIs are not.\n3. Show enough context to paste and run: required setup, the file or project\n   location, a language-tagged fence, commands in execution order, and expected\n   output or resulting state. Do not hide essential steps behind `\u002F\u002F ...`.\n4. Run the owning build\u002Fspec or snippet extractor and the sample command where\n   feasible. Make the expected result an assertion or inspectable output, not\n   just 'the command exited 0'. A rendered code fence proves syntax highlighting,\n   not compilation or behavior.\n5. Check documentation links, accessibility of diagrams\u002Fimages, and that the\n   extracted block still matches the compiled source. For a sample that uses\n   external services, name their setup and the check that could not run.\n6. Record the source revision and verification scope in the change summary,\n   not as a permanent receipt embedded in the page.\n\n## Version constraints belong in the page; the test log does not\n\nA reader needs the versions that change what they install or write. Published\nprose can say that a feature needs a minimum release (\"This needs Chronicle\n\u003Cversion> or later\"), pin packages and images in the commands a reader runs, and\nname the one release where behavior changed.\n\nKeep the author's verification record out of the page. Exact SDK builds, image\ndigests or commit SHAs recorded for provenance, the date it was run, \"tested\nwith X on Y\", \"also checked against a development server\", counts of passing\nspecifications and a list of which tabs were not run are all a log of what\nthe author did. A reader cannot act on them, they are stale by the next\nrelease, and a page that ends in an audit trail reads as generated, not\nwritten. Put them in the change summary, the pull request comment or\n`.ai-work\u002F`, per the step above.\n\nTest each version sentence: would a reader install or write something\ndifferent because of it? If not, remove it. A real limitation stays, stated as\na fact about the product (\"the Kotlin client has no equivalent yet\"), not as a\nrecord of what was and was not run. A digest in a command the reader runs is\npart of the command, not a note, and stays.\n\n## Know what the owning gate actually checks\n\nLook for a snippet validator before designing another checker. Arc and\nChronicle's .NET repositories use `Documentation\u002Fvalidate-client-snippets.py`\nfor supported **C#** fences in `Documentation\u002Fclient-snippets\u002F**`; Arc's\nvalidator has a `--self-test` that plants a failing snippet. Other client\nrepositories own their own validators and toolchains. Check the validator's\nreported count and exclusions: unsupported markers or legacy snippets are not\nproved compilable just because the run passed. Run the owning validator for\nevery changed client snippet, or name a missing toolchain and rely on its\nrequired CI gate. These checks **do not** compile ordinary Markdown\u002FMDX fences\nelsewhere in product documentation. For those, verify against real source and\na runnable sample\u002Fspec or an explicit snippet comparison; do not claim\ncoverage from a site build or a validator that never scans the page.\n\nA compiling tab is not a working tab. For each backend, confirm that the\nartifact is discovered and registered, that proxy generation emits the file\nand types the page names, and that any runtime behavior the page claims (live\nupdates, constraint rejection) was observed against a real kernel and sink. If\na tab's code compiles but fails at runtime, don't publish it with a workaround\nin the prose after it. Put working code in the tab and reference the tracking\nissue in a code comment.\n\nA simple process beats a large unmaintained examples gallery: give the reader\none small success first, then link to a fuller sample when they need it. Update\nexamples alongside public API changes and incoming reports of copy\u002Fpaste failure.\n\n## Stop conditions\n\nDo not claim a sample is runnable when a dependency, runtime, credential,\nexternal service, supported client, or version needed to reproduce it is\nunknown. Do not silently replace a source-verified example with plausible\nlooking pseudo-code. Identify the missing check or narrow the claim instead.\n","\u003C!-- cratis-ai-managed: skills\u002Fcratis-technical-examples\u002FSKILL.md -->\n\n# Technical examples readers can trust\n\nA reader will paste the example before they read its explanation. Make that\nfirst attempt work, and show how to tell. A substantial tutorial should have a\nreal project behind it; a five-line illustration need not become a new sample\nrepository. This skill owns the example workflow, not the owning product's\nlanguage-tab layout or documentation site implementation.\n\n## Choose the right source\n\n- **Short illustration:** use the smallest self-contained block that proves one\n  point. Verify every framework type, import, signature, and option against\n  first-party source at the supported version. State any domain types or setup\n  the excerpt assumes; do not present a partial excerpt as a standalone app.\n- **Multi-step tutorial or long example:** write or find a buildable sample or\n  spec maintained with the product. Extract the displayed snippet from that\n  source when tooling supports it. Otherwise keep a reproducible extraction or\n  snippet-equality check beside the sample and run it with the sample build in\n  CI. Manual comparison alone is a one-time review, not a drift guard; name\n  that limitation when automation is unavailable. Do not copy once and let\n  the page drift. Link each extracted block to its source file so a reader\n  can follow it to the fuller example; that link is navigation, not a\n  verification receipt. The Cratis site adds these links automatically to\n  client-language tabs, so don't add them by hand there.\n- **Multi-language client example:** keep one explanation; use the established\n  client-owned snippet mechanism, compile each client against its own SDK, and\n  offer only implementations that exist. Do not translate a C# call by guess.\n  Use the same domain type names in every tab; if the prose has to explain\n  which name each tab uses, fix the snippets instead. State each backend's id\n  and command-response wire type (for example `Guid` versus `string`) and keep\n  one id type per concept across every page of a series. Shared frontend code\n  that depends on those types must be backend-neutral or tabbed per backend.\n- **Sample application:** one realistic domain, explicit prerequisites and\n  package versions, a documented run command, a reproducible state to start\n  from, and a visible result. Keep it minimal enough for a new reader to finish.\n  Link from the documentation step to the precise sample file, not just the\n  repository root. State how to reset sample state safely, what resources the\n  example creates, and any costs or security shortcuts that make it unsuitable\n  for production. Never use real credentials or personal data.\n\nFor Cratis-specific API traps and source-location guidance, read\n[Writing Correct Code Examples](..\u002F..\u002Frules\u002Fwriting-correct-examples.md).\nA local Chronicle client documentation workflow takes precedence for shared\nlanguage tabs. Never hand-edit a generated proxy or a synchronized docs copy.\n\n## Build the example as a reader would\n\n1. Decide what the example demonstrates and what it deliberately omits. Check\n   the version the page targets, not an arbitrary sibling checkout at HEAD.\n2. Start with a working program, spec, or focused use of the public API. Model\n   the product's intended idioms, not just a way that happens to compile. Name\n   a common non-idiomatic trap where it helps the reader avoid a likely mistake.\n   Check\n   packages, imports, namespaces, required attributes, method receivers and\n   overloads against product source. Invented *domain* names are fine;\n   invented framework APIs are not.\n3. Show enough context to paste and run: required setup, the file or project\n   location, a language-tagged fence, commands in execution order, and expected\n   output or resulting state. Do not hide essential steps behind `\u002F\u002F ...`.\n4. Run the owning build\u002Fspec or snippet extractor and the sample command where\n   feasible. Make the expected result an assertion or inspectable output, not\n   just 'the command exited 0'. A rendered code fence proves syntax highlighting,\n   not compilation or behavior.\n5. Check documentation links, accessibility of diagrams\u002Fimages, and that the\n   extracted block still matches the compiled source. For a sample that uses\n   external services, name their setup and the check that could not run.\n6. Record the source revision and verification scope in the change summary,\n   not as a permanent receipt embedded in the page.\n\n## Version constraints belong in the page; the test log does not\n\nA reader needs the versions that change what they install or write. Published\nprose can say that a feature needs a minimum release (\"This needs Chronicle\n\u003Cversion> or later\"), pin packages and images in the commands a reader runs, and\nname the one release where behavior changed.\n\nKeep the author's verification record out of the page. Exact SDK builds, image\ndigests or commit SHAs recorded for provenance, the date it was run, \"tested\nwith X on Y\", \"also checked against a development server\", counts of passing\nspecifications and a list of which tabs were not run are all a log of what\nthe author did. A reader cannot act on them, they are stale by the next\nrelease, and a page that ends in an audit trail reads as generated, not\nwritten. Put them in the change summary, the pull request comment or\n`.ai-work\u002F`, per the step above.\n\nTest each version sentence: would a reader install or write something\ndifferent because of it? If not, remove it. A real limitation stays, stated as\na fact about the product (\"the Kotlin client has no equivalent yet\"), not as a\nrecord of what was and was not run. A digest in a command the reader runs is\npart of the command, not a note, and stays.\n\n## Know what the owning gate actually checks\n\nLook for a snippet validator before designing another checker. Arc and\nChronicle's .NET repositories use `Documentation\u002Fvalidate-client-snippets.py`\nfor supported **C#** fences in `Documentation\u002Fclient-snippets\u002F**`; Arc's\nvalidator has a `--self-test` that plants a failing snippet. Other client\nrepositories own their own validators and toolchains. Check the validator's\nreported count and exclusions: unsupported markers or legacy snippets are not\nproved compilable just because the run passed. Run the owning validator for\nevery changed client snippet, or name a missing toolchain and rely on its\nrequired CI gate. These checks **do not** compile ordinary Markdown\u002FMDX fences\nelsewhere in product documentation. For those, verify against real source and\na runnable sample\u002Fspec or an explicit snippet comparison; do not claim\ncoverage from a site build or a validator that never scans the page.\n\nA compiling tab is not a working tab. For each backend, confirm that the\nartifact is discovered and registered, that proxy generation emits the file\nand types the page names, and that any runtime behavior the page claims (live\nupdates, constraint rejection) was observed against a real kernel and sink. If\na tab's code compiles but fails at runtime, don't publish it with a workaround\nin the prose after it. Put working code in the tab and reference the tracking\nissue in a code comment.\n\nA simple process beats a large unmaintained examples gallery: give the reader\none small success first, then link to a fuller sample when they need it. Update\nexamples alongside public API changes and incoming reports of copy\u002Fpaste failure.\n\n## Stop conditions\n\nDo not claim a sample is runnable when a dependency, runtime, credential,\nexternal service, supported client, or version needed to reproduce it is\nunknown. Do not silently replace a source-verified example with plausible\nlooking pseudo-code. Identify the missing check or narrow the claim instead.\n",{"name":5,"license":14,"metadata":24,"description":7},{"cratis-hint-paths":25},"**\u002FSamples\u002F**\u002F*.{cs,ts,tsx}","main","68f67ef8a166617b7a614aae2545f77d3c7d5ab8",".cratis\u002Fai\u002Fskills\u002Fcratis-technical-examples","https:\u002F\u002Fgithub.com\u002FCratis\u002FArchitecture","https:\u002F\u002Fwww.cratis.io\u002Farchitecture\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 06:37:25",{"source":8,"skillName":5,"commands":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add Cratis\u002FArchitecture --skill cratis-technical-examples",{"tool":41,"command":42},"bunx","bunx skills add Cratis\u002FArchitecture --skill cratis-technical-examples",{"tool":44,"command":45},"pnpm","pnpm dlx skills add Cratis\u002FArchitecture --skill cratis-technical-examples","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FCratis\u002FArchitecture\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Fcratis-technical-examples\u002FSKILL.md",true,[49],{"path":50,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":52,"sourceHtmlUrl":15},"LICENSE","许可证",204,[54,62,70,78,86,94],{"skillNo":55,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":58,"sourceHtmlUrl":59,"categories":60,"keywords":61,"publishedAt":19},"01M74EZHX4AJ09G25KF026Q7P5","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\u002FArchitecture\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Fvectorization\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FCratis\u002FArchitecture\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Fvectorization\u002FSKILL.md",[],[],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":66,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":19},"01M74EZD5Y0JQAJATM11TTSZRA","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\u002FArchitecture\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Ftarget-authoring\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FCratis\u002FArchitecture\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Ftarget-authoring\u002FSKILL.md",[],[],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":74,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":19},"01M74EZ8ZSW7M8ZR2WBDED4YNA","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\u002FArchitecture\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Frun-tests\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FCratis\u002FArchitecture\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Frun-tests\u002FSKILL.md",[],[],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":82,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":19},"01M74EZ4Q0W4B632KY77V6K5EP","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\u002FArchitecture\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Fprofiling\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FCratis\u002FArchitecture\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Fprofiling\u002FSKILL.md",[],[],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":90,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":19},"01M74EZ08N8PGKKZY6Z1DRR5YS","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\u002FArchitecture\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Fplatform-detection\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FCratis\u002FArchitecture\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Fplatform-detection\u002FSKILL.md",[],[],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":98,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":19},"01M74EYW35N2Y22QQXANX9TQ1V","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\u002FArchitecture\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Forleans\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FCratis\u002FArchitecture\u002Fblob\u002Fmain\u002F.cratis\u002Fai\u002Fskills\u002Forleans\u002FSKILL.md",[],[]]