[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FXKVECF4PBYZPJ0GTVZ6Y9":3,"skill-same:01M6FXKVECF4PBYZPJ0GTVZ6Y9":78},{"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":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":59,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M6FXKVECF4PBYZPJ0GTVZ6Y9","ui-interview",null,"Interview page by page to define a complete UI specification, including layout, hierarchy, controls, links, spacing, sizing, responsive behavior, visual states, and implementation-ready interface details — supports a requirements-only mode that establishes data, actions, and states without locking layout or component decisions","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\u002Fui-interview\u002Farchive\u002Fv0.4\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000038","人力资源",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"ui","ui interview","interview","define","planning","links","interface","states","controls","complete","app","feature","page","requirements","visual","interface details","ready","only","actions","decisions","2026-11-10 10:12:30",false,"---\nname: ui-interview\ndescription: Interview page by page to define a complete UI specification, including layout, hierarchy, controls, links, spacing, sizing, responsive behavior, visual states, and implementation-ready interface details — supports a requirements-only mode that establishes data, actions, and states without locking layout or component decisions\ntype: planning\nversion: v0.4\nargument-hint: \"[optional: app, page, flow, feature, or draft UI]\"\n---\n\n# UI Interview\n\nInvoke as `\u002Fui-interview`.\n\nUse this skill when the user needs to turn a rough product idea, feature, page, wireframe, screenshot, or existing app surface into a detailed implementation-ready UI specification. This skill focuses on the interface itself: pages, regions, components, buttons, links, labels, spacing, element size, visual hierarchy, state, responsive layout, and accessibility.\n\nUse `\u002Fux-variations` after this skill when the user wants multiple experience concepts or interface variants to compare before locking the final direction.\n\nWhen invoked with `--requirements-only` (or when the user says \"just requirements\", \"requirements only\", or \"content requirements\"), this skill stops after establishing what the page needs — data, actions, states, and constraints — without committing to any layout, component, or spatial decisions. This mode feeds directly into `\u002Fux-variations --layout-mode` to explore multiple concrete visual approaches for the same content contract.\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, screenshots, and design artifacts when present.\n   - If the request is for an existing UI, inspect the current implementation before interviewing.\n   - If multiple apps or surfaces are plausible, ask the user which app, flow, or page to cover first.\n\n2. **Treat inputs as draft material**\n   - Do not assume the current UI, prompt, screenshot, or mockup is final.\n   - Product specs, ICP documents, and journey maps are reference material, not locked constraints. The user may override any product decision during the interview. When a user's interview answer contradicts an existing spec, adopt the interview answer and note the divergence.\n   - Preserve explicit constraints, but challenge unclear defaults before they become implementation decisions.\n   - Distinguish product behavior decisions from UI presentation decisions.\n\n3. **Surface assumptions before probing**\n   - Present a UI Assumptions Manifest before deep questioning.\n   - Tag each assumption with `[from spec]`, `[from codebase]`, `[from research]`, `[from artifact]`, or `[inferred]`.\n   - Cover product and user context, pages and routes, primary tasks, navigation, hierarchy, layout grid, spatial density, component inventory, button and link semantics, form behavior, empty\u002Floading\u002Ferror\u002Fsuccess states, responsive behavior, accessibility, visual language, implementation constraints, and the prototype-first boundary for new product or substantial feature work: what the user should be able to click through first, whether multiple route-based experiments should be built, what data can be fake, fixture-backed, or in-memory, and which infrastructure must be represented visually but not implemented yet.\n   - Use AskUserQuestion to ask the user to confirm, correct, or flag assumptions before continuing.\n\n4. **Interview page by page**\n   - Ask 1 to 3 focused questions per turn using AskUserQuestion.\n   - Move through the interface in this order unless the user asks otherwise:\n     - Global shell: header, sidebar, footer, navigation, account controls, notifications\n     - Page inventory: every route, modal, drawer, overlay, and important empty state\n     - Page purpose: user goal, task priority, and success condition\n     - Prototype calibration: first clickable journey, route-based experiment set, fixture\u002Ffake data boundaries, infrastructure-only states to mock rather than implement, and taste\u002Ffeel questions the prototype must answer before database, auth, payment, analytics, deployment, admin, or multi-tenant work is planned.\n\n4b. **Requirements gate (requirements-only mode)**\n   - In requirements-only mode, stop here — do not proceed to layout anatomy, component inventory, or spatial decisions.\n   - For each page, confirm:\n     - Data fields and entities (with cardinality: one, many, nested, polymorphic)\n     - User actions (create, edit, delete, filter, sort, export, navigate, bulk-select, reorder)\n     - States (empty, loading, error, partial, full, offline, permission-denied)\n     - Constraints (real-time updates, offline support, accessibility requirements, performance budgets)\n     - Content hierarchy (primary \u002F secondary \u002F tertiary information)\n     - Relationships between data elements (parent-child, peer, reference, aggregate)\n   - Present a **Content Requirements Manifest** summarizing all pages, then use AskUserQuestion to confirm before writing deliverables.\n   - Write `specs\u002Fui-requirements-[topic].md` (content requirements) and `ui-requirements-[topic]-interview.md` (interview log).\n   - After writing files, recommend `\u002Fux-variations --layout-mode` to explore multiple visual approaches for these requirements, or `\u002Fui-interview` (full mode, no flag) to proceed directly to a single deep UI specification.\n   - Stop. Do not continue to step 5 or beyond.\n\n5. **Full UI specification** (no `--content-only` flag):\n\n   - Layout anatomy: top-to-bottom and left-to-right regions, alignment, density, scroll behavior\n     - Component inventory: tables, lists, cards, forms, charts, media, editors, maps, canvases\n     - Controls: every button, icon button, segmented control, checkbox, radio, toggle, input, menu, tab, link, and destructive action\n     - Copy: headings, labels, helper text, validation text, confirmation text, empty-state text\n     - States: default, hover, focus, active, selected, disabled, loading, error, success, partial, offline\n     - Spatial details: element prominence, approximate sizes, gaps, padding, fixed or fluid dimensions, sticky regions, overlap rules, max widths\n     - Responsive behavior: desktop, tablet, mobile, wide desktop, touch target sizing, collapsed controls\n     - Accessibility: keyboard order, focus traps, labels, contrast, reduced motion, screen reader names. Include color-blind safe patterns, keyboard navigation, reduced motion support, and screen reader labels by default in every spec. Do not present accessibility features as optional checkboxes. Only ask about domain-specific accessibility (gamepad support, dyslexia fonts) when the product context warrants it.\n   - When a page includes repeated items, define one canonical item and its variations rather than asking about every row individually.\n\n5. **Research and recommend by default**\n   - Use project evidence and established UI conventions before asking the user to invent details.\n   - For material decisions, present options, a recommendation, rationale, tradeoffs, and mitigation.\n   - Recommend familiar controls over novel patterns unless the product has a strong reason to deviate.\n   - Respect the existing design system, component library, and implementation patterns.\n   - Reference and inspiration questions (\"apps you admire?\") are low-priority. Ask once early, accept any answer including \"none\" or \"let's experiment,\" and move on. Do not block the interview on reference input.\n\n6. **Coverage checkpoint**\n   - Before concluding, use AskUserQuestion to present a concise checklist of pages, components, controls, states, responsive behavior, and unresolved risks.\n   - Ask whether anything is missing or should be revisited before writing deliverables.\n\n## Deliverables\n\n- Write the completed UI specification to `specs\u002Fui-[topic].md`.\n- Write the interview log to `ui-[topic]-interview.md`.\n\nThe UI specification must include source evidence, the confirmed UI Assumptions Manifest, page inventory, route map, global shell rules, page-by-page anatomy, component inventory, control inventory, link inventory, layout and responsive rules, visual style direction, interaction states, accessibility requirements, implementation notes, open questions, risks, and non-goals. For new product interfaces or substantial feature interfaces, include a prototype-first section naming the first clickable journey, experiment route map when multiple alternatives should be tested, fake\u002Ffixture data, visually mocked infrastructure states, deferred production infrastructure, and the evidence required before implementation planning promotes any deferred infrastructure.\n\nThe interview log must include the manifest, every question asked, options and recommendations presented, user responses, final decisions, and notable changes from the initial draft, current implementation, or artifact.\n\nAfter writing files, recommend `\u002Fux-variations` if variants are needed before implementation, or check `.agents\u002Fproject.json.enabled_packs` for `agent-work-admin` — if `agent-work-admin` is not enabled, recommend `\u002Fpack install agent-work-admin` first; if `agent-work-admin` is enabled, recommend `\u002Froadmap` — if the interface is ready to sequence into work.\n\n### Alignment Page\n\nBuild and attempt to open `alignment\u002Fui-interview-{topic}.html` before writing or replacing `specs\u002Fui-[topic].md` or the interview log.\n\n**Alignment gates.** Treat gates as explicit review sections inside the HTML page. Include evidence coverage, assumptions\u002Fconfidence, scope\u002Fnon-goals, candidate\u002Fverdict decisions, artifact destination, proposed file changes, coverage checkpoint, and approval gates. Render surfaced assumptions, the UI or content requirements manifest, page inventory, route map, component\u002Fcontrol\u002Flink inventories, prototype-first boundary, and every proposed deliverable section with no context loss from source evidence or interview notes.\n\n**Required inline questions.** Ask whether the evidence is sufficient for the UI decisions, whether any assumptions or confidence levels are wrong, whether page\u002Fcomponent decisions and non-goals are acceptable, whether the proposed canonical file changes are approved, and whether any downstream route should remain blocked.\n\n**Gate YAML contract.** Compile answers into YAML with `section`, `gate_type`, `status`, `decision`, `notes`, and `approved_file_changes` fields. The page must automatically attempt to copy the YAML to the clipboard, provide an explicit \"Copy YAML\" button, and fall back to selecting the textarea contents.\n\n**Pre-approval stop.** Before user approval, the next action is review of the HTML alignment page. Ask the user to review the page and provide the compiled YAML answers. Do not include `Recommended next skill`, `Recommended next command`, or downstream routing language until after compiled YAML has been provided and the approved artifacts have been written or updated.\n\n## Constraints\n\n- Do not skip small interface elements. Buttons, links, icons, menus, and empty states are part of the spec.\n- Do not collapse UI detail into generic phrases such as \"standard dashboard layout\" or \"normal form behavior.\"\n- Do not create implementation plans until the page anatomy and control behavior are decision-complete.\n- Do not treat visual polish as separate from implementation. Size, spacing, hierarchy, and responsive behavior must be specified well enough for a developer to build.\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","# UI Interview\n\nInvoke as `\u002Fui-interview`.\n\nUse this skill when the user needs to turn a rough product idea, feature, page, wireframe, screenshot, or existing app surface into a detailed implementation-ready UI specification. This skill focuses on the interface itself: pages, regions, components, buttons, links, labels, spacing, element size, visual hierarchy, state, responsive layout, and accessibility.\n\nUse `\u002Fux-variations` after this skill when the user wants multiple experience concepts or interface variants to compare before locking the final direction.\n\nWhen invoked with `--requirements-only` (or when the user says \"just requirements\", \"requirements only\", or \"content requirements\"), this skill stops after establishing what the page needs — data, actions, states, and constraints — without committing to any layout, component, or spatial decisions. This mode feeds directly into `\u002Fux-variations --layout-mode` to explore multiple concrete visual approaches for the same content contract.\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, screenshots, and design artifacts when present.\n   - If the request is for an existing UI, inspect the current implementation before interviewing.\n   - If multiple apps or surfaces are plausible, ask the user which app, flow, or page to cover first.\n\n2. **Treat inputs as draft material**\n   - Do not assume the current UI, prompt, screenshot, or mockup is final.\n   - Product specs, ICP documents, and journey maps are reference material, not locked constraints. The user may override any product decision during the interview. When a user's interview answer contradicts an existing spec, adopt the interview answer and note the divergence.\n   - Preserve explicit constraints, but challenge unclear defaults before they become implementation decisions.\n   - Distinguish product behavior decisions from UI presentation decisions.\n\n3. **Surface assumptions before probing**\n   - Present a UI Assumptions Manifest before deep questioning.\n   - Tag each assumption with `[from spec]`, `[from codebase]`, `[from research]`, `[from artifact]`, or `[inferred]`.\n   - Cover product and user context, pages and routes, primary tasks, navigation, hierarchy, layout grid, spatial density, component inventory, button and link semantics, form behavior, empty\u002Floading\u002Ferror\u002Fsuccess states, responsive behavior, accessibility, visual language, implementation constraints, and the prototype-first boundary for new product or substantial feature work: what the user should be able to click through first, whether multiple route-based experiments should be built, what data can be fake, fixture-backed, or in-memory, and which infrastructure must be represented visually but not implemented yet.\n   - Use AskUserQuestion to ask the user to confirm, correct, or flag assumptions before continuing.\n\n4. **Interview page by page**\n   - Ask 1 to 3 focused questions per turn using AskUserQuestion.\n   - Move through the interface in this order unless the user asks otherwise:\n     - Global shell: header, sidebar, footer, navigation, account controls, notifications\n     - Page inventory: every route, modal, drawer, overlay, and important empty state\n     - Page purpose: user goal, task priority, and success condition\n     - Prototype calibration: first clickable journey, route-based experiment set, fixture\u002Ffake data boundaries, infrastructure-only states to mock rather than implement, and taste\u002Ffeel questions the prototype must answer before database, auth, payment, analytics, deployment, admin, or multi-tenant work is planned.\n\n4b. **Requirements gate (requirements-only mode)**\n   - In requirements-only mode, stop here — do not proceed to layout anatomy, component inventory, or spatial decisions.\n   - For each page, confirm:\n     - Data fields and entities (with cardinality: one, many, nested, polymorphic)\n     - User actions (create, edit, delete, filter, sort, export, navigate, bulk-select, reorder)\n     - States (empty, loading, error, partial, full, offline, permission-denied)\n     - Constraints (real-time updates, offline support, accessibility requirements, performance budgets)\n     - Content hierarchy (primary \u002F secondary \u002F tertiary information)\n     - Relationships between data elements (parent-child, peer, reference, aggregate)\n   - Present a **Content Requirements Manifest** summarizing all pages, then use AskUserQuestion to confirm before writing deliverables.\n   - Write `specs\u002Fui-requirements-[topic].md` (content requirements) and `ui-requirements-[topic]-interview.md` (interview log).\n   - After writing files, recommend `\u002Fux-variations --layout-mode` to explore multiple visual approaches for these requirements, or `\u002Fui-interview` (full mode, no flag) to proceed directly to a single deep UI specification.\n   - Stop. Do not continue to step 5 or beyond.\n\n5. **Full UI specification** (no `--content-only` flag):\n\n   - Layout anatomy: top-to-bottom and left-to-right regions, alignment, density, scroll behavior\n     - Component inventory: tables, lists, cards, forms, charts, media, editors, maps, canvases\n     - Controls: every button, icon button, segmented control, checkbox, radio, toggle, input, menu, tab, link, and destructive action\n     - Copy: headings, labels, helper text, validation text, confirmation text, empty-state text\n     - States: default, hover, focus, active, selected, disabled, loading, error, success, partial, offline\n     - Spatial details: element prominence, approximate sizes, gaps, padding, fixed or fluid dimensions, sticky regions, overlap rules, max widths\n     - Responsive behavior: desktop, tablet, mobile, wide desktop, touch target sizing, collapsed controls\n     - Accessibility: keyboard order, focus traps, labels, contrast, reduced motion, screen reader names. Include color-blind safe patterns, keyboard navigation, reduced motion support, and screen reader labels by default in every spec. Do not present accessibility features as optional checkboxes. Only ask about domain-specific accessibility (gamepad support, dyslexia fonts) when the product context warrants it.\n   - When a page includes repeated items, define one canonical item and its variations rather than asking about every row individually.\n\n5. **Research and recommend by default**\n   - Use project evidence and established UI conventions before asking the user to invent details.\n   - For material decisions, present options, a recommendation, rationale, tradeoffs, and mitigation.\n   - Recommend familiar controls over novel patterns unless the product has a strong reason to deviate.\n   - Respect the existing design system, component library, and implementation patterns.\n   - Reference and inspiration questions (\"apps you admire?\") are low-priority. Ask once early, accept any answer including \"none\" or \"let's experiment,\" and move on. Do not block the interview on reference input.\n\n6. **Coverage checkpoint**\n   - Before concluding, use AskUserQuestion to present a concise checklist of pages, components, controls, states, responsive behavior, and unresolved risks.\n   - Ask whether anything is missing or should be revisited before writing deliverables.\n\n## Deliverables\n\n- Write the completed UI specification to `specs\u002Fui-[topic].md`.\n- Write the interview log to `ui-[topic]-interview.md`.\n\nThe UI specification must include source evidence, the confirmed UI Assumptions Manifest, page inventory, route map, global shell rules, page-by-page anatomy, component inventory, control inventory, link inventory, layout and responsive rules, visual style direction, interaction states, accessibility requirements, implementation notes, open questions, risks, and non-goals. For new product interfaces or substantial feature interfaces, include a prototype-first section naming the first clickable journey, experiment route map when multiple alternatives should be tested, fake\u002Ffixture data, visually mocked infrastructure states, deferred production infrastructure, and the evidence required before implementation planning promotes any deferred infrastructure.\n\nThe interview log must include the manifest, every question asked, options and recommendations presented, user responses, final decisions, and notable changes from the initial draft, current implementation, or artifact.\n\nAfter writing files, recommend `\u002Fux-variations` if variants are needed before implementation, or check `.agents\u002Fproject.json.enabled_packs` for `agent-work-admin` — if `agent-work-admin` is not enabled, recommend `\u002Fpack install agent-work-admin` first; if `agent-work-admin` is enabled, recommend `\u002Froadmap` — if the interface is ready to sequence into work.\n\n### Alignment Page\n\nBuild and attempt to open `alignment\u002Fui-interview-{topic}.html` before writing or replacing `specs\u002Fui-[topic].md` or the interview log.\n\n**Alignment gates.** Treat gates as explicit review sections inside the HTML page. Include evidence coverage, assumptions\u002Fconfidence, scope\u002Fnon-goals, candidate\u002Fverdict decisions, artifact destination, proposed file changes, coverage checkpoint, and approval gates. Render surfaced assumptions, the UI or content requirements manifest, page inventory, route map, component\u002Fcontrol\u002Flink inventories, prototype-first boundary, and every proposed deliverable section with no context loss from source evidence or interview notes.\n\n**Required inline questions.** Ask whether the evidence is sufficient for the UI decisions, whether any assumptions or confidence levels are wrong, whether page\u002Fcomponent decisions and non-goals are acceptable, whether the proposed canonical file changes are approved, and whether any downstream route should remain blocked.\n\n**Gate YAML contract.** Compile answers into YAML with `section`, `gate_type`, `status`, `decision`, `notes`, and `approved_file_changes` fields. The page must automatically attempt to copy the YAML to the clipboard, provide an explicit \"Copy YAML\" button, and fall back to selecting the textarea contents.\n\n**Pre-approval stop.** Before user approval, the next action is review of the HTML alignment page. Ask the user to review the page and provide the compiled YAML answers. Do not include `Recommended next skill`, `Recommended next command`, or downstream routing language until after compiled YAML has been provided and the approved artifacts have been written or updated.\n\n## Constraints\n\n- Do not skip small interface elements. Buttons, links, icons, menus, and empty states are part of the spec.\n- Do not collapse UI detail into generic phrases such as \"standard dashboard layout\" or \"normal form behavior.\"\n- Do not create implementation plans until the page anatomy and control behavior are decision-complete.\n- Do not treat visual polish as separate from implementation. Size, spacing, hierarchy, and responsive behavior must be specified well enough for a developer to build.\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":31,"version":52,"description":7,"argument-hint":53},"v0.4","[optional: app, page, flow, feature, or draft UI]","master","96e2912af886dd1606b1b97df707715aef062b02","packs\u002Fproduct-design\u002Fclaude\u002Fui-interview\u002Farchive\u002Fv0.4",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":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add GeorgeQLe\u002Fagentic-skills --skill ui-interview",{"tool":70,"command":71},"bunx","bunx skills add GeorgeQLe\u002Fagentic-skills --skill ui-interview",{"tool":73,"command":74},"pnpm","pnpm dlx skills add GeorgeQLe\u002Fagentic-skills --skill ui-interview","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fproduct-design\u002Fclaude\u002Fui-interview\u002Farchive\u002Fv0.4\u002FSKILL.md",true,[],[79,91,101,113,128,139],{"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":47},"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",[],[86,87,88,44,89,90],"source checkout allowed","checkout","fixture","v0","valid",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":47},"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",[],[98,99,100,90,88,89],"deck install valid","deck","install",{"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":107,"publishedAt":47},"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",[],[108,109,110,90,111,112,88,89],"codex pack guard valid","pack","guard","codex","availability",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":124,"publishedAt":47},"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",[119],{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[125,126,90,111,89,127,88],"codex missing skill valid","missing","fallback",{"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":135,"publishedAt":47},"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",[134],{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},[90,111,127,136,137,138,89,88],"base skill","codex base skill fallback valid","base",{"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":145,"publishedAt":47},"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",[],[90,110,109,146,112,89,88],"claude pack guard valid"]