[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FX56FVTNHYB3A47E24CMGP":3,"skill-same:01M6FX56FVTNHYB3A47E24CMGP":67},{"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":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":48,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6FX56FVTNHYB3A47E24CMGP","consolidate-variations",null,"Compare multiple built UI variations, interview the user on what works and what doesn't, cherry-pick best elements, resolve conflicts, and produce a final consolidated implementation-ready UI specification","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\u002Fconsolidate-prototypes\u002Farchive\u002Fv0.2\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35],"consolidate variations","consolidate","ready","compare","elements","specification","conflicts","implementation","resolve conflicts","planning","v0","interview","user","pick","page","ui","produce","2026-11-10 10:12:30",false,"---\nname: consolidate-variations\ndescription: Compare multiple built UI variations, interview the user on what works and what doesn't, cherry-pick best elements, resolve conflicts, and produce a final consolidated implementation-ready UI specification\ntype: planning\nversion: v0.2\nargument-hint: \"[optional: topic, page, or path to variation specs]\"\n---\n\n# Consolidate Variations\n\nInvoke as `\u002Fconsolidate-variations`.\n\nUse this skill after the user has built and evaluated multiple UI layout variations (typically generated via `\u002Fux-variations --layout-mode`, built via `\u002Fexec`, and evaluated via `\u002Fuat --variant-evaluation` (check `.agents\u002Fproject.json.enabled_packs` for `product-testing` — if `product-testing` is not enabled, recommend `\u002Fpack install product-testing` first)). This skill compares the variations, interviews the user on what works and what doesn't in each one, cherry-picks the best elements, resolves conflicts where preferred choices are incompatible, and produces a single consolidated implementation-ready UI specification.\n\nUsers with manually built variations (not from the `\u002Fux-variations` pipeline) can also use this skill directly, but consolidation should not happen before the user has reviewed the variants and captured evidence.\n\n## Workflow\n\n1. **Resolve context**\n   - Read `.agents\u002Fproject.json` if it exists.\n   - Read `README.md`, `AGENTS.md`, `CLAUDE.md`, relevant `docs\u002F`, `specs\u002F`, `research\u002F`, route files, component directories, and design artifacts when present.\n   - Locate the variation spec: `specs\u002Fui-layout-variations-[topic].md` or `specs\u002Fux-variations-[topic].md`.\n   - Locate the content requirements: `specs\u002Fui-requirements-[topic].md` or equivalent content contract.\n   - Locate variant evaluation evidence: `research\u002Fuat-variant-evaluation-[topic].md`, `research\u002Fuat-plan.md` result logs, screenshots, notes, recordings, or explicit user-provided review notes.\n   - Locate built implementations: scan route files, component directories, and any variation-specific directories or branches.\n   - If the variation spec or implementations cannot be found, ask the user to point to them.\n\n2. **Evidence gate**\n   - If no evaluation evidence exists and the user has not explicitly said they already reviewed the variants and is ready to converge, stop and recommend `\u002Fuat --variant-evaluation` (check `.agents\u002Fproject.json.enabled_packs` for `product-testing` — if `product-testing` is not enabled, recommend `\u002Fpack install product-testing` first).\n   - Do not infer a winner from specs alone. Built variants need hands-on review or explicit user readiness before consolidation.\n   - If some variants are unreviewed, ask whether to exclude them, evaluate them first via `\u002Fuat --variant-evaluation` (check `.agents\u002Fproject.json.enabled_packs` for `product-testing` — if `product-testing` is not enabled, recommend `\u002Fpack install product-testing` first), or include them as spec-only references.\n\n3. **Present variation inventory**\n   - List each variation with a one-line summary of its approach.\n   - Note build status for each: built and reviewed, built but unreviewed, partially built, spec-only.\n   - Note evidence status for each: result log present, user notes present, no evidence.\n   - Use AskUserQuestion to confirm which variations the user has reviewed and wants to evaluate. Skip unreviewed or unbuilt variations unless the user wants to include them from spec alone.\n\n4. **Interview per variation**\n   - For each reviewed variation, ask using AskUserQuestion (1–3 questions per turn):\n     - What works well in this variation? Name specific elements, regions, or interactions.\n     - What doesn't work? What feels wrong, cluttered, sparse, or confusing?\n     - Any specific component, region, or interaction you want to keep in the final design?\n     - Anything to explicitly reject — never use this approach?\n   - Record responses as structured annotations per variation:\n     - **Keep**: elements the user wants in the final design (with source variation)\n     - **Reject**: elements the user never wants (with source variation)\n     - **Neutral**: elements the user has no strong opinion on\n\n5. **Cross-variation synthesis**\n   - Present a **Consolidation Matrix** showing each design dimension and which variation's approach the user preferred:\n\n   | Design Element | Variation A | Variation B | Variation C | Winner |\n   |---|---|---|---|---|\n   | Container pattern | card grid | data table | list+detail | ? |\n   | Detail view | modal | sidebar | full-page | ? |\n   | Navigation | top-nav | side-nav | tabs | ? |\n   | ... | ... | ... | ... | ... |\n\n   - Fill in winners based on the interview. Mark conflicts where preferred choices from different dimensions are incompatible (e.g., user wants sidebar detail from Variation B but also wants the full-width card grid from Variation A — these compete for horizontal space).\n   - For each conflict:\n     - Present the tension clearly\n     - Offer 2–3 resolution options with tradeoffs\n     - State a recommendation\n     - Use AskUserQuestion to resolve\n   - Continue until every row in the matrix has a winner and all conflicts are resolved.\n\n6. **Build consolidated prototype**\n   - Merge the best elements from variation prototypes into a single runnable artifact at `prototypes\u002F{topic}\u002Fconsolidated\u002F`.\n   - The consolidated prototype must reflect:\n     - Layout skeleton (regions, proportions, scroll behavior)\n     - Primary content pattern (how items are displayed)\n     - Detail view pattern (how full item details are accessed)\n     - Navigation pattern and placement\n     - Action placement (create, edit, delete, bulk, contextual)\n     - Density and spacing approach\n     - Responsive behavior at mobile, tablet, and desktop breakpoints\n     - States rendering (empty, loading, error, partial, offline)\n   - Use AskUserQuestion to confirm the consolidated design before building the prototype.\n\n7. **Coverage checkpoint**\n   - Verify every content requirement from `specs\u002Fui-requirements-[topic].md` has a UI home in the consolidated spec.\n   - Verify every user action has a placement (button, menu item, keyboard shortcut, or gesture).\n   - Verify all states (empty, loading, error, partial, full, offline, permission-denied) are accounted for.\n   - Flag any gaps and resolve via AskUserQuestion before writing.\n\n## Deliverables\n\n- Write the consolidated prototype to `prototypes\u002F{topic}\u002Fconsolidated\u002F`.\n- Write the consolidation interview log to `consolidate-variations-[topic]-interview.md`.\n\n### Alignment Page\n\nFollow the shared Alignment Page convention in CLAUDE.md. Output: `alignment\u002Fconsolidate-variations-{topic}.html`.\n\n## Constraints\n\n- Do not proceed without evaluation evidence unless the user explicitly says they have reviewed the variants and is ready to converge.\n- Do not pick winners without user input. Present the matrix and let the user decide.\n- Do not ignore conflicts. If two preferred choices are spatially or functionally incompatible, surface the tension and resolve it explicitly.\n- The consolidated spec must be at least as detailed as a `\u002Fui-interview` output — implementation-ready, not a summary.\n- Do not lose content requirements. Every data field, action, and state from the requirements spec must appear in the final design.\n- Do not bias toward the first or last variation reviewed. Present them neutrally and let the user's feedback drive the outcome.\n- When recommending a skill from another pack, verify the pack is installed via `.agents\u002Fproject.json` `enabled_packs`. If not installed, prepend `\u002Fpack install \u003Cpack-name>` to the recommendation.\n\n## Archive-First Replacement Policy\n\n- Before replacing or substantively rewriting an existing canonical research\u002Fspec document (`research\u002F**\u002F*.md`, `specs\u002F**\u002F*.md`, or `docs\u002Fspecifications\u002F**\u002F*.md`), copy the current file to `docs\u002Fhistory\u002Farchive\u002FYYYY-MM-DD\u002FHHMMSS\u002F\u003Coriginal-relative-path>`.\n- Preserve the archived snapshot exactly as it existed before the change; do not edit the archived copy after creating it.\n- After the archive snapshot exists, write the updated document to the original canonical path.\n- Report both the archive path and the updated canonical path in the final output.\n- New files do not need archive snapshots. Append-only updates do not need archive snapshots unless an existing section is regenerated or rewritten.\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n","# Consolidate Variations\n\nInvoke as `\u002Fconsolidate-variations`.\n\nUse this skill after the user has built and evaluated multiple UI layout variations (typically generated via `\u002Fux-variations --layout-mode`, built via `\u002Fexec`, and evaluated via `\u002Fuat --variant-evaluation` (check `.agents\u002Fproject.json.enabled_packs` for `product-testing` — if `product-testing` is not enabled, recommend `\u002Fpack install product-testing` first)). This skill compares the variations, interviews the user on what works and what doesn't in each one, cherry-picks the best elements, resolves conflicts where preferred choices are incompatible, and produces a single consolidated implementation-ready UI specification.\n\nUsers with manually built variations (not from the `\u002Fux-variations` pipeline) can also use this skill directly, but consolidation should not happen before the user has reviewed the variants and captured evidence.\n\n## Workflow\n\n1. **Resolve context**\n   - Read `.agents\u002Fproject.json` if it exists.\n   - Read `README.md`, `AGENTS.md`, `CLAUDE.md`, relevant `docs\u002F`, `specs\u002F`, `research\u002F`, route files, component directories, and design artifacts when present.\n   - Locate the variation spec: `specs\u002Fui-layout-variations-[topic].md` or `specs\u002Fux-variations-[topic].md`.\n   - Locate the content requirements: `specs\u002Fui-requirements-[topic].md` or equivalent content contract.\n   - Locate variant evaluation evidence: `research\u002Fuat-variant-evaluation-[topic].md`, `research\u002Fuat-plan.md` result logs, screenshots, notes, recordings, or explicit user-provided review notes.\n   - Locate built implementations: scan route files, component directories, and any variation-specific directories or branches.\n   - If the variation spec or implementations cannot be found, ask the user to point to them.\n\n2. **Evidence gate**\n   - If no evaluation evidence exists and the user has not explicitly said they already reviewed the variants and is ready to converge, stop and recommend `\u002Fuat --variant-evaluation` (check `.agents\u002Fproject.json.enabled_packs` for `product-testing` — if `product-testing` is not enabled, recommend `\u002Fpack install product-testing` first).\n   - Do not infer a winner from specs alone. Built variants need hands-on review or explicit user readiness before consolidation.\n   - If some variants are unreviewed, ask whether to exclude them, evaluate them first via `\u002Fuat --variant-evaluation` (check `.agents\u002Fproject.json.enabled_packs` for `product-testing` — if `product-testing` is not enabled, recommend `\u002Fpack install product-testing` first), or include them as spec-only references.\n\n3. **Present variation inventory**\n   - List each variation with a one-line summary of its approach.\n   - Note build status for each: built and reviewed, built but unreviewed, partially built, spec-only.\n   - Note evidence status for each: result log present, user notes present, no evidence.\n   - Use AskUserQuestion to confirm which variations the user has reviewed and wants to evaluate. Skip unreviewed or unbuilt variations unless the user wants to include them from spec alone.\n\n4. **Interview per variation**\n   - For each reviewed variation, ask using AskUserQuestion (1–3 questions per turn):\n     - What works well in this variation? Name specific elements, regions, or interactions.\n     - What doesn't work? What feels wrong, cluttered, sparse, or confusing?\n     - Any specific component, region, or interaction you want to keep in the final design?\n     - Anything to explicitly reject — never use this approach?\n   - Record responses as structured annotations per variation:\n     - **Keep**: elements the user wants in the final design (with source variation)\n     - **Reject**: elements the user never wants (with source variation)\n     - **Neutral**: elements the user has no strong opinion on\n\n5. **Cross-variation synthesis**\n   - Present a **Consolidation Matrix** showing each design dimension and which variation's approach the user preferred:\n\n   | Design Element | Variation A | Variation B | Variation C | Winner |\n   |---|---|---|---|---|\n   | Container pattern | card grid | data table | list+detail | ? |\n   | Detail view | modal | sidebar | full-page | ? |\n   | Navigation | top-nav | side-nav | tabs | ? |\n   | ... | ... | ... | ... | ... |\n\n   - Fill in winners based on the interview. Mark conflicts where preferred choices from different dimensions are incompatible (e.g., user wants sidebar detail from Variation B but also wants the full-width card grid from Variation A — these compete for horizontal space).\n   - For each conflict:\n     - Present the tension clearly\n     - Offer 2–3 resolution options with tradeoffs\n     - State a recommendation\n     - Use AskUserQuestion to resolve\n   - Continue until every row in the matrix has a winner and all conflicts are resolved.\n\n6. **Build consolidated prototype**\n   - Merge the best elements from variation prototypes into a single runnable artifact at `prototypes\u002F{topic}\u002Fconsolidated\u002F`.\n   - The consolidated prototype must reflect:\n     - Layout skeleton (regions, proportions, scroll behavior)\n     - Primary content pattern (how items are displayed)\n     - Detail view pattern (how full item details are accessed)\n     - Navigation pattern and placement\n     - Action placement (create, edit, delete, bulk, contextual)\n     - Density and spacing approach\n     - Responsive behavior at mobile, tablet, and desktop breakpoints\n     - States rendering (empty, loading, error, partial, offline)\n   - Use AskUserQuestion to confirm the consolidated design before building the prototype.\n\n7. **Coverage checkpoint**\n   - Verify every content requirement from `specs\u002Fui-requirements-[topic].md` has a UI home in the consolidated spec.\n   - Verify every user action has a placement (button, menu item, keyboard shortcut, or gesture).\n   - Verify all states (empty, loading, error, partial, full, offline, permission-denied) are accounted for.\n   - Flag any gaps and resolve via AskUserQuestion before writing.\n\n## Deliverables\n\n- Write the consolidated prototype to `prototypes\u002F{topic}\u002Fconsolidated\u002F`.\n- Write the consolidation interview log to `consolidate-variations-[topic]-interview.md`.\n\n### Alignment Page\n\nFollow the shared Alignment Page convention in CLAUDE.md. Output: `alignment\u002Fconsolidate-variations-{topic}.html`.\n\n## Constraints\n\n- Do not proceed without evaluation evidence unless the user explicitly says they have reviewed the variants and is ready to converge.\n- Do not pick winners without user input. Present the matrix and let the user decide.\n- Do not ignore conflicts. If two preferred choices are spatially or functionally incompatible, surface the tension and resolve it explicitly.\n- The consolidated spec must be at least as detailed as a `\u002Fui-interview` output — implementation-ready, not a summary.\n- Do not lose content requirements. Every data field, action, and state from the requirements spec must appear in the final design.\n- Do not bias toward the first or last variation reviewed. Present them neutrally and let the user's feedback drive the outcome.\n- When recommending a skill from another pack, verify the pack is installed via `.agents\u002Fproject.json` `enabled_packs`. If not installed, prepend `\u002Fpack install \u003Cpack-name>` to the recommendation.\n\n## Archive-First Replacement Policy\n\n- Before replacing or substantively rewriting an existing canonical research\u002Fspec document (`research\u002F**\u002F*.md`, `specs\u002F**\u002F*.md`, or `docs\u002Fspecifications\u002F**\u002F*.md`), copy the current file to `docs\u002Fhistory\u002Farchive\u002FYYYY-MM-DD\u002FHHMMSS\u002F\u003Coriginal-relative-path>`.\n- Preserve the archived snapshot exactly as it existed before the change; do not edit the archived copy after creating it.\n- After the archive snapshot exists, write the updated document to the original canonical path.\n- Report both the archive path and the updated canonical path in the final output.\n- New files do not need archive snapshots. Append-only updates do not need archive snapshots unless an existing section is regenerated or rewritten.\n\n## Default Shipping Contract\n\nFollow the shared shipping contract convention in CLAUDE.md.\n",{"name":5,"type":28,"version":41,"description":7,"argument-hint":42},"v0.2","[optional: topic, page, or path to variation specs]","master","96e2912af886dd1606b1b97df707715aef062b02","packs\u002Fproduct-design\u002Fclaude\u002Fconsolidate-prototypes\u002Farchive\u002Fv0.2",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":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add GeorgeQLe\u002Fagentic-skills --skill consolidate-variations",{"tool":59,"command":60},"bunx","bunx skills add GeorgeQLe\u002Fagentic-skills --skill consolidate-variations",{"tool":62,"command":63},"pnpm","pnpm dlx skills add GeorgeQLe\u002Fagentic-skills --skill consolidate-variations","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fproduct-design\u002Fclaude\u002Fconsolidate-prototypes\u002Farchive\u002Fv0.2\u002FSKILL.md",true,[],[68,80,90,102,117,128],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":36},"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",[],[75,76,77,78,29,79],"source checkout allowed","checkout","fixture","only","valid",{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":36},"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",[],[87,88,89,79,77,29],"deck install valid","deck","install",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":36},"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",[],[97,98,99,79,100,101,77,29],"codex pack guard valid","pack","guard","codex","availability",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":113,"publishedAt":36},"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",[108],{"categoryNo":109,"categoryName":110,"taxonomyType":111,"taxonomyTypeDesc":112},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[114,115,79,100,29,116,77],"codex missing skill valid","missing","fallback",{"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":124,"publishedAt":36},"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",[123],{"categoryNo":109,"categoryName":110,"taxonomyType":111,"taxonomyTypeDesc":112},[79,100,116,125,126,127,29,77],"base skill","codex base skill fallback valid","base",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":36},"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",[],[79,99,98,135,101,29,77],"claude pack guard valid"]