[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6FY2F42YW9BVST5RF7W46CW":3,"skill-same:01M6FY2F42YW9BVST5RF7W46CW":74},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":57,"ownerDescription":58,"updatedAt":59,"install":60,"resources":73},"01M6FY2F42YW9BVST5RF7W46CW","prototype",null,"Build tangible, runnable prototypes from UX variation and UI specs — static HTML\u002FCSS for UI projects, runnable scripts for CLI, endpoint stubs for API, or minimal configs for infra","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\u002Flogic-wiring\u002Farchive\u002Fv0.0\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[5,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"cli","css","ux","ui","endpoint","execution","api","projects","v0","html","minimal","build","infra","scripts","2026-11-10 10:12:30",false,"---\nname: prototype\ndescription: Build tangible, runnable prototypes from UX variation and UI specs — static HTML\u002FCSS for UI projects, runnable scripts for CLI, endpoint stubs for API, or minimal configs for infra\ntype: execution\nversion: v0.0\nargument-hint: \"[optional: topic, --variant N]\"\n---\n\n# Prototype\n\nInvoke as `$prototype`.\n\nBuild tangible, runnable prototypes before production spec work begins. This skill creates the first concrete artifact users can interact with, grounded in research and UX variation planning. Prototypes are cheap, disposable, and designed for evaluation — not production readiness. The goal is to give humans something to click, run, or curl so they can form opinions before committing to a direction.\n\n## Gate\n\nBefore proceeding, verify the following files exist:\n\n- At least one `specs\u002Fux-variations-*.md` file.\n- At least one `specs\u002Fui-*.md` file (e.g., `specs\u002Fui-[topic].md`, `specs\u002Fui-layout-variations-[topic].md`, or `specs\u002Fui-requirements-[topic].md`).\n\nIf either is missing, halt with a clear message:\n\n> Prototyping requires UX variation planning and UI specification. Missing prerequisites:\n> - `specs\u002Fux-variations-*.md` — run `$ux-variations` to create variation concepts.\n> - `specs\u002Fui-*.md` — run `$ui-interview` to define the interface specification.\n\nDo not proceed past this gate until both prerequisites exist.\n\n## Workflow\n\n### 1. Resolve context\n\n- Read `.agents\u002Fproject.json` if it exists. Extract `project_type` for dispatch decisions.\n- Read research documents when present:\n  - `research\u002Fconcept-brief.md` — assumptions to test, core value proposition, and hypothesis framing.\n  - `research\u002Ficp.md` — ideal customer profile; informs copy density, terminology, and information hierarchy.\n  - `research\u002Fcompetitive-analysis.md` — differentiation points the prototype should highlight.\n  - `research\u002Fjourney-map.md` — screen flow ordering, entry points, and task sequencing.\n- Read variation specs: `specs\u002Fux-variations-[topic].md` for each relevant topic.\n- Read per-variation UI specs: `specs\u002Fui-[topic].md`, `specs\u002Fui-layout-variations-[topic].md`, and `specs\u002Fui-requirements-[topic].md` when present.\n- If an argument is provided, use it as the topic filter. Otherwise, identify the topic from available specs.\n\n### 2. Research integration\n\nBefore building, extract actionable signals from research:\n\n- **ICP** (`research\u002Ficp.md`): Determine copy density (expert vs. novice), terminology choices, information hierarchy, and default density (compact vs. spacious). The prototype should feel like it was built for the target user, not a generic audience.\n- **Journey map** (`research\u002Fjourney-map.md`): Derive screen flow ordering. The prototype's navigation and page sequence should follow the user's natural task progression, not an arbitrary menu order.\n- **Competitive analysis** (`research\u002Fcompetitive-analysis.md`): Identify differentiation points the prototype must highlight. If the product's thesis is \"faster than X\" or \"simpler than Y,\" the prototype should make that advantage viscerally obvious.\n- **Concept brief** (`research\u002Fconcept-brief.md`): Surface assumptions the prototype is designed to test. Each prototype variation should help validate or invalidate at least one concept-brief assumption.\n\nDocument which research signals influenced which prototype decisions in a brief `## Research Integration` section at the top of the hub page.\n\n### 3. Project type dispatch\n\nDetermine the project type from `.agents\u002Fproject.json` `project_type` field. If the field is absent, infer from repository signals (package.json scripts, Dockerfile presence, CLI entry points, route files, etc.). Dispatch to one of the following modes:\n\n#### UI mode (business-app, or default when no project_type)\n\nBuild static HTML\u002FCSS prototypes for each variation:\n\n- One self-contained HTML file per variation at `prototypes\u002F{topic}\u002Fvariation-{N}\u002Findex.html`.\n- Inline CSS and minimal inline JS (no build tools, no bundler, no framework dependencies).\n- Fake but realistic data — use plausible names, dates, amounts, and content that matches the ICP.\n- Clickable navigation between pages\u002Fviews within the variation. Use anchor links, hash routing, or multiple HTML files as appropriate.\n- Responsive layout when the UI spec defines responsive behavior.\n- Visual states: show default, empty, loading (static representation), and error states where the spec defines them.\n- Do not use CDN-hosted frameworks or libraries. The prototype must work offline from a file:\u002F\u002F URL.\n- Include a brief `\u003C!-- Variation N: [Name] — [Thesis] -->` comment at the top of each HTML file.\n\n#### CLI mode (devtool with CLI focus)\n\nBuild runnable script prototypes for each variation:\n\n- One executable script per variation at `prototypes\u002F{topic}\u002Fvariation-{N}\u002Fdemo.sh` (or `.py`, `.js`, etc., matching the project's primary language).\n- Include fixture data files alongside the script.\n- Demonstrate one core workflow end-to-end: the user runs a single command (or short sequence) and sees realistic output.\n- Include inline comments explaining which variation thesis this demonstrates.\n- Scripts must be runnable with standard tooling (bash, node, python) without additional dependencies.\n\n#### API mode (devtool with API focus)\n\nBuild endpoint stub prototypes for each variation:\n\n- One lightweight server or mock per variation at `prototypes\u002F{topic}\u002Fvariation-{N}\u002Fserver.{ext}`.\n- Fixture JSON responses for each endpoint.\n- A `curl-examples.sh` file with annotated curl commands demonstrating the core workflow.\n- Include a brief README in each variation directory explaining the API design thesis.\n- Endpoints return fixture data; no database or persistence required.\n\n#### Infra mode\n\nBuild minimal configuration prototypes for each variation:\n\n- One `docker-compose.yml` or equivalent config per variation at `prototypes\u002F{topic}\u002Fvariation-{N}\u002F`.\n- Include `.env.example`, config files, and documentation sufficient to understand the infrastructure concept.\n- Do not require running services; use placeholder images or mock services where possible.\n- Include a brief README explaining the infrastructure thesis and what a user would observe if they ran it.\n\n### 4. Scope rule (non-UI modes)\n\nFor CLI, API, and Infra modes, build exactly one core workflow demo with fixture data per variation. Do not attempt full API coverage, complete CLI help systems, or production-ready infrastructure. The prototype exists to make the variation thesis tangible, not to implement the product.\n\n### 5. Build each variation\n\nFor each variation defined in `specs\u002Fux-variations-[topic].md`:\n\n1. Read the variation's thesis, target user, layout\u002Fflow model, and prototype scope from the spec.\n2. Read the corresponding UI spec details from `specs\u002Fui-[topic].md` or `specs\u002Fui-layout-variations-[topic].md`.\n3. Build the prototype artifact in `prototypes\u002F{topic}\u002Fvariation-{N}\u002F`.\n4. Name the directory using the variation number from the spec (1-indexed).\n5. Ensure the prototype is immediately usable: open the HTML file, run the script, curl the endpoint, or read the config.\n\n### 6. Build the hub page\n\nCreate a hub page at `prototypes\u002F{topic}\u002Findex.html` that:\n\n- Lists every variation with its name, thesis, and a direct link to the variation's entry point.\n- Includes the research integration summary (which research signals drove which decisions).\n- Provides brief instructions for evaluating each variation.\n- For UI mode: links open the variation's `index.html` in the same browser.\n- For CLI\u002FAPI\u002FInfra modes: the hub page is a simple HTML document with copy-pasteable commands to run each variation.\n- After writing or updating the hub page, attempt to open `prototypes\u002F{topic}\u002Findex.html` in the browser and report whether the browser open succeeded or was blocked. A blocked browser open does not make the prototype fail when the files were written correctly.\n\n### 7. `--variant N` flag\n\nWhen the user provides `--variant N` (or says \"rebuild variation N\", \"only variation N\", etc.):\n\n- Build or rebuild only variation N, preserving all other existing variations and the hub page.\n- Update the hub page to reflect any changes to the rebuilt variation.\n- Do not delete or modify other variation directories.\n\n## Output\n\nThe skill produces the following file structure:\n\n```\nprototypes\u002F{topic}\u002F\n  index.html                    # Hub page listing all variations\n  variation-1\u002F\n    index.html (or demo.sh, server.js, docker-compose.yml)\n    [supporting files: fixtures, styles, curl-examples, README]\n  variation-2\u002F\n    index.html (or demo.sh, server.js, docker-compose.yml)\n    [supporting files]\n  variation-N\u002F\n    ...\n```\n\n## Next Step\n\nAfter prototypes are built, recommend:\n\n> Recommended next command: `$uat --variant-evaluation`\n\nThe user should interact with each prototype variation hands-on before consolidating. UAT variant evaluation provides a structured comparison framework to capture evidence for each variation's strengths, friction points, and rejection signals.\n\n## Constraints\n\n- Do not introduce build tools, bundlers, package managers, or framework dependencies into prototypes. Prototypes must be immediately usable without installation steps.\n- Do not connect to real databases, APIs, or external services. All data must be fixture\u002Ffake data.\n- Do not build production-quality code. Prototypes are disposable artifacts for evaluation, not starting points for implementation.\n- Do not skip variations. Build all variations defined in the spec unless `--variant N` is provided.\n- Do not choose a winning variation or recommend consolidation. That is the user's decision after UAT evaluation.\n- Do not modify specs, research documents, or task files. This skill only creates files in the `prototypes\u002F` directory.\n\n## Alignment Page\n\nWhen this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page at `alignment\u002Fprototype-{topic}.html`. Use a normalized topic slug derived from the app, feature, research subject, report subject, or output filename.\n\n**Full content requirement.** The alignment page must contain the complete content of every proposed markdown deliverable -- every section, every finding, every detail, every list item. It is a thorough interactive review document, not a summary. Render the full deliverable content in clean, readable HTML with appropriate hierarchy, styling, and navigation. If the skill writes multiple scoped deliverables in one run, build one alignment page that contains all deliverables with anchor-linked navigation. Durable tracker artifacts, such as `research\u002Fassumption-tracker.md`, remain canonical markdown outputs but must also be fully rendered into the alignment page before approval.\n\n**Dark-mode styling.** Use a dark color scheme by default. Base CSS variables: `--bg: #0d1117; --surface: #161b22; --border: #30363d; --text: #c9d1d9; --text-muted: #8b949e; --accent: #58a6ff; --green: #3fb950; --red: #f85149; --orange: #d29922; --purple: #bc8cff;`. Apply `background: var(--bg); color: var(--text);` on body. Use `--surface` for cards, nav, and table headers. Use `--border` for all borders. Use `--purple` for question blocks and gate headings. Use `--accent` for links and section headings. Keep headings `color: #fff` or `var(--accent)` for hierarchy. Question block backgrounds should use `#1c2333`.\n\n**Alignment gates.** Treat gates as explicit review sections inside the HTML page. A gate blocks finalization until its required inline questions are answered and compiled into YAML. Include every gate that applies to the skill output, and include these gate types whenever relevant: evidence coverage, assumptions\u002Fconfidence, scope\u002Fnon-goals, candidate\u002Fverdict decisions, artifact destination, proposed file changes, coverage checkpoint, and post-approval route.\n\n**Report-only research gates.** For report-only or pre-approval research skills, the alignment page must explicitly contain evidence coverage, assumptions\u002Fconfidence, recommended path, proposed file changes, and approval gates before any canonical research, spec, or task file is created or updated.\n\n**Prototype-specific gates.** Render source-spec coverage, prototype scope, non-goals and deferred infrastructure, route\u002Ffile destinations, proposed file changes, validation plan, and post-approval UAT route as gates.\n\n\n**Required inline questions.** Each gate must contain at least one required inline question placed directly under the content it governs, inside a visually distinct question block. Each question must use radio-button inputs and include two standing options after the skill-generated choices: \"Other \u002F None of the above\" backed by a multi-line text box for free-form input, and \"Need clarification\" backed by an optional notes box where the user can explain what is unclear. When any radio option other than \"Other\" or \"Need clarification\" is selected, show an optional \"Additional notes\" text box beneath it so the user can qualify their choice. Generate questions based on what genuinely needs user input -- do not add filler questions. Do not create a separate bottom \"Decisions & Clarifications\" section.\n\n**Gate YAML contract.** At the bottom of the page, include a \"Compile Answers\" button that aggregates answers from all inline gate questions throughout the page, including free-text notes. The button remains disabled until every required question has a selection, shows a count of remaining unanswered questions, and scrolls to the first unanswered question if clicked early. When every question is answered, generate a structured YAML block with one item per gate answer using this stable shape: `section`, `gate_type`, `status` (`answered`, `other`, or `needs-clarification`), `answer`, optional `notes`, and optional `target_artifact` or `target_path` when the gate controls file output. After successful compilation, automatically attempt to copy the YAML to the clipboard with the Clipboard API, display copy status, and display the YAML in a read-only textarea with an explicit \"Copy YAML\" button. The copy button must retry clipboard copy when supported and fall back to selecting the textarea contents when clipboard access is unavailable or blocked.\n\n**Pre-approval stop.** Before user approval, the next action is review of the HTML alignment page, not downstream routing. 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**Diff highlighting on updates.** When the agent updates an existing alignment page after receiving compiled answers, highlight what changed since the previous version. The agent chooses inline annotation or side-by-side layout per situation.\n\n**Archiving.** Before replacing an existing alignment page, archive it to `docs\u002Fhistory\u002Farchive\u002FYYYY-MM-DD\u002FHHMMSS\u002Falignment\u002Fprototype-{topic}.html`.\n\n**Browser open.** Attempt to open the resulting HTML page in the browser and report whether the open succeeded or was blocked. A blocked browser-open attempt does not make the skill fail when the files were written correctly.\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\n- **Default next-step routing:** when reporting completion, include either `Recommended next skill: \u003Ccommand>` or the two-line pair `**Next work:** \u003Cspecific task or \"none\">` and `**Recommended next command:** \u003Cone command or route>` so the next operator has a concrete handoff.\n- If this skill creates or modifies tracked repository files, finish by committing and pushing all intended changes to the repository primary branch (`main` when present, otherwise `master`) before stopping, even if the user did not explicitly ask for commit\u002Fpush.\n- Do not leave tracked changes or unpushed commits behind. If unrelated tracked work is already present, either include it in sensible commits too or stop and explain the blocker.\n- This contract does not override stricter safety rules about secrets, destructive history changes, release publication\u002Ftag confirmation, or production deploy confirmation.\n","# Prototype\n\nInvoke as `$prototype`.\n\nBuild tangible, runnable prototypes before production spec work begins. This skill creates the first concrete artifact users can interact with, grounded in research and UX variation planning. Prototypes are cheap, disposable, and designed for evaluation — not production readiness. The goal is to give humans something to click, run, or curl so they can form opinions before committing to a direction.\n\n## Gate\n\nBefore proceeding, verify the following files exist:\n\n- At least one `specs\u002Fux-variations-*.md` file.\n- At least one `specs\u002Fui-*.md` file (e.g., `specs\u002Fui-[topic].md`, `specs\u002Fui-layout-variations-[topic].md`, or `specs\u002Fui-requirements-[topic].md`).\n\nIf either is missing, halt with a clear message:\n\n> Prototyping requires UX variation planning and UI specification. Missing prerequisites:\n> - `specs\u002Fux-variations-*.md` — run `$ux-variations` to create variation concepts.\n> - `specs\u002Fui-*.md` — run `$ui-interview` to define the interface specification.\n\nDo not proceed past this gate until both prerequisites exist.\n\n## Workflow\n\n### 1. Resolve context\n\n- Read `.agents\u002Fproject.json` if it exists. Extract `project_type` for dispatch decisions.\n- Read research documents when present:\n  - `research\u002Fconcept-brief.md` — assumptions to test, core value proposition, and hypothesis framing.\n  - `research\u002Ficp.md` — ideal customer profile; informs copy density, terminology, and information hierarchy.\n  - `research\u002Fcompetitive-analysis.md` — differentiation points the prototype should highlight.\n  - `research\u002Fjourney-map.md` — screen flow ordering, entry points, and task sequencing.\n- Read variation specs: `specs\u002Fux-variations-[topic].md` for each relevant topic.\n- Read per-variation UI specs: `specs\u002Fui-[topic].md`, `specs\u002Fui-layout-variations-[topic].md`, and `specs\u002Fui-requirements-[topic].md` when present.\n- If an argument is provided, use it as the topic filter. Otherwise, identify the topic from available specs.\n\n### 2. Research integration\n\nBefore building, extract actionable signals from research:\n\n- **ICP** (`research\u002Ficp.md`): Determine copy density (expert vs. novice), terminology choices, information hierarchy, and default density (compact vs. spacious). The prototype should feel like it was built for the target user, not a generic audience.\n- **Journey map** (`research\u002Fjourney-map.md`): Derive screen flow ordering. The prototype's navigation and page sequence should follow the user's natural task progression, not an arbitrary menu order.\n- **Competitive analysis** (`research\u002Fcompetitive-analysis.md`): Identify differentiation points the prototype must highlight. If the product's thesis is \"faster than X\" or \"simpler than Y,\" the prototype should make that advantage viscerally obvious.\n- **Concept brief** (`research\u002Fconcept-brief.md`): Surface assumptions the prototype is designed to test. Each prototype variation should help validate or invalidate at least one concept-brief assumption.\n\nDocument which research signals influenced which prototype decisions in a brief `## Research Integration` section at the top of the hub page.\n\n### 3. Project type dispatch\n\nDetermine the project type from `.agents\u002Fproject.json` `project_type` field. If the field is absent, infer from repository signals (package.json scripts, Dockerfile presence, CLI entry points, route files, etc.). Dispatch to one of the following modes:\n\n#### UI mode (business-app, or default when no project_type)\n\nBuild static HTML\u002FCSS prototypes for each variation:\n\n- One self-contained HTML file per variation at `prototypes\u002F{topic}\u002Fvariation-{N}\u002Findex.html`.\n- Inline CSS and minimal inline JS (no build tools, no bundler, no framework dependencies).\n- Fake but realistic data — use plausible names, dates, amounts, and content that matches the ICP.\n- Clickable navigation between pages\u002Fviews within the variation. Use anchor links, hash routing, or multiple HTML files as appropriate.\n- Responsive layout when the UI spec defines responsive behavior.\n- Visual states: show default, empty, loading (static representation), and error states where the spec defines them.\n- Do not use CDN-hosted frameworks or libraries. The prototype must work offline from a file:\u002F\u002F URL.\n- Include a brief `\u003C!-- Variation N: [Name] — [Thesis] -->` comment at the top of each HTML file.\n\n#### CLI mode (devtool with CLI focus)\n\nBuild runnable script prototypes for each variation:\n\n- One executable script per variation at `prototypes\u002F{topic}\u002Fvariation-{N}\u002Fdemo.sh` (or `.py`, `.js`, etc., matching the project's primary language).\n- Include fixture data files alongside the script.\n- Demonstrate one core workflow end-to-end: the user runs a single command (or short sequence) and sees realistic output.\n- Include inline comments explaining which variation thesis this demonstrates.\n- Scripts must be runnable with standard tooling (bash, node, python) without additional dependencies.\n\n#### API mode (devtool with API focus)\n\nBuild endpoint stub prototypes for each variation:\n\n- One lightweight server or mock per variation at `prototypes\u002F{topic}\u002Fvariation-{N}\u002Fserver.{ext}`.\n- Fixture JSON responses for each endpoint.\n- A `curl-examples.sh` file with annotated curl commands demonstrating the core workflow.\n- Include a brief README in each variation directory explaining the API design thesis.\n- Endpoints return fixture data; no database or persistence required.\n\n#### Infra mode\n\nBuild minimal configuration prototypes for each variation:\n\n- One `docker-compose.yml` or equivalent config per variation at `prototypes\u002F{topic}\u002Fvariation-{N}\u002F`.\n- Include `.env.example`, config files, and documentation sufficient to understand the infrastructure concept.\n- Do not require running services; use placeholder images or mock services where possible.\n- Include a brief README explaining the infrastructure thesis and what a user would observe if they ran it.\n\n### 4. Scope rule (non-UI modes)\n\nFor CLI, API, and Infra modes, build exactly one core workflow demo with fixture data per variation. Do not attempt full API coverage, complete CLI help systems, or production-ready infrastructure. The prototype exists to make the variation thesis tangible, not to implement the product.\n\n### 5. Build each variation\n\nFor each variation defined in `specs\u002Fux-variations-[topic].md`:\n\n1. Read the variation's thesis, target user, layout\u002Fflow model, and prototype scope from the spec.\n2. Read the corresponding UI spec details from `specs\u002Fui-[topic].md` or `specs\u002Fui-layout-variations-[topic].md`.\n3. Build the prototype artifact in `prototypes\u002F{topic}\u002Fvariation-{N}\u002F`.\n4. Name the directory using the variation number from the spec (1-indexed).\n5. Ensure the prototype is immediately usable: open the HTML file, run the script, curl the endpoint, or read the config.\n\n### 6. Build the hub page\n\nCreate a hub page at `prototypes\u002F{topic}\u002Findex.html` that:\n\n- Lists every variation with its name, thesis, and a direct link to the variation's entry point.\n- Includes the research integration summary (which research signals drove which decisions).\n- Provides brief instructions for evaluating each variation.\n- For UI mode: links open the variation's `index.html` in the same browser.\n- For CLI\u002FAPI\u002FInfra modes: the hub page is a simple HTML document with copy-pasteable commands to run each variation.\n- After writing or updating the hub page, attempt to open `prototypes\u002F{topic}\u002Findex.html` in the browser and report whether the browser open succeeded or was blocked. A blocked browser open does not make the prototype fail when the files were written correctly.\n\n### 7. `--variant N` flag\n\nWhen the user provides `--variant N` (or says \"rebuild variation N\", \"only variation N\", etc.):\n\n- Build or rebuild only variation N, preserving all other existing variations and the hub page.\n- Update the hub page to reflect any changes to the rebuilt variation.\n- Do not delete or modify other variation directories.\n\n## Output\n\nThe skill produces the following file structure:\n\n```\nprototypes\u002F{topic}\u002F\n  index.html                    # Hub page listing all variations\n  variation-1\u002F\n    index.html (or demo.sh, server.js, docker-compose.yml)\n    [supporting files: fixtures, styles, curl-examples, README]\n  variation-2\u002F\n    index.html (or demo.sh, server.js, docker-compose.yml)\n    [supporting files]\n  variation-N\u002F\n    ...\n```\n\n## Next Step\n\nAfter prototypes are built, recommend:\n\n> Recommended next command: `$uat --variant-evaluation`\n\nThe user should interact with each prototype variation hands-on before consolidating. UAT variant evaluation provides a structured comparison framework to capture evidence for each variation's strengths, friction points, and rejection signals.\n\n## Constraints\n\n- Do not introduce build tools, bundlers, package managers, or framework dependencies into prototypes. Prototypes must be immediately usable without installation steps.\n- Do not connect to real databases, APIs, or external services. All data must be fixture\u002Ffake data.\n- Do not build production-quality code. Prototypes are disposable artifacts for evaluation, not starting points for implementation.\n- Do not skip variations. Build all variations defined in the spec unless `--variant N` is provided.\n- Do not choose a winning variation or recommend consolidation. That is the user's decision after UAT evaluation.\n- Do not modify specs, research documents, or task files. This skill only creates files in the `prototypes\u002F` directory.\n\n## Alignment Page\n\nWhen this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page at `alignment\u002Fprototype-{topic}.html`. Use a normalized topic slug derived from the app, feature, research subject, report subject, or output filename.\n\n**Full content requirement.** The alignment page must contain the complete content of every proposed markdown deliverable -- every section, every finding, every detail, every list item. It is a thorough interactive review document, not a summary. Render the full deliverable content in clean, readable HTML with appropriate hierarchy, styling, and navigation. If the skill writes multiple scoped deliverables in one run, build one alignment page that contains all deliverables with anchor-linked navigation. Durable tracker artifacts, such as `research\u002Fassumption-tracker.md`, remain canonical markdown outputs but must also be fully rendered into the alignment page before approval.\n\n**Dark-mode styling.** Use a dark color scheme by default. Base CSS variables: `--bg: #0d1117; --surface: #161b22; --border: #30363d; --text: #c9d1d9; --text-muted: #8b949e; --accent: #58a6ff; --green: #3fb950; --red: #f85149; --orange: #d29922; --purple: #bc8cff;`. Apply `background: var(--bg); color: var(--text);` on body. Use `--surface` for cards, nav, and table headers. Use `--border` for all borders. Use `--purple` for question blocks and gate headings. Use `--accent` for links and section headings. Keep headings `color: #fff` or `var(--accent)` for hierarchy. Question block backgrounds should use `#1c2333`.\n\n**Alignment gates.** Treat gates as explicit review sections inside the HTML page. A gate blocks finalization until its required inline questions are answered and compiled into YAML. Include every gate that applies to the skill output, and include these gate types whenever relevant: evidence coverage, assumptions\u002Fconfidence, scope\u002Fnon-goals, candidate\u002Fverdict decisions, artifact destination, proposed file changes, coverage checkpoint, and post-approval route.\n\n**Report-only research gates.** For report-only or pre-approval research skills, the alignment page must explicitly contain evidence coverage, assumptions\u002Fconfidence, recommended path, proposed file changes, and approval gates before any canonical research, spec, or task file is created or updated.\n\n**Prototype-specific gates.** Render source-spec coverage, prototype scope, non-goals and deferred infrastructure, route\u002Ffile destinations, proposed file changes, validation plan, and post-approval UAT route as gates.\n\n\n**Required inline questions.** Each gate must contain at least one required inline question placed directly under the content it governs, inside a visually distinct question block. Each question must use radio-button inputs and include two standing options after the skill-generated choices: \"Other \u002F None of the above\" backed by a multi-line text box for free-form input, and \"Need clarification\" backed by an optional notes box where the user can explain what is unclear. When any radio option other than \"Other\" or \"Need clarification\" is selected, show an optional \"Additional notes\" text box beneath it so the user can qualify their choice. Generate questions based on what genuinely needs user input -- do not add filler questions. Do not create a separate bottom \"Decisions & Clarifications\" section.\n\n**Gate YAML contract.** At the bottom of the page, include a \"Compile Answers\" button that aggregates answers from all inline gate questions throughout the page, including free-text notes. The button remains disabled until every required question has a selection, shows a count of remaining unanswered questions, and scrolls to the first unanswered question if clicked early. When every question is answered, generate a structured YAML block with one item per gate answer using this stable shape: `section`, `gate_type`, `status` (`answered`, `other`, or `needs-clarification`), `answer`, optional `notes`, and optional `target_artifact` or `target_path` when the gate controls file output. After successful compilation, automatically attempt to copy the YAML to the clipboard with the Clipboard API, display copy status, and display the YAML in a read-only textarea with an explicit \"Copy YAML\" button. The copy button must retry clipboard copy when supported and fall back to selecting the textarea contents when clipboard access is unavailable or blocked.\n\n**Pre-approval stop.** Before user approval, the next action is review of the HTML alignment page, not downstream routing. 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**Diff highlighting on updates.** When the agent updates an existing alignment page after receiving compiled answers, highlight what changed since the previous version. The agent chooses inline annotation or side-by-side layout per situation.\n\n**Archiving.** Before replacing an existing alignment page, archive it to `docs\u002Fhistory\u002Farchive\u002FYYYY-MM-DD\u002FHHMMSS\u002Falignment\u002Fprototype-{topic}.html`.\n\n**Browser open.** Attempt to open the resulting HTML page in the browser and report whether the open succeeded or was blocked. A blocked browser-open attempt does not make the skill fail when the files were written correctly.\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\n- **Default next-step routing:** when reporting completion, include either `Recommended next skill: \u003Ccommand>` or the two-line pair `**Next work:** \u003Cspecific task or \"none\">` and `**Recommended next command:** \u003Cone command or route>` so the next operator has a concrete handoff.\n- If this skill creates or modifies tracked repository files, finish by committing and pushing all intended changes to the repository primary branch (`main` when present, otherwise `master`) before stopping, even if the user did not explicitly ask for commit\u002Fpush.\n- Do not leave tracked changes or unpushed commits behind. If unrelated tracked work is already present, either include it in sensible commits too or stop and explain the blocker.\n- This contract does not override stricter safety rules about secrets, destructive history changes, release publication\u002Ftag confirmation, or production deploy confirmation.\n",{"name":5,"type":34,"version":48,"description":7,"argument-hint":49},"v0.0","[optional: topic, --variant N]","master","96e2912af886dd1606b1b97df707715aef062b02","packs\u002Fproduct-design\u002Fcodex\u002Flogic-wiring\u002Farchive\u002Fv0.0",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":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add GeorgeQLe\u002Fagentic-skills --skill prototype",{"tool":66,"command":67},"bunx","bunx skills add GeorgeQLe\u002Fagentic-skills --skill prototype",{"tool":69,"command":70},"pnpm","pnpm dlx skills add GeorgeQLe\u002Fagentic-skills --skill prototype","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Fpacks\u002Fproduct-design\u002Fcodex\u002Flogic-wiring\u002Farchive\u002Fv0.0\u002FSKILL.md",true,[],[75,87,97,109,122,133],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":43},"01M6G0NJES15RJKZE6YZ0TSYGF","source-checkout-allowed","Valid source-checkout-only fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fsource-checkout-allowed\u002FSKILL.md",[],[82,83,84,85,37,86],"source checkout allowed","checkout","fixture","only","valid",{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":43},"01M6G0NFZ3R1MNB1E3DVTM0WB7","deck-install-valid","Valid deck install fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fdeck-install\u002FSKILL.md",[],[94,95,96,86,84,37],"deck install valid","deck","install",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":43},"01M6G0ND3QZQC4MDZ9NVB97PT2","codex-pack-guard-valid","Valid Codex Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-pack-guard\u002FSKILL.md",[],[104,105,106,86,107,108,84,37],"codex pack guard valid","pack","guard","codex","availability",{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":118,"publishedAt":43},"01M6G0NA9YB3NKGZKD3S96JMNB","codex-missing-skill-valid","Valid Codex missing skill fallback fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fcodex-missing-skill-fallback\u002FSKILL.md",[115],{"categoryNo":116,"categoryName":117,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[119,120,86,107,37,121,84],"codex missing skill valid","missing","fallback",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":129,"publishedAt":43},"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",[128],{"categoryNo":116,"categoryName":117,"taxonomyType":21,"taxonomyTypeDesc":22},[86,107,121,130,131,132,37,84],"base skill","codex base skill fallback valid","base",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":43},"01M6G0N4VRR2YKZQ6N3Y6S2BQA","claude-pack-guard-valid","Valid Claude Pack Availability Guard fixture.","https:\u002F\u002Fgithub.com\u002FGeorgeQLe\u002Fagentic-skills\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fskill-install-routing\u002Fvalid\u002Fclaude-pack-guard\u002FSKILL.md",[],[86,106,105,140,108,37,84],"claude pack guard valid"]