[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DM9GTV13DR5PZCSCXFKFZA":3,"skill-same:01M6DM9GTV13DR5PZCSCXFKFZA":110},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":49,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M6DM9GTV13DR5PZCSCXFKFZA","ub-nuxt",null,"Use this skill for Nuxt framework, runtime, and app-structure work. Apply it when the task involves nuxt.config.*, Nuxt modules, middleware or plugins, runtime config, Nitro or server routes, rendering or deployment mode, data fetching, route structure, app setup, or Nuxt migration.","robert-hoffmann\u002Funcle-bob","robert-hoffmann","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F5472296?v=4","01M6DM8QYHW65WRHBE8H2WC9JK","Robert Hoffmann","01M6DM8R3MX0HR6MQFDZVH98NQ",28,"MIT","https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-nuxt\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"ub nuxt","nuxt","work","app","runtime","structure","route","task","migration","modules","use","config","nuxt modules","nitro","data","server","plugins","framework","deployment","setup","2026-11-10 10:12:30",false,"---\nname: ub-nuxt\ndescription: Use this skill for Nuxt framework, runtime, and app-structure work. Apply it when the task involves nuxt.config.*, Nuxt modules, middleware or plugins, runtime config, Nitro or server routes, rendering or deployment mode, data fetching, route structure, app setup, or Nuxt migration.\n---\n\n# UB Nuxt\n\n## Overview\n\nUse this skill to keep Nuxt work current-version aligned, type-safe, and framework-native. This skill targets the latest stable Nuxt: enforce the `app\u002F`-first source layout, modern Nuxt runtime defaults, and current Vue + TypeScript patterns while rejecting legacy directory guidance.\n\nImplement against the detected project and runtime truth, but bias framework\nguidance toward forward-compatible migration rather than preserving legacy\nlayouts, outdated recipes, or compatibility-layer drift by default.\n\n## Load References On Demand\n\n- Read `..\u002Fub-authoring\u002Freferences\u002Fauthoring-conventions.md` when adjusting routing\n  guidance or cross-skill authoring conventions.\n- Read `references\u002Fnuxt-vue-patterns.md` for architecture, data-fetching, routing, server, and rendering guidance.\n- Read `references\u002Ftypescript-modern.md` for strict TypeScript defaults, typing patterns, and anti-pattern checks.\n- Read `references\u002Fecosystem-preferences.md` for modern package preferences, VueUse-first heuristics, and replacement matrix.\n- Read `references\u002Fnuxt-legacy-to-modern-migration.md` for migration deltas, codemod mapping, and compatibility caveats.\n\n## When Not To Use\n\n- Do not use this skill when the task is framework-agnostic Vue component or\n  composable logic without Nuxt runtime, app-directory, or Nitro concerns;\n  co-load or defer that to `ub-vuejs` depending on whether Vue authoring\n  remains a first-class concern.\n- Do not use this skill when the primary change surface is pure CSS or\n  Tailwind integration rather than Nuxt framework behavior; co-load the\n  relevant styling skill when the task spans both surfaces.\n\n## Core Workflow\n\n1. Detect Nuxt generation and active toolchain from `package.json`, `nuxt.config.*`, lockfiles, and modules. Always inspect `srcDir`, `future.compatibilityVersion`, and `app\u002F` directory presence.\n2. Decide rendering\u002Fruntime mode first (SSR, SSG, hybrid, edge\u002Fserver) before writing code.\n3. Compare official guidance, repo truth, and observed code reality for\n   non-trivial or version-sensitive recommendations.\n4. Surface `OFFICIAL_CONFLICT` when authoritative sources, repo truth, or live\n   code reality materially disagree on a non-trivial recommendation.\n5. Surface `UNVERIFIED` when a non-trivial claim could not be confirmed in\n   official sources after targeted research.\n6. Implement features with Composition API, `\u003Cscript setup lang=\"ts\">`, typed composables, and server\u002Fclient separation.\n7. Prefer VueUse and modern ecosystem defaults from `references\u002Fecosystem-preferences.md`.\n8. Apply modern Nuxt runtime semantics from `references\u002Fnuxt-vue-patterns.md` and migration deltas from `references\u002Fnuxt-legacy-to-modern-migration.md`.\n9. Reject legacy Nuxt\u002FVue patterns and replace them with current equivalents.\n10. Validate types, lint\u002Fbuild output, and framework-specific constraints after edits.\n\n## Nuxt Modern Structure Contract (Hard Requirement)\n\n- Place all app source in `app\u002F`:\n  - `app\u002Fpages`, `app\u002Fcomponents`, `app\u002Flayouts`, `app\u002Fmiddleware`, `app\u002Fplugins`\n  - `app\u002Fapp.vue`, `app\u002Fapp.config.ts`\n- Keep runtime and project roots at repository root:\n  - `server\u002F`, `shared\u002F`, `public\u002F`, `modules\u002F`, `nuxt.config.ts`\n- Respect `srcDir` if explicitly configured, but still apply modern Nuxt structure semantics within that source root.\n- Treat `future.compatibilityVersion` as a required detection signal:\n  - if present and below the current stable version, call out mismatch and provide correction guidance.\n- Do not scaffold or recommend legacy root app directories:\n  - `pages\u002F`, `components\u002F`, `layouts\u002F`, `middleware\u002F`, `plugins\u002F` at repository root.\n\n## Implementation Rules\n\n### Nuxt and Vue\n\n- Use Nuxt-native primitives (`useAsyncData`, `useFetch`, Nitro server routes, plugins, runtime config) instead of custom framework bypasses.\n- Use Composition API and composables for reuse; avoid Options API for new work unless explicitly required.\n- Keep data ownership clear across server routes, server composables, and client composables.\n- Prefer auto-imported Nuxt utilities and composables where they improve consistency.\n- Enforce modern Nuxt directory and runtime defaults when generating or reviewing code; do not emit legacy directory placements.\n\n### TypeScript\n\n- Enable strict TypeScript behavior and avoid `any` in application code.\n- Type runtime config, API responses, composable contracts, and emits\u002Fprops explicitly.\n- Prefer inferred types where stable; add explicit exported\u002Fpublic types at boundaries.\n- Use modern TypeScript features that improve correctness (satisfies, const assertions, template literal types, discriminated unions).\n\n### Ecosystem and Package Selection\n\n- Prefer VueUse before introducing utility packages for reactivity, browser APIs, sensors, lifecycle wrappers, and async helpers.\n- Choose Nuxt ecosystem modules and actively maintained libraries with strong TypeScript support.\n- Keep dependencies minimal; remove redundant packages when Nuxt\u002FVueUse\u002Fstandard platform APIs already solve the need.\n- Defer deep Tailwind guidance to `.agents\u002Fskills\u002Fub-tailwind\u002FSKILL.md`; keep only integration-level Tailwind notes in Nuxt tasks.\n\n## Legacy-Avoidance Guardrails\n\n- Do not scaffold or recommend legacy Nuxt directory conventions that conflict with modern Nuxt defaults.\n- Do not introduce Vue 2-era patterns (`mixins`, filters, class-style component decorators) for new implementation.\n- Do not default to ad-hoc global stores or plugin side effects when composables or typed stores are clearer.\n- Do not use old router\u002Fdata-fetching idioms when Nuxt-native patterns are available.\n- Do not generate app source files in root-level `pages\u002F`, `components\u002F`, `layouts\u002F`, `middleware\u002F`, or `plugins\u002F`.\n\n## Version & Research Policy\n\n- Target the latest stable release of Nuxt.\n- Detect the project's actual Nuxt version from `package.json`, `nuxt.config.*`, and lockfiles.\n- Use web search to verify current best practices, API availability, and migration guidance against official Nuxt documentation.\n- Treat repo truth as the gold implementation standard when deciding what can\n  actually ship safely in the current project.\n- Treat official Nuxt docs as the preferred guidance baseline for\n  forward-looking design and migration-ready patterns.\n- If official guidance and repo truth diverge materially on a non-trivial\n  recommendation, surface `OFFICIAL_CONFLICT`, implement the repo-safe path,\n  and explain the migration path.\n- If official sources disagree with each other on a non-trivial\n  recommendation, also surface `OFFICIAL_CONFLICT` instead of silently\n  collapsing the disagreement.\n- If a non-trivial claim cannot be confirmed in official sources after\n  targeted research, mark it `UNVERIFIED` or avoid presenting it as settled\n  guidance.\n- Keep conflict and uncertainty disclosure scoped to non-trivial,\n  version-sensitive, or contested guidance rather than trivial edits.\n- When the project's installed version is behind latest stable, note the version gap and recommend an upgrade path.\n- Inspect the host repository's `AGENTS.md` or equivalent instructions when\n  present for project-specific version policy and tooling; do not assume it\n  contains this catalog's defaults.\n- Do not hardcode version numbers in generated guidance — keep recommendations evergreen.\n\n## Freshness Review\n\n- Volatility: high\n- Review recommendation: review on touch and during periodic maintenance, targeting a quarterly rhythm when practical.\n- Trigger signals: Nuxt release-cycle changes, updated framework migration guides, runtime defaults shifts, or ecosystem-module guidance changes.\n- Enforcement: advisory only; freshness markers should prioritize review, not block unrelated Nuxt work automatically.\n- Stable core: Nuxt-native primitives, clear server\u002Fclient boundaries, and app-source versus runtime-root separation remain the stable principles even when recipes evolve.\n\n## Output Requirements\n\nWhen generating or reviewing code, always include:\n\n1. A short environment detection note (Nuxt generation, Vue version family, TS strictness state).\n2. A source truth note: detected project version, runtime layout, and any\n   material gap versus latest stable guidance.\n3. A modern Nuxt structure compliance note (`app\u002F` placement, root runtime dirs, `srcDir` handling, `future.compatibilityVersion` status).\n4. The selected rendering\u002Fruntime strategy and why it fits.\n5. The package selection rationale when adding dependencies (especially VueUse vs alternatives).\n6. A concise list of legacy patterns removed or avoided.\n7. Validation actions performed (typecheck\u002Fbuild\u002Ftest\u002Flint as available).\n8. Conflict note when relevant: `OFFICIAL_CONFLICT` or `UNVERIFIED` with a\n   concise explanation and the implementation consequence.\n\n## Completion Checklist\n\n- Nuxt mode and toolchain are identified before edits.\n- Modern Nuxt structure contract is satisfied (`app\u002F` app source; root runtime dirs).\n- Composition-first and Nuxt-native patterns are used throughout.\n- TypeScript boundary types are explicit and `any` is avoided.\n- VueUse-first preference is applied for utility\u002Freactive helpers.\n- Added dependencies are modern, maintained, and justified.\n- Tailwind details are delegated to `ub-tailwind` when needed.\n- Legacy patterns are replaced, not carried forward.\n- Any material official-source conflict or unverified non-trivial guidance is\n  disclosed explicitly when relevant.\n","# UB Nuxt\n\n## Overview\n\nUse this skill to keep Nuxt work current-version aligned, type-safe, and framework-native. This skill targets the latest stable Nuxt: enforce the `app\u002F`-first source layout, modern Nuxt runtime defaults, and current Vue + TypeScript patterns while rejecting legacy directory guidance.\n\nImplement against the detected project and runtime truth, but bias framework\nguidance toward forward-compatible migration rather than preserving legacy\nlayouts, outdated recipes, or compatibility-layer drift by default.\n\n## Load References On Demand\n\n- Read `..\u002Fub-authoring\u002Freferences\u002Fauthoring-conventions.md` when adjusting routing\n  guidance or cross-skill authoring conventions.\n- Read `references\u002Fnuxt-vue-patterns.md` for architecture, data-fetching, routing, server, and rendering guidance.\n- Read `references\u002Ftypescript-modern.md` for strict TypeScript defaults, typing patterns, and anti-pattern checks.\n- Read `references\u002Fecosystem-preferences.md` for modern package preferences, VueUse-first heuristics, and replacement matrix.\n- Read `references\u002Fnuxt-legacy-to-modern-migration.md` for migration deltas, codemod mapping, and compatibility caveats.\n\n## When Not To Use\n\n- Do not use this skill when the task is framework-agnostic Vue component or\n  composable logic without Nuxt runtime, app-directory, or Nitro concerns;\n  co-load or defer that to `ub-vuejs` depending on whether Vue authoring\n  remains a first-class concern.\n- Do not use this skill when the primary change surface is pure CSS or\n  Tailwind integration rather than Nuxt framework behavior; co-load the\n  relevant styling skill when the task spans both surfaces.\n\n## Core Workflow\n\n1. Detect Nuxt generation and active toolchain from `package.json`, `nuxt.config.*`, lockfiles, and modules. Always inspect `srcDir`, `future.compatibilityVersion`, and `app\u002F` directory presence.\n2. Decide rendering\u002Fruntime mode first (SSR, SSG, hybrid, edge\u002Fserver) before writing code.\n3. Compare official guidance, repo truth, and observed code reality for\n   non-trivial or version-sensitive recommendations.\n4. Surface `OFFICIAL_CONFLICT` when authoritative sources, repo truth, or live\n   code reality materially disagree on a non-trivial recommendation.\n5. Surface `UNVERIFIED` when a non-trivial claim could not be confirmed in\n   official sources after targeted research.\n6. Implement features with Composition API, `\u003Cscript setup lang=\"ts\">`, typed composables, and server\u002Fclient separation.\n7. Prefer VueUse and modern ecosystem defaults from `references\u002Fecosystem-preferences.md`.\n8. Apply modern Nuxt runtime semantics from `references\u002Fnuxt-vue-patterns.md` and migration deltas from `references\u002Fnuxt-legacy-to-modern-migration.md`.\n9. Reject legacy Nuxt\u002FVue patterns and replace them with current equivalents.\n10. Validate types, lint\u002Fbuild output, and framework-specific constraints after edits.\n\n## Nuxt Modern Structure Contract (Hard Requirement)\n\n- Place all app source in `app\u002F`:\n  - `app\u002Fpages`, `app\u002Fcomponents`, `app\u002Flayouts`, `app\u002Fmiddleware`, `app\u002Fplugins`\n  - `app\u002Fapp.vue`, `app\u002Fapp.config.ts`\n- Keep runtime and project roots at repository root:\n  - `server\u002F`, `shared\u002F`, `public\u002F`, `modules\u002F`, `nuxt.config.ts`\n- Respect `srcDir` if explicitly configured, but still apply modern Nuxt structure semantics within that source root.\n- Treat `future.compatibilityVersion` as a required detection signal:\n  - if present and below the current stable version, call out mismatch and provide correction guidance.\n- Do not scaffold or recommend legacy root app directories:\n  - `pages\u002F`, `components\u002F`, `layouts\u002F`, `middleware\u002F`, `plugins\u002F` at repository root.\n\n## Implementation Rules\n\n### Nuxt and Vue\n\n- Use Nuxt-native primitives (`useAsyncData`, `useFetch`, Nitro server routes, plugins, runtime config) instead of custom framework bypasses.\n- Use Composition API and composables for reuse; avoid Options API for new work unless explicitly required.\n- Keep data ownership clear across server routes, server composables, and client composables.\n- Prefer auto-imported Nuxt utilities and composables where they improve consistency.\n- Enforce modern Nuxt directory and runtime defaults when generating or reviewing code; do not emit legacy directory placements.\n\n### TypeScript\n\n- Enable strict TypeScript behavior and avoid `any` in application code.\n- Type runtime config, API responses, composable contracts, and emits\u002Fprops explicitly.\n- Prefer inferred types where stable; add explicit exported\u002Fpublic types at boundaries.\n- Use modern TypeScript features that improve correctness (satisfies, const assertions, template literal types, discriminated unions).\n\n### Ecosystem and Package Selection\n\n- Prefer VueUse before introducing utility packages for reactivity, browser APIs, sensors, lifecycle wrappers, and async helpers.\n- Choose Nuxt ecosystem modules and actively maintained libraries with strong TypeScript support.\n- Keep dependencies minimal; remove redundant packages when Nuxt\u002FVueUse\u002Fstandard platform APIs already solve the need.\n- Defer deep Tailwind guidance to `.agents\u002Fskills\u002Fub-tailwind\u002FSKILL.md`; keep only integration-level Tailwind notes in Nuxt tasks.\n\n## Legacy-Avoidance Guardrails\n\n- Do not scaffold or recommend legacy Nuxt directory conventions that conflict with modern Nuxt defaults.\n- Do not introduce Vue 2-era patterns (`mixins`, filters, class-style component decorators) for new implementation.\n- Do not default to ad-hoc global stores or plugin side effects when composables or typed stores are clearer.\n- Do not use old router\u002Fdata-fetching idioms when Nuxt-native patterns are available.\n- Do not generate app source files in root-level `pages\u002F`, `components\u002F`, `layouts\u002F`, `middleware\u002F`, or `plugins\u002F`.\n\n## Version & Research Policy\n\n- Target the latest stable release of Nuxt.\n- Detect the project's actual Nuxt version from `package.json`, `nuxt.config.*`, and lockfiles.\n- Use web search to verify current best practices, API availability, and migration guidance against official Nuxt documentation.\n- Treat repo truth as the gold implementation standard when deciding what can\n  actually ship safely in the current project.\n- Treat official Nuxt docs as the preferred guidance baseline for\n  forward-looking design and migration-ready patterns.\n- If official guidance and repo truth diverge materially on a non-trivial\n  recommendation, surface `OFFICIAL_CONFLICT`, implement the repo-safe path,\n  and explain the migration path.\n- If official sources disagree with each other on a non-trivial\n  recommendation, also surface `OFFICIAL_CONFLICT` instead of silently\n  collapsing the disagreement.\n- If a non-trivial claim cannot be confirmed in official sources after\n  targeted research, mark it `UNVERIFIED` or avoid presenting it as settled\n  guidance.\n- Keep conflict and uncertainty disclosure scoped to non-trivial,\n  version-sensitive, or contested guidance rather than trivial edits.\n- When the project's installed version is behind latest stable, note the version gap and recommend an upgrade path.\n- Inspect the host repository's `AGENTS.md` or equivalent instructions when\n  present for project-specific version policy and tooling; do not assume it\n  contains this catalog's defaults.\n- Do not hardcode version numbers in generated guidance — keep recommendations evergreen.\n\n## Freshness Review\n\n- Volatility: high\n- Review recommendation: review on touch and during periodic maintenance, targeting a quarterly rhythm when practical.\n- Trigger signals: Nuxt release-cycle changes, updated framework migration guides, runtime defaults shifts, or ecosystem-module guidance changes.\n- Enforcement: advisory only; freshness markers should prioritize review, not block unrelated Nuxt work automatically.\n- Stable core: Nuxt-native primitives, clear server\u002Fclient boundaries, and app-source versus runtime-root separation remain the stable principles even when recipes evolve.\n\n## Output Requirements\n\nWhen generating or reviewing code, always include:\n\n1. A short environment detection note (Nuxt generation, Vue version family, TS strictness state).\n2. A source truth note: detected project version, runtime layout, and any\n   material gap versus latest stable guidance.\n3. A modern Nuxt structure compliance note (`app\u002F` placement, root runtime dirs, `srcDir` handling, `future.compatibilityVersion` status).\n4. The selected rendering\u002Fruntime strategy and why it fits.\n5. The package selection rationale when adding dependencies (especially VueUse vs alternatives).\n6. A concise list of legacy patterns removed or avoided.\n7. Validation actions performed (typecheck\u002Fbuild\u002Ftest\u002Flint as available).\n8. Conflict note when relevant: `OFFICIAL_CONFLICT` or `UNVERIFIED` with a\n   concise explanation and the implementation consequence.\n\n## Completion Checklist\n\n- Nuxt mode and toolchain are identified before edits.\n- Modern Nuxt structure contract is satisfied (`app\u002F` app source; root runtime dirs).\n- Composition-first and Nuxt-native patterns are used throughout.\n- TypeScript boundary types are explicit and `any` is avoided.\n- VueUse-first preference is applied for utility\u002Freactive helpers.\n- Added dependencies are modern, maintained, and justified.\n- Tailwind details are delegated to `ub-tailwind` when needed.\n- Legacy patterns are replaced, not carried forward.\n- Any material official-source conflict or unverified non-trivial guidance is\n  disclosed explicitly when relevant.\n",{"name":5,"description":7},"main","3185d182c8d358d17a62485cb20f13024a81e429",".agents\u002Fskills\u002Fub-nuxt",6,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob","https:\u002F\u002Frobert-hoffmann.github.io\u002Funcle-bob\u002F","https:\u002F\u002Fgithub.com\u002Frobert-hoffmann","https:\u002F\u002Fi-technology.net","Tech geek (Psychology, Marketing, Biotech, AI)\r\n\r\n+25 years of experience (Software Engineering, Marketing, B2B\u002FB2C, R&D)","2026-09-23 06:57:44",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add robert-hoffmann\u002Funcle-bob --skill ub-nuxt",{"tool":60,"command":61},"bunx","bunx skills add robert-hoffmann\u002Funcle-bob --skill ub-nuxt",{"tool":63,"command":64},"pnpm","pnpm dlx skills add robert-hoffmann\u002Funcle-bob --skill ub-nuxt","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-nuxt\u002FSKILL.md",true,[68,74,80,84,88,92,98,102,106],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"pyproject.toml","OTHER","其他",266,"https:\u002F\u002Fgithub.com\u002Fcateyephotos\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills.pre-symlink-1776435493\u002Fprototype-react-iterate\u002Fpyproject.toml",{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Fecosystem-preferences.md","REFERENCE","参考文档",2344,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-nuxt\u002Freferences\u002Fecosystem-preferences.md",{"path":81,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fnuxt-legacy-to-modern-migration.md",2726,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-nuxt\u002Freferences\u002Fnuxt-legacy-to-modern-migration.md",{"path":85,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Fnuxt-vue-patterns.md",4838,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-nuxt\u002Freferences\u002Fnuxt-vue-patterns.md",{"path":89,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Ftypescript-modern.md",1866,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-nuxt\u002Freferences\u002Ftypescript-modern.md",{"path":93,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":96,"sourceHtmlUrl":97},"run.sh","SCRIPT","脚本",1206,"https:\u002F\u002Fgithub.com\u002Fcateyephotos\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills.pre-symlink-1776435493\u002Fprototype-react-iterate\u002Frun.sh",{"path":99,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":100,"sourceHtmlUrl":101},"sanity.sh",2706,"https:\u002F\u002Fgithub.com\u002Fcateyephotos\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills.pre-symlink-1776435493\u002Fprototype-react-iterate\u002Fsanity.sh",{"path":103,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":104,"sourceHtmlUrl":105},"scripts\u002Floop.sh",164,"https:\u002F\u002Fgithub.com\u002Fcateyephotos\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills.pre-symlink-1776435493\u002Fprototype-react-iterate\u002Fscripts\u002Floop.sh",{"path":107,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":108,"sourceHtmlUrl":109},"scripts\u002Fsimulate_user.py",410,"https:\u002F\u002Fgithub.com\u002Fcateyephotos\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills.pre-symlink-1776435493\u002Fprototype-react-iterate\u002Fscripts\u002Fsimulate_user.py",[111,126,136,142,147,153],{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":122,"publishedAt":39},"01M6DMC7SMYB87B35SJ9E0TPHQ","beta-skill","Test description for beta-skill","https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002Ftests\u002Fskills\u002Fub-governance\u002Ffixtures\u002Frepo_integrity\u002Fpass\u002F.agents\u002Fskills\u002Fbeta-skill\u002FSKILL.md",[117],{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[123,124,125],"beta skill","beta","test",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":133,"publishedAt":39},"01M6DMC5730XA703CT93CNYRG1","alpha-skill","Test description for alpha-skill","https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002Ftests\u002Fskills\u002Fub-governance\u002Ffixtures\u002Frepo_integrity\u002Fpass\u002F.agents\u002Fskills\u002Falpha-skill\u002FSKILL.md",[132],{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},[134,135,125],"alpha skill","alpha",{"skillNo":137,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":141,"publishedAt":39},"01M6DMC20EVS4GM93CHNQ6DE54","https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002Ftests\u002Fskills\u002Fub-governance\u002Ffixtures\u002Frepo_integrity\u002Ffail-skill-schema\u002F.agents\u002Fskills\u002Fbeta-skill\u002FSKILL.md",[140],{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},[123,124,125],{"skillNo":143,"name":128,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":39},"01M6DMBZBDXQ076Y50Q6Q98V8B","https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002Ftests\u002Fskills\u002Fub-governance\u002Ffixtures\u002Frepo_integrity\u002Ffail-skill-schema\u002F.agents\u002Fskills\u002Falpha-skill\u002FSKILL.md",[],[134,135],{"skillNo":148,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":152,"publishedAt":39},"01M6DMBT9Y0TX70ZWH2M9NR0XN","https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002Ftests\u002Fskills\u002Fub-governance\u002Ffixtures\u002Frepo_integrity\u002Ffail-readme-agent-drift\u002F.agents\u002Fskills\u002Fbeta-skill\u002FSKILL.md",[151],{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},[123,124,125],{"skillNo":154,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":158,"publishedAt":39},"01M6DMBQ4YH9MJ3P9W7CJ148P4","https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002Ftests\u002Fskills\u002Fub-governance\u002Ffixtures\u002Frepo_integrity\u002Ffail-readme-agent-drift\u002F.agents\u002Fskills\u002Falpha-skill\u002FSKILL.md",[157],{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},[135,134,125]]