[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FXY0QZP0KDB4BHX6VFMACS":3,"skill-same:01M6FXY0QZP0KDB4BHX6VFMACS":66},{"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":35,"linkOnly":36,"markdownContent":37,"markdownBody":38,"frontMatter":39,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":45,"repositoryHtmlUrl":46,"repositoryHomepageUrl":47,"ownerHtmlUrl":48,"ownerBlogUrl":49,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6FXY0QZP0KDB4BHX6VFMACS","consolidate-variations",null,"Compare multiple built UI variations after UAT evidence, interview the user on what works and what does not, resolve conflicts, and produce a final 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\u002Fcodex\u002Fconsolidate-prototypes\u002Farchive\u002Fv0.1\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34],"consolidate","consolidate variations","planning","produce","ui","page","user","interview","v0","evidence","ready","resolve conflicts","implementation","conflicts","specification","compare","2026-11-10 10:12:30",false,"---\nname: consolidate-variations\ndescription: Compare multiple built UI variations after UAT evidence, interview the user on what works and what does not, resolve conflicts, and produce a final implementation-ready UI specification\ntype: planning\nversion: v0.1\nargument-hint: \"[optional: topic, page, or path to variation specs]\"\n---\n\n# Consolidate Variations\n\nInvoke as `$consolidate-variations`.\n\nUse this skill after the user has built and evaluated multiple UI layout variations, typically generated via `$ux-variations --layout-mode`, built via `$exec`, and evaluated via `$uat --variant-evaluation`. This skill compares the variations, interviews the user on what works and what does not 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 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 `$uat --variant-evaluation`.\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 `$uat --variant-evaluation`, 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   - Confirm which variations the user wants to consolidate.\n\n4. **Interview per variation**\n   - For each reviewed variation, ask one primary decision question per turn by default. Use short follow-up bullets only when they clarify the same variation decision, not to batch unrelated questions:\n     - What works well in this variation? Name specific elements, regions, or interactions.\n     - What does not work? What feels wrong, cluttered, sparse, or confusing?\n     - Any specific component, region, or interaction to keep in the final design?\n     - Anything to explicitly reject and never use?\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   - Fill in winners based on UAT evidence and interview responses.\n   - Mark conflicts where preferred choices from different dimensions are incompatible.\n   - For each conflict, present the tension, offer 2-3 resolution options with tradeoffs, state a recommendation, and ask the user to resolve it.\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\n     - Detail view pattern\n     - Navigation pattern and placement\n     - Action placement\n     - Density and spacing approach\n     - Responsive behavior at mobile, tablet, and desktop breakpoints\n     - States rendering\n   - Ask the user 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 are accounted for: empty, loading, error, partial, full, offline, permission-denied.\n   - Flag any gaps and resolve them 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 `$ui-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 and evaluation evidence drive the outcome.\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 `$consolidate-variations`.\n\nUse this skill after the user has built and evaluated multiple UI layout variations, typically generated via `$ux-variations --layout-mode`, built via `$exec`, and evaluated via `$uat --variant-evaluation`. This skill compares the variations, interviews the user on what works and what does not 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 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 `$uat --variant-evaluation`.\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 `$uat --variant-evaluation`, 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   - Confirm which variations the user wants to consolidate.\n\n4. **Interview per variation**\n   - For each reviewed variation, ask one primary decision question per turn by default. Use short follow-up bullets only when they clarify the same variation decision, not to batch unrelated questions:\n     - What works well in this variation? Name specific elements, regions, or interactions.\n     - What does not work? What feels wrong, cluttered, sparse, or confusing?\n     - Any specific component, region, or interaction to keep in the final design?\n     - Anything to explicitly reject and never use?\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   - Fill in winners based on UAT evidence and interview responses.\n   - Mark conflicts where preferred choices from different dimensions are incompatible.\n   - For each conflict, present the tension, offer 2-3 resolution options with tradeoffs, state a recommendation, and ask the user to resolve it.\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\n     - Detail view pattern\n     - Navigation pattern and placement\n     - Action placement\n     - Density and spacing approach\n     - Responsive behavior at mobile, tablet, and desktop breakpoints\n     - States rendering\n   - Ask the user 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 are accounted for: empty, loading, error, partial, full, offline, permission-denied.\n   - Flag any gaps and resolve them 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 `$ui-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 and evaluation evidence drive the outcome.\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":21,"version":40,"description":7,"argument-hint":41},"v0.1","[optional: topic, page, or path to variation specs]","master","96e2912af886dd1606b1b97df707715aef062b02","packs\u002Fproduct-design\u002Fcodex\u002Fconsolidate-prototypes\u002Farchive\u002Fv0.1",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":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add GeorgeQLe\u002Fagentic-skills --skill consolidate-variations",{"tool":58,"command":59},"bunx","bunx skills add GeorgeQLe\u002Fagentic-skills --skill consolidate-variations",{"tool":61,"command":62},"pnpm","pnpm dlx skills add GeorgeQLe\u002Fagentic-skills --skill consolidate-variations","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fproduct-design\u002Fcodex\u002Fconsolidate-prototypes\u002Farchive\u002Fv0.1\u002FSKILL.md",true,[],[67,79,89,101,116,127],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":35},"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",[],[74,75,76,77,27,78],"source checkout allowed","checkout","fixture","only","valid",{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":35},"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",[],[86,87,88,78,76,27],"deck install valid","deck","install",{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":35},"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",[],[96,97,98,78,99,100,76,27],"codex pack guard valid","pack","guard","codex","availability",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":112,"publishedAt":35},"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",[107],{"categoryNo":108,"categoryName":109,"taxonomyType":110,"taxonomyTypeDesc":111},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[113,114,78,99,27,115,76],"codex missing skill valid","missing","fallback",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":123,"publishedAt":35},"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",[122],{"categoryNo":108,"categoryName":109,"taxonomyType":110,"taxonomyTypeDesc":111},[78,99,115,124,125,126,27,76],"base skill","codex base skill fallback valid","base",{"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":35},"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",[],[78,98,97,134,100,27,76],"claude pack guard valid"]