[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6NVNARMEF2TBYD4FEJNZAP9":3,"skill-same:01M6NVNARMEF2TBYD4FEJNZAP9":80},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6NVNARMEF2TBYD4FEJNZAP9","ui-patterns",null,"Use this skill when the user needs to build a dashboard, settings page, data table, or any page layout. Also use when choosing component libraries, implementing responsive design, dark mode, or handling UI states (loading, empty, error). Covers component selection, page composition, and responsive implementation.","mattonweb\u002Fai-assistant-foundry","mattonweb","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F2309734?v=4","01M6NQYCY846TKYN2ZCRS71WQ7","Matt Johnson","01M6NQYD2NPAQEFVD8TW9W0SVX",1,"MIT","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fdesign-ui\u002Fwhawkinsiv\u002Fui-patterns\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"ui patterns","ui","patterns","layout","dark","implementing","mode","ui states","loading","states","error","dark mode","design","selection","use","page","Composition","libraries","component","dashboard","2026-11-10 10:12:30",false,"---\nname: ui-patterns\ndescription: \"Use this skill when the user needs to build a dashboard, settings page, data table, or any page layout. Also use when choosing component libraries, implementing responsive design, dark mode, or handling UI states (loading, empty, error). Covers component selection, page composition, and responsive implementation.\"\n---\n\n# UI Patterns\n\nThis skill covers how to build pages and compose components for SaaS applications. It provides the structural decisions — which components to use, how to lay out pages, and how to handle every UI state. For visual styling (colors, typography, spacing systems), see the beautify skill. For user flow design, see ux-design. For accessibility requirements (semantic HTML, keyboard nav, ARIA), see ux-design\u002FACCESSIBILITY.md.\n\n## Component Library Selection\n\n**Default: shadcn\u002Fui + Tailwind CSS.** This is the correct choice for 90% of founder-built SaaS apps. shadcn\u002Fui provides copy-paste components built on Radix primitives — you own the code, can customize freely, and avoid dependency lock-in.\n\nDecision framework:\n\n| Situation | Choice | Why |\n|---|---|---|\n| Public-facing SaaS product | shadcn\u002Fui + Tailwind | Full design control, great defaults, accessible |\n| Internal admin tool \u002F back-office | Ant Design or MUI | Dense data display, built-in table\u002Fform patterns, faster to ship |\n| Need one specific primitive (tooltip, dialog) | Radix directly | Skip the styling layer, use just the behavior |\n| Existing MUI\u002FChakra codebase | Stay with current lib | Migration cost rarely worth it mid-project |\n| React Native \u002F mobile app | React Native Paper or Tamagui | Web component libs don't apply |\n\nWhen using shadcn\u002Fui: install components individually (`npx shadcn-ui@latest add button`), don't install everything upfront. Configure the `components.json` path aliases to match the project structure.\n\n## Page Composition Principles\n\nEvery SaaS page follows a predictable anatomy. Structure pages using these content zones:\n\n**Page header** — Title, description, primary action button (top-right). Breadcrumbs above the title if nested. Height: 64-80px.\n\n**Primary content** — The main purpose of the page. Takes 60-70% of width on desktop. This is the \"spine\" — the vertical column the user's eye follows.\n\n**Secondary content** — Supporting information, filters, related items. Sidebar or below primary content. Takes 30-40% width or full-width below on mobile.\n\n**Actions area** — Sticky bottom bar for forms, floating action button, or inline with content. Never hide primary actions in menus.\n\nThe page spine principle: every page has one dominant vertical column. On a dashboard, it's the metrics-to-activity flow. On a settings page, it's the form sections. On a list page, it's the table. Identify the spine and give it visual priority — other content supports it.\n\nStandard page container: `max-w-7xl mx-auto px-4 sm:px-6 lg:px-8`. For content-heavy pages (docs, settings forms): `max-w-3xl`. For full-bleed layouts (dashboards): no max-width, use the sidebar to constrain.\n\n## The State Matrix\n\nEvery data-driven component must handle five states. Missing any one of these creates a broken experience. When building any component that displays dynamic data, implement all five:\n\n### Loading State\nUse skeleton loaders that match the shape of the real content. Never use spinners for inline content — spinners are only for full-page loads or button actions.\n\n- Tables: render 5-8 skeleton rows with column-width-matched blocks\n- Cards: render the card shell with pulsing placeholder blocks\n- Lists: render 3-5 skeleton items\n- Use `animate-pulse` with `bg-muted` blocks. Match heights and widths to actual content.\n\n### Empty State\nThe most neglected state. Every empty state needs: an icon or illustration, a headline explaining what will appear here, a description of how to populate it, and a primary CTA button.\n\n```\nNo projects yet → \"Create your first project\" button\nNo search results → \"Try different keywords\" suggestion\nNo notifications → \"You're all caught up\" message (no CTA needed)\n```\n\nEmpty states are onboarding moments. Use them to teach users what to do next.\n\n### Error State\nDisplay what went wrong in plain language and provide a retry action. Never show raw error codes or stack traces.\n\n- Inline errors: red text below the failed component + retry button\n- Full-page errors: centered message with retry and \"go back\" options\n- Network errors: \"Connection lost. Retrying...\" with auto-retry logic\n- Always preserve user input on form errors — never clear fields\n\n### Success State\nThe normal content display. This is what most developers build first (and sometimes only). Ensure it handles variable content lengths — long titles, missing optional fields, various image aspect ratios.\n\n### Overflow State\nWhat happens when there's too much data:\n\n- Tables: paginate at 10-25 rows, show total count, provide page size selector\n- Lists: infinite scroll or \"Load more\" button. Show count: \"Showing 20 of 148\"\n- Text: truncate with ellipsis and \"Show more\" expand option. Use `line-clamp-2` or `line-clamp-3`\n- Tags\u002Fbadges: show first 3 + \"+N more\" pill\n\n## Responsive Strategy\n\nUse mobile-first with Tailwind's breakpoint system. Default styles target mobile, then layer on complexity:\n\n| Breakpoint | Width | Target |\n|---|---|---|\n| default | 0-639px | Mobile phones |\n| `sm` | 640px+ | Large phones, small tablets |\n| `md` | 768px+ | Tablets |\n| `lg` | 1024px+ | Small laptops, landscape tablets |\n| `xl` | 1280px+ | Desktops |\n| `2xl` | 1536px+ | Large monitors |\n\n**What changes at each breakpoint:**\n\n- **Mobile (default):** Single column. Bottom navigation. Cards stack vertically. Tables become card lists. Sidebar hidden behind hamburger. Modals go full-screen. Horizontal padding: 16px.\n- **sm:** Minor adjustments. Two-column grids where appropriate. Slightly more padding.\n- **md:** Sidebar can appear as collapsible overlay. Tables can show with horizontal scroll. Two or three column grids. Padding: 24px.\n- **lg:** Full sidebar visible. Tables display normally. Multi-column layouts activate. Dashboard grids expand. Padding: 32px.\n- **xl+:** Max-width containers center content. Extra whitespace on sides. Optional: wider sidebar, more columns.\n\n**Key responsive patterns:**\n\n| Desktop Pattern | Mobile Adaptation |\n|---|---|\n| Sidebar navigation | Bottom tab bar (5 items max) or hamburger menu |\n| Data table | Stacked cards with key fields visible |\n| Multi-column grid | Single column, stacked |\n| Side-by-side panels | Tabbed or stacked sections |\n| Hover tooltips | Tap-to-reveal or always-visible labels |\n| Right-click context menu | Long-press menu or action row with icons |\n| Modal dialog | Full-screen sheet sliding up from bottom |\n\nFor the sidebar-to-bottom-nav pattern: don't just hide the sidebar. Build a dedicated `BottomNav` component with 4-5 icon+label items. The items should map to the top-level sidebar sections, not be a 1:1 copy.\n\n## Dark Mode\n\n**When to implement:** If building an MVP for validation, skip dark mode. If building a product users will spend hours in (dashboards, dev tools, writing apps), implement from day 1. Adding dark mode later requires touching every component — it's significantly cheaper to build it in from the start.\n\n**Implementation approach:**\n\n1. Define all colors as CSS custom properties in `:root` and `.dark`\n2. Use Tailwind's `dark:` prefix for overrides\n3. If using shadcn\u002Fui, this is already set up — just configure the theme in `globals.css`\n4. Toggle with a class on `\u003Chtml>` element: `document.documentElement.classList.toggle('dark')`\n5. Respect system preference with `prefers-color-scheme` media query, but let users override\n6. Persist preference in `localStorage`\n\n**What changes beyond swapping background\u002Ftext colors:**\n\n- Shadows: reduce opacity significantly or remove entirely. Dark surfaces don't cast visible shadows — use subtle borders or lighter surface colors to create elevation instead.\n- Borders: increase visibility. Use `border-border` (which maps to a lighter value in dark mode) rather than hardcoded colors.\n- Images and illustrations: reduce brightness slightly (`brightness-90`). Avoid pure-white images on dark backgrounds.\n- Status colors: adjust saturation down and lightness up. A red that works on white won't work on dark gray — it needs to be softer.\n- Hover states: use `hover:bg-muted` rather than hardcoded opacity changes. Light mode hovers darken, dark mode hovers lighten.\n- Focus rings: ensure visibility on dark backgrounds. Default blue rings work; custom colored rings may not.\n\n## Common Mistakes\n\n| Mistake | What to do instead |\n|---|---|\n| Building a custom component library from scratch | Use shadcn\u002Fui. Customize after shipping. |\n| Only implementing the success state | Build all five states (loading, empty, error, success, overflow) for every data component |\n| Using spinners everywhere | Skeleton loaders for inline content, spinners only for page-level or button loading |\n| Fixed layouts that don't respond to screen size | Mobile-first responsive with Tailwind breakpoints, test at 375px width |\n| Hiding critical actions in dropdown menus | Primary actions get dedicated buttons, only secondary\u002Ftertiary go in menus |\n| Pixel-perfect custom breakpoints | Use Tailwind's standard breakpoints — they cover real devices |\n| Dark mode as an afterthought | Decide at project start: implement now or explicitly defer. Don't half-implement. |\n| Tables on mobile with horizontal scroll only | Transform tables into card layouts on mobile, showing key data points |\n| Modals on top of modals | One modal at a time. Use sheets\u002Fslide-outs for secondary actions from a modal. |\n| Inconsistent spacing between sections | Pick a page section gap and stick with it: `space-y-8` for page sections, `space-y-4` within sections |\n","# UI Patterns\n\nThis skill covers how to build pages and compose components for SaaS applications. It provides the structural decisions — which components to use, how to lay out pages, and how to handle every UI state. For visual styling (colors, typography, spacing systems), see the beautify skill. For user flow design, see ux-design. For accessibility requirements (semantic HTML, keyboard nav, ARIA), see ux-design\u002FACCESSIBILITY.md.\n\n## Component Library Selection\n\n**Default: shadcn\u002Fui + Tailwind CSS.** This is the correct choice for 90% of founder-built SaaS apps. shadcn\u002Fui provides copy-paste components built on Radix primitives — you own the code, can customize freely, and avoid dependency lock-in.\n\nDecision framework:\n\n| Situation | Choice | Why |\n|---|---|---|\n| Public-facing SaaS product | shadcn\u002Fui + Tailwind | Full design control, great defaults, accessible |\n| Internal admin tool \u002F back-office | Ant Design or MUI | Dense data display, built-in table\u002Fform patterns, faster to ship |\n| Need one specific primitive (tooltip, dialog) | Radix directly | Skip the styling layer, use just the behavior |\n| Existing MUI\u002FChakra codebase | Stay with current lib | Migration cost rarely worth it mid-project |\n| React Native \u002F mobile app | React Native Paper or Tamagui | Web component libs don't apply |\n\nWhen using shadcn\u002Fui: install components individually (`npx shadcn-ui@latest add button`), don't install everything upfront. Configure the `components.json` path aliases to match the project structure.\n\n## Page Composition Principles\n\nEvery SaaS page follows a predictable anatomy. Structure pages using these content zones:\n\n**Page header** — Title, description, primary action button (top-right). Breadcrumbs above the title if nested. Height: 64-80px.\n\n**Primary content** — The main purpose of the page. Takes 60-70% of width on desktop. This is the \"spine\" — the vertical column the user's eye follows.\n\n**Secondary content** — Supporting information, filters, related items. Sidebar or below primary content. Takes 30-40% width or full-width below on mobile.\n\n**Actions area** — Sticky bottom bar for forms, floating action button, or inline with content. Never hide primary actions in menus.\n\nThe page spine principle: every page has one dominant vertical column. On a dashboard, it's the metrics-to-activity flow. On a settings page, it's the form sections. On a list page, it's the table. Identify the spine and give it visual priority — other content supports it.\n\nStandard page container: `max-w-7xl mx-auto px-4 sm:px-6 lg:px-8`. For content-heavy pages (docs, settings forms): `max-w-3xl`. For full-bleed layouts (dashboards): no max-width, use the sidebar to constrain.\n\n## The State Matrix\n\nEvery data-driven component must handle five states. Missing any one of these creates a broken experience. When building any component that displays dynamic data, implement all five:\n\n### Loading State\nUse skeleton loaders that match the shape of the real content. Never use spinners for inline content — spinners are only for full-page loads or button actions.\n\n- Tables: render 5-8 skeleton rows with column-width-matched blocks\n- Cards: render the card shell with pulsing placeholder blocks\n- Lists: render 3-5 skeleton items\n- Use `animate-pulse` with `bg-muted` blocks. Match heights and widths to actual content.\n\n### Empty State\nThe most neglected state. Every empty state needs: an icon or illustration, a headline explaining what will appear here, a description of how to populate it, and a primary CTA button.\n\n```\nNo projects yet → \"Create your first project\" button\nNo search results → \"Try different keywords\" suggestion\nNo notifications → \"You're all caught up\" message (no CTA needed)\n```\n\nEmpty states are onboarding moments. Use them to teach users what to do next.\n\n### Error State\nDisplay what went wrong in plain language and provide a retry action. Never show raw error codes or stack traces.\n\n- Inline errors: red text below the failed component + retry button\n- Full-page errors: centered message with retry and \"go back\" options\n- Network errors: \"Connection lost. Retrying...\" with auto-retry logic\n- Always preserve user input on form errors — never clear fields\n\n### Success State\nThe normal content display. This is what most developers build first (and sometimes only). Ensure it handles variable content lengths — long titles, missing optional fields, various image aspect ratios.\n\n### Overflow State\nWhat happens when there's too much data:\n\n- Tables: paginate at 10-25 rows, show total count, provide page size selector\n- Lists: infinite scroll or \"Load more\" button. Show count: \"Showing 20 of 148\"\n- Text: truncate with ellipsis and \"Show more\" expand option. Use `line-clamp-2` or `line-clamp-3`\n- Tags\u002Fbadges: show first 3 + \"+N more\" pill\n\n## Responsive Strategy\n\nUse mobile-first with Tailwind's breakpoint system. Default styles target mobile, then layer on complexity:\n\n| Breakpoint | Width | Target |\n|---|---|---|\n| default | 0-639px | Mobile phones |\n| `sm` | 640px+ | Large phones, small tablets |\n| `md` | 768px+ | Tablets |\n| `lg` | 1024px+ | Small laptops, landscape tablets |\n| `xl` | 1280px+ | Desktops |\n| `2xl` | 1536px+ | Large monitors |\n\n**What changes at each breakpoint:**\n\n- **Mobile (default):** Single column. Bottom navigation. Cards stack vertically. Tables become card lists. Sidebar hidden behind hamburger. Modals go full-screen. Horizontal padding: 16px.\n- **sm:** Minor adjustments. Two-column grids where appropriate. Slightly more padding.\n- **md:** Sidebar can appear as collapsible overlay. Tables can show with horizontal scroll. Two or three column grids. Padding: 24px.\n- **lg:** Full sidebar visible. Tables display normally. Multi-column layouts activate. Dashboard grids expand. Padding: 32px.\n- **xl+:** Max-width containers center content. Extra whitespace on sides. Optional: wider sidebar, more columns.\n\n**Key responsive patterns:**\n\n| Desktop Pattern | Mobile Adaptation |\n|---|---|\n| Sidebar navigation | Bottom tab bar (5 items max) or hamburger menu |\n| Data table | Stacked cards with key fields visible |\n| Multi-column grid | Single column, stacked |\n| Side-by-side panels | Tabbed or stacked sections |\n| Hover tooltips | Tap-to-reveal or always-visible labels |\n| Right-click context menu | Long-press menu or action row with icons |\n| Modal dialog | Full-screen sheet sliding up from bottom |\n\nFor the sidebar-to-bottom-nav pattern: don't just hide the sidebar. Build a dedicated `BottomNav` component with 4-5 icon+label items. The items should map to the top-level sidebar sections, not be a 1:1 copy.\n\n## Dark Mode\n\n**When to implement:** If building an MVP for validation, skip dark mode. If building a product users will spend hours in (dashboards, dev tools, writing apps), implement from day 1. Adding dark mode later requires touching every component — it's significantly cheaper to build it in from the start.\n\n**Implementation approach:**\n\n1. Define all colors as CSS custom properties in `:root` and `.dark`\n2. Use Tailwind's `dark:` prefix for overrides\n3. If using shadcn\u002Fui, this is already set up — just configure the theme in `globals.css`\n4. Toggle with a class on `\u003Chtml>` element: `document.documentElement.classList.toggle('dark')`\n5. Respect system preference with `prefers-color-scheme` media query, but let users override\n6. Persist preference in `localStorage`\n\n**What changes beyond swapping background\u002Ftext colors:**\n\n- Shadows: reduce opacity significantly or remove entirely. Dark surfaces don't cast visible shadows — use subtle borders or lighter surface colors to create elevation instead.\n- Borders: increase visibility. Use `border-border` (which maps to a lighter value in dark mode) rather than hardcoded colors.\n- Images and illustrations: reduce brightness slightly (`brightness-90`). Avoid pure-white images on dark backgrounds.\n- Status colors: adjust saturation down and lightness up. A red that works on white won't work on dark gray — it needs to be softer.\n- Hover states: use `hover:bg-muted` rather than hardcoded opacity changes. Light mode hovers darken, dark mode hovers lighten.\n- Focus rings: ensure visibility on dark backgrounds. Default blue rings work; custom colored rings may not.\n\n## Common Mistakes\n\n| Mistake | What to do instead |\n|---|---|\n| Building a custom component library from scratch | Use shadcn\u002Fui. Customize after shipping. |\n| Only implementing the success state | Build all five states (loading, empty, error, success, overflow) for every data component |\n| Using spinners everywhere | Skeleton loaders for inline content, spinners only for page-level or button loading |\n| Fixed layouts that don't respond to screen size | Mobile-first responsive with Tailwind breakpoints, test at 375px width |\n| Hiding critical actions in dropdown menus | Primary actions get dedicated buttons, only secondary\u002Ftertiary go in menus |\n| Pixel-perfect custom breakpoints | Use Tailwind's standard breakpoints — they cover real devices |\n| Dark mode as an afterthought | Decide at project start: implement now or explicitly defer. Don't half-implement. |\n| Tables on mobile with horizontal scroll only | Transform tables into card layouts on mobile, showing key data points |\n| Modals on top of modals | One modal at a time. Use sheets\u002Fslide-outs for secondary actions from a modal. |\n| Inconsistent spacing between sections | Pick a page section gap and stick with it: `space-y-8` for page sections, `space-y-4` within sections |\n",{"name":5,"description":7},"main","d8518247cb8ab8b2dac57a6be33543ffd23b97c5","design-ui\u002Fwhawkinsiv\u002Fui-patterns",0,"https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry","https:\u002F\u002Fgithub.com\u002Fmattonweb","2026-05-29 08:42:23",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add mattonweb\u002Fai-assistant-foundry --skill ui-patterns",{"tool":62,"command":63},"bunx","bunx skills add mattonweb\u002Fai-assistant-foundry --skill ui-patterns",{"tool":65,"command":66},"pnpm","pnpm dlx skills add mattonweb\u002Fai-assistant-foundry --skill ui-patterns","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fdesign-ui\u002Fwhawkinsiv\u002Fui-patterns\u002FSKILL.md",true,[70,76],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"COMPONENTS.md","REFERENCE","参考文档",14265,"https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fdesign-ui\u002Fwhawkinsiv\u002Fui-patterns\u002FCOMPONENTS.md",{"path":77,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":78,"sourceHtmlUrl":79},"LAYOUTS.md",23339,"https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fdesign-ui\u002Fwhawkinsiv\u002Fui-patterns\u002FLAYOUTS.md",[81,113,127,147,168,194],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":95,"publishedAt":44},"01M6P02DENRHN6KVGYC55FKASJ","writing-clearly-and-concisely","Use when writing prose humans will read—documentation, commit messages, error messages, explanations, reports, or UI text. Applies Strunk's timeless rules for clearer, stronger, more professional writing.","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fwrite-technical\u002Fsoftaworks\u002Fwriting-clearly-and-concisely\u002FSKILL.md",[87,92],{"categoryNo":88,"categoryName":89,"taxonomyType":90,"taxonomyTypeDesc":91},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":93,"categoryName":94,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000036","内容创作者",[96,97,98,99,100,101,102,34,103,104,105,38,106,107,108,109,110,25,111,112],"writing clearly and concisely","writing","concisely","text","for","more","timeless","professional","prose","reports","read","Rules","commit messages","messages","error messages","documentation","commit",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":44},"01M6P0286HZ8RWMFCCPC8HF7SC","crafting-effective-readmes","Use when writing or improving README files. Not all READMEs are the same — provides templates and guidance matched to your audience and project type.","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fwrite-technical\u002Fsoftaworks\u002Fcrafting-effective-readmes\u002FSKILL.md",[],[120,121,97,122,123,38,124,125,126],"crafting effective readmes","README","templates","type","project","guidance","files",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":136,"publishedAt":44},"01M6P025A41BBTPWVTZ3GFQVG6","wiki-architect","You are a documentation architect that produces structured wiki catalogues and onboarding guides from codebases.","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fwrite-technical\u002Fsickn33\u002Fwiki-architect\u002FSKILL.md",[133],{"categoryNo":134,"categoryName":135,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000038","人力资源",[137,138,139,140,141,142,143,144,145,146,111],"wiki","architect","wiki architect","unknown","you","documentation architect","guides","structured","community","onboarding",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":44},"01M6P01NSKPXP77NWB4K0PXRK5","readme","You are an expert technical writer creating comprehensive project documentation. Your goal is to write a README.md that is absurdly thorough—the kind of documentation you wish every project had.","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fwrite-technical\u002Fsickn33\u002Freadme\u002FSKILL.md",[],[121,154,155,156,141,157,158,124,159,160,49,161,162,163,164,165,111,166,167],"project documentation","tree","kind","expert","github","wish","writer","goal","write","technical writer","technical","https","write a readme","safe",{"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":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":174,"publishedAt":44},"01M6P01GP0NEN8KT3A3SA6ZFVE","ubiquitous-language","Extract a DDD-style ubiquitous language glossary from the current conversation, flagging ambiguities and proposing canonical terms. Saves to UBIQUITOUS_LANGUAGE.md. Use when user wants to define domain terms, build a glossary, harden terminology, create a ubiquitous language, or mentions \"domain model\" or \"DDD\".","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fwrite-technical\u002Fmattpocock\u002Fubiquitous-language\u002FSKILL.md",[],[175,176,38,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193],"ubiquitous language","language","extract","user","glossary","model","terms","ddd","create","build","true","canonical","style","define","harden","domain model","domain","terminology","conversation",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":202,"publishedAt":44},"01M6P01BJBP9XP4TDRT7QD1ZVA","technical-writing-style","Enforce clear, direct writing in software development documents including OKRs, PRDs, tech specs, architecture decision records (ADRs), git commit messages, PR descriptions, READMEs, changelogs, runbooks, incident postmortems, API docs, and onboarding guides. Trigger whenever a user asks to write, edit, revise, or review any of these document types. Also trigger when the user says writing \"sounds like AI\", \"feels robotic\", \"needs polish\", or asks to \"make it sound more natural\" in the context of technical or professional prose. Do not trigger for fiction, poetry, creative writing, academic papers, or legal documents unless the user explicitly asks for a more natural tone.","https:\u002F\u002Fgithub.com\u002Fmattonweb\u002Fai-assistant-foundry\u002Fblob\u002Fmain\u002Fwrite-technical\u002Fmattnebr\u002Ftechnical-writing-style\u002FSKILL.md",[200,201],{"categoryNo":88,"categoryName":89,"taxonomyType":90,"taxonomyTypeDesc":91},{"categoryNo":93,"categoryName":94,"taxonomyType":21,"taxonomyTypeDesc":22},[203,204,187,164,97,205,103,206,207,208,209,210,211,212,213,109,214,215,112,216],"writing style","technical writing style","technical writing","papers","types","runbooks","software development","incident","Poetry","decision","api","documents","architecture","review"]