[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FXG3ME4JCK62AHS5SQXRW4":3,"skill-same:01M6FXG3ME4JCK62AHS5SQXRW4":104},{"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":34,"publishedAt":55,"linkOnly":56,"markdownContent":57,"markdownBody":58,"frontMatter":59,"refName":66,"commitSha":67,"skillDirectory":68,"forksCount":69,"repositoryHtmlUrl":70,"repositoryHomepageUrl":71,"ownerHtmlUrl":72,"ownerBlogUrl":73,"ownerDescription":74,"updatedAt":75,"install":76,"resources":89},"01M6FXG3ME4JCK62AHS5SQXRW4","take-inspiration",null,"Study one specific product or reference through an approved lens, synthesize it against the current design tree, and recommend owner-routed design actions","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\u002Fproduct-design\u002Fclaude\u002Ftake-inspiration\u002FSKILL.md",[18,23,26,31],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",{"categoryNo":32,"categoryName":33,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"take","take inspiration","reference","research","lens","app","pattern","synthesize","study","document","alignment","product","design","design tree","v0","interview","page","site","loop","actions","2026-11-10 10:12:30",false,"---\nname: take-inspiration\ndescription: Study one specific product or reference through an approved lens, synthesize it against the current design tree, and recommend owner-routed design actions\ntype: research\nversion: v0.0\nrequired_conventions: [alignment-page, design-tree-loop]\nargument-hint: \"\u003Creference product\u002Fsite\u002Fapp\u002Fpattern> [optional: topic, surface, or lens]\"\ncontext_intake: interview\nvisual_tier: document\ninvocation: optional-amendment\n---\n\n# Take Inspiration\n\nInvoke as `\u002Ftake-inspiration`.\n\nReference-specific product-design study for when the user names one product, site, app, workflow, pattern, or visual reference and wants to understand what to adopt, adapt, reject, or route into the design tree. Unlike `\u002Fbrainstorm-inspirations`, this skill does not survey many candidates. It interrogates why this reference matters, researches it through an approved lens, and synthesizes findings against existing design-tree artifacts.\n\nFollow `DESIGN-TREE-LOOP.md` for design-tree state, approval boundaries, and routing constraints. `take-inspiration` is an optional feeder\u002Famendment skill, **not** a fixed route position. It writes approved evidence into the scoped flow-tree manifest `source_artifacts[]` only; do not add new manifest schema fields.\n\n## Reference-Lens Interrogation\n\nBefore research, ask why the user chose the reference. Cover the relevant lenses without forcing all of them:\n\n- visual style, brand identity, color, typography, spacing, illustration, imagery, or motion\n- tone, copy, onboarding speed, first-value path, trust cues, or perceived quality\n- workflow, support flow, settings, collaboration, permissioning, data display, IA, or navigation\n- components, interaction patterns, state handling, empty\u002Floading\u002Ferror states, or responsive behavior\n- what the user explicitly does **not** want to copy\n\nIf the user only names a reference and says \"use it as inspiration,\" ask the lens questions before proposing research scope. Do not infer a full design direction from the reference name alone.\n\n## Report-First Approval Gate\n\nDefault to scope-first approval. Before synthesized research, inspect enough repository and design-tree context to propose the reference lens, source plan, assumptions, output paths, and approval questions in a `review` alignment page plus a concise conversation summary.\n\nDo not perform synthesized research, make adopt\u002Fadapt\u002Freject recommendations, or write working packets or canonical deliverables until final compiled YAML approves the reference-study scope. Minimal pre-approval discovery may identify available files, source categories, reference availability, design-tree state, and open questions; label it as scope evidence, not findings.\n\nAfter approved scope YAML, research the chosen reference through the approved lens and write only the non-canonical working packet. Then update the `review` alignment page with reference findings, design-tree synthesis, and proposed COAs. Stop again for feedback-only YAML or final compiled YAML artifact approval before creating or updating canonical research, design, task, or alignment files.\n\n## Design-Tree Context\n\nRead current design-tree context before proposing the research scope:\n\n- `design\u002F**\u002Fflow-tree-*.yaml`\n- `design\u002Fuser-flow-*.md`, `design\u002Fux-variations-*.md`, `design\u002Fui-*.md`, `design\u002Fui-requirements-*.md`, and scoped equivalents\n- existing prototypes, mockups, screenshots, routes, component systems, design-system docs, and relevant research\n- approved `design\u002Fbrainstorm-inspirations-*.md` and `design\u002Ftake-inspiration-*.md` artifacts when present\n\nUse `research\u002F.progress.yaml` only when the reference study would create or compare a materially different product path or product line. Ordinary UX branch state lives in `design\u002F**\u002Fflow-tree-*.yaml`.\n\n## Staged Research Workflow\n\n1. **Stage 1 - Scope discovery and approval.** Interrogate the reference lens, inspect enough design-tree context, and build `alignment\u002Ftake-inspiration-{topic}-{reference}.html`. The page must render the chosen reference, why the user chose it, approved\u002Fdenied lenses, available source categories, design-tree inputs, proposed working-packet and canonical output paths, and research-scope approval gates. Stop for final compiled YAML approval of the research scope.\n2. **Stage 2 - Research and artifact review.** Only after approved scope YAML with no unresolved negative feedback, research the chosen reference through the approved lens and write only `research\u002F_working\u002Fpreliminary-take-inspiration-{topic}-{reference}.md` or `research\u002F{slug}\u002F_working\u002Fpreliminary-take-inspiration-{topic}-{reference}.md`. Update the alignment page as a structured reference-study board with evidence, screenshots\u002Flinks when available, source confidence, design-tree synthesis, and COA gates. Raw Markdown may appear only as a supplemental source view after the rendered review UI.\n3. **Stage 3 - Finalize approved artifacts.** Consume final compiled YAML only when it has no unresolved negative feedback. Apply approved edits first, archive the working packet, remove the active working packet, write the approved canonical artifact to `design\u002Ftake-inspiration-{topic}-{reference}.md` or `design\u002F{slug}\u002Ftake-inspiration-{topic}-{reference}.md`, reference that artifact from the scoped flow-tree manifest `source_artifacts[]`, and convert the alignment page to `confirmed` with the approval record preserved.\n\n## Synthesis And COAs\n\nSynthesize the reference against the existing design tree. Recommended courses of action may include:\n\n- adopt a pattern or principle as-is\n- adapt a pattern to fit current constraints\n- reject a reference aspect and state why\n- add a branch\n- revise a branch\n- prune a branch\n- update the design system\n- refactor UI\u002Fprototype work\n- route to a downstream or owning skill\n\nActual canonical tree mutations still go through the owning design-tree skill and its approval gate. This skill recommends owner-routed actions; it does not directly rewrite user-flow, UX variation, UI, prototype, or spec artifacts except for its own approved reference-study artifact and `source_artifacts[]` link.\n\n## Process\n\n1. **Resolve reference and topic.** Use `$ARGUMENTS` to identify the reference and any topic, surface, product path, UX branch, or lens. Normalize the reference slug for filenames.\n2. **Interrogate the why.** Ask focused lens questions until the study scope is explicit enough to research.\n3. **Read local context.** Locate relevant flow-tree manifests and design artifacts. Identify locked decisions, open branches, UI\u002Fprototype state, and design-system constraints.\n4. **Seek scope approval.** Present the reference lens, source plan, output paths, and gates in the Stage 1 alignment page. Stop for approved compiled YAML.\n5. **Research the reference.** After approval, gather source evidence for the chosen lens. Use official\u002Fproduct sources, public docs, screenshots, teardowns, support docs, app-store\u002Fweb listings, or credible third-party analysis as appropriate. Separate observed evidence from inference.\n6. **Synthesize against the tree.** Compare the reference to current artifacts and recommend COAs with owner routing, rationale, risk, and confidence.\n7. **Finalize after approval.** After final artifact approval, archive the working packet, write the canonical artifact, update `source_artifacts[]`, confirm the alignment page, and route to the owning design-tree skill for any actual mutation.\n\n## Output\n\nStage 1 output is only `alignment\u002Ftake-inspiration-{topic}-{reference}.html` in `review` state and a concise request for final compiled YAML approving scope.\n\nStage 2 output is the working packet, raw search\u002Fsource log, and updated structured reference-study page.\n\nStage 3 output is the approved canonical artifact at `design\u002Ftake-inspiration-{topic}-{reference}.md` or `design\u002F{slug}\u002Ftake-inspiration-{topic}-{reference}.md`. The artifact must include reference, user-stated lens, design-tree inputs, source evidence, observed-vs-inferred findings, COA recommendations, owner routing, risks, confidence, and `source_artifacts[]` update note. End with:\n\n```md\n**Reference:** \u003Cproduct \u002F site \u002F app \u002F pattern>\n**Study lens:** \u003Capproved lens>\n**Flow-tree reference:** \u003Cdesign\u002F**\u002Fflow-tree-*.yaml or none>\n**Source artifact:** \u003Cdesign\u002F...\u002Ftake-inspiration-{topic}-{reference}.md>\n**Recommended owner:** \u003Cowning design-tree skill or none>\n```\n\n## Constraints\n\n- **Reference specificity.** Study one primary reference per run. Use `\u002Fbrainstorm-inspirations` when the user wants a broad candidate survey.\n- **Approval before depth.** Do not do deep research before the user approves the reference lens and scope.\n- **Structured board required.** The alignment page must render evidence, synthesis, and COA gates as structured HTML, not raw Markdown-only.\n- **No copying claim.** Do not claim pixel-perfect reproduction or imply proprietary assets can be copied.\n- Do not add this skill to the fixed flow-tree `route` tuple.\n- Do not create new flow-tree schema fields for inspirations; use `source_artifacts[]`.\n- Do not use `research\u002F.progress.yaml` for ordinary UX branch state.\n\n## Alignment Page\n\nFollow the shared alignment-page convention via the packaged convention resolver; output path is `alignment\u002Ftake-inspiration-{topic}-{reference}.html`.\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n","# Take Inspiration\n\nInvoke as `\u002Ftake-inspiration`.\n\nReference-specific product-design study for when the user names one product, site, app, workflow, pattern, or visual reference and wants to understand what to adopt, adapt, reject, or route into the design tree. Unlike `\u002Fbrainstorm-inspirations`, this skill does not survey many candidates. It interrogates why this reference matters, researches it through an approved lens, and synthesizes findings against existing design-tree artifacts.\n\nFollow `DESIGN-TREE-LOOP.md` for design-tree state, approval boundaries, and routing constraints. `take-inspiration` is an optional feeder\u002Famendment skill, **not** a fixed route position. It writes approved evidence into the scoped flow-tree manifest `source_artifacts[]` only; do not add new manifest schema fields.\n\n## Reference-Lens Interrogation\n\nBefore research, ask why the user chose the reference. Cover the relevant lenses without forcing all of them:\n\n- visual style, brand identity, color, typography, spacing, illustration, imagery, or motion\n- tone, copy, onboarding speed, first-value path, trust cues, or perceived quality\n- workflow, support flow, settings, collaboration, permissioning, data display, IA, or navigation\n- components, interaction patterns, state handling, empty\u002Floading\u002Ferror states, or responsive behavior\n- what the user explicitly does **not** want to copy\n\nIf the user only names a reference and says \"use it as inspiration,\" ask the lens questions before proposing research scope. Do not infer a full design direction from the reference name alone.\n\n## Report-First Approval Gate\n\nDefault to scope-first approval. Before synthesized research, inspect enough repository and design-tree context to propose the reference lens, source plan, assumptions, output paths, and approval questions in a `review` alignment page plus a concise conversation summary.\n\nDo not perform synthesized research, make adopt\u002Fadapt\u002Freject recommendations, or write working packets or canonical deliverables until final compiled YAML approves the reference-study scope. Minimal pre-approval discovery may identify available files, source categories, reference availability, design-tree state, and open questions; label it as scope evidence, not findings.\n\nAfter approved scope YAML, research the chosen reference through the approved lens and write only the non-canonical working packet. Then update the `review` alignment page with reference findings, design-tree synthesis, and proposed COAs. Stop again for feedback-only YAML or final compiled YAML artifact approval before creating or updating canonical research, design, task, or alignment files.\n\n## Design-Tree Context\n\nRead current design-tree context before proposing the research scope:\n\n- `design\u002F**\u002Fflow-tree-*.yaml`\n- `design\u002Fuser-flow-*.md`, `design\u002Fux-variations-*.md`, `design\u002Fui-*.md`, `design\u002Fui-requirements-*.md`, and scoped equivalents\n- existing prototypes, mockups, screenshots, routes, component systems, design-system docs, and relevant research\n- approved `design\u002Fbrainstorm-inspirations-*.md` and `design\u002Ftake-inspiration-*.md` artifacts when present\n\nUse `research\u002F.progress.yaml` only when the reference study would create or compare a materially different product path or product line. Ordinary UX branch state lives in `design\u002F**\u002Fflow-tree-*.yaml`.\n\n## Staged Research Workflow\n\n1. **Stage 1 - Scope discovery and approval.** Interrogate the reference lens, inspect enough design-tree context, and build `alignment\u002Ftake-inspiration-{topic}-{reference}.html`. The page must render the chosen reference, why the user chose it, approved\u002Fdenied lenses, available source categories, design-tree inputs, proposed working-packet and canonical output paths, and research-scope approval gates. Stop for final compiled YAML approval of the research scope.\n2. **Stage 2 - Research and artifact review.** Only after approved scope YAML with no unresolved negative feedback, research the chosen reference through the approved lens and write only `research\u002F_working\u002Fpreliminary-take-inspiration-{topic}-{reference}.md` or `research\u002F{slug}\u002F_working\u002Fpreliminary-take-inspiration-{topic}-{reference}.md`. Update the alignment page as a structured reference-study board with evidence, screenshots\u002Flinks when available, source confidence, design-tree synthesis, and COA gates. Raw Markdown may appear only as a supplemental source view after the rendered review UI.\n3. **Stage 3 - Finalize approved artifacts.** Consume final compiled YAML only when it has no unresolved negative feedback. Apply approved edits first, archive the working packet, remove the active working packet, write the approved canonical artifact to `design\u002Ftake-inspiration-{topic}-{reference}.md` or `design\u002F{slug}\u002Ftake-inspiration-{topic}-{reference}.md`, reference that artifact from the scoped flow-tree manifest `source_artifacts[]`, and convert the alignment page to `confirmed` with the approval record preserved.\n\n## Synthesis And COAs\n\nSynthesize the reference against the existing design tree. Recommended courses of action may include:\n\n- adopt a pattern or principle as-is\n- adapt a pattern to fit current constraints\n- reject a reference aspect and state why\n- add a branch\n- revise a branch\n- prune a branch\n- update the design system\n- refactor UI\u002Fprototype work\n- route to a downstream or owning skill\n\nActual canonical tree mutations still go through the owning design-tree skill and its approval gate. This skill recommends owner-routed actions; it does not directly rewrite user-flow, UX variation, UI, prototype, or spec artifacts except for its own approved reference-study artifact and `source_artifacts[]` link.\n\n## Process\n\n1. **Resolve reference and topic.** Use `$ARGUMENTS` to identify the reference and any topic, surface, product path, UX branch, or lens. Normalize the reference slug for filenames.\n2. **Interrogate the why.** Ask focused lens questions until the study scope is explicit enough to research.\n3. **Read local context.** Locate relevant flow-tree manifests and design artifacts. Identify locked decisions, open branches, UI\u002Fprototype state, and design-system constraints.\n4. **Seek scope approval.** Present the reference lens, source plan, output paths, and gates in the Stage 1 alignment page. Stop for approved compiled YAML.\n5. **Research the reference.** After approval, gather source evidence for the chosen lens. Use official\u002Fproduct sources, public docs, screenshots, teardowns, support docs, app-store\u002Fweb listings, or credible third-party analysis as appropriate. Separate observed evidence from inference.\n6. **Synthesize against the tree.** Compare the reference to current artifacts and recommend COAs with owner routing, rationale, risk, and confidence.\n7. **Finalize after approval.** After final artifact approval, archive the working packet, write the canonical artifact, update `source_artifacts[]`, confirm the alignment page, and route to the owning design-tree skill for any actual mutation.\n\n## Output\n\nStage 1 output is only `alignment\u002Ftake-inspiration-{topic}-{reference}.html` in `review` state and a concise request for final compiled YAML approving scope.\n\nStage 2 output is the working packet, raw search\u002Fsource log, and updated structured reference-study page.\n\nStage 3 output is the approved canonical artifact at `design\u002Ftake-inspiration-{topic}-{reference}.md` or `design\u002F{slug}\u002Ftake-inspiration-{topic}-{reference}.md`. The artifact must include reference, user-stated lens, design-tree inputs, source evidence, observed-vs-inferred findings, COA recommendations, owner routing, risks, confidence, and `source_artifacts[]` update note. End with:\n\n```md\n**Reference:** \u003Cproduct \u002F site \u002F app \u002F pattern>\n**Study lens:** \u003Capproved lens>\n**Flow-tree reference:** \u003Cdesign\u002F**\u002Fflow-tree-*.yaml or none>\n**Source artifact:** \u003Cdesign\u002F...\u002Ftake-inspiration-{topic}-{reference}.md>\n**Recommended owner:** \u003Cowning design-tree skill or none>\n```\n\n## Constraints\n\n- **Reference specificity.** Study one primary reference per run. Use `\u002Fbrainstorm-inspirations` when the user wants a broad candidate survey.\n- **Approval before depth.** Do not do deep research before the user approves the reference lens and scope.\n- **Structured board required.** The alignment page must render evidence, synthesis, and COA gates as structured HTML, not raw Markdown-only.\n- **No copying claim.** Do not claim pixel-perfect reproduction or imply proprietary assets can be copied.\n- Do not add this skill to the fixed flow-tree `route` tuple.\n- Do not create new flow-tree schema fields for inspirations; use `source_artifacts[]`.\n- Do not use `research\u002F.progress.yaml` for ordinary UX branch state.\n\n## Alignment Page\n\nFollow the shared alignment-page convention via the packaged convention resolver; output path is `alignment\u002Ftake-inspiration-{topic}-{reference}.html`.\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n",{"name":5,"type":38,"version":60,"invocation":61,"description":7,"visual_tier":44,"argument-hint":62,"context_intake":50,"required_conventions":63},"v0.0","optional-amendment","\u003Creference product\u002Fsite\u002Fapp\u002Fpattern> [optional: topic, surface, or lens]",[64,65],"alignment-page","design-tree-loop","master","96e2912af886dd1606b1b97df707715aef062b02","packs\u002Fproduct-design\u002Fclaude\u002Ftake-inspiration",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":77,"prompt":87,"zipAvailable":88},[78,81,84],{"tool":79,"command":80},"npx","npx skills add GeorgeQLe\u002Fagentic-skills --skill take-inspiration",{"tool":82,"command":83},"bunx","bunx skills add GeorgeQLe\u002Fagentic-skills --skill take-inspiration",{"tool":85,"command":86},"pnpm","pnpm dlx skills add GeorgeQLe\u002Fagentic-skills --skill take-inspiration","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fproduct-design\u002Fclaude\u002Ftake-inspiration\u002FSKILL.md",true,[90,96,100],{"path":91,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":94,"sourceHtmlUrl":95},"ALIGNMENT-PAGE.md","REFERENCE","参考文档",54304,"https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fproduct-design\u002Fclaude\u002Ftake-inspiration\u002FALIGNMENT-PAGE.md",{"path":97,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":98,"sourceHtmlUrl":99},"CHANGELOG.md",440,"https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fproduct-design\u002Fclaude\u002Ftake-inspiration\u002FCHANGELOG.md",{"path":101,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":102,"sourceHtmlUrl":103},"DESIGN-TREE-LOOP.md",44814,"https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fproduct-design\u002Fclaude\u002Ftake-inspiration\u002FDESIGN-TREE-LOOP.md",[105,117,127,139,152,163],{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":55},"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",[],[112,113,114,115,49,116],"source checkout allowed","checkout","fixture","only","valid",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":55},"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",[],[124,125,126,116,114,49],"deck install valid","deck","install",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":55},"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",[],[134,135,136,116,137,138,114,49],"codex pack guard valid","pack","guard","codex","availability",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":148,"publishedAt":55},"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",[145],{"categoryNo":146,"categoryName":147,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[149,150,116,137,49,151,114],"codex missing skill valid","missing","fallback",{"skillNo":153,"name":154,"nameZh":6,"description":155,"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":55},"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",[158],{"categoryNo":146,"categoryName":147,"taxonomyType":21,"taxonomyTypeDesc":22},[116,137,151,160,161,162,49,114],"base skill","codex base skill fallback valid","base",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"publishedAt":55},"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",[],[116,136,135,170,138,49,114],"claude pack guard valid"]