[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DMAKPXXWR95BBGDPAQNQB9":3,"skill-same:01M6DMAKPXXWR95BBGDPAQNQB9":121},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":52,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M6DMAKPXXWR95BBGDPAQNQB9","ub-ts",null,"Use this skill for TypeScript typing and compiler configuration in Node, bundler, library, Vue, Nuxt, and other TypeScript projects. Apply it when the task involves tsconfig, module or moduleResolution behavior, compiler flags, emitted types, type errors, project-wide TS modernization, or boundary typing.","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-ts\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"ub ts","behavior","type","module","project","task","flags","configuration","use","typescript","node","nuxt","projects","boundary","vue","library","compiler","modernization","2026-11-10 10:12:30",false,"---\nname: ub-ts\ndescription: Use this skill for TypeScript typing and compiler configuration in Node, bundler, library, Vue, Nuxt, and other TypeScript projects. Apply it when the task involves tsconfig, module or moduleResolution behavior, compiler flags, emitted types, type errors, project-wide TS modernization, or boundary typing.\n---\n\n# UB TS\n\n## Overview\n\nUse this skill to enforce latest stable TypeScript modern defaults and patterns across app and library codebases. Generate modern-only output for new code, and allow legacy retention only as a bounded migration exception.\n\nImplement against the detected project TypeScript and runtime truth, but bias\ndesign toward forward-compatible migration rather than compatibility layers or\nlegacy fallbacks.\n\n## Bundled Assets\n\nThis skill ships reusable `tsconfig` starter scaffolding and an optional ESLint\nflat-config starter under `assets\u002F`, plus a deterministic helper under\n`scripts\u002F`.\n\nUse them when a repository wants this house-style starting point and does not\nyet have active TypeScript config of its own.\n\n## Load References On Demand\n\n- Read `references\u002Fts-modern-patterns.md` for archetype selection, tsconfig baselines, and modern typing patterns.\n- Read `references\u002Fts-legacy-to-modern-migration.md` for old-to-new migrations, banned patterns, and exception handling.\n- Read `references\u002Fts-config-resolution.md` when local TypeScript config\n  discovery, starter scaffolding, or optional ESLint support matters.\n- Read `references\u002Ftask-bundle.md` only when the target repository wants an\n  optional Task-based automation overlay for this skill's starter profile.\n- Use `scripts\u002Fscaffold_ts_baseline.py` with `assets\u002Ftsconfig-template\u002F` and\n  `assets\u002Feslint-template\u002F` when a target repository needs a deterministic\n  starter instead of ad hoc config creation.\n\n## Skill Coordination\n\n- Co-load this skill with `ub-vuejs` or `ub-nuxt` when TypeScript issues live\n  inside framework projects.\n- Defer framework runtime, routing, and app-structure decisions to the sibling\n  skill that owns them.\n\n## Core Workflow\n\n1. Detect the project archetype from `package.json`, lockfiles, runtime targets, build tooling, and existing `tsconfig*.json` files.\n2. Choose module strategy that matches runtime truth:\n   - Node runtime: `module` as `node20` or `nodenext`\n   - Bundler runtime: `moduleResolution` as `bundler` with `module` as `esnext`\n   - Library publishing: prefer Node-faithful resolution for compatibility checks\n   - Type-stripping runtime: enforce erasable TypeScript subset\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. Apply strict safety baseline and module hygiene defaults from `references\u002Fts-modern-patterns.md`.\n7. Implement modern type patterns first (`satisfies`, `const` type parameters, `NoInfer`, discriminated unions, explicit boundary typing).\n8. Reject legacy output for new code and apply migration mapping from `references\u002Fts-legacy-to-modern-migration.md` when touching existing code.\n9. Validate with available typecheck, lint, tests, and build commands in the target project.\n10. If a repository wants this baseline but lacks TypeScript config, scaffold\n    the bundled starter and explain the remaining repo-local adaptations.\n\n## Version & Research Policy\n\n- Target the latest stable release of TypeScript.\n- Detect the project's actual TypeScript version from `package.json` and lockfiles.\n- Use web search to verify current best practices, API availability, and migration guidance against official TypeScript 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 TypeScript 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 recommendation,\n  also surface `OFFICIAL_CONFLICT` instead of silently collapsing the\n  disagreement.\n- If a non-trivial claim cannot be confirmed in official sources after targeted\n  research, mark it `UNVERIFIED` or avoid presenting it as settled guidance.\n- Keep conflict and uncertainty disclosure scoped to non-trivial,\n  version-sensitive, or contested guidance rather than trivial edits.\n- Do not emit beta-only syntax unless the user explicitly requests it.\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: TypeScript release changes, compiler-flag behavior shifts, new module-resolution guidance, or runtime-platform updates that affect tsconfig strategy.\n- Enforcement: advisory only; freshness should inform review priority, not become a blocking requirement by itself.\n- Stable core: runtime-faithful module strategy, strict typing, and explicit boundary modeling remain the durable guidance even when compiler defaults evolve.\n\n## Implementation Rules\n\n### Project Archetype and Modules\n\n- Decide archetype before changing compiler options.\n- Keep module settings runtime-faithful, not preference-driven.\n- Keep `moduleDetection` as `force` unless a known compatibility constraint requires otherwise.\n\n### Import and Export Hygiene\n\n- Keep `verbatimModuleSyntax` enabled.\n- Use `import type` and `export type` for type-only symbols.\n- Keep side-effect imports explicit and resolvable.\n\n### Type System Patterns\n\n- Prefer `satisfies` to validate shapes without widening literals.\n- Prefer `const` type parameters in reusable APIs that benefit from literal preservation.\n- Use built-in `NoInfer` when inference must be constrained.\n- Model state with discriminated unions when behavior depends on variants.\n- Use `unknown` at trust boundaries, then narrow with validation.\n\n### Compiler Baseline\n\n- Keep `strict: true`.\n- Keep `noUncheckedIndexedAccess: true`.\n- Keep `exactOptionalPropertyTypes: true`.\n- Enable `isolatedModules` in toolchain-mixed repos.\n- Enable `isolatedDeclarations` for declaration-heavy library workflows.\n- Use `noUncheckedSideEffectImports` when side-effect imports are present.\n\n## Config Resolution And Scaffolding\n\nTreat real project config as the source of truth:\n\n1. inspect `tsconfig*.json`, `eslint.config.*`, `package.json`, and lockfiles\n   first when they exist\n2. match local runtime, bundler, and package-manager truth before choosing a\n   starter\n3. use the bundled `tsconfig` scaffold only when the repository lacks active\n   config and wants this house-style baseline\n4. treat the ESLint starter as optional strong-default support for TS repos,\n   not as universal TypeScript policy\n5. do not silently install dependencies or mutate CI as part of scaffolding\n\n### Tradeoff Handling\n\n- Use the shared `ub-quality` decision-analysis baseline for major TypeScript\n  decisions.\n- State TypeScript-specific pros and cons for each option, especially around\n  correctness, compatibility, DX, and migration cost.\n- Default to the safest modern option unless user constraints indicate otherwise.\n\n## Legacy-Avoidance Guardrails\n\n- Do not generate legacy experimental decorator patterns for new code.\n- Do not generate `namespace`-centric architecture for new code.\n- Do not rely on implicit type-only import elision.\n- Do not use assertion-heavy shortcuts (`as any`, chained assertions) where narrowing is possible.\n- Do not introduce legacy module ambiguity between ESM and CJS.\n\nMigration-aware exception policy:\n\n- Allow temporary legacy retention only for explicit compatibility constraints in existing code.\n- Document exactly what is retained, why it is retained, and the concrete follow-up modernization step.\n- Scope each exception narrowly and avoid introducing new dependency on retained legacy behavior.\n\n## Output Requirements\n\nWhen generating or reviewing code, include:\n\n1. Environment note: detected archetype, runtime target, and toolchain context.\n2. Source truth note: detected project version\u002Ftoolchain reality and any\n   material gap versus latest stable guidance.\n3. Version note: TypeScript baseline and any intentional deviations.\n4. Decision note: chosen module and compiler strategy with one alternative.\n5. Tradeoff note: concise pros and cons for chosen path and rejected option.\n6. Legacy note: removed legacy patterns or bounded exceptions with rationale.\n7. Validation note: what checks were run and outcomes.\n8. Conflict note when relevant: `OFFICIAL_CONFLICT` or `UNVERIFIED` with a\n   concise explanation and the implementation consequence.\n\nWhen this skill is used to scaffold TypeScript config into another repository,\nalso include:\n\n1. which files were created or skipped\n2. which archetype was chosen and one rejected alternative\n3. which repo-local settings or dependencies still need adaptation\n4. the exact next validation command to run\n\n## Completion Checklist\n\n- Latest stable TypeScript modern baseline is enforced.\n- Project archetype was detected before config or code changes.\n- Module strategy matches runtime behavior.\n- Strict safety flags are enabled intentionally.\n- New code avoids legacy patterns.\n- Any retained legacy pattern is documented with a migration path.\n- Typecheck and relevant project validations were executed when available.\n- Any material official-source conflict or unverified non-trivial guidance is\n  disclosed explicitly when relevant.\n- Any scaffolded baseline was reported as a starter profile rather than silent\n  repo policy.\n","# UB TS\n\n## Overview\n\nUse this skill to enforce latest stable TypeScript modern defaults and patterns across app and library codebases. Generate modern-only output for new code, and allow legacy retention only as a bounded migration exception.\n\nImplement against the detected project TypeScript and runtime truth, but bias\ndesign toward forward-compatible migration rather than compatibility layers or\nlegacy fallbacks.\n\n## Bundled Assets\n\nThis skill ships reusable `tsconfig` starter scaffolding and an optional ESLint\nflat-config starter under `assets\u002F`, plus a deterministic helper under\n`scripts\u002F`.\n\nUse them when a repository wants this house-style starting point and does not\nyet have active TypeScript config of its own.\n\n## Load References On Demand\n\n- Read `references\u002Fts-modern-patterns.md` for archetype selection, tsconfig baselines, and modern typing patterns.\n- Read `references\u002Fts-legacy-to-modern-migration.md` for old-to-new migrations, banned patterns, and exception handling.\n- Read `references\u002Fts-config-resolution.md` when local TypeScript config\n  discovery, starter scaffolding, or optional ESLint support matters.\n- Read `references\u002Ftask-bundle.md` only when the target repository wants an\n  optional Task-based automation overlay for this skill's starter profile.\n- Use `scripts\u002Fscaffold_ts_baseline.py` with `assets\u002Ftsconfig-template\u002F` and\n  `assets\u002Feslint-template\u002F` when a target repository needs a deterministic\n  starter instead of ad hoc config creation.\n\n## Skill Coordination\n\n- Co-load this skill with `ub-vuejs` or `ub-nuxt` when TypeScript issues live\n  inside framework projects.\n- Defer framework runtime, routing, and app-structure decisions to the sibling\n  skill that owns them.\n\n## Core Workflow\n\n1. Detect the project archetype from `package.json`, lockfiles, runtime targets, build tooling, and existing `tsconfig*.json` files.\n2. Choose module strategy that matches runtime truth:\n   - Node runtime: `module` as `node20` or `nodenext`\n   - Bundler runtime: `moduleResolution` as `bundler` with `module` as `esnext`\n   - Library publishing: prefer Node-faithful resolution for compatibility checks\n   - Type-stripping runtime: enforce erasable TypeScript subset\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. Apply strict safety baseline and module hygiene defaults from `references\u002Fts-modern-patterns.md`.\n7. Implement modern type patterns first (`satisfies`, `const` type parameters, `NoInfer`, discriminated unions, explicit boundary typing).\n8. Reject legacy output for new code and apply migration mapping from `references\u002Fts-legacy-to-modern-migration.md` when touching existing code.\n9. Validate with available typecheck, lint, tests, and build commands in the target project.\n10. If a repository wants this baseline but lacks TypeScript config, scaffold\n    the bundled starter and explain the remaining repo-local adaptations.\n\n## Version & Research Policy\n\n- Target the latest stable release of TypeScript.\n- Detect the project's actual TypeScript version from `package.json` and lockfiles.\n- Use web search to verify current best practices, API availability, and migration guidance against official TypeScript 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 TypeScript 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 recommendation,\n  also surface `OFFICIAL_CONFLICT` instead of silently collapsing the\n  disagreement.\n- If a non-trivial claim cannot be confirmed in official sources after targeted\n  research, mark it `UNVERIFIED` or avoid presenting it as settled guidance.\n- Keep conflict and uncertainty disclosure scoped to non-trivial,\n  version-sensitive, or contested guidance rather than trivial edits.\n- Do not emit beta-only syntax unless the user explicitly requests it.\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: TypeScript release changes, compiler-flag behavior shifts, new module-resolution guidance, or runtime-platform updates that affect tsconfig strategy.\n- Enforcement: advisory only; freshness should inform review priority, not become a blocking requirement by itself.\n- Stable core: runtime-faithful module strategy, strict typing, and explicit boundary modeling remain the durable guidance even when compiler defaults evolve.\n\n## Implementation Rules\n\n### Project Archetype and Modules\n\n- Decide archetype before changing compiler options.\n- Keep module settings runtime-faithful, not preference-driven.\n- Keep `moduleDetection` as `force` unless a known compatibility constraint requires otherwise.\n\n### Import and Export Hygiene\n\n- Keep `verbatimModuleSyntax` enabled.\n- Use `import type` and `export type` for type-only symbols.\n- Keep side-effect imports explicit and resolvable.\n\n### Type System Patterns\n\n- Prefer `satisfies` to validate shapes without widening literals.\n- Prefer `const` type parameters in reusable APIs that benefit from literal preservation.\n- Use built-in `NoInfer` when inference must be constrained.\n- Model state with discriminated unions when behavior depends on variants.\n- Use `unknown` at trust boundaries, then narrow with validation.\n\n### Compiler Baseline\n\n- Keep `strict: true`.\n- Keep `noUncheckedIndexedAccess: true`.\n- Keep `exactOptionalPropertyTypes: true`.\n- Enable `isolatedModules` in toolchain-mixed repos.\n- Enable `isolatedDeclarations` for declaration-heavy library workflows.\n- Use `noUncheckedSideEffectImports` when side-effect imports are present.\n\n## Config Resolution And Scaffolding\n\nTreat real project config as the source of truth:\n\n1. inspect `tsconfig*.json`, `eslint.config.*`, `package.json`, and lockfiles\n   first when they exist\n2. match local runtime, bundler, and package-manager truth before choosing a\n   starter\n3. use the bundled `tsconfig` scaffold only when the repository lacks active\n   config and wants this house-style baseline\n4. treat the ESLint starter as optional strong-default support for TS repos,\n   not as universal TypeScript policy\n5. do not silently install dependencies or mutate CI as part of scaffolding\n\n### Tradeoff Handling\n\n- Use the shared `ub-quality` decision-analysis baseline for major TypeScript\n  decisions.\n- State TypeScript-specific pros and cons for each option, especially around\n  correctness, compatibility, DX, and migration cost.\n- Default to the safest modern option unless user constraints indicate otherwise.\n\n## Legacy-Avoidance Guardrails\n\n- Do not generate legacy experimental decorator patterns for new code.\n- Do not generate `namespace`-centric architecture for new code.\n- Do not rely on implicit type-only import elision.\n- Do not use assertion-heavy shortcuts (`as any`, chained assertions) where narrowing is possible.\n- Do not introduce legacy module ambiguity between ESM and CJS.\n\nMigration-aware exception policy:\n\n- Allow temporary legacy retention only for explicit compatibility constraints in existing code.\n- Document exactly what is retained, why it is retained, and the concrete follow-up modernization step.\n- Scope each exception narrowly and avoid introducing new dependency on retained legacy behavior.\n\n## Output Requirements\n\nWhen generating or reviewing code, include:\n\n1. Environment note: detected archetype, runtime target, and toolchain context.\n2. Source truth note: detected project version\u002Ftoolchain reality and any\n   material gap versus latest stable guidance.\n3. Version note: TypeScript baseline and any intentional deviations.\n4. Decision note: chosen module and compiler strategy with one alternative.\n5. Tradeoff note: concise pros and cons for chosen path and rejected option.\n6. Legacy note: removed legacy patterns or bounded exceptions with rationale.\n7. Validation note: what checks were run and outcomes.\n8. Conflict note when relevant: `OFFICIAL_CONFLICT` or `UNVERIFIED` with a\n   concise explanation and the implementation consequence.\n\nWhen this skill is used to scaffold TypeScript config into another repository,\nalso include:\n\n1. which files were created or skipped\n2. which archetype was chosen and one rejected alternative\n3. which repo-local settings or dependencies still need adaptation\n4. the exact next validation command to run\n\n## Completion Checklist\n\n- Latest stable TypeScript modern baseline is enforced.\n- Project archetype was detected before config or code changes.\n- Module strategy matches runtime behavior.\n- Strict safety flags are enabled intentionally.\n- New code avoids legacy patterns.\n- Any retained legacy pattern is documented with a migration path.\n- Typecheck and relevant project validations were executed when available.\n- Any material official-source conflict or unverified non-trivial guidance is\n  disclosed explicitly when relevant.\n- Any scaffolded baseline was reported as a starter profile rather than silent\n  repo policy.\n",{"name":5,"description":7},"main","3185d182c8d358d17a62485cb20f13024a81e429",".agents\u002Fskills\u002Fub-ts",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":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add robert-hoffmann\u002Funcle-bob --skill ub-ts",{"tool":63,"command":64},"bunx","bunx skills add robert-hoffmann\u002Funcle-bob --skill ub-ts",{"tool":66,"command":67},"pnpm","pnpm dlx skills add robert-hoffmann\u002Funcle-bob --skill ub-ts","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-ts\u002FSKILL.md",true,[71,77,83,87,91,95,99,105,109,113,117],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"assets\u002Feslint-template\u002Feslint.config.mjs","SCRIPT","脚本",506,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-ts\u002Fassets\u002Feslint-template\u002Feslint.config.mjs",{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"assets\u002Ftask-bundle\u002Fbase\u002Fub-ts.Taskfile.yml","ASSET","资产文件",205,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-ts\u002Fassets\u002Ftask-bundle\u002Fbase\u002Fub-ts.Taskfile.yml",{"path":84,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":85,"sourceHtmlUrl":86},"assets\u002Ftask-bundle\u002Feslint\u002Fub-ts.Taskfile.yml",312,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-ts\u002Fassets\u002Ftask-bundle\u002Feslint\u002Fub-ts.Taskfile.yml",{"path":88,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":89,"sourceHtmlUrl":90},"assets\u002Ftsconfig-template\u002Fbundler\u002Ftsconfig.json",557,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-ts\u002Fassets\u002Ftsconfig-template\u002Fbundler\u002Ftsconfig.json",{"path":92,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":93,"sourceHtmlUrl":94},"assets\u002Ftsconfig-template\u002Flibrary\u002Ftsconfig.json",595,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-ts\u002Fassets\u002Ftsconfig-template\u002Flibrary\u002Ftsconfig.json",{"path":96,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":97,"sourceHtmlUrl":98},"assets\u002Ftsconfig-template\u002Fnode\u002Ftsconfig.json",478,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-ts\u002Fassets\u002Ftsconfig-template\u002Fnode\u002Ftsconfig.json",{"path":100,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":103,"sourceHtmlUrl":104},"references\u002Ftask-bundle.md","REFERENCE","参考文档",3005,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-ts\u002Freferences\u002Ftask-bundle.md",{"path":106,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":107,"sourceHtmlUrl":108},"references\u002Fts-config-resolution.md",2118,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-ts\u002Freferences\u002Fts-config-resolution.md",{"path":110,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":111,"sourceHtmlUrl":112},"references\u002Fts-legacy-to-modern-migration.md",3532,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-ts\u002Freferences\u002Fts-legacy-to-modern-migration.md",{"path":114,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":115,"sourceHtmlUrl":116},"references\u002Fts-modern-patterns.md",7109,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-ts\u002Freferences\u002Fts-modern-patterns.md",{"path":118,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":119,"sourceHtmlUrl":120},"scripts\u002Fscaffold_ts_baseline.py",2390,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-ts\u002Fscripts\u002Fscaffold_ts_baseline.py",[122,133,143,149,154,160],{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":129,"publishedAt":42},"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",[128],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[130,131,132],"beta skill","beta","test",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":140,"publishedAt":42},"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",[139],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[141,142,132],"alpha skill","alpha",{"skillNo":144,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":148,"publishedAt":42},"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",[147],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[130,131,132],{"skillNo":150,"name":135,"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":151,"categories":152,"keywords":153,"publishedAt":42},"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",[],[141,142],{"skillNo":155,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":159,"publishedAt":42},"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",[158],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[130,131,132],{"skillNo":161,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":165,"publishedAt":42},"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",[164],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[142,141,132]]