[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BSS79MSQEV7C0JGDXNX2AC":3,"skill-same:01M6BSS79MSQEV7C0JGDXNX2AC":106},{"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":16,"sourceHtmlUrl":17,"categories":18,"keywords":35,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":6,"ownerHtmlUrl":61,"ownerBlogUrl":62,"ownerDescription":63,"updatedAt":64,"install":65,"resources":78},"01M6BSS79MSQEV7C0JGDXNX2AC","explore-design",null,"Generate a single self-contained HTML file showing 3–6 distinct visual directions for a UI section, page, or component side-by-side for comparison, then faithfully implement the variant the user picks. Use when the user asks to \"explore directions\", \"show me a few options\", \"brainstorm designs\", \"concept this\", \"lay out variants\", or wants to compare visual approaches before committing to one. Each variant gets a label, a one-line tradeoff, a live rendered preview, and a short analysis. Also use for the follow-up — \"implement option C\", \"build this exploration\", \"turn this mock into the real page\", \"make the implementation match the design\" — which runs the implementation phase in references\u002Fimplement.md. Saying \"init\" or \"rebrand the explorations\" (re)captures the repo's brand style into a repo-local template.","mikker\u002Fdotfiles","mikker","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F2819?v=4","01M6BSPF9WRVEQ89CW9NNJ7JK4","Mikkel Malmberg","01M6BSPFEEZKZSB4B603CZGV9W",116,"LicenseRef-Custom","https:\u002F\u002Fgithub.com\u002Fmikker\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fagents.symlink\u002Fskills\u002Fexplore-design\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fmikker\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fagents.symlink\u002Fskills\u002Fexplore-design\u002FSKILL.md",[19,24,27,30],{"categoryNo":20,"categoryName":21,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":25,"categoryName":26,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":28,"categoryName":29,"taxonomyType":22,"taxonomyTypeDesc":23},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":31,"categoryName":32,"taxonomyType":33,"taxonomyTypeDesc":34},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[36,37,38,39,40,41,42,43,44,45,46],"design","explore design","implement","component","init","status","generate","https","file","ui","analysis","2026-11-10 10:12:30",false,"---\nname: explore-design\ndescription: Generate a single self-contained HTML file showing 3–6 distinct visual directions for a UI section, page, or component side-by-side for comparison, then faithfully implement the variant the user picks. Use when the user asks to \"explore directions\", \"show me a few options\", \"brainstorm designs\", \"concept this\", \"lay out variants\", or wants to compare visual approaches before committing to one. Each variant gets a label, a one-line tradeoff, a live rendered preview, and a short analysis. Also use for the follow-up — \"implement option C\", \"build this exploration\", \"turn this mock into the real page\", \"make the implementation match the design\" — which runs the implementation phase in references\u002Fimplement.md. Saying \"init\" or \"rebrand the explorations\" (re)captures the repo's brand style into a repo-local template.\nsources:\n  - url: https:\u002F\u002Fx.com\u002Ftrq212\u002Fstatus\u002F2052809885763747935\n    title: Thariq (@trq212) on HTML as agent output\n---\n\n# explore-design\n\nProduce ONE standalone `.html` file that lays out several visual directions side-by-side so the user can pick a direction. The output is for visual comparison — it is not production code.\n\nTwo phases:\n1. **Explore** (this file) — generate the side-by-side comparison.\n2. **Implement** — when the user picks a variant or asks to build a mock, read `references\u002Fimplement.md` in this skill's directory and follow it.\n\n## When to use this skill\n\n- \"Explore directions\" \u002F \"show me a few options\" \u002F \"brainstorm designs\" \u002F \"concept this\" \u002F \"what could this look like\"\n- \"Implement option C\" \u002F \"build this exploration\" \u002F \"make the implementation match the mock\" (→ phase 2)\n- \"Init\" \u002F \"rebrand the explorations\" (→ re-run brand init)\n\n## When NOT to use this skill\n\n- Production components wanted directly, with no exploration step and no mock to match → build in the codebase\n- An approved direction from outside this skill, no mock to hold parity against → normal implementation\n- A tiny styling tweak to shipped code → just edit it\n\n## Workflow\n\n1. **Run the brand scan — always, before anything else:**\n   ```\n   bash \u003Cskill-dir>\u002Fscripts\u002Fscan-brand.sh \u003Crepo-root>\n   ```\n   Its first section is the init gate:\n   - `STATUS: TEMPLATE_FOUND` → tell the user you're reusing their branded template; continue to step 2.\n   - `STATUS: NO_TEMPLATE` → read `references\u002Fbrand-init.md` and complete brand init BEFORE writing any exploration HTML. **No exceptions.** The source mock\u002Fwireframe being styled differently is never a reason to skip init — init styles the document chrome only; the mock contributes content, not brand. Init must end with `design-explorations\u002F_template.html` and `_brand.md` on disk.\n2. Read the source spec\u002Fbrief. Identify the **specific surface** being explored (a hero, a card, a page, a flow). If the spec is large, narrow to the highest-leverage surface and say what you scoped to.\n3. **Optional — Landingfolio inspiration.** If the Landingfolio MCP is connected (tools named `mcp__landingfolio__*`), pull 3–5 real examples of the surface type being explored (hero, pricing, testimonials, …) and let them inform the variant theses in the next step. If it is NOT installed, never block and never ask — tell the user in one line that you're passing on it, e.g. \"Landingfolio MCP not installed — skipping the inspiration pull. Install it at landingfolio.com\u002Fmcp if you want reference designs informing the variants.\" Then continue as normal.\n4. Brainstorm 4 distinctly different directions (range 3–6), each with a one-sentence thesis. **Announce them before writing** — \"Building 4 directions: A) social-proof-led, B) calculator-led, …\" — this is the last message before the longest silent stretch.\n5. If the surface renders a data record, sample a real record first (see \"Ground variants in real data\").\n6. Copy `design-explorations\u002F_template.html` to `design-explorations\u002F\u003Cshort-name>.html` and fill in the page header + variant sections. Use real copy from the spec\u002Fcodebase.\n7. If a data record is involved, emit `\u003Cshort-name>.manifest.md` (see below).\n8. Open the file in the default browser: `open` (macOS) \u002F `xdg-open` (Linux) \u002F `start` (Windows); skip if headless and just report the path.\n9. Report: the variants with their one-line tradeoffs, the file path, the manifest path if emitted, and any Aspirational elements to flag.\n10. When the user picks a variant (now or later), read `references\u002Fimplement.md` and follow it.\n\n**Narrate as you go:** the generation stretch runs minutes with no visible output. One-line status at each checkpoint — after the scan (what it found), after scoping, before writing (the variant theses), after writing (the path). A 3-minute silence must never be the first sign of progress.\n\n## Output location\n\n`design-explorations\u002F\u003Cshort-name>.html` at the repo root (create the directory if missing; mention it may want gitignoring). If the repo has a conventional scratch location, prefer an `explorations\u002F` folder there — the scan script finds templates in either place.\n\n## Structure of the output file\n\nThe template gives you the skeleton:\n\n1. **Page header** — title, one-line subtitle, meta strip (date, source spec, surface name)\n2. **Variants** — each a section with: letter label + name · a one-line **tradeoff** (what it optimizes for AND gives up) · the live preview (mobile-width ~440px or full-width as fits) · a short **analysis** (≤3 sentences: what works, what risks, when to pick)\n3. **Decision row** — \"If you want X → pick A. If Y → pick B…\"\n\n## Variant design rules\n\n- **Make them actually distinct.** Differing button colors is a wasted format — push on layout, hierarchy, density, tone, and what gets prioritized. If you can't write distinct one-sentence theses, you don't have distinct variants.\n- **Each variant names its tradeoff out loud** (\"Most confident, least social-proof\") so the user picks on tradeoff, not vibes.\n- **Use real copy from the spec\u002Fcodebase.** Lorem ipsum kills the exercise.\n- **Variants explore structure, not identity — by default.** Every variant is drawn in the brand captured at init (its fonts, colors, feel) and the exploration happens in layout, hierarchy, density, and what gets prioritized. Going off-brand is allowed ONLY when the user explicitly asks to explore visual identity \u002F rebrand directions.\n- **The source spec\u002Fmock\u002Fwireframe is content, not a style mandate.** Take its copy, structure, and fixtures. Its existing layout is at most one variant's direction among several — the brand the variants wear comes from init, not from the mock.\n- **All variants work on the same fixtures** (same product, same data shape). The user compares visual treatments, not features.\n\n## Ground variants in real data (CRITICAL — prevents barebones implementations)\n\nAn exploration drawn with fabricated, fully-populated data sets an expectation real data can't meet: the user falls in love with the mock, then the implementation comes out barebones. Two rules:\n\n1. **Pull real data before drawing.** When the surface renders a data record, sample the actual dataset — wherever the repo keeps its data models, API response shapes, fixtures, or seed data — and draw with a real record's values.\n2. **Aspirational elements are allowed but disclosed.** Showing a field the product doesn't have yet is fine (it's a spec for what to build) — but tag it in a manifest so the gap is known at pick-time.\n\n**The manifest** (`\u003Cshort-name>.manifest.md`, next to the HTML): one row per data-bound element — element · field path · class · count. Classes: **✅ Real** (reliably populated) · **⚠️ Sometimes** (often null — quantify, e.g. `70\u002F120`) · **❌ Aspirational** (no data today — quantify). Count from the real dataset, don't guess. The implement phase turns every gap into an explicit source\u002Fderive\u002Fplaceholder\u002Fcut decision. Skip the manifest only when there's no data record (e.g. pure marketing copy).\n\n## Style rules\n\nThe page **chrome** (header, labels, analysis cards) comes from `_template.html` — the user's brand, captured at init. Don't restyle it per exploration. The **inner preview** of each variant is structurally free canvas but wears the captured brand by default (see Variant design rules); if the brand itself is dark, the previews are dark — that's the brand, not a violation. Scope variant CSS with per-variant prefixes (`.va-`, `.vb-`, …) to avoid cross-bleed.\n\nHard rules:\n- One single HTML file. No CSS files, no JS modules, no Tailwind CDN — vanilla CSS scoped to the page.\n- System-font fallbacks on every font stack.\n- No dark \"AI artifact\" aesthetic for chrome (dark gray + neon + monospace everything).\n- No comments in the HTML except one top-of-file header block (title, source spec, date).\n- Open the file in a browser before reporting done.\n\n## Examples\n\n**\"Explore 4 directions for the pricing hero\"** → scan (template found) → theses: A) social-proof-led, B) calculator-led, C) tier-comparison-led, D) testimonial-led → `design-explorations\u002Fpricing-hero.html` → open → user picks one → implement phase.\n\n**\"Let's go with option C — build it\"** → read `references\u002Fimplement.md`: extract variant C to a reference file, build the data manifest, resolve every gap with the user, implement, screenshot-diff to parity.\n\n## Troubleshooting\n\n- **Generated without running init** (no `_template.html`\u002F`_brand.md` on disk): the gate in workflow step 1 was skipped. Run the scan script, complete init, then re-skin the exploration from the branded template.\n- **All variants look the same:** theses aren't distinct — rework them before touching CSS.\n- **Chrome clashes with the product:** init ran scan-only or captured the wrong brand. Re-run it (\"rebrand the explorations\").\n- **Implementation came out barebones:** gaps were hidden instead of resolved — run the implement phase's manifest + gap-decision steps.\n","# explore-design\n\nProduce ONE standalone `.html` file that lays out several visual directions side-by-side so the user can pick a direction. The output is for visual comparison — it is not production code.\n\nTwo phases:\n1. **Explore** (this file) — generate the side-by-side comparison.\n2. **Implement** — when the user picks a variant or asks to build a mock, read `references\u002Fimplement.md` in this skill's directory and follow it.\n\n## When to use this skill\n\n- \"Explore directions\" \u002F \"show me a few options\" \u002F \"brainstorm designs\" \u002F \"concept this\" \u002F \"what could this look like\"\n- \"Implement option C\" \u002F \"build this exploration\" \u002F \"make the implementation match the mock\" (→ phase 2)\n- \"Init\" \u002F \"rebrand the explorations\" (→ re-run brand init)\n\n## When NOT to use this skill\n\n- Production components wanted directly, with no exploration step and no mock to match → build in the codebase\n- An approved direction from outside this skill, no mock to hold parity against → normal implementation\n- A tiny styling tweak to shipped code → just edit it\n\n## Workflow\n\n1. **Run the brand scan — always, before anything else:**\n   ```\n   bash \u003Cskill-dir>\u002Fscripts\u002Fscan-brand.sh \u003Crepo-root>\n   ```\n   Its first section is the init gate:\n   - `STATUS: TEMPLATE_FOUND` → tell the user you're reusing their branded template; continue to step 2.\n   - `STATUS: NO_TEMPLATE` → read `references\u002Fbrand-init.md` and complete brand init BEFORE writing any exploration HTML. **No exceptions.** The source mock\u002Fwireframe being styled differently is never a reason to skip init — init styles the document chrome only; the mock contributes content, not brand. Init must end with `design-explorations\u002F_template.html` and `_brand.md` on disk.\n2. Read the source spec\u002Fbrief. Identify the **specific surface** being explored (a hero, a card, a page, a flow). If the spec is large, narrow to the highest-leverage surface and say what you scoped to.\n3. **Optional — Landingfolio inspiration.** If the Landingfolio MCP is connected (tools named `mcp__landingfolio__*`), pull 3–5 real examples of the surface type being explored (hero, pricing, testimonials, …) and let them inform the variant theses in the next step. If it is NOT installed, never block and never ask — tell the user in one line that you're passing on it, e.g. \"Landingfolio MCP not installed — skipping the inspiration pull. Install it at landingfolio.com\u002Fmcp if you want reference designs informing the variants.\" Then continue as normal.\n4. Brainstorm 4 distinctly different directions (range 3–6), each with a one-sentence thesis. **Announce them before writing** — \"Building 4 directions: A) social-proof-led, B) calculator-led, …\" — this is the last message before the longest silent stretch.\n5. If the surface renders a data record, sample a real record first (see \"Ground variants in real data\").\n6. Copy `design-explorations\u002F_template.html` to `design-explorations\u002F\u003Cshort-name>.html` and fill in the page header + variant sections. Use real copy from the spec\u002Fcodebase.\n7. If a data record is involved, emit `\u003Cshort-name>.manifest.md` (see below).\n8. Open the file in the default browser: `open` (macOS) \u002F `xdg-open` (Linux) \u002F `start` (Windows); skip if headless and just report the path.\n9. Report: the variants with their one-line tradeoffs, the file path, the manifest path if emitted, and any Aspirational elements to flag.\n10. When the user picks a variant (now or later), read `references\u002Fimplement.md` and follow it.\n\n**Narrate as you go:** the generation stretch runs minutes with no visible output. One-line status at each checkpoint — after the scan (what it found), after scoping, before writing (the variant theses), after writing (the path). A 3-minute silence must never be the first sign of progress.\n\n## Output location\n\n`design-explorations\u002F\u003Cshort-name>.html` at the repo root (create the directory if missing; mention it may want gitignoring). If the repo has a conventional scratch location, prefer an `explorations\u002F` folder there — the scan script finds templates in either place.\n\n## Structure of the output file\n\nThe template gives you the skeleton:\n\n1. **Page header** — title, one-line subtitle, meta strip (date, source spec, surface name)\n2. **Variants** — each a section with: letter label + name · a one-line **tradeoff** (what it optimizes for AND gives up) · the live preview (mobile-width ~440px or full-width as fits) · a short **analysis** (≤3 sentences: what works, what risks, when to pick)\n3. **Decision row** — \"If you want X → pick A. If Y → pick B…\"\n\n## Variant design rules\n\n- **Make them actually distinct.** Differing button colors is a wasted format — push on layout, hierarchy, density, tone, and what gets prioritized. If you can't write distinct one-sentence theses, you don't have distinct variants.\n- **Each variant names its tradeoff out loud** (\"Most confident, least social-proof\") so the user picks on tradeoff, not vibes.\n- **Use real copy from the spec\u002Fcodebase.** Lorem ipsum kills the exercise.\n- **Variants explore structure, not identity — by default.** Every variant is drawn in the brand captured at init (its fonts, colors, feel) and the exploration happens in layout, hierarchy, density, and what gets prioritized. Going off-brand is allowed ONLY when the user explicitly asks to explore visual identity \u002F rebrand directions.\n- **The source spec\u002Fmock\u002Fwireframe is content, not a style mandate.** Take its copy, structure, and fixtures. Its existing layout is at most one variant's direction among several — the brand the variants wear comes from init, not from the mock.\n- **All variants work on the same fixtures** (same product, same data shape). The user compares visual treatments, not features.\n\n## Ground variants in real data (CRITICAL — prevents barebones implementations)\n\nAn exploration drawn with fabricated, fully-populated data sets an expectation real data can't meet: the user falls in love with the mock, then the implementation comes out barebones. Two rules:\n\n1. **Pull real data before drawing.** When the surface renders a data record, sample the actual dataset — wherever the repo keeps its data models, API response shapes, fixtures, or seed data — and draw with a real record's values.\n2. **Aspirational elements are allowed but disclosed.** Showing a field the product doesn't have yet is fine (it's a spec for what to build) — but tag it in a manifest so the gap is known at pick-time.\n\n**The manifest** (`\u003Cshort-name>.manifest.md`, next to the HTML): one row per data-bound element — element · field path · class · count. Classes: **✅ Real** (reliably populated) · **⚠️ Sometimes** (often null — quantify, e.g. `70\u002F120`) · **❌ Aspirational** (no data today — quantify). Count from the real dataset, don't guess. The implement phase turns every gap into an explicit source\u002Fderive\u002Fplaceholder\u002Fcut decision. Skip the manifest only when there's no data record (e.g. pure marketing copy).\n\n## Style rules\n\nThe page **chrome** (header, labels, analysis cards) comes from `_template.html` — the user's brand, captured at init. Don't restyle it per exploration. The **inner preview** of each variant is structurally free canvas but wears the captured brand by default (see Variant design rules); if the brand itself is dark, the previews are dark — that's the brand, not a violation. Scope variant CSS with per-variant prefixes (`.va-`, `.vb-`, …) to avoid cross-bleed.\n\nHard rules:\n- One single HTML file. No CSS files, no JS modules, no Tailwind CDN — vanilla CSS scoped to the page.\n- System-font fallbacks on every font stack.\n- No dark \"AI artifact\" aesthetic for chrome (dark gray + neon + monospace everything).\n- No comments in the HTML except one top-of-file header block (title, source spec, date).\n- Open the file in a browser before reporting done.\n\n## Examples\n\n**\"Explore 4 directions for the pricing hero\"** → scan (template found) → theses: A) social-proof-led, B) calculator-led, C) tier-comparison-led, D) testimonial-led → `design-explorations\u002Fpricing-hero.html` → open → user picks one → implement phase.\n\n**\"Let's go with option C — build it\"** → read `references\u002Fimplement.md`: extract variant C to a reference file, build the data manifest, resolve every gap with the user, implement, screenshot-diff to parity.\n\n## Troubleshooting\n\n- **Generated without running init** (no `_template.html`\u002F`_brand.md` on disk): the gate in workflow step 1 was skipped. Run the scan script, complete init, then re-skin the exploration from the branded template.\n- **All variants look the same:** theses aren't distinct — rework them before touching CSS.\n- **Chrome clashes with the product:** init ran scan-only or captured the wrong brand. Re-run it (\"rebrand the explorations\").\n- **Implementation came out barebones:** gaps were hidden instead of resolved — run the implement phase's manifest + gap-decision steps.\n",{"name":5,"sources":52,"description":7},[53],{"url":54,"title":55},"https:\u002F\u002Fx.com\u002Ftrq212\u002Fstatus\u002F2052809885763747935","Thariq (@trq212) on HTML as agent output","master","8d883d350240b10cc23da854de1fb212e889caed","agents.symlink\u002Fskills\u002Fexplore-design",4,"https:\u002F\u002Fgithub.com\u002Fmikker\u002Fdotfiles","https:\u002F\u002Fgithub.com\u002Fmikker","https:\u002F\u002Fmikkelmalmberg.com\u002Fama","Top Highlight – research at @githubnext","2026-11-10 22:09:39",{"source":8,"skillName":5,"commands":66,"prompt":76,"zipAvailable":77},[67,70,73],{"tool":68,"command":69},"npx","npx skills add mikker\u002Fdotfiles --skill explore-design",{"tool":71,"command":72},"bunx","bunx skills add mikker\u002Fdotfiles --skill explore-design",{"tool":74,"command":75},"pnpm","pnpm dlx skills add mikker\u002Fdotfiles --skill explore-design","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmikker\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fagents.symlink\u002Fskills\u002Fexplore-design\u002FSKILL.md",true,[79,85,90,96,100],{"path":80,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":83,"sourceHtmlUrl":84},"assets\u002Ftemplate.html","ASSET","资产文件",10453,"https:\u002F\u002Fgithub.com\u002Fmikker\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fagents.symlink\u002Fskills\u002Fexplore-design\u002Fassets\u002Ftemplate.html",{"path":86,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":89,"sourceHtmlUrl":16},"LICENSE.md","LICENSE","许可证",428,{"path":91,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002Fbrand-init.md","REFERENCE","参考文档",4512,"https:\u002F\u002Fgithub.com\u002Fmikker\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fagents.symlink\u002Fskills\u002Fexplore-design\u002Freferences\u002Fbrand-init.md",{"path":97,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Fimplement.md",10511,"https:\u002F\u002Fgithub.com\u002Fmikker\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fagents.symlink\u002Fskills\u002Fexplore-design\u002Freferences\u002Fimplement.md",{"path":101,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":104,"sourceHtmlUrl":105},"scripts\u002Fscan-brand.sh","SCRIPT","脚本",2922,"https:\u002F\u002Fgithub.com\u002Fmikker\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fagents.symlink\u002Fskills\u002Fexplore-design\u002Fscripts\u002Fscan-brand.sh",[107,118,145,168,183,196],{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":111,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":47},"01M6WFXRC2WZQA9G5AT4D6PCAY","unslop","Cut AI tells from any writing.","MIT","https:\u002F\u002Fgithub.com\u002Fmikker\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fagents.symlink\u002Fskills\u002Funslop\u002FSKILL.md",[],[109,115,116,117],"writing","cut","true",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":111,"licenseFileUrl":122,"sourceHtmlUrl":123,"categories":124,"keywords":126,"publishedAt":47},"01M6WFWGJTZWZTVED8A7DHZSCB","stageshow","Build faux product UI that looks like a real product, as a still illustration or an animated demo with a cursor. Browser and app windows, dashboards, phones, notifications, terminals, bento grids and cursor walkthroughs, framed, masked and cropped the way a marketing page, feature card or docs hero needs them. Use whenever someone wants a fake or mocked UI, a product demo or walkthrough animation, a hero or feature-card illustration of an app, a product shot in the style of a polished marketing site, or an animated cursor doing things in an interface, even if they never say \"faux UI\". React and plain CSS.","https:\u002F\u002Fgithub.com\u002Fmikker\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fagents.symlink\u002Fskills\u002Fstageshow\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fmikker\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fagents.symlink\u002Fskills\u002Fstageshow\u002FSKILL.md",[125],{"categoryNo":20,"categoryName":21,"taxonomyType":22,"taxonomyTypeDesc":23},[120,127,128,129,130,131,132,45,133,134,135,136,137,138,139,140,141,142,143,144],"css","react","windows","browser","dashboards","product","notifications","Animation","walkthrough","marketing","never","feature","as","app","framed","card","interface","hero",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":111,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":47},"01M6WFW0TZQ1H9C9X4HMZBTBYZ","clean-copy","Cut interface copy that shouldn't exist — captions that restate a label, hints that pre-empt a worry the user never had, warnings that are scar tissue from a fixed bug. Use when writing or reviewing any user-facing string (labels, hints, empty states, toasts, confirmations, button text), or when asked to clean up \u002F tighten copy.","https:\u002F\u002Fgithub.com\u002Fmikker\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fagents.symlink\u002Fskills\u002Fclean-copy\u002FSKILL.md",[],[152,153,154,143,155,156,157,158,159,160,115,161,162,163,164,137,165,166,116,167],"copy","clean copy","clean","labels","states","when","restate","empty","STRING","Captions","text","user","use","up","bug","tighten",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":111,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":174,"publishedAt":47},"01M6BSWBGGT11ZA2BQ0EJH2ZBN","elyx","Elyx is a design tool with local, AI-friendly `.elyx` files for screens, components, layouts, flows, and design systems. This skill is only available to agents running in external harnesses while using the Elyx CLI. It is unavailable and must not be used when running in the ACP harness inside the Elyx app. In external harnesses, use this skill before reading, reasoning about, or answering any question that touches Elyx or `.elyx` files — authoring, editing, validating, inspecting, reviewing, refactoring, comparing, or recommending changes, including read-only analysis where you produce no edit. Do not reason about `.elyx` from source text alone; imports, instances, overrides, and layout only resolve through the tools.","https:\u002F\u002Fgithub.com\u002Fmikker\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fpi\u002Fskills\u002Felyx\u002FSKILL.md",[],[170,175,36,176,177,178,179,180,181,182,46],"acp","cli","components","reasoning","design systems","harness","produce","Tools",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":111,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":189,"publishedAt":47},"01M6BSW8K6Z805WVG0670SHXY9","uikit-app-modernization","Modernizes UIKit apps for multi-window environments by replacing legacy shared-state APIs with context-appropriate modern alternatives. This includes references to mainScreen, interfaceOrientation, application and scene lifecycle, as well as safe area inset updates.","https:\u002F\u002Fgithub.com\u002Fmikker\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fagents.symlink\u002Fskills\u002Fxcode-skills\u002Fuikit-app-modernization\u002FSKILL.md",[],[190,191,192,193,194,195],"uikit app modernization","app modernization","modernization","safe","state","lifecycle",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":111,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":202,"publishedAt":47},"01M6BSW5SCT7GQ4QX7CBSB4WF1","swiftui-whats-new-27","New SwiftUI APIs, behaviors, and deprecations in the 2027 OS releases (iOS 27 and aligned macOS\u002FwatchOS\u002FtvOS\u002FvisionOS). Consult when asked what's new in SwiftUI 27, or when working with: - @State compile errors after an SDK update (\"used before being initialized\", \"invalid redeclaration of synthesized property\") or @State becaming a macro - @ViewBuilder\u002F@ContentBuilder ambiguous overloads or type-check regressions; drag-to-reorder in any container (List, stacks, grids, custom layouts) via reorderable()\u002FreorderContainer and its drag-and-drop - AsyncImage caching, reloading on scroll, or a custom URLSession - Swipe actions outside List (ScrollView, LazyVStack, LazyVGrid) via swipeActions()\u002FswipeActionsContainer() - Toolbar overflow, visibility (visibilityPriority, ToolbarOverflowMenu, toolbarMinimizeBehavior), and pinning - Presenting a confirmationDialog or alert from an optional item binding","https:\u002F\u002Fgithub.com\u002Fmikker\u002Fdotfiles\u002Fblob\u002Fmaster\u002Fagents.symlink\u002Fskills\u002Fxcode-skills\u002Fswiftui-whats-new-27\u002FSKILL.md",[],[203,204,205,194,206,207,208,209,210],"swiftui whats new 27","sdk","update","compile","actions","ios","macro","macos"]