[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71KF1C14HSYSFE21PVJDR35":3,"skill-same:01M71KF1C14HSYSFE21PVJDR35":83},{"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":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":38,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":58,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":61,"updatedAt":62,"install":63,"resources":76},"01M71KF1C14HSYSFE21PVJDR35","design-exploration",null,"Use this skill when the user asks to 'generate variations,' 'explore alternatives,' 'try different approaches,' 'show me options,' 'what else could this be,' or any request that implies divergent design exploration rather than deterministic editing. Also activate when the user selects a component and asks for 'ideas,' 'directions,' or 'possibilities.' This skill intercepts the request at the main agent level and produces a structured design brief BEFORE delegating to the design subagent. Do NOT skip the analysis phase. Do NOT pass raw file paths without a design brief.","clawdsolana\u002FOpenClawd","clawdsolana","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F279036008?v=4","01M71JTVF9FNGKE2SVJRPTQM31","OpenClawd","01M71JTVGCKWBSS8ZYC1HYWVA5",2,"MIT","https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd\u002Fblob\u002Fmain\u002Fskills\u002Fdesign-exploration\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"design","design exploration","exploration","file","analysis","show me","directions","when","use","main","explore","alternatives","editing","for","ideas","show","design brief","do","brief","deterministic","2026-11-10 10:12:30",false,"---\nname: design-exploration\ndescription: \"Use this skill when the user asks to 'generate variations,' 'explore alternatives,' 'try different approaches,' 'show me options,' 'what else could this be,' or any request that implies divergent design exploration rather than deterministic editing. Also activate when the user selects a component and asks for 'ideas,' 'directions,' or 'possibilities.' This skill intercepts the request at the main agent level and produces a structured design brief BEFORE delegating to the design subagent. Do NOT skip the analysis phase. Do NOT pass raw file paths without a design brief.\"\n---\n\n# Design Exploration\n\n## Purpose\n\nThis skill ensures the agent performs **problem comprehension before generation** when handling variation requests. Analyze what a component does, what constrains it, and what is meaningfully free to vary — then compose a design brief and pass it to the design subagent. Never skip straight from \"user asked for variations\" to output.\n\nDesign exploration is the divergent phase of an explore\u002Fexploit loop. Each variation should represent a **distinct design hypothesis** — a meaningfully different answer to \"what could this be?\" — not a reskin of the same hypothesis.\n\n## Step 1: Read and Comprehend the Component\n\nRead the selected component's source code and surrounding context (parent layout, route structure, dependencies, styles). Build an internal model of:\n\n- **Function**: What does it do? What user problem does it solve? What's its role in the broader flow?\n- **Content model**: What information does it present or collect? What's the semantic structure?\n- **Interaction model**: How does the user engage with it? What states and transitions exist?\n- **Visual structure**: How is it composed? What are its regions, hierarchy, and spatial relationships?\n- **Context**: Where does it live? What comes before and after? What assumptions does it inherit?\n\n## Step 2: Identify Constraints and Degrees of Freedom\n\nDistinguish between:\n\n- **Hard constraints**: Cannot change without breaking the component (required data fields, accessibility requirements, platform constraints, explicit user decisions).\n- **Soft constraints**: Assumed by the current implementation but reconsidered (a list that could be a grid; a bottom-anchored CTA that could be inline; a formal tone that could be conversational).\n- **Degrees of freedom**: Dimensions along which the design could meaningfully vary.\n\nBe explicit about what you're holding fixed and why.\n\n## Step 3: Select Meaningful Variation Axes\n\nSelect 2–3 axes that produce the most meaningfully different outcomes. The five axis categories:\n\n- **Structural**: Layout, information hierarchy, component decomposition, navigation pattern. Answers: \"What if this were organized differently?\" (e.g., settings as scrolling form vs. tabbed panel vs. progressive wizard)\n- **Content \u002F Semantic**: What's foregrounded, backgrounded, or reframed. Answers: \"What if we emphasized different things?\" (e.g., pricing that leads with features vs. social proof vs. comparison)\n- **Conceptual**: The underlying metaphor or interaction paradigm. Answers: \"What if we thought about this differently?\" (e.g., file manager as spatial desktop vs. conversation vs. timeline)\n- **Behavioral**: State transitions, progressive disclosure, interaction sequencing. Answers: \"What if it behaved differently?\" (e.g., form validates on blur vs. submit vs. inline)\n- **Aesthetic**: Color, typography, spacing, mood, material quality. Answers: \"What if it looked and felt different?\" (e.g., three distinct visual identities for the same card component)\n\n### Selection Heuristic\n\nRead the user's intent to determine where they are in the exploration funnel:\n\n- **\"Generate variations\" \u002F \"show me options\" (no further context)**: The user hasn't specified an axis. Analyze the component to determine which axes have the most unexplored space. For structurally complex components (pages, flows, dashboards), default to structural and conceptual axes. For visually-driven or structurally simple components (cards, heroes, buttons, marketing sections), structural AND aesthetic are both strong first-round choices — lead with whichever produces more meaningfully different outcomes.\n- **User describes a direction but not a form** (\"something more premium,\" \"more playful,\" \"feels enterprise\"): This is an aesthetic\u002Ftonal signal. Explore visual treatment as a primary axis, but pair it with one structural or content axis so the variations aren't just reskins.\n- **User names a specific axis** (\"try different layouts,\" \"what if the copy were different\"): Follow their lead. Pair with one complementary axis that might surface unexpected possibilities.\n- **User is iterating on an established structure** (\"I like this layout, but...\"): Focus on aesthetic and behavioral refinement.\n\nThe goal is progressive funnel narrowing: broad exploration → emerging preferences → focused refinement → final form. Match axis selection to where the user actually is, not to a fixed priority order.\n\n## Step 4: Compose the Design Brief\n\nCompose a structured brief covering: component analysis, constraints (with rationale), chosen variation axes (with rationale), and concrete variation specifications. Each variation spec should name the design hypothesis it represents and describe concretely how it differs from the current implementation.\n\nThis brief — not just the file path — is what you pass to the design subagent. The brief is the primary artifact of this skill.\n\n## Step 5: Delegate with the Brief\n\nYour delegation message to the design subagent must include:\n\n1. The full design brief from Step 4\n2. The source file path(s)\n3. This instruction: \"Each variation should be a distinct design hypothesis. Do not produce variations that differ only in color, font, or spacing unless the brief specifically calls for aesthetic exploration.\"\n\n**Do not just pass the file path. Do not say \"generate 3 variations of this component\" without the brief.**\n\n## Communicating with the User\n\n### Before generation\n\nTell the user what axes you chose to explore and why. Name the design concepts at play so the user builds vocabulary over time. This makes your reasoning legible and gives the user a chance to redirect.\n\nExample: \"I'm going to explore 3 variations of your pricing section. The current design uses a **comparison table** — that's a strong structural choice, so I'll hold it. Instead I'll vary the **content hierarchy** (what information leads the user's eye and shapes their first impression) and the **conceptual framing** (whether the tiers are positioned as good\u002Fbetter\u002Fbest, or as use-case-based recommendations). These are often the highest-leverage dimensions for pricing — small changes in what's foregrounded can significantly shift conversion.\"\n\nIf the user redirects, update the axis selection and re-delegate. The comprehension step doesn't need to repeat.\n\n### After generation\n\nWhen presenting variations, explain what each one teaches about the design problem — not just what it looks like. Frame each variation as a hypothesis with observable trade-offs:\n\n- Name the **design decision** each variation embodies (\"This one foregrounds social proof because...\")\n- Call out the **trade-off** it makes (\"...which builds trust at the cost of information density\")\n- Suggest **what to watch for** when evaluating (\"Notice how your eye moves differently across these — that's the hierarchy at work\")\n\nThe goal is for the user to finish the exploration knowing *more about their design problem* than when they started — not just having picked a favorite variant.\n\n## Anti-Patterns\n\n- **Skipping comprehension**: Going from request to generation without analysis. This always produces shallow output.\n- **Producing variations that answer the same question**: If all 3 variations are different visual treatments of the same layout with the same content hierarchy, you've generated 1 hypothesis with 3 skins.\n- **Treating the brief as optional**: If you skip the brief, you've skipped the skill. The brief is the reasoning. Generation is downstream.\n","# Design Exploration\n\n## Purpose\n\nThis skill ensures the agent performs **problem comprehension before generation** when handling variation requests. Analyze what a component does, what constrains it, and what is meaningfully free to vary — then compose a design brief and pass it to the design subagent. Never skip straight from \"user asked for variations\" to output.\n\nDesign exploration is the divergent phase of an explore\u002Fexploit loop. Each variation should represent a **distinct design hypothesis** — a meaningfully different answer to \"what could this be?\" — not a reskin of the same hypothesis.\n\n## Step 1: Read and Comprehend the Component\n\nRead the selected component's source code and surrounding context (parent layout, route structure, dependencies, styles). Build an internal model of:\n\n- **Function**: What does it do? What user problem does it solve? What's its role in the broader flow?\n- **Content model**: What information does it present or collect? What's the semantic structure?\n- **Interaction model**: How does the user engage with it? What states and transitions exist?\n- **Visual structure**: How is it composed? What are its regions, hierarchy, and spatial relationships?\n- **Context**: Where does it live? What comes before and after? What assumptions does it inherit?\n\n## Step 2: Identify Constraints and Degrees of Freedom\n\nDistinguish between:\n\n- **Hard constraints**: Cannot change without breaking the component (required data fields, accessibility requirements, platform constraints, explicit user decisions).\n- **Soft constraints**: Assumed by the current implementation but reconsidered (a list that could be a grid; a bottom-anchored CTA that could be inline; a formal tone that could be conversational).\n- **Degrees of freedom**: Dimensions along which the design could meaningfully vary.\n\nBe explicit about what you're holding fixed and why.\n\n## Step 3: Select Meaningful Variation Axes\n\nSelect 2–3 axes that produce the most meaningfully different outcomes. The five axis categories:\n\n- **Structural**: Layout, information hierarchy, component decomposition, navigation pattern. Answers: \"What if this were organized differently?\" (e.g., settings as scrolling form vs. tabbed panel vs. progressive wizard)\n- **Content \u002F Semantic**: What's foregrounded, backgrounded, or reframed. Answers: \"What if we emphasized different things?\" (e.g., pricing that leads with features vs. social proof vs. comparison)\n- **Conceptual**: The underlying metaphor or interaction paradigm. Answers: \"What if we thought about this differently?\" (e.g., file manager as spatial desktop vs. conversation vs. timeline)\n- **Behavioral**: State transitions, progressive disclosure, interaction sequencing. Answers: \"What if it behaved differently?\" (e.g., form validates on blur vs. submit vs. inline)\n- **Aesthetic**: Color, typography, spacing, mood, material quality. Answers: \"What if it looked and felt different?\" (e.g., three distinct visual identities for the same card component)\n\n### Selection Heuristic\n\nRead the user's intent to determine where they are in the exploration funnel:\n\n- **\"Generate variations\" \u002F \"show me options\" (no further context)**: The user hasn't specified an axis. Analyze the component to determine which axes have the most unexplored space. For structurally complex components (pages, flows, dashboards), default to structural and conceptual axes. For visually-driven or structurally simple components (cards, heroes, buttons, marketing sections), structural AND aesthetic are both strong first-round choices — lead with whichever produces more meaningfully different outcomes.\n- **User describes a direction but not a form** (\"something more premium,\" \"more playful,\" \"feels enterprise\"): This is an aesthetic\u002Ftonal signal. Explore visual treatment as a primary axis, but pair it with one structural or content axis so the variations aren't just reskins.\n- **User names a specific axis** (\"try different layouts,\" \"what if the copy were different\"): Follow their lead. Pair with one complementary axis that might surface unexpected possibilities.\n- **User is iterating on an established structure** (\"I like this layout, but...\"): Focus on aesthetic and behavioral refinement.\n\nThe goal is progressive funnel narrowing: broad exploration → emerging preferences → focused refinement → final form. Match axis selection to where the user actually is, not to a fixed priority order.\n\n## Step 4: Compose the Design Brief\n\nCompose a structured brief covering: component analysis, constraints (with rationale), chosen variation axes (with rationale), and concrete variation specifications. Each variation spec should name the design hypothesis it represents and describe concretely how it differs from the current implementation.\n\nThis brief — not just the file path — is what you pass to the design subagent. The brief is the primary artifact of this skill.\n\n## Step 5: Delegate with the Brief\n\nYour delegation message to the design subagent must include:\n\n1. The full design brief from Step 4\n2. The source file path(s)\n3. This instruction: \"Each variation should be a distinct design hypothesis. Do not produce variations that differ only in color, font, or spacing unless the brief specifically calls for aesthetic exploration.\"\n\n**Do not just pass the file path. Do not say \"generate 3 variations of this component\" without the brief.**\n\n## Communicating with the User\n\n### Before generation\n\nTell the user what axes you chose to explore and why. Name the design concepts at play so the user builds vocabulary over time. This makes your reasoning legible and gives the user a chance to redirect.\n\nExample: \"I'm going to explore 3 variations of your pricing section. The current design uses a **comparison table** — that's a strong structural choice, so I'll hold it. Instead I'll vary the **content hierarchy** (what information leads the user's eye and shapes their first impression) and the **conceptual framing** (whether the tiers are positioned as good\u002Fbetter\u002Fbest, or as use-case-based recommendations). These are often the highest-leverage dimensions for pricing — small changes in what's foregrounded can significantly shift conversion.\"\n\nIf the user redirects, update the axis selection and re-delegate. The comprehension step doesn't need to repeat.\n\n### After generation\n\nWhen presenting variations, explain what each one teaches about the design problem — not just what it looks like. Frame each variation as a hypothesis with observable trade-offs:\n\n- Name the **design decision** each variation embodies (\"This one foregrounds social proof because...\")\n- Call out the **trade-off** it makes (\"...which builds trust at the cost of information density\")\n- Suggest **what to watch for** when evaluating (\"Notice how your eye moves differently across these — that's the hierarchy at work\")\n\nThe goal is for the user to finish the exploration knowing *more about their design problem* than when they started — not just having picked a favorite variant.\n\n## Anti-Patterns\n\n- **Skipping comprehension**: Going from request to generation without analysis. This always produces shallow output.\n- **Producing variations that answer the same question**: If all 3 variations are different visual treatments of the same layout with the same content hierarchy, you've generated 1 hypothesis with 3 skins.\n- **Treating the brief as optional**: If you skip the brief, you've skipped the skill. The brief is the reasoning. Generation is downstream.\n",{"name":5,"description":7},"6b4a291df75c639681e93b4b5b812126443fd6ed","skills\u002Fdesign-exploration",3,"https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd","https:\u002F\u002Fsolanaclawd.com\u002Fopenclawd","https:\u002F\u002Fgithub.com\u002Fclawdsolana","https:\u002F\u002Fmusebook.trade","Welcome to Open Clawd. The future of Ai on and off chain. Bringing webMCP to web 3 using X402, A2A, MPP and so much more!","2026-08-01 09:30:51",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add clawdsolana\u002FOpenClawd --skill design-exploration",{"tool":69,"command":70},"bunx","bunx skills add clawdsolana\u002FOpenClawd --skill design-exploration",{"tool":72,"command":73},"pnpm","pnpm dlx skills add clawdsolana\u002FOpenClawd --skill design-exploration","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd\u002Fblob\u002Fmain\u002Fskills\u002Fdesign-exploration\u002FSKILL.md",true,[77],{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},".fingerprint","OTHER","其他",32,"https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd\u002Fblob\u002Fmain\u002Fskills\u002Fdesign-exploration\u002F.fingerprint",[84,114,141,167,177,199],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":93,"publishedAt":113},"01M71KRBD0W01EAXJ8YM4M1SJ2","solana-dev","End-to-end Solana development playbook (Jan 2026). Prefer Solana Foundation framework-kit (@solana\u002Fclient + @solana\u002Freact-hooks) for React\u002FNext.js UI. Prefer @solana\u002Fkit for all new client\u002FRPC\u002Ftransaction code. When legacy dependencies require web3.js, isolate it behind @solana\u002Fweb3-compat (or @solana\u002Fweb3.js as a true legacy fallback). Covers wallet-standard-first connection (incl. ConnectorKit), Anchor\u002FPinocchio programs, Codama-based client generation, LiteSVM\u002FMollusk\u002FSurfpool testing, and security checklists.","https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd\u002Fblob\u002Fmain\u002Fsrc\u002Fskills\u002Fsolana-dev\u002FSKILL.md",[90],{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[94,95,96,97,98,99,100,101,102,36,103,104,105,106,107,108,109,110,111,112],"solana dev","dev","solana","Wallet","end","testing","hooks","kit","new","web3","code","react","next","2026","playbook","security","ui","fallback","framework","2026-11-10 10:56:23",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":123,"publishedAt":113},"01M71KR8QPESSY61SVE8ZTFNVT","xurl","A CLI tool for making authenticated requests to the X (Twitter) API. Use this skill when you need to post tweets, reply, quote, search, read posts, manage followers, send DMs, upload media, or interact with any X API v2 endpoint.","https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd\u002Fblob\u002Fmain\u002Fskills\u002Fxurl\u002FSKILL.md",[120],{"categoryNo":121,"categoryName":122,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[116,124,125,126,127,128,129,36,130,131,132,133,134,135,136,137,42,138,139,140],"posts","Media","x api","search","send","tap","you","api","cli","read","install","cli tool","endpoint","brew","manage","tool","twitter",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":148,"publishedAt":113},"01M71KR6FSXV88YDKWP7NBY3SH","wurk-integration","WURK API integration for monetizing agents with x402 payments on Solana\u002FBase - create social jobs, custom challenges, and agent help tasks","https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd\u002Fblob\u002Fmain\u002Fskills\u002Fwurk-integration\u002FSKILL.md",[147],{"categoryNo":121,"categoryName":122,"taxonomyType":21,"taxonomyTypeDesc":22},[149,150,151,152,153,154,155,156,131,157,158,159,160,161,162,163,42,164,165,166],"wurk","wurk integration","integration","x402","social","payments","tasks","team","create","social-jobs","command","agent-help","custom-jobs","clawd","safe","api integration","custom","true",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":173,"publishedAt":113},"01M71KR4HCX41BPAK9GP7RPRRP","workflows","Manage application workflows including configuration, restart, and removal.","https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd\u002Fblob\u002Fmain\u002Fskills\u002Fworkflows\u002FSKILL.md",[],[169,138,174,175,176],"configuration","application","restart",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":183,"publishedAt":113},"01M71KR1VM0F5GPEQDNG5J7A0H","web-search","Search the web, fetch content, extract branding profiles, and capture screenshots from URLs. Use for real-time information, API documentation, current events, design matching, and visual reference.","https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd\u002Fblob\u002Fmain\u002Fskills\u002Fweb-search\u002FSKILL.md",[],[184,127,185,186,187,42,188,189,190,29,37,191,192,131,193,194,195,196,197,198],"web search","web","fetch","api documentation","real-time","time","profiles","information","visual","documentation","branding","matching","reference","capture","content",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":205,"publishedAt":113},"01M71KQZN5MR1JFQHG5GWXYAHS","weather","Get current weather and forecasts via wttr.in or Open-Meteo. Use when: user asks about weather, temperature, or forecasts for any location. NOT for: historical weather data, severe weather alerts, or detailed meteorological analysis. No API key needed.","https:\u002F\u002Fgithub.com\u002Fclawdsolana\u002FOpenClawd\u002Fblob\u002Fmain\u002Fskills\u002Fweather\u002FSKILL.md",[],[201,206,42,207,37,36,33,131,208,209,210,211,212,213,214,215,216,217],"get","open","alerts","temperature","curl","via","help","about","https","location","data","user"]