[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DM9TGE51FHFTJVP99DHJS5":3,"skill-same:01M6DM9TGE51FHFTJVP99DHJS5":129},{"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":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":62,"ownerHtmlUrl":63,"ownerBlogUrl":64,"ownerDescription":65,"updatedAt":66,"install":67,"resources":80},"01M6DM9TGE51FHFTJVP99DHJS5","ub-quality",null,"Use this skill alongside the primary implementation, review, or workflow skill when the user wants code review, repo scanning, maintainability or architecture feedback, implementation planning, documentation cleanup, readable comparisons, or a clearer structured answer. Apply it when shared formatting, alignment, and response-structure rules must be enforced across touched code or documents. Do not use it as the primary owner of language, framework, runtime, or workflow decisions.","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-quality\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"ub quality","quality","scanning","workflow skill","as","formatting","shared","across","structure","do","alignment","code review","framework","code","cleanup","documents","documentation","architecture","workflow","review","2026-11-10 10:12:30",false,"---\nname: ub-quality\ndescription: Use this skill alongside the primary implementation, review, or workflow skill when the user wants code review, repo scanning, maintainability or architecture feedback, implementation planning, documentation cleanup, readable comparisons, or a clearer structured answer. Apply it when shared formatting, alignment, and response-structure rules must be enforced across touched code or documents. Do not use it as the primary owner of language, framework, runtime, or workflow decisions.\n---\n\n# UB Quality\n\n## Critical Contract\n\nApply the embedded baseline in this `SKILL.md` immediately whenever\n`ub-quality` is loaded.\n\nFor work that depends on deeper quality rules, load the relevant references by\nthe trigger table in this skill before producing the output. Do not skip a\ntriggered reference because the task looks small or the local style differs.\n\nFor every touched eligible vertical separator block, separators must align into one column. Use separator-column alignment (`key : value`), not value-column alignment (`key: value`).\n\nThis applies across code, configs, comments, docstrings, markup attributes, and documentation blocks when the structure is eligible.\n\nTreat embedded language blocks such as `\u003Cstyle>` and `\u003Cscript>` as native CSS and JavaScript formatting surfaces, not as generic HTML text.\n\nOnly syntax breakage or a verified tooling or runtime constraint may justify leaving an eligible touched block unaligned.\n\nCompliant:\n\n```text\ngrid      : ''\nsolar     : ''\ntextMuted : ''\n```\n\nNon-compliant:\n\n```text\ngrid:      ''\nsolar:     ''\ntextMuted: ''\n```\n\n## When To Use\n\nUse this skill alongside the primary implementation, review, or workflow skill\nfor:\n\n- New code generation\n- Code edits and refactors\n- Code review responses\n- Repo scans, architecture explanations, and maintainability feedback\n- Documentation, config, comment, and formatting normalization in touched regions\n- User-facing responses that need clearer structure or comparison formatting\n\nApply this skill whenever you create, modify, review, refactor, or normalize\ncode or documents and the task benefits from shared quality or readability\nrules.\n\n## Do Not Treat As Optional\n\n- Do not treat formatting and alignment as optional cleanup.\n- If this skill is loaded, its formatting and alignment rules apply to all touched eligible blocks.\n- Do not skip alignment because nearby code is unaligned, because a shorter style looks more familiar, or because the block is in documentation rather than code.\n- Do not normalize unrelated blocks outside the touched logical scope unless broader normalization was explicitly requested.\n\n## Reference Loading Contract\n\n`ub-quality` itself remains the always-loaded baseline. Deeper references are\nnot optional; they are loaded by trigger so the right contract is applied at\nthe right time without treating every task as if every quality subdomain is\nactive.\n\nMUST load and apply:\n\n- `references\u002Fdesign-patterns.md` when making architecture, implementation,\n  refactoring, abstraction, dependency, or maintainability decisions.\n- `references\u002Fformatting-alignment.md` before creating or modifying code,\n  configs, examples, comments, docstrings, markup attributes, documentation\n  tables, or any other touched content with eligible separator blocks.\n- `references\u002Fdocumentation-structure-refactoring.md` before creating,\n  editing, reviewing, reorganizing, or refactoring documentation, comments,\n  file structure, public call surfaces, or large source files.\n- `references\u002Fimportant-tags-and-doc-generation.md` before creating or\n  modifying generated documents, comment tags, TODO-like markers, or any\n  content that may contain special preservation tags.\n- `references\u002Fresponse-readability.md` before substantial user-facing plans,\n  reviews, explanations, comparisons, or any answer where structure materially\n  affects scanability.\n- `references\u002Ffreshness-portability.md` when deciding whether guidance is\n  repository policy, a strong house default, advisory freshness guidance, or a\n  portability concern.\n\nIf more than one trigger applies, load every relevant reference before\nproducing the dependent output.\n\n## Non-Compliance\n\nThe following are non-compliant when a touched block is eligible for alignment:\n\n- An eligible vertical separator block whose separators do not form one column.\n- Value-column alignment in an eligible block.\n- Leaving embedded CSS\u002FJS blocks unformatted as native language blocks when the touched content is eligible for alignment.\n- Skipping alignment because of convenience, omission, or surrounding local style.\n- Normalizing unrelated blocks outside the touched logical scope.\n\n## Decision Analysis Baseline\n\nFor planning, design, architecture, implementation direction, and other\nchoice-bearing guidance:\n\n- Surface `2+` plausible approaches by default.\n- Prefer a curated set of `2-4` options instead of exhaustive enumeration.\n- Include concise pros\u002Fcons for each option and identify the recommended path.\n- If only one path is materially meaningful, say that explicitly and explain\n  why the alternatives are not meaningfully different instead of fabricating a\n  fake option set.\n- Leave sibling skills free to add domain-specific tradeoff dimensions when\n  they add real value.\n\n## Readability Baseline\n\nFor user-facing responses across chat, planning, reviews, specs, and\nexplanations:\n\n- Lead with the answer, recommendation, or key point.\n- Use informative headings for substantial responses.\n- Keep paragraphs short and visually separated.\n- Use bullets for collections and numbered steps for sequence.\n- Keep list items parallel in grammar and intent.\n- Use tables only for true multi-attribute comparisons that stay compact.\n- Avoid dense text blocks when structure would improve scanning.\n- Keep short answers compact and avoid ceremonial formatting.\n\nTable rule:\n\n- Prefer compact tables only when they materially improve side-by-side\n  comparison.\n- Usually keep tables to `2-4` columns with short headers and brief cells.\n- Do not force sentence-length prose into table cells.\n- When a table becomes too wide, dense, or renderer-fragile, convert it to a\n  safer fallback structure instead of trying to preserve the grid.\n\n## Core Workflow\n\n1. Inspect the task scope and touched files.\n2. Apply the embedded baseline immediately.\n3. Load and apply every reference triggered by the task before producing\n   dependent output.\n4. Apply the decision-analysis baseline for planning, design, architecture,\n   implementation direction, and other choice-bearing guidance.\n5. Apply the readability baseline for user-facing responses and choose tables\n   versus safer fallback structures accordingly.\n6. Choose the simplest approach that preserves behavior and constraints.\n7. Apply formatting, documentation, and structure rules only in touched logical blocks.\n8. Validate behavior and explain any intentional exceptions allowed by the triggered references.\n\n## Skill Coordination\n\n- Apply this skill together with the most relevant language\u002Fframework skill when available.\n- Treat this skill as a companion baseline, not as a replacement for the\n  primary implementation or workflow skill.\n- Treat syntax, runtime, and framework correctness as primary constraints.\n- Do not treat formatter preference or familiar house style as a valid reason to violate the alignment contract.\n- Prefer code and naming to carry mechanics, then use docs and comments for\n  contract, rationale, and non-obvious constraints.\n\n## Policy Versus Defaults\n\n- In this repository, the alignment contract and triggered-reference workflow are repository policy when `ub-quality` is loaded.\n- Many language\u002Fframework recommendations coordinated through sibling skills are strong defaults, not universal portability requirements.\n- Treat volatile setup recipes as freshness-review candidates first, not as automatic blockers, unless the repository explicitly promotes them to policy.\n\n## Output Requirements\n\nWhen generating or modifying code:\n\n1. Include concise pros\u002Fcons and a recommendation for meaningful implementation\n   choices.\n2. Keep solutions simple and avoid overengineering.\n3. Preserve existing behavior unless change is explicitly requested.\n4. Call out any intentionally retained technical debt or deferred cleanup.\n5. Favor high-signal documentation over broad narration, especially in shared\n   guidance and heavily reused code.\n6. Make user-facing explanations easy to scan before deep reading.\n7. Match the structure to the information shape instead of defaulting to dense\n   prose or oversized tables.\n\n## Completion Gate\n\nBefore finalizing:\n\n- Check every touched eligible separator block.\n- Treat touched `\u003Cstyle>` and `\u003Cscript>` content as native CSS and JavaScript surfaces.\n- Expand dense multiline-capable structures (for example literals, argument lists, and config\u002Fdata blocks) into one-item-per-line form when required by `references\u002Fformatting-alignment.md`, then align eligible entries.\n- Align separators into one column using the longest-left-token rule from `references\u002Fformatting-alignment.md`.\n- Confirm no unrelated blocks were normalized.\n- If any eligible block remains unaligned, the edit is incomplete unless a named exception from `references\u002Fformatting-alignment.md` applies.\n- Ensure special comment tags and `AGENT_TODO` handling policy are respected.\n- Expose the answer or recommendation early in user-facing responses.\n- Use headings, bullets, steps, tables, or fallback blocks only when they\n  improve scanability for the information shape.\n- Confirm list items stay parallel and concise.\n- Confirm any table adds clarity rather than width or density problems.\n- If a comparison table became too wide or text-heavy, convert it to a stacked\n  fallback structure instead of forcing the grid.\n- Keep brief answers brief.\n","# UB Quality\n\n## Critical Contract\n\nApply the embedded baseline in this `SKILL.md` immediately whenever\n`ub-quality` is loaded.\n\nFor work that depends on deeper quality rules, load the relevant references by\nthe trigger table in this skill before producing the output. Do not skip a\ntriggered reference because the task looks small or the local style differs.\n\nFor every touched eligible vertical separator block, separators must align into one column. Use separator-column alignment (`key : value`), not value-column alignment (`key: value`).\n\nThis applies across code, configs, comments, docstrings, markup attributes, and documentation blocks when the structure is eligible.\n\nTreat embedded language blocks such as `\u003Cstyle>` and `\u003Cscript>` as native CSS and JavaScript formatting surfaces, not as generic HTML text.\n\nOnly syntax breakage or a verified tooling or runtime constraint may justify leaving an eligible touched block unaligned.\n\nCompliant:\n\n```text\ngrid      : ''\nsolar     : ''\ntextMuted : ''\n```\n\nNon-compliant:\n\n```text\ngrid:      ''\nsolar:     ''\ntextMuted: ''\n```\n\n## When To Use\n\nUse this skill alongside the primary implementation, review, or workflow skill\nfor:\n\n- New code generation\n- Code edits and refactors\n- Code review responses\n- Repo scans, architecture explanations, and maintainability feedback\n- Documentation, config, comment, and formatting normalization in touched regions\n- User-facing responses that need clearer structure or comparison formatting\n\nApply this skill whenever you create, modify, review, refactor, or normalize\ncode or documents and the task benefits from shared quality or readability\nrules.\n\n## Do Not Treat As Optional\n\n- Do not treat formatting and alignment as optional cleanup.\n- If this skill is loaded, its formatting and alignment rules apply to all touched eligible blocks.\n- Do not skip alignment because nearby code is unaligned, because a shorter style looks more familiar, or because the block is in documentation rather than code.\n- Do not normalize unrelated blocks outside the touched logical scope unless broader normalization was explicitly requested.\n\n## Reference Loading Contract\n\n`ub-quality` itself remains the always-loaded baseline. Deeper references are\nnot optional; they are loaded by trigger so the right contract is applied at\nthe right time without treating every task as if every quality subdomain is\nactive.\n\nMUST load and apply:\n\n- `references\u002Fdesign-patterns.md` when making architecture, implementation,\n  refactoring, abstraction, dependency, or maintainability decisions.\n- `references\u002Fformatting-alignment.md` before creating or modifying code,\n  configs, examples, comments, docstrings, markup attributes, documentation\n  tables, or any other touched content with eligible separator blocks.\n- `references\u002Fdocumentation-structure-refactoring.md` before creating,\n  editing, reviewing, reorganizing, or refactoring documentation, comments,\n  file structure, public call surfaces, or large source files.\n- `references\u002Fimportant-tags-and-doc-generation.md` before creating or\n  modifying generated documents, comment tags, TODO-like markers, or any\n  content that may contain special preservation tags.\n- `references\u002Fresponse-readability.md` before substantial user-facing plans,\n  reviews, explanations, comparisons, or any answer where structure materially\n  affects scanability.\n- `references\u002Ffreshness-portability.md` when deciding whether guidance is\n  repository policy, a strong house default, advisory freshness guidance, or a\n  portability concern.\n\nIf more than one trigger applies, load every relevant reference before\nproducing the dependent output.\n\n## Non-Compliance\n\nThe following are non-compliant when a touched block is eligible for alignment:\n\n- An eligible vertical separator block whose separators do not form one column.\n- Value-column alignment in an eligible block.\n- Leaving embedded CSS\u002FJS blocks unformatted as native language blocks when the touched content is eligible for alignment.\n- Skipping alignment because of convenience, omission, or surrounding local style.\n- Normalizing unrelated blocks outside the touched logical scope.\n\n## Decision Analysis Baseline\n\nFor planning, design, architecture, implementation direction, and other\nchoice-bearing guidance:\n\n- Surface `2+` plausible approaches by default.\n- Prefer a curated set of `2-4` options instead of exhaustive enumeration.\n- Include concise pros\u002Fcons for each option and identify the recommended path.\n- If only one path is materially meaningful, say that explicitly and explain\n  why the alternatives are not meaningfully different instead of fabricating a\n  fake option set.\n- Leave sibling skills free to add domain-specific tradeoff dimensions when\n  they add real value.\n\n## Readability Baseline\n\nFor user-facing responses across chat, planning, reviews, specs, and\nexplanations:\n\n- Lead with the answer, recommendation, or key point.\n- Use informative headings for substantial responses.\n- Keep paragraphs short and visually separated.\n- Use bullets for collections and numbered steps for sequence.\n- Keep list items parallel in grammar and intent.\n- Use tables only for true multi-attribute comparisons that stay compact.\n- Avoid dense text blocks when structure would improve scanning.\n- Keep short answers compact and avoid ceremonial formatting.\n\nTable rule:\n\n- Prefer compact tables only when they materially improve side-by-side\n  comparison.\n- Usually keep tables to `2-4` columns with short headers and brief cells.\n- Do not force sentence-length prose into table cells.\n- When a table becomes too wide, dense, or renderer-fragile, convert it to a\n  safer fallback structure instead of trying to preserve the grid.\n\n## Core Workflow\n\n1. Inspect the task scope and touched files.\n2. Apply the embedded baseline immediately.\n3. Load and apply every reference triggered by the task before producing\n   dependent output.\n4. Apply the decision-analysis baseline for planning, design, architecture,\n   implementation direction, and other choice-bearing guidance.\n5. Apply the readability baseline for user-facing responses and choose tables\n   versus safer fallback structures accordingly.\n6. Choose the simplest approach that preserves behavior and constraints.\n7. Apply formatting, documentation, and structure rules only in touched logical blocks.\n8. Validate behavior and explain any intentional exceptions allowed by the triggered references.\n\n## Skill Coordination\n\n- Apply this skill together with the most relevant language\u002Fframework skill when available.\n- Treat this skill as a companion baseline, not as a replacement for the\n  primary implementation or workflow skill.\n- Treat syntax, runtime, and framework correctness as primary constraints.\n- Do not treat formatter preference or familiar house style as a valid reason to violate the alignment contract.\n- Prefer code and naming to carry mechanics, then use docs and comments for\n  contract, rationale, and non-obvious constraints.\n\n## Policy Versus Defaults\n\n- In this repository, the alignment contract and triggered-reference workflow are repository policy when `ub-quality` is loaded.\n- Many language\u002Fframework recommendations coordinated through sibling skills are strong defaults, not universal portability requirements.\n- Treat volatile setup recipes as freshness-review candidates first, not as automatic blockers, unless the repository explicitly promotes them to policy.\n\n## Output Requirements\n\nWhen generating or modifying code:\n\n1. Include concise pros\u002Fcons and a recommendation for meaningful implementation\n   choices.\n2. Keep solutions simple and avoid overengineering.\n3. Preserve existing behavior unless change is explicitly requested.\n4. Call out any intentionally retained technical debt or deferred cleanup.\n5. Favor high-signal documentation over broad narration, especially in shared\n   guidance and heavily reused code.\n6. Make user-facing explanations easy to scan before deep reading.\n7. Match the structure to the information shape instead of defaulting to dense\n   prose or oversized tables.\n\n## Completion Gate\n\nBefore finalizing:\n\n- Check every touched eligible separator block.\n- Treat touched `\u003Cstyle>` and `\u003Cscript>` content as native CSS and JavaScript surfaces.\n- Expand dense multiline-capable structures (for example literals, argument lists, and config\u002Fdata blocks) into one-item-per-line form when required by `references\u002Fformatting-alignment.md`, then align eligible entries.\n- Align separators into one column using the longest-left-token rule from `references\u002Fformatting-alignment.md`.\n- Confirm no unrelated blocks were normalized.\n- If any eligible block remains unaligned, the edit is incomplete unless a named exception from `references\u002Fformatting-alignment.md` applies.\n- Ensure special comment tags and `AGENT_TODO` handling policy are respected.\n- Expose the answer or recommendation early in user-facing responses.\n- Use headings, bullets, steps, tables, or fallback blocks only when they\n  improve scanability for the information shape.\n- Confirm list items stay parallel and concise.\n- Confirm any table adds clarity rather than width or density problems.\n- If a comparison table became too wide or text-heavy, convert it to a stacked\n  fallback structure instead of forcing the grid.\n- Keep brief answers brief.\n",{"name":5,"description":7},"main","3185d182c8d358d17a62485cb20f13024a81e429",".agents\u002Fskills\u002Fub-quality",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":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add robert-hoffmann\u002Funcle-bob --skill ub-quality",{"tool":73,"command":74},"bunx","bunx skills add robert-hoffmann\u002Funcle-bob --skill ub-quality",{"tool":76,"command":77},"pnpm","pnpm dlx skills add robert-hoffmann\u002Funcle-bob --skill ub-quality","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-quality\u002FSKILL.md",true,[81,87,91,95,99,105,109,113,117,121,125],{"path":82,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":86},"examples\u002F3p-updates.md","REFERENCE","参考文档",3274,"https:\u002F\u002Fgithub.com\u002Fshikhar13012001\u002Ffitness-tracker\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Finternal-comms\u002Fexamples\u002F3p-updates.md",{"path":88,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":89,"sourceHtmlUrl":90},"examples\u002Fcompany-newsletter.md",3295,"https:\u002F\u002Fgithub.com\u002Fshikhar13012001\u002Ffitness-tracker\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Finternal-comms\u002Fexamples\u002Fcompany-newsletter.md",{"path":92,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":93,"sourceHtmlUrl":94},"examples\u002Ffaq-answers.md",2366,"https:\u002F\u002Fgithub.com\u002Fshikhar13012001\u002Ffitness-tracker\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Finternal-comms\u002Fexamples\u002Ffaq-answers.md",{"path":96,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":97,"sourceHtmlUrl":98},"examples\u002Fgeneral-comms.md",602,"https:\u002F\u002Fgithub.com\u002Fshikhar13012001\u002Ffitness-tracker\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Finternal-comms\u002Fexamples\u002Fgeneral-comms.md",{"path":100,"resourceType":101,"resourceTypeDesc":102,"sizeBytes":103,"sourceHtmlUrl":104},"LICENSE.txt","LICENSE","许可证",11345,"https:\u002F\u002Fgithub.com\u002Fshikhar13012001\u002Ffitness-tracker\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Finternal-comms\u002FLICENSE.txt",{"path":106,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":107,"sourceHtmlUrl":108},"references\u002Fdesign-patterns.md",3537,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-quality\u002Freferences\u002Fdesign-patterns.md",{"path":110,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":111,"sourceHtmlUrl":112},"references\u002Fdocumentation-structure-refactoring.md",14837,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-quality\u002Freferences\u002Fdocumentation-structure-refactoring.md",{"path":114,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":115,"sourceHtmlUrl":116},"references\u002Fformatting-alignment.md",8783,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-quality\u002Freferences\u002Fformatting-alignment.md",{"path":118,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":119,"sourceHtmlUrl":120},"references\u002Ffreshness-portability.md",4797,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-quality\u002Freferences\u002Ffreshness-portability.md",{"path":122,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":123,"sourceHtmlUrl":124},"references\u002Fimportant-tags-and-doc-generation.md",1175,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-quality\u002Freferences\u002Fimportant-tags-and-doc-generation.md",{"path":126,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":127,"sourceHtmlUrl":128},"references\u002Fresponse-readability.md",7918,"https:\u002F\u002Fgithub.com\u002Frobert-hoffmann\u002Funcle-bob\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fub-quality\u002Freferences\u002Fresponse-readability.md",[130,141,151,157,162,168],{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":137,"publishedAt":52},"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",[136],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[138,139,140],"beta skill","beta","test",{"skillNo":142,"name":143,"nameZh":6,"description":144,"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":52},"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",[147],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[149,150,140],"alpha skill","alpha",{"skillNo":152,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":156,"publishedAt":52},"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",[155],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[138,139,140],{"skillNo":158,"name":143,"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":159,"categories":160,"keywords":161,"publishedAt":52},"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",[],[149,150],{"skillNo":163,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":167,"publishedAt":52},"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",[166],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[138,139,140],{"skillNo":169,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":173,"publishedAt":52},"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",[172],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[150,149,140]]