[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6D7SC50FJMXK4FJY2CVJKQX":3,"skill-same:01M6D7SC50FJMXK4FJY2CVJKQX":74},{"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":31,"linkOnly":32,"markdownContent":33,"markdownBody":34,"frontMatter":35,"refName":40,"commitSha":41,"skillDirectory":42,"forksCount":43,"repositoryHtmlUrl":44,"repositoryHomepageUrl":45,"ownerHtmlUrl":46,"ownerBlogUrl":47,"ownerDescription":48,"updatedAt":49,"install":50,"resources":63},"01M6D7SC50FJMXK4FJY2CVJKQX","slim-audit",null,"Audit codebase for opportunities to reduce lines of code while preserving functionality, performance, and quality","GeorgeQLe\u002Fagentic-skills","GeorgeQLe","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F21134126?v=4","01M6D2JP418S0VGJGF8M93EC3H","George Le","01M6D2JPBAKYD82TA5FS6HKQ3D",1,"MIT","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fcode-review\u002Fclaude\u002Fslim-audit\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30],"audit","slim audit","directory","performance","code","package","file","analysis","page","quality","v0","alignment","2026-11-10 10:12:30",false,"---\nname: slim-audit\ndescription: Audit codebase for opportunities to reduce lines of code while preserving functionality, performance, and quality\ntype: analysis\nversion: v0.1\nrequired_conventions: [alignment-page]\nargument-hint: \"[optional: specific package, directory, or file to scope the audit]\"\n---\n\n# Slim Audit\n\nAudit the codebase, documentation, and specs to identify concrete opportunities to reduce lines of code while maintaining or improving functionality, performance, and code quality. Outputs a prioritized reduction plan with estimated LOC savings.\n\n## Process\n\n1. **Gather project context:**\n   - Read `CLAUDE.md`, `README.md`, and project config files to understand conventions, architecture, and constraints.\n   - Search for and read project documentation: specs (`specs\u002F`, `spec.md`, `docs\u002F`), changelogs (`CHANGELOG.md`, `tasks\u002Fhistory.md`), ADRs, and design docs.\n   - Read `tasks\u002Froadmap.md`, `tasks\u002Ftodo.md`, `tasks\u002Fmanual-todo.md`, `tasks\u002Frecord-todo.md`, and `tasks\u002Frecurring-todo.md` if they exist to understand in-progress and advisory work.\n   - Build a mental model of **intentional decisions** — patterns, trade-offs, and constraints the team has deliberately chosen.\n\n2. **Determine scope:**\n   - If `$ARGUMENTS` specifies a package, directory, or file, scope the audit there.\n   - Otherwise, audit the entire project (or all packages in a monorepo).\n\n3. **Analyze for reduction opportunities across these categories:**\n\n   **a. Duplicate and near-duplicate code:**\n   - Identify code blocks that are identical or structurally similar (same logic, different names\u002Fvalues).\n   - Flag copy-paste patterns across files that could be consolidated into a shared function or module.\n   - Look for repeated patterns in tests that could use shared fixtures, helpers, or parameterized tests.\n\n   **b. Over-abstraction and unnecessary indirection:**\n   - Wrapper functions\u002Fclasses that add no logic — they just forward calls to an inner implementation.\n   - Adapter or facade layers with a single consumer that could be inlined.\n   - Abstract base classes or interfaces implemented by only one concrete class.\n   - Factory patterns where a direct constructor or function call would suffice.\n   - Middleware or decorator chains that could be collapsed.\n\n   **c. Verbose patterns with idiomatic alternatives:**\n   - Manual loops that could be replaced by built-in array\u002Fcollection methods (`map`, `filter`, `reduce`).\n   - Verbose null\u002Fundefined checks that could use optional chaining, nullish coalescing, or pattern matching.\n   - Hand-rolled utility functions that duplicate standard library or already-imported dependency functionality.\n   - Explicit type definitions that could be inferred by the compiler\u002Fruntime.\n   - Verbose error handling patterns that could use a shared error handler or middleware.\n\n   **d. Redundant logic:**\n   - Validation or guard checks already performed upstream (caller validates, callee re-validates).\n   - Dead branches in conditionals — conditions that are always true\u002Ffalse given the surrounding code.\n   - Redundant type conversions or serialization round-trips.\n   - Configuration or initialization code that duplicates framework defaults.\n\n   **e. Hand-rolled implementations replaceable by dependencies:**\n   - Custom implementations of functionality provided by an already-imported library (e.g., hand-rolled date formatting when `date-fns` is already in `package.json`).\n   - Utility code that reimplements well-tested standard library functions.\n   - **Note:** Only suggest replacing with libraries *already in the dependency tree*. Do not suggest adding new dependencies.\n\n   **f. Structural bloat:**\n   - Files that exist purely for re-export (barrel files) with no additional logic, where the re-exports could be replaced by direct imports.\n   - Excessive file splitting where closely related code (used together, changed together) is scattered across many small files that could be a single cohesive module.\n   - Boilerplate-heavy patterns that could be reduced with code generation, decorators, or framework conventions.\n\n4. **Cross-reference findings against documentation:**\n   - Before reporting a finding, check if the pattern was an intentional decision documented in specs, ADRs, changelogs, or design docs.\n   - If a verbose pattern exists because of a documented constraint (performance, compatibility, readability preference), **do not flag it**. Note it under \"Intentional Decisions\" instead.\n   - If a finding would change externally-visible behavior (API contracts, output format, error messages), flag it as **Behavior Change Risk** rather than a safe reduction.\n\n5. **Estimate impact:**\n   - For each opportunity, estimate the approximate LOC reduction (net lines removed after the refactor).\n   - Assess risk: Low (pure refactor, no behavior change), Medium (internal behavior change, needs testing), High (external behavior change risk).\n   - Assess effort: Small (\u003C 30 min), Medium (1-2 hours), Large (half-day+).\n\n6. **Cross-reference with git:**\n   - For flagged areas, check `git log` and `git blame` to understand why the code exists in its current form.\n   - Code with recent intentional refactoring history should be flagged with lower confidence.\n   - Code untouched for 6+ months with clear reduction paths gets higher priority.\n\n7. **Verify findings (false-positive filter):**\n   - Before finalizing, re-read the actual source code for every finding. For each one, confirm:\n     - The \"duplicate\" code is genuinely duplicated — not just structurally similar with important semantic differences.\n     - The \"unnecessary wrapper\" doesn't handle edge cases, logging, error transformation, or other subtle behavior you missed on first read.\n     - The \"verbose pattern\" replacement is actually equivalent — same behavior for all inputs, including edge cases.\n     - The \"redundant check\" is genuinely redundant — the upstream validation actually covers all cases the downstream check handles.\n     - The suggested library replacement produces identical output for all relevant inputs.\n     - The reduction **preserves all existing functionality** unless the current behavior is a clear, demonstrable bug.\n   - **Drop any finding you cannot re-confirm with a second read.** If uncertain, move it to \"Needs Investigation\" rather than recommending removal.\n\n## Output\n\n### Summary\n- **Total opportunities found**: N\n- **Estimated total LOC reduction**: ~N lines\n- **Risk breakdown**: N low \u002F N medium \u002F N high\n\n### High-Value Reductions (low risk, high LOC savings)\n| Location | Category | Current LOC | Est. Savings | Risk | Description |\n|----------|----------|-------------|--------------|------|-------------|\n| `path\u002Ffile.ts:20-85` | Duplication | 65 | ~40 | Low | Consolidate into shared helper |\n\nFor each high-value finding, include:\n- **Current code**: brief description or snippet of the verbose\u002Fduplicated pattern\n- **Proposed approach**: how to reduce it\n- **Why it's safe**: what guarantees functionality is preserved\n\n### Medium-Value Reductions\nSame table format — moderate savings or moderate risk.\n\n### Low-Value Reductions\nBrief list — small savings, worth tracking but not urgent.\n\n### Behavior Change Risk\nOpportunities that would reduce code but may alter externally-visible behavior. Each includes:\n- What would change\n- Why it might be acceptable (e.g., fixing a likely bug)\n- What testing would be needed to confirm safety\n\n### Intentional Decisions (no action)\nVerbose patterns that exist for documented reasons — not flagged as issues.\n\n### Needs Investigation\nItems that look reducible but have ambiguous usage patterns or unclear intent. Each includes what specifically needs to be investigated.\n\n## Constraints\n- Use subagents to parallelize analysis across packages in a monorepo.\n- **Never automatically modify code** — only report findings and recommendations.\n- **Functionality preservation is the top priority.** Every recommendation must preserve existing behavior unless the current behavior is a clear, demonstrable bug. When in doubt, classify as \"Behavior Change Risk\" rather than recommending removal.\n- Do not recommend reductions that trade LOC for readability — if the verbose version is clearer, it stays.\n- Do not recommend adding new dependencies to replace hand-rolled code. Only suggest replacements using libraries already in the dependency tree.\n- Do not flag test code for reduction unless the reduction clearly improves test maintainability (e.g., shared fixtures reducing update burden).\n- Do not flag configuration files, migration files, or generated code.\n- Be specific — always include file paths and line numbers or ranges.\n- Every recommendation must include a concrete \"proposed approach,\" not just \"simplify this.\"\n- Prefer many small, independent reductions over large sweeping refactors — smaller changes are safer and easier to review.\n- If the codebase has no specs or documentation, proceed with the audit but note the absence and increase the confidence threshold for recommendations.\n\n\n## Alignment Page\n\nFollow the shared alignment-page convention via the packaged convention resolver; output path is `alignment\u002Fslim-audit-{topic}.html`.\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n","# Slim Audit\n\nAudit the codebase, documentation, and specs to identify concrete opportunities to reduce lines of code while maintaining or improving functionality, performance, and code quality. Outputs a prioritized reduction plan with estimated LOC savings.\n\n## Process\n\n1. **Gather project context:**\n   - Read `CLAUDE.md`, `README.md`, and project config files to understand conventions, architecture, and constraints.\n   - Search for and read project documentation: specs (`specs\u002F`, `spec.md`, `docs\u002F`), changelogs (`CHANGELOG.md`, `tasks\u002Fhistory.md`), ADRs, and design docs.\n   - Read `tasks\u002Froadmap.md`, `tasks\u002Ftodo.md`, `tasks\u002Fmanual-todo.md`, `tasks\u002Frecord-todo.md`, and `tasks\u002Frecurring-todo.md` if they exist to understand in-progress and advisory work.\n   - Build a mental model of **intentional decisions** — patterns, trade-offs, and constraints the team has deliberately chosen.\n\n2. **Determine scope:**\n   - If `$ARGUMENTS` specifies a package, directory, or file, scope the audit there.\n   - Otherwise, audit the entire project (or all packages in a monorepo).\n\n3. **Analyze for reduction opportunities across these categories:**\n\n   **a. Duplicate and near-duplicate code:**\n   - Identify code blocks that are identical or structurally similar (same logic, different names\u002Fvalues).\n   - Flag copy-paste patterns across files that could be consolidated into a shared function or module.\n   - Look for repeated patterns in tests that could use shared fixtures, helpers, or parameterized tests.\n\n   **b. Over-abstraction and unnecessary indirection:**\n   - Wrapper functions\u002Fclasses that add no logic — they just forward calls to an inner implementation.\n   - Adapter or facade layers with a single consumer that could be inlined.\n   - Abstract base classes or interfaces implemented by only one concrete class.\n   - Factory patterns where a direct constructor or function call would suffice.\n   - Middleware or decorator chains that could be collapsed.\n\n   **c. Verbose patterns with idiomatic alternatives:**\n   - Manual loops that could be replaced by built-in array\u002Fcollection methods (`map`, `filter`, `reduce`).\n   - Verbose null\u002Fundefined checks that could use optional chaining, nullish coalescing, or pattern matching.\n   - Hand-rolled utility functions that duplicate standard library or already-imported dependency functionality.\n   - Explicit type definitions that could be inferred by the compiler\u002Fruntime.\n   - Verbose error handling patterns that could use a shared error handler or middleware.\n\n   **d. Redundant logic:**\n   - Validation or guard checks already performed upstream (caller validates, callee re-validates).\n   - Dead branches in conditionals — conditions that are always true\u002Ffalse given the surrounding code.\n   - Redundant type conversions or serialization round-trips.\n   - Configuration or initialization code that duplicates framework defaults.\n\n   **e. Hand-rolled implementations replaceable by dependencies:**\n   - Custom implementations of functionality provided by an already-imported library (e.g., hand-rolled date formatting when `date-fns` is already in `package.json`).\n   - Utility code that reimplements well-tested standard library functions.\n   - **Note:** Only suggest replacing with libraries *already in the dependency tree*. Do not suggest adding new dependencies.\n\n   **f. Structural bloat:**\n   - Files that exist purely for re-export (barrel files) with no additional logic, where the re-exports could be replaced by direct imports.\n   - Excessive file splitting where closely related code (used together, changed together) is scattered across many small files that could be a single cohesive module.\n   - Boilerplate-heavy patterns that could be reduced with code generation, decorators, or framework conventions.\n\n4. **Cross-reference findings against documentation:**\n   - Before reporting a finding, check if the pattern was an intentional decision documented in specs, ADRs, changelogs, or design docs.\n   - If a verbose pattern exists because of a documented constraint (performance, compatibility, readability preference), **do not flag it**. Note it under \"Intentional Decisions\" instead.\n   - If a finding would change externally-visible behavior (API contracts, output format, error messages), flag it as **Behavior Change Risk** rather than a safe reduction.\n\n5. **Estimate impact:**\n   - For each opportunity, estimate the approximate LOC reduction (net lines removed after the refactor).\n   - Assess risk: Low (pure refactor, no behavior change), Medium (internal behavior change, needs testing), High (external behavior change risk).\n   - Assess effort: Small (\u003C 30 min), Medium (1-2 hours), Large (half-day+).\n\n6. **Cross-reference with git:**\n   - For flagged areas, check `git log` and `git blame` to understand why the code exists in its current form.\n   - Code with recent intentional refactoring history should be flagged with lower confidence.\n   - Code untouched for 6+ months with clear reduction paths gets higher priority.\n\n7. **Verify findings (false-positive filter):**\n   - Before finalizing, re-read the actual source code for every finding. For each one, confirm:\n     - The \"duplicate\" code is genuinely duplicated — not just structurally similar with important semantic differences.\n     - The \"unnecessary wrapper\" doesn't handle edge cases, logging, error transformation, or other subtle behavior you missed on first read.\n     - The \"verbose pattern\" replacement is actually equivalent — same behavior for all inputs, including edge cases.\n     - The \"redundant check\" is genuinely redundant — the upstream validation actually covers all cases the downstream check handles.\n     - The suggested library replacement produces identical output for all relevant inputs.\n     - The reduction **preserves all existing functionality** unless the current behavior is a clear, demonstrable bug.\n   - **Drop any finding you cannot re-confirm with a second read.** If uncertain, move it to \"Needs Investigation\" rather than recommending removal.\n\n## Output\n\n### Summary\n- **Total opportunities found**: N\n- **Estimated total LOC reduction**: ~N lines\n- **Risk breakdown**: N low \u002F N medium \u002F N high\n\n### High-Value Reductions (low risk, high LOC savings)\n| Location | Category | Current LOC | Est. Savings | Risk | Description |\n|----------|----------|-------------|--------------|------|-------------|\n| `path\u002Ffile.ts:20-85` | Duplication | 65 | ~40 | Low | Consolidate into shared helper |\n\nFor each high-value finding, include:\n- **Current code**: brief description or snippet of the verbose\u002Fduplicated pattern\n- **Proposed approach**: how to reduce it\n- **Why it's safe**: what guarantees functionality is preserved\n\n### Medium-Value Reductions\nSame table format — moderate savings or moderate risk.\n\n### Low-Value Reductions\nBrief list — small savings, worth tracking but not urgent.\n\n### Behavior Change Risk\nOpportunities that would reduce code but may alter externally-visible behavior. Each includes:\n- What would change\n- Why it might be acceptable (e.g., fixing a likely bug)\n- What testing would be needed to confirm safety\n\n### Intentional Decisions (no action)\nVerbose patterns that exist for documented reasons — not flagged as issues.\n\n### Needs Investigation\nItems that look reducible but have ambiguous usage patterns or unclear intent. Each includes what specifically needs to be investigated.\n\n## Constraints\n- Use subagents to parallelize analysis across packages in a monorepo.\n- **Never automatically modify code** — only report findings and recommendations.\n- **Functionality preservation is the top priority.** Every recommendation must preserve existing behavior unless the current behavior is a clear, demonstrable bug. When in doubt, classify as \"Behavior Change Risk\" rather than recommending removal.\n- Do not recommend reductions that trade LOC for readability — if the verbose version is clearer, it stays.\n- Do not recommend adding new dependencies to replace hand-rolled code. Only suggest replacements using libraries already in the dependency tree.\n- Do not flag test code for reduction unless the reduction clearly improves test maintainability (e.g., shared fixtures reducing update burden).\n- Do not flag configuration files, migration files, or generated code.\n- Be specific — always include file paths and line numbers or ranges.\n- Every recommendation must include a concrete \"proposed approach,\" not just \"simplify this.\"\n- Prefer many small, independent reductions over large sweeping refactors — smaller changes are safer and easier to review.\n- If the codebase has no specs or documentation, proceed with the audit but note the absence and increase the confidence threshold for recommendations.\n\n\n## Alignment Page\n\nFollow the shared alignment-page convention via the packaged convention resolver; output path is `alignment\u002Fslim-audit-{topic}.html`.\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n",{"name":5,"type":26,"version":36,"description":7,"argument-hint":37,"required_conventions":38},"v0.1","[optional: specific package, directory, or file to scope the audit]",[39],"alignment-page","master","96e2912af886dd1606b1b97df707715aef062b02","packs\u002Fcode-review\u002Fclaude\u002Fslim-audit",0,"https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills","https:\u002F\u002Fagentic-skills-blush.vercel.app","https:\u002F\u002Fgithub.com\u002FGeorgeQLe","georgeqle.com","George Le is a futurist and serial tech entrepreneur who wants to work toward a world where humanity is free from robotic tasks.","2026-11-10 04:07:24",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add GeorgeQLe\u002Fagentic-skills --skill slim-audit",{"tool":56,"command":57},"bunx","bunx skills add GeorgeQLe\u002Fagentic-skills --skill slim-audit",{"tool":59,"command":60},"pnpm","pnpm dlx skills add GeorgeQLe\u002Fagentic-skills --skill slim-audit","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fcode-review\u002Fclaude\u002Fslim-audit\u002FSKILL.md",true,[64,70],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"ALIGNMENT-PAGE.md","REFERENCE","参考文档",53161,"https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fcode-review\u002Fclaude\u002Fslim-audit\u002FALIGNMENT-PAGE.md",{"path":71,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":72,"sourceHtmlUrl":73},"CHANGELOG.md",311,"https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fcode-review\u002Fclaude\u002Fslim-audit\u002FCHANGELOG.md",[75,87,97,109,124,135],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":31},"01M6G0NJES15RJKZE6YZ0TSYGF","source-checkout-allowed","Valid source-checkout-only fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fsource-checkout-allowed\u002FSKILL.md",[],[82,83,84,85,29,86],"source checkout allowed","checkout","fixture","only","valid",{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":31},"01M6G0NFZ3R1MNB1E3DVTM0WB7","deck-install-valid","Valid deck install fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fdeck-install\u002FSKILL.md",[],[94,95,96,86,84,29],"deck install valid","deck","install",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":31},"01M6G0ND3QZQC4MDZ9NVB97PT2","codex-pack-guard-valid","Valid Codex Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-pack-guard\u002FSKILL.md",[],[104,105,106,86,107,108,84,29],"codex pack guard valid","pack","guard","codex","availability",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":120,"publishedAt":31},"01M6G0NA9YB3NKGZKD3S96JMNB","codex-missing-skill-valid","Valid Codex missing skill fallback fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-missing-skill-fallback\u002FSKILL.md",[115],{"categoryNo":116,"categoryName":117,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[121,122,86,107,29,123,84],"codex missing skill valid","missing","fallback",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":131,"publishedAt":31},"01M6G0N7PC0EKFD40ZWQAXSAQ9","codex-base-skill-fallback-valid","Valid Codex base skill fallback fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-base-skill-fallback\u002FSKILL.md",[130],{"categoryNo":116,"categoryName":117,"taxonomyType":118,"taxonomyTypeDesc":119},[86,107,123,132,133,134,29,84],"base skill","codex base skill fallback valid","base",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":141,"publishedAt":31},"01M6G0N4VRR2YKZQ6N3Y6S2BQA","claude-pack-guard-valid","Valid Claude Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fclaude-pack-guard\u002FSKILL.md",[],[86,106,105,142,108,29,84],"claude pack guard valid"]