[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71N0W779GGGS1BABFX7BB5S":3,"skill-same:01M71N0W779GGGS1BABFX7BB5S":95},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":15,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":67,"commitSha":68,"skillDirectory":69,"forksCount":70,"repositoryHtmlUrl":71,"repositoryHomepageUrl":72,"ownerHtmlUrl":73,"ownerBlogUrl":74,"ownerDescription":6,"updatedAt":75,"install":76,"resources":89},"01M71N0W779GGGS1BABFX7BB5S","frontend-design-direction",null,"Use when a working web UI reads as generic and needs an explicit direction first: purpose, audience, tone and one memorable detail, before styling. ECC's design-direction checklist; for studio-style visual design guidance use frontend-design.","monoes\u002Fmonomind","monoes","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F276744696?v=4","01M71KWF37AJ2NJBP3KWBVSDGT","01M71KWF4CSF8ADH0M6HA09VD2",23,"MIT","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Ffrontend-design-direction\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Ffrontend-design-direction\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"design direction","frontend","frontend design direction","design","frontend design","direction","visual design","web ui","tone","one","visual","studio","when","detail","use","fix","for","frontend-design","generic","as","2026-11-10 10:56:23",false,"---\nname: frontend-design-direction\ndescription: \"Use when a working web UI reads as generic and needs an explicit direction first: purpose, audience, tone and one memorable detail, before styling. ECC's design-direction checklist; for studio-style visual design guidance use frontend-design.\"\ntags: [\"design\",\"frontend\",\"ui\",\"ux\"]\ntools: [\"monodesign_detect\",\"monodesign_fix\",\"monodesign_palette\"]\nlicense: MIT\nsource: https:\u002F\u002Fgithub.com\u002Faffaan-m\u002FECC\nsource_path: \"skills\u002Ffrontend-design-direction\"\nsource_commit: bf70150eb2df8070024e5bdf08e4aa08959e2735\n---\n# Frontend Design Direction\n\nUse this skill when the work is not just making UI function, but making it feel\npurposeful, polished, and appropriate to the product domain.\n\nSource: salvaged from stale community PR #1659 by `linus707`.\n\nNote: ECC intentionally does not rebundle the canonical Anthropic\n`frontend-design` skill. Install that from `anthropics\u002Fskills` when you want the\nofficial upstream skill. This skill is the ECC-specific design-direction salvage\nof the useful local guidance from #1659.\n\n## When to Use\n\n- The user asks to build a web page, app, dashboard, artifact, component, or UI.\n- The user asks to make an interface more polished, distinctive, beautiful, or\n  less generic.\n- The implementation needs visual hierarchy, typography, color, motion, layout,\n  and interaction choices.\n- The current UI works but reads as flat, generic, templated, or mismatched to\n  the audience.\n\n## Design Direction\n\nBefore coding, choose a specific direction:\n\n1. Purpose: what job does the interface do?\n2. Audience: who repeats this workflow, and what do they need to scan first?\n3. Tone: utilitarian, editorial, playful, industrial, refined, technical,\n   maximal, minimal, dense, calm, or another explicit direction.\n4. Memorable detail: one design idea that makes the result feel intentional.\n5. Constraints: framework, accessibility, performance, responsiveness, and\n   existing design system.\n\nMatch the direction to the domain. A SaaS operations tool should usually be\ndense, quiet, and scannable. A portfolio, launch page, game, or editorial piece\ncan be more expressive. Do not force a landing-page composition onto a tool that\nneeds repeated daily use.\n\n## Implementation Guidance\n\n- Build the actual usable experience as the first screen unless the user\n  explicitly asks for marketing copy.\n- Use existing project components, tokens, icon libraries, and routing patterns\n  before introducing a new visual system.\n- Use real or generated visual assets when the interface depends on images,\n  products, places, people, gameplay, charts, or inspectable media.\n- Prefer contextual typography and spacing over generic oversized hero text.\n- Keep palettes multi-dimensional: avoid a UI dominated by one hue family.\n- Use CSS variables or existing design tokens so the direction remains\n  coherent across states.\n- Design responsive constraints explicitly: grids, aspect ratios, min\u002Fmax\n  sizes, stable toolbars, and fixed-format controls should not shift when labels\n  or hover states appear.\n- Use motion sparingly but deliberately. Prefer high-signal transitions that\n  clarify state over decorative animation.\n- Verify text fit on mobile and desktop. Long labels must wrap or resize\n  cleanly rather than overflowing.\n\n## Anti-Patterns\n\n- Do not default to common generated patterns: purple gradients, decorative\n  blobs, oversized cards, vague hero copy, or stock-like atmospheric media.\n- Do not add UI cards inside other cards.\n- Do not use a single decorative style everywhere when the domain calls for\n  restraint.\n- Do not hide the primary product, tool, object, or workflow behind generic\n  marketing sections.\n- Do not add a new dependency for a design flourish unless it clearly pays for\n  itself.\n- Do not describe the UI's features inside the UI when the controls can speak\n  for themselves.\n\n## Review Checklist\n\n- The first viewport immediately communicates the product, workflow, or object.\n- The visual hierarchy supports scanning and repeated use.\n- Typography fits the container and does not overlap adjacent content.\n- Color choices have contrast and do not collapse into a one-note palette.\n- Icons are used for familiar tool actions where available.\n- Responsive layout has stable dimensions for boards, grids, toolbars,\n  controls, tiles, and counters.\n- Assets render and carry the subject matter instead of acting as filler.\n- Motion improves orientation and does not mask sluggishness.\n- The result matches the repo's existing frontend conventions unless there is a\n  clear reason to depart.\n","# Frontend Design Direction\n\nUse this skill when the work is not just making UI function, but making it feel\npurposeful, polished, and appropriate to the product domain.\n\nSource: salvaged from stale community PR #1659 by `linus707`.\n\nNote: ECC intentionally does not rebundle the canonical Anthropic\n`frontend-design` skill. Install that from `anthropics\u002Fskills` when you want the\nofficial upstream skill. This skill is the ECC-specific design-direction salvage\nof the useful local guidance from #1659.\n\n## When to Use\n\n- The user asks to build a web page, app, dashboard, artifact, component, or UI.\n- The user asks to make an interface more polished, distinctive, beautiful, or\n  less generic.\n- The implementation needs visual hierarchy, typography, color, motion, layout,\n  and interaction choices.\n- The current UI works but reads as flat, generic, templated, or mismatched to\n  the audience.\n\n## Design Direction\n\nBefore coding, choose a specific direction:\n\n1. Purpose: what job does the interface do?\n2. Audience: who repeats this workflow, and what do they need to scan first?\n3. Tone: utilitarian, editorial, playful, industrial, refined, technical,\n   maximal, minimal, dense, calm, or another explicit direction.\n4. Memorable detail: one design idea that makes the result feel intentional.\n5. Constraints: framework, accessibility, performance, responsiveness, and\n   existing design system.\n\nMatch the direction to the domain. A SaaS operations tool should usually be\ndense, quiet, and scannable. A portfolio, launch page, game, or editorial piece\ncan be more expressive. Do not force a landing-page composition onto a tool that\nneeds repeated daily use.\n\n## Implementation Guidance\n\n- Build the actual usable experience as the first screen unless the user\n  explicitly asks for marketing copy.\n- Use existing project components, tokens, icon libraries, and routing patterns\n  before introducing a new visual system.\n- Use real or generated visual assets when the interface depends on images,\n  products, places, people, gameplay, charts, or inspectable media.\n- Prefer contextual typography and spacing over generic oversized hero text.\n- Keep palettes multi-dimensional: avoid a UI dominated by one hue family.\n- Use CSS variables or existing design tokens so the direction remains\n  coherent across states.\n- Design responsive constraints explicitly: grids, aspect ratios, min\u002Fmax\n  sizes, stable toolbars, and fixed-format controls should not shift when labels\n  or hover states appear.\n- Use motion sparingly but deliberately. Prefer high-signal transitions that\n  clarify state over decorative animation.\n- Verify text fit on mobile and desktop. Long labels must wrap or resize\n  cleanly rather than overflowing.\n\n## Anti-Patterns\n\n- Do not default to common generated patterns: purple gradients, decorative\n  blobs, oversized cards, vague hero copy, or stock-like atmospheric media.\n- Do not add UI cards inside other cards.\n- Do not use a single decorative style everywhere when the domain calls for\n  restraint.\n- Do not hide the primary product, tool, object, or workflow behind generic\n  marketing sections.\n- Do not add a new dependency for a design flourish unless it clearly pays for\n  itself.\n- Do not describe the UI's features inside the UI when the controls can speak\n  for themselves.\n\n## Review Checklist\n\n- The first viewport immediately communicates the product, workflow, or object.\n- The visual hierarchy supports scanning and repeated use.\n- Typography fits the container and does not overlap adjacent content.\n- Color choices have contrast and do not collapse into a one-note palette.\n- Icons are used for familiar tool actions where available.\n- Responsive layout has stable dimensions for boards, grids, toolbars,\n  controls, tiles, and counters.\n- Assets render and carry the subject matter instead of acting as filler.\n- Motion improves orientation and does not mask sluggishness.\n- The result matches the repo's existing frontend conventions unless there is a\n  clear reason to depart.\n",{"name":5,"tags":57,"tools":60,"source":64,"license":14,"description":7,"source_path":65,"source_commit":66},[35,33,58,59],"ui","ux",[61,62,63],"monodesign_detect","monodesign_fix","monodesign_palette","https:\u002F\u002Fgithub.com\u002Faffaan-m\u002FECC","skills\u002Ffrontend-design-direction","bf70150eb2df8070024e5bdf08e4aa08959e2735","main","f7cd4595d0f8959822163e14f9787117765c931a","packages\u002F@monomind\u002Fcli\u002Forg-skills\u002Ffrontend-design-direction",2,"https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind","https:\u002F\u002Fmonoes.github.io\u002Fmonomind\u002F","https:\u002F\u002Fgithub.com\u002Fmonoes","https:\u002F\u002Fmonoes.me","2026-11-10 01:53:48",{"source":8,"skillName":5,"commands":77,"prompt":87,"zipAvailable":88},[78,81,84],{"tool":79,"command":80},"npx","npx skills add monoes\u002Fmonomind --skill frontend-design-direction",{"tool":82,"command":83},"bunx","bunx skills add monoes\u002Fmonomind --skill frontend-design-direction",{"tool":85,"command":86},"pnpm","pnpm dlx skills add monoes\u002Fmonomind --skill frontend-design-direction","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Ffrontend-design-direction\u002FSKILL.md",true,[90],{"path":91,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":94,"sourceHtmlUrl":15},"LICENSE.txt","LICENSE","许可证",1071,[96,124,155,181,205,232],{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":100,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":123},"01M71PB3SHWKMNJM6MD65VX8D6","zk-steward","Org role guidance for a ZK steward: engineer zero-knowledge proof systems with circuit design, SNARK vs STARK choice and security review. This is zero-knowledge cryptography, not Zettelkasten note-taking.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fzk-steward\u002FSKILL.md",[],[104,105,106,107,108,109,35,110,111,112,113,114,115,116,117,118,119,120,121,122],"zk","zk steward","steward","zero-knowledge","engineer","choice","knowledge","impact","query","snark","review","monomind","security review","stark","zettelkasten","cryptography","security","org","blockchain","2026-11-10 13:02:02",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":128,"sourceHtmlUrl":129,"categories":130,"keywords":137,"publishedAt":123},"01M71PB18SDG28WBKPKJNB814K","writing-plans","Use when you have a spec or requirements for a multi-step coding task and must write an implementation plan before touching code. Produces bite-sized TDD tasks with exact file paths, code and commands for an engineer with zero context.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwriting-plans\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwriting-plans\u002FSKILL.md",[131,134],{"categoryNo":132,"categoryName":133,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":135,"categoryName":136,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000036","内容创作者",[138,139,140,108,141,142,44,143,112,144,145,146,147,148,149,150,151,152,153,154],"writing","writing plans","plans","superpowers","implementation plan","you","code","tasks","plan","product","write","commands","paths","suggest","coding","context","ZeRO",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":100,"licenseFileUrl":159,"sourceHtmlUrl":160,"categories":161,"keywords":165,"publishedAt":123},"01M71PAXFM488X9ARXK0T04TF5","write-spec","Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea or user request into a structured document, scoping a feature with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec\u002FSKILL.md",[162],{"categoryNo":163,"categoryName":164,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000031","产品经理",[148,166,167,168,169,110,170,44,171,172,173,147,174,175,176,177,178,179,46,180],"write spec","spec","user request","problem","acceptance","ask","vague","work","request","scoping","idea","metrics","feature","problem statement","document",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":100,"licenseFileUrl":185,"sourceHtmlUrl":186,"categories":187,"keywords":191,"publishedAt":123},"01M71PASSZY800C0RPEARBS918","write-query","Write optimized SQL for your dialect with best practices. Use when translating a natural-language data need into SQL, building a multi-CTE query with joins and aggregations, optimizing a query against a large partitioned table, or getting dialect-specific syntax for Snowflake, BigQuery, Postgres, etc.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query\u002FSKILL.md",[188],{"categoryNo":189,"categoryName":190,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000033","数据分析师",[112,148,192,193,48,194,110,46,44,195,196,197,198,173,199,200,201,202,203,204],"write query","postgres","snowflake","best practices","natural-language","with","multi","github","sql","https","syntax","plugins","data",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":100,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":217,"publishedAt":123},"01M71PAPTX0T3PF6ETFVR96SJJ","workflow-automation","Org role guidance for workflow automation: build and maintain CI\u002FCD definitions in GitHub Actions or equivalent: triggers, jobs, matrices, caching. Covers path filters, dependency caching, parallel jobs, timeouts and fail-fast ordering.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworkflow-automation\u002FSKILL.md",[211,214],{"categoryNo":212,"categoryName":213,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":215,"categoryName":216,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[218,219,220,221,48,222,223,224,225,111,226,227,228,112,115,199,229,230,231,201],"Workflow Automation","automation","workflow","parallel","actions","ci","triggers","github actions","maintain","filters","caching","build","dependency","devops",{"skillNo":233,"name":234,"nameZh":6,"description":235,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":100,"licenseFileUrl":6,"sourceHtmlUrl":236,"categories":237,"keywords":239,"publishedAt":123},"01M71PAM19Z1XTV9NPCFSE2MY8","workflow-architect","Org role guidance for a workflow architect: map full workflow trees for systems, user journeys and agents, covering every branch and failure. Covers discovering workflows from code, handoff contracts, timeouts, recovery paths and observable state.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworkflow-architect\u002FSKILL.md",[238],{"categoryNo":215,"categoryName":216,"taxonomyType":21,"taxonomyTypeDesc":22},[220,240,241,242,243,244,245,48,246,247,144,248,249,250,115,199,251,252,201,253],"workflow architect","architect","trees","user journeys","branch","planning","map","workflows","architecture","state","leadership","recovery","operations","systems"]