[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DZ0TFXESR3CVRM2FZ49PDC":3,"skill-same:01M6DZ0TFXESR3CVRM2FZ49PDC":93},{"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":28,"publishedAt":53,"linkOnly":54,"markdownContent":55,"markdownBody":56,"frontMatter":57,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":62,"repositoryHtmlUrl":63,"repositoryHomepageUrl":64,"ownerHtmlUrl":65,"ownerBlogUrl":66,"ownerDescription":67,"updatedAt":68,"install":69,"resources":82},"01M6DZ0TFXESR3CVRM2FZ49PDC","chous",null,"Use Chous in .NET repositories that ship sizeable frontend codebases and want file-structure linting, naming convention enforcement, and folder-layout policy as a CLI gate. USE FOR: growing frontend trees; naming, folder, or file-placement policy; CI checks for frontend layout drift. DO NOT USE FOR: semantic code bugs, type errors, or framework API misuse; CSS, HTML, or JS rule enforcement inside files. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.","managedcode\u002Fdotnet-skills","managedcode","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F78253589?v=4","01M6DYDJR3EG8KB5G4PC65XCTT","Managed Code","01M6DYDJX0ZT432N04NYJW89DN",511,"MIT","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FTools\u002FChous\u002Fskills\u002Fchous\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[5,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52],"context","when","inspect","errors","relevant","linting","layout","commands","structure","drift","files","html","frontend","edit","node","ship","api","ci","repository","framework","code","run","css","cli","2026-11-10 10:12:30",false,"---\nname: chous\ndescription: \"Use Chous in .NET repositories that ship sizeable frontend codebases and want file-structure linting, naming convention enforcement, and folder-layout policy as a CLI gate. USE FOR: growing frontend trees; naming, folder, or file-placement policy; CI checks for frontend layout drift. DO NOT USE FOR: semantic code bugs, type errors, or framework API misuse; CSS, HTML, or JS rule enforcement inside files. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.\"\ncompatibility: \"Requires a repository with a meaningful frontend file tree and Node-based tooling or `npx`; Chous complements code linters and does not replace ESLint, Stylelint, or runtime site audits.\"\n---\n\n# Chous for Frontend File-Structure Linting in .NET Repositories\n\n## Trigger On\n\n- the repo has a growing frontend tree and the user asks about naming conventions, folder structure, or file placement rules\n- the repo wants to enforce layout policy for `ClientApp\u002F`, `src\u002F`, `apps\u002F`, or `packages\u002F`\n- architectural drift in the frontend file tree is a larger problem than syntax errors\n\n## Do Not Use For\n\n- semantic code bugs, type errors, or framework API misuse\n- CSS, HTML, or JS rule enforcement inside files\n- very small repos where a structure linter would add more ceremony than value\n\n## Inputs\n\n- the nearest `AGENTS.md`\n- `package.json`\n- any existing `.chous` file\n- the frontend tree that needs policy enforcement\n\n## Workflow\n\n1. Define the structure problem first:\n   - naming convention drift\n   - component placement\n   - forbidden folders or files\n   - monorepo frontend boundaries\n2. Start from `chous init` or a known preset, then tighten only the rules the repo can explain.\n3. Keep the checked-in `.chous` file readable enough that future contributors understand the policy.\n4. Add repeatable commands such as:\n   - `npx chous`\n5. Exclude generated folders, build artifacts, and vendored assets so the signal stays architectural.\n6. Use Chous as a supplement to semantic linters, not as their replacement.\n7. Re-run after moves or refactors to confirm the structure policy still matches the intended design.\n\n## Bootstrap When Missing\n\n1. Detect current state:\n   - `rg --files -g 'package.json' -g '.chous'`\n   - `rg -n '\"chous\"' --glob 'package.json' .`\n2. Start with the official no-install or global paths:\n   - `npx chous`\n   - `npm install -g chous`\n3. Initialize config when the repo truly wants structure policy:\n   - `npx chous init`\n4. Add a repeatable command to `AGENTS.md` and `package.json`, then verify with:\n   - `npx chous`\n5. Return `status: configured` if the repo now has a checked-in structure-lint baseline, or `status: improved` if an existing baseline was tightened.\n6. Return `status: not_applicable` when the repo is too small or too fluid to justify a structure-lint gate right now.\n\n## Handle Failures\n\n- If Chous flags large parts of the tree after the first rollout, the rule set is probably too strict for the repo's current maturity; start from the preset and tighten incrementally.\n- Generated or vendored folders should be excluded instead of repeatedly ignored in reviews.\n- If contributors cannot explain what a rule protects, simplify the `.chous` policy before enforcing it in CI.\n\n## Deliver\n\n- a checked-in frontend structure policy\n- repeatable file-tree linting commands\n- explicit exclusions for generated and vendored folders\n\n## Validate\n\n- the `.chous` rules reflect real architecture intent\n- generated output is excluded\n- Chous is used alongside, not instead of, semantic linters\n- the policy remains understandable after the first rollout\n\n## Ralph Loop\n\n1. Plan: analyze current state, target outcome, constraints, and risks.\n2. Execute one step and produce a concrete delta.\n3. Review the result and capture findings.\n4. Apply fixes in small batches and rerun checks.\n5. Update the plan after each iteration.\n6. Repeat until outcomes are acceptable.\n7. If a dependency is missing, bootstrap it or return `status: not_applicable` with a reason.\n\n### Required Result Format\n\n- `status`: `complete` | `clean` | `improved` | `configured` | `not_applicable` | `blocked`\n- `plan`: concise plan and current step\n- `actions_taken`: concrete changes made\n- `verification`: commands, checks, or review evidence\n- `remaining`: unresolved items or `none`\n\n## Example Requests\n\n- \"Enforce frontend folder naming and placement rules.\"\n- \"Add file-structure linting to the web client.\"\n- \"Why is our frontend tree drifting even though code linting passes?\"\n","# Chous for Frontend File-Structure Linting in .NET Repositories\n\n## Trigger On\n\n- the repo has a growing frontend tree and the user asks about naming conventions, folder structure, or file placement rules\n- the repo wants to enforce layout policy for `ClientApp\u002F`, `src\u002F`, `apps\u002F`, or `packages\u002F`\n- architectural drift in the frontend file tree is a larger problem than syntax errors\n\n## Do Not Use For\n\n- semantic code bugs, type errors, or framework API misuse\n- CSS, HTML, or JS rule enforcement inside files\n- very small repos where a structure linter would add more ceremony than value\n\n## Inputs\n\n- the nearest `AGENTS.md`\n- `package.json`\n- any existing `.chous` file\n- the frontend tree that needs policy enforcement\n\n## Workflow\n\n1. Define the structure problem first:\n   - naming convention drift\n   - component placement\n   - forbidden folders or files\n   - monorepo frontend boundaries\n2. Start from `chous init` or a known preset, then tighten only the rules the repo can explain.\n3. Keep the checked-in `.chous` file readable enough that future contributors understand the policy.\n4. Add repeatable commands such as:\n   - `npx chous`\n5. Exclude generated folders, build artifacts, and vendored assets so the signal stays architectural.\n6. Use Chous as a supplement to semantic linters, not as their replacement.\n7. Re-run after moves or refactors to confirm the structure policy still matches the intended design.\n\n## Bootstrap When Missing\n\n1. Detect current state:\n   - `rg --files -g 'package.json' -g '.chous'`\n   - `rg -n '\"chous\"' --glob 'package.json' .`\n2. Start with the official no-install or global paths:\n   - `npx chous`\n   - `npm install -g chous`\n3. Initialize config when the repo truly wants structure policy:\n   - `npx chous init`\n4. Add a repeatable command to `AGENTS.md` and `package.json`, then verify with:\n   - `npx chous`\n5. Return `status: configured` if the repo now has a checked-in structure-lint baseline, or `status: improved` if an existing baseline was tightened.\n6. Return `status: not_applicable` when the repo is too small or too fluid to justify a structure-lint gate right now.\n\n## Handle Failures\n\n- If Chous flags large parts of the tree after the first rollout, the rule set is probably too strict for the repo's current maturity; start from the preset and tighten incrementally.\n- Generated or vendored folders should be excluded instead of repeatedly ignored in reviews.\n- If contributors cannot explain what a rule protects, simplify the `.chous` policy before enforcing it in CI.\n\n## Deliver\n\n- a checked-in frontend structure policy\n- repeatable file-tree linting commands\n- explicit exclusions for generated and vendored folders\n\n## Validate\n\n- the `.chous` rules reflect real architecture intent\n- generated output is excluded\n- Chous is used alongside, not instead of, semantic linters\n- the policy remains understandable after the first rollout\n\n## Ralph Loop\n\n1. Plan: analyze current state, target outcome, constraints, and risks.\n2. Execute one step and produce a concrete delta.\n3. Review the result and capture findings.\n4. Apply fixes in small batches and rerun checks.\n5. Update the plan after each iteration.\n6. Repeat until outcomes are acceptable.\n7. If a dependency is missing, bootstrap it or return `status: not_applicable` with a reason.\n\n### Required Result Format\n\n- `status`: `complete` | `clean` | `improved` | `configured` | `not_applicable` | `blocked`\n- `plan`: concise plan and current step\n- `actions_taken`: concrete changes made\n- `verification`: commands, checks, or review evidence\n- `remaining`: unresolved items or `none`\n\n## Example Requests\n\n- \"Enforce frontend folder naming and placement rules.\"\n- \"Add file-structure linting to the web client.\"\n- \"Why is our frontend tree drifting even though code linting passes?\"\n",{"name":5,"description":7,"compatibility":58},"Requires a repository with a meaningful frontend file tree and Node-based tooling or `npx`; Chous complements code linters and does not replace ESLint, Stylelint, or runtime site audits.","main","497cc9aba79a931ac6fb8d36a48cc22fe3d6d74b","catalog\u002FTools\u002FChous\u002Fskills\u002Fchous",41,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills","https:\u002F\u002Fskills.managed-code.com","https:\u002F\u002Fgithub.com\u002Fmanagedcode","https:\u002F\u002Fwww.managed-code.com","Open Source Community for .NET Developers: Reliable, Actively Maintained, and Community-Driven. Made in Ukraine 🇺🇦 with ❤️","2026-11-10 19:58:06",{"source":8,"skillName":5,"commands":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add managedcode\u002Fdotnet-skills --skill chous",{"tool":75,"command":76},"bunx","bunx skills add managedcode\u002Fdotnet-skills --skill chous",{"tool":78,"command":79},"pnpm","pnpm dlx skills add managedcode\u002Fdotnet-skills --skill chous","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FTools\u002FChous\u002Fskills\u002Fchous\u002FSKILL.md",true,[83,89],{"path":84,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":87,"sourceHtmlUrl":88},"index.json","REFERENCE","参考文档",679,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fsoc\u002Fhunting\u002Fntlmrelay\u002Fdetect\u002Findex.json",{"path":90,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":91,"sourceHtmlUrl":92},"manifest.json",118,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FTools\u002FChous\u002Fskills\u002Fchous\u002Fmanifest.json",[94,118,142,172,182,209],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":104,"publishedAt":53},"01M6DYQE1Y9FHAQHEDTVFQ3447","xtwitter-scraper","Use XTwitterScraper when a .NET application needs typed access to Xquik's X automation REST API for tweet search, user lookup, posting workflows, extraction jobs, monitors, webhooks, or giveaway draws. USE FOR: integrating the XTwitterScraper NuGet package; reviewing Xquik API client usage; modeling API-key configuration, pagination, binary exports, raw responses, retries, and webhook\u002Fevent flows in .NET. DO NOT USE FOR: unrelated stacks; direct browser automation; generic social-media strategy; or code that does not call Xquik. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FLibraries\u002FXTwitterScraper\u002Fskills\u002Fxtwitter-scraper\u002FSKILL.md",[100,103],{"categoryNo":101,"categoryName":102,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[105,106,107,50,49,108,109,47,45,110,111,112,42,113,114,39,115,36,116,117],"xtwitter scraper","browser automation","workflows","browser","search","Media","api client","access","unrelated","webhooks","social","modeling","webhook",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":130,"publishedAt":53},"01M6DYQ9S4PE1H6G8MCH9T21HR","sep","Use Sep for high-performance separated-value parsing and writing in .NET, including delimiter inference, explicit parser\u002Fwriter options, and low-allocation row\u002Fcolumn workflows. USE FOR: delimited data needs are performance-sensitive and allocation-aware; project needs explicit control over separator inference, escaping, trimming, and header behavior;. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FLibraries\u002FSep\u002Fskills\u002Fsep\u002FSKILL.md",[124,127],{"categoryNo":125,"categoryName":126,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":128,"categoryName":129,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",[120,131,132,107,133,50,47,134,135,136,42,29,113,39,137,138,139,140,36,141],"writing","performance","tasks","data","parsing","parser","do","writer","options","project","high-performance",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":53},"01M6DZS2DNEPXCGGF6SSCW6G5V","webgpu-threejs-tsl","Comprehensive guide for developing WebGPU-enabled Three.js applications using TSL (Three.js Shading Language). Covers WebGPU renderer setup, TSL syntax and node materials, compute shaders, post-processing effects, and WGSL integration. Use this skill when working with Three.js WebGPU, TSL shaders, node materials, or GPU compute in Three.js.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fwebgpu-claude-skill\u002Fskills\u002Fwebgpu-threejs-tsl\u002FSKILL.md",[],[149,150,151,152,153,154,155,156,157,43,158,159,160,161,162,163,164,165,166,167,168,169,170,171,30],"webgpu","threejs","webgpu threejs tsl","setup","shaders","gpu","integration","applications","js","syntax","guide","use","language","three","compute","post","processing","with","renderer","for","materials","wgsl","effects",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":178,"publishedAt":53},"01M6DZS0BQXW2B56A289XF1X76","roslynk","Use Roslynk for semantic inspection and edits of *.cs, *.razor and *.cshtml solution files.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Froslynk\u002Fskills\u002Froslynk\u002FSKILL.md",[],[174,160,39,179,180,168,181],"semantic","razor","inspection",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":188,"publishedAt":53},"01M6DZRW6MEJCVW80K3S4XV60K","system-text-json-net11","Imperative guidance for the System.Text.Json APIs added in .NET 11: the built-in `JsonNamingPolicy.PascalCase` naming policy, and the strongly-typed generic `JsonSerializerOptions.GetTypeInfo` and `JsonSerializerOptions.TryGetTypeInfo` metadata accessors (generic overloads that return a typed `JsonTypeInfo`). USE ONLY when the user is targeting net11.0 or later and needs PascalCase JSON property or dictionary-key names without writing a custom naming policy, a strongly-typed generic `JsonTypeInfo` instead of the non-generic `JsonTypeInfo`, or a no-throw way to probe whether a type's serialization metadata is resolved. DO NOT USE when the target is earlier than net11.0, the requested behavior uses an established pre-net11 naming policy, or the user explicitly selected another JSON library.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet11\u002Fskills\u002Fsystem-text-json-net11\u002FSKILL.md",[],[189,190,191,192,131,193,194,195,196,197,198,160,199,200,201,202,137,203,204,205,206,168,207,208,30],"system","json","text","system text json net11","policy","metadata","library","serialization","behavior","user","only","probe","guidance","later","type","dictionary","naming","targeting","custom","generic",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":217,"publishedAt":53},"01M6DZRRJP3S662NFSG1RSPQQ7","process-api-net11","Provides guidance on the new System.Diagnostics.Process APIs introduced in .NET 11: Process.Run, Process.RunAndCaptureText, Process.StartAndForget, Process.ReadAllText\u002FBytes\u002FLines, KillOnParentExit, InheritedHandles, and StartDetached. USE FOR: starting, orchestrating, or capturing output from external processes in applications targeting net11.0 or later. DO NOT USE FOR: applications targeting .NET 10 or earlier, or basic pre-.NET 11 Process.Start usage without new APIs.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet11\u002Fskills\u002Fprocess-api-net11\u002FSKILL.md",[215,216],{"categoryNo":101,"categoryName":102,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},[45,218,219,220,50,221,156,189,160,201,202,137,222,223,224,225,206,168,226],"process","process api net11","diagnostics","start","basic","processes","output","usage","new"]