[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JP85E28CE8FWRBXH1YXT3G":3,"skill-same:01M6JP85E28CE8FWRBXH1YXT3G":95},{"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":34,"publishedAt":55,"linkOnly":56,"markdownContent":57,"markdownBody":58,"frontMatter":59,"refName":60,"commitSha":61,"skillDirectory":62,"forksCount":14,"repositoryHtmlUrl":63,"repositoryHomepageUrl":6,"ownerHtmlUrl":64,"ownerBlogUrl":6,"ownerDescription":65,"updatedAt":66,"install":67,"resources":80},"01M6JP85E28CE8FWRBXH1YXT3G","frontend-architecture",null,"Design frontend architecture — React component hierarchy, state management, design tokens, data fetching, routing, error boundaries, code organization. Triggers: component architecture, state management, design system, design tokens, component library, React structure, folder structure, Zustand vs Redux, React Query, code splitting, error boundary, compound component.","SWEStash\u002Fswe-workflow-skills","SWEStash","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F272895713?v=4","01M6JNRQ84JN5WFK9S1V5H4G46","SWE Stash","01M6JNRQCM45X8WPNHY30TSAB0",1,"MIT","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fdesigner\u002Fskills\u002Ffrontend-architecture\u002FSKILL.md",[18,23,26,29],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"architecture","frontend architecture","frontend","library","data fetching","design frontend","error","structure","organization","query","folder structure","zustand","data","component library","component architecture","code","design system","component","react","design","2026-11-10 10:12:30",false,"---\nname: frontend-architecture\ndescription: \"Design frontend architecture — React component hierarchy, state management, design tokens, data fetching, routing, error boundaries, code organization. Triggers: component architecture, state management, design system, design tokens, component library, React structure, folder structure, Zustand vs Redux, React Query, code splitting, error boundary, compound component.\"\n---\n\n# Frontend Architecture\n\nDesign the technical structure of frontend applications — component hierarchy, state management, data fetching, and code organization. Good frontend architecture makes features easy to build, bugs easy to find, and the codebase easy to onboard into.\n\n## Core Principle\n\n**Colocation over separation.** Keep related things together. A component's styles, tests, types, and stories should live next to the component, not in separate `\u002Fstyles`, `\u002Ftests`, `\u002Ftypes` directories. Separation by file type creates coupling across the filesystem; separation by feature creates independence.\n\n## Workflow\n\n### Step 0: Inventory What Already Exists\n\nIn an existing codebase, establish what the app already provides before adding a\nnew component, hook, store, or token. Search the shared surfaces **directly** —\n`components\u002F`, `hooks\u002F`, `lib\u002F`, the token file, and each feature's public\n`index.ts` — rather than inferring from the design or from memory.\n\nCover both:\n\n- **Artifacts** — existing components, hooks, stores, and tokens that already\n  cover, or nearly cover, the need. Search by behavior, not just by name: the\n  component you want often exists under a different label.\n- **Written decisions** — established conventions, the design system's rules,\n  and prior audit findings.\n\n**Exit condition** — one line, then keep going in the same response:\n*\"`\u003Cexisting component\u002Fhook>` already covers `\u003Cbehavior>`; it does \u002F does not\nserve this because `\u003Creason>`.\"*\n\n**This step is not a gate on delivering.** Greenfield — a new app, or a codebase\nyou can't reach — closes it in one line: say so and go straight to Step 1. When\nyou can't inspect, name what you would check and continue under stated\nassumptions. Never answer with inventory and questions alone; produce the\narchitecture in the same reply.\n\nThis constrains the input, not the choice. A new component is a fine outcome; an\nunexamined one isn't — a near-duplicate of an existing one is how design systems\nrot.\n\n### Step 1: Design the Component Hierarchy\n\nStart from the UI design (or the screen spec from `ui-ux-design`) and decompose into components:\n\n1. **Identify the visual boundaries** — Draw boxes around distinct UI regions\n2. **Apply the single-responsibility principle** — Each component does one thing\n3. **Identify reusability** — Which components appear in multiple places?\n4. **Define the tree** — Parent → child relationships\n\nComponent classification:\n- **Page components**: Route-level, fetch data, compose layout\n- **Feature components**: Implement a business feature (UserProfile, OrderSummary)\n- **UI components**: Reusable, no business logic (Button, Card, Modal, Input)\n- **Layout components**: Structure only (Sidebar, Grid, Stack, Container)\n\nSee [references\u002Fcomponent-patterns.md](references\u002Fcomponent-patterns.md) for design patterns.\n\n### Step 2: Plan State Management\n\nState management is the most impactful architectural decision in a React app. Apply the state placement ladder — use the simplest option that works:\n\n```\n1. Local state (useState)           → Simplest. Use for UI state within a component.\n2. Lifted state (parent useState)   → Share between siblings via parent.\n3. Composition (children prop)      → Avoid prop drilling with component composition.\n4. Context                          → Share across distant components (theme, auth, locale).\n5. URL state (query params)         → Shareable, bookmarkable state (filters, pagination).\n6. Server state (React Query \u002F SWR) → Data from API with caching + refetching.\n7. Global store (Zustand \u002F Redux)   → Client state shared across many unrelated components.\n```\n\n**Decision rules:**\n- If it's only used in one component → `useState`\n- If shared between parent\u002Fchild → lift state up\n- If shared across distant components but rarely changes → Context\n- If it comes from the server → React Query \u002F SWR \u002F TanStack Query (NOT global store)\n- If it's complex client state updated from many places → Zustand or Redux Toolkit\n- If it should survive a page refresh → URL params or localStorage\n\nSee [references\u002Fcomponent-patterns.md](references\u002Fcomponent-patterns.md) for detailed guidance.\n\n### Step 3: Define Design Tokens\n\nDesign tokens are the foundation of visual consistency. Define tokens before building components:\n\n```typescript\n\u002F\u002F tokens.ts\nexport const tokens = {\n  color: {\n    primary: { 50: '#eff6ff', 500: '#3b82f6', 700: '#1d4ed8' },\n    neutral: { 50: '#f9fafb', 200: '#e5e7eb', 800: '#1f2937' },\n    success: '#10b981',\n    warning: '#f59e0b',\n    error: '#ef4444',\n  },\n  spacing: { xs: '0.25rem', sm: '0.5rem', md: '1rem', lg: '1.5rem', xl: '2rem' },\n  radius: { sm: '0.25rem', md: '0.5rem', lg: '1rem', full: '9999px' },\n  fontSize: { sm: '0.875rem', base: '1rem', lg: '1.125rem', xl: '1.25rem' },\n  shadow: {\n    sm: '0 1px 2px rgba(0,0,0,0.05)',\n    md: '0 4px 6px rgba(0,0,0,0.1)',\n  },\n};\n```\n\nUse tokens everywhere — never hardcode `#3b82f6` or `16px` in a component.\n\n### Step 4: Design the Data Fetching Strategy\n\nChoose patterns based on the data's nature:\n\n| Data Pattern | Approach | When |\n|-------------|----------|------|\n| Server data (read) | TanStack Query \u002F SWR | Lists, details, dashboards |\n| Server data (mutate) | TanStack Query mutations | Create, update, delete |\n| Real-time data | WebSocket + state sync | Chat, notifications, live dashboards |\n| Form data | React Hook Form \u002F Formik | Any form |\n| Static data | Build-time fetch (SSG) | Blog posts, docs, marketing pages |\n\nKey rules:\n- **Separate server state from client state.** Server state lives in the query cache, not in Redux.\n- **Fetch at the route level** when possible. Components receive data as props, not fetch their own.\n- **Handle loading, error, and empty** at every fetch boundary. Use error boundaries for unexpected errors.\n\n### Step 5: Organize the Codebase\n\nRecommended structure — feature-based with shared library:\n\n```\nsrc\u002F\n├── app\u002F                    # App-level: providers, routing, global config\n│   ├── providers.tsx       # All context providers composed\n│   ├── router.tsx          # Route definitions\n│   └── layout.tsx          # Root layout\n├── features\u002F               # Feature modules (the meat of the app)\n│   ├── auth\u002F\n│   │   ├── components\u002F     # Feature-specific components\n│   │   ├── hooks\u002F          # Feature-specific hooks\n│   │   ├── api.ts          # API calls for this feature\n│   │   ├── types.ts        # Types for this feature\n│   │   └── index.ts        # Public API (barrel file)\n│   ├── projects\u002F\n│   └── settings\u002F\n├── components\u002F             # Shared UI components (Button, Modal, etc.)\n│   ├── ui\u002F                 # Atomic UI primitives\n│   └── layout\u002F             # Layout components (Sidebar, Stack)\n├── hooks\u002F                  # Shared hooks (useDebounce, useMediaQuery)\n├── lib\u002F                    # Shared utilities, API client, tokens\n│   ├── api-client.ts\n│   ├── tokens.ts\n│   └── utils.ts\n└── types\u002F                  # Shared types\n```\n\nRules:\n- Features import from `components\u002F` and `lib\u002F`, never from other features\n- Features export a clean public API through their `index.ts`\n- Circular imports between features means a responsibility boundary is wrong\n\nUse [templates\u002Ffolder-structure.md](templates\u002Ffolder-structure.md) as a starting point — includes the full `src\u002F` layout, a co-located component template, design tokens, and a custom hook pattern.\n\n### Step 6: Validate the Architecture\n\n- [ ] Can a new engineer understand where to add a new feature?\n- [ ] Can you delete a feature directory without breaking unrelated features?\n- [ ] Is server state separate from client state?\n- [ ] Are components reusable without bringing business logic along?\n- [ ] Is there one clear way to do common tasks (fetching, forms, navigation)?\n- [ ] Are design tokens used consistently (no hardcoded values)?\n- [ ] Does every library this design adds (state, fetching, routing, UI kit) carry `dependency-management`'s Step 1 verdict: own module, adopt, or ask the user?\n\n## Principles Applied\n\n- **KISS**: Use `useState` until you need something more. Don't reach for Redux on day one.\n- **DRY**: Shared UI components in `components\u002F`, shared hooks in `hooks\u002F`. Feature-specific code in features.\n- **Functional Independence**: Features don't know about each other. Shared dependencies go in `lib\u002F` or `components\u002F`.\n- **YAGNI**: Don't abstract until you have 2+ consumers. A single-use component doesn't need to be in the shared library.\n- **Separation of Concerns**: Components render UI. Hooks manage state and side effects. API modules handle HTTP. Types define shapes. Keep them apart.\n","# Frontend Architecture\n\nDesign the technical structure of frontend applications — component hierarchy, state management, data fetching, and code organization. Good frontend architecture makes features easy to build, bugs easy to find, and the codebase easy to onboard into.\n\n## Core Principle\n\n**Colocation over separation.** Keep related things together. A component's styles, tests, types, and stories should live next to the component, not in separate `\u002Fstyles`, `\u002Ftests`, `\u002Ftypes` directories. Separation by file type creates coupling across the filesystem; separation by feature creates independence.\n\n## Workflow\n\n### Step 0: Inventory What Already Exists\n\nIn an existing codebase, establish what the app already provides before adding a\nnew component, hook, store, or token. Search the shared surfaces **directly** —\n`components\u002F`, `hooks\u002F`, `lib\u002F`, the token file, and each feature's public\n`index.ts` — rather than inferring from the design or from memory.\n\nCover both:\n\n- **Artifacts** — existing components, hooks, stores, and tokens that already\n  cover, or nearly cover, the need. Search by behavior, not just by name: the\n  component you want often exists under a different label.\n- **Written decisions** — established conventions, the design system's rules,\n  and prior audit findings.\n\n**Exit condition** — one line, then keep going in the same response:\n*\"`\u003Cexisting component\u002Fhook>` already covers `\u003Cbehavior>`; it does \u002F does not\nserve this because `\u003Creason>`.\"*\n\n**This step is not a gate on delivering.** Greenfield — a new app, or a codebase\nyou can't reach — closes it in one line: say so and go straight to Step 1. When\nyou can't inspect, name what you would check and continue under stated\nassumptions. Never answer with inventory and questions alone; produce the\narchitecture in the same reply.\n\nThis constrains the input, not the choice. A new component is a fine outcome; an\nunexamined one isn't — a near-duplicate of an existing one is how design systems\nrot.\n\n### Step 1: Design the Component Hierarchy\n\nStart from the UI design (or the screen spec from `ui-ux-design`) and decompose into components:\n\n1. **Identify the visual boundaries** — Draw boxes around distinct UI regions\n2. **Apply the single-responsibility principle** — Each component does one thing\n3. **Identify reusability** — Which components appear in multiple places?\n4. **Define the tree** — Parent → child relationships\n\nComponent classification:\n- **Page components**: Route-level, fetch data, compose layout\n- **Feature components**: Implement a business feature (UserProfile, OrderSummary)\n- **UI components**: Reusable, no business logic (Button, Card, Modal, Input)\n- **Layout components**: Structure only (Sidebar, Grid, Stack, Container)\n\nSee [references\u002Fcomponent-patterns.md](references\u002Fcomponent-patterns.md) for design patterns.\n\n### Step 2: Plan State Management\n\nState management is the most impactful architectural decision in a React app. Apply the state placement ladder — use the simplest option that works:\n\n```\n1. Local state (useState)           → Simplest. Use for UI state within a component.\n2. Lifted state (parent useState)   → Share between siblings via parent.\n3. Composition (children prop)      → Avoid prop drilling with component composition.\n4. Context                          → Share across distant components (theme, auth, locale).\n5. URL state (query params)         → Shareable, bookmarkable state (filters, pagination).\n6. Server state (React Query \u002F SWR) → Data from API with caching + refetching.\n7. Global store (Zustand \u002F Redux)   → Client state shared across many unrelated components.\n```\n\n**Decision rules:**\n- If it's only used in one component → `useState`\n- If shared between parent\u002Fchild → lift state up\n- If shared across distant components but rarely changes → Context\n- If it comes from the server → React Query \u002F SWR \u002F TanStack Query (NOT global store)\n- If it's complex client state updated from many places → Zustand or Redux Toolkit\n- If it should survive a page refresh → URL params or localStorage\n\nSee [references\u002Fcomponent-patterns.md](references\u002Fcomponent-patterns.md) for detailed guidance.\n\n### Step 3: Define Design Tokens\n\nDesign tokens are the foundation of visual consistency. Define tokens before building components:\n\n```typescript\n\u002F\u002F tokens.ts\nexport const tokens = {\n  color: {\n    primary: { 50: '#eff6ff', 500: '#3b82f6', 700: '#1d4ed8' },\n    neutral: { 50: '#f9fafb', 200: '#e5e7eb', 800: '#1f2937' },\n    success: '#10b981',\n    warning: '#f59e0b',\n    error: '#ef4444',\n  },\n  spacing: { xs: '0.25rem', sm: '0.5rem', md: '1rem', lg: '1.5rem', xl: '2rem' },\n  radius: { sm: '0.25rem', md: '0.5rem', lg: '1rem', full: '9999px' },\n  fontSize: { sm: '0.875rem', base: '1rem', lg: '1.125rem', xl: '1.25rem' },\n  shadow: {\n    sm: '0 1px 2px rgba(0,0,0,0.05)',\n    md: '0 4px 6px rgba(0,0,0,0.1)',\n  },\n};\n```\n\nUse tokens everywhere — never hardcode `#3b82f6` or `16px` in a component.\n\n### Step 4: Design the Data Fetching Strategy\n\nChoose patterns based on the data's nature:\n\n| Data Pattern | Approach | When |\n|-------------|----------|------|\n| Server data (read) | TanStack Query \u002F SWR | Lists, details, dashboards |\n| Server data (mutate) | TanStack Query mutations | Create, update, delete |\n| Real-time data | WebSocket + state sync | Chat, notifications, live dashboards |\n| Form data | React Hook Form \u002F Formik | Any form |\n| Static data | Build-time fetch (SSG) | Blog posts, docs, marketing pages |\n\nKey rules:\n- **Separate server state from client state.** Server state lives in the query cache, not in Redux.\n- **Fetch at the route level** when possible. Components receive data as props, not fetch their own.\n- **Handle loading, error, and empty** at every fetch boundary. Use error boundaries for unexpected errors.\n\n### Step 5: Organize the Codebase\n\nRecommended structure — feature-based with shared library:\n\n```\nsrc\u002F\n├── app\u002F                    # App-level: providers, routing, global config\n│   ├── providers.tsx       # All context providers composed\n│   ├── router.tsx          # Route definitions\n│   └── layout.tsx          # Root layout\n├── features\u002F               # Feature modules (the meat of the app)\n│   ├── auth\u002F\n│   │   ├── components\u002F     # Feature-specific components\n│   │   ├── hooks\u002F          # Feature-specific hooks\n│   │   ├── api.ts          # API calls for this feature\n│   │   ├── types.ts        # Types for this feature\n│   │   └── index.ts        # Public API (barrel file)\n│   ├── projects\u002F\n│   └── settings\u002F\n├── components\u002F             # Shared UI components (Button, Modal, etc.)\n│   ├── ui\u002F                 # Atomic UI primitives\n│   └── layout\u002F             # Layout components (Sidebar, Stack)\n├── hooks\u002F                  # Shared hooks (useDebounce, useMediaQuery)\n├── lib\u002F                    # Shared utilities, API client, tokens\n│   ├── api-client.ts\n│   ├── tokens.ts\n│   └── utils.ts\n└── types\u002F                  # Shared types\n```\n\nRules:\n- Features import from `components\u002F` and `lib\u002F`, never from other features\n- Features export a clean public API through their `index.ts`\n- Circular imports between features means a responsibility boundary is wrong\n\nUse [templates\u002Ffolder-structure.md](templates\u002Ffolder-structure.md) as a starting point — includes the full `src\u002F` layout, a co-located component template, design tokens, and a custom hook pattern.\n\n### Step 6: Validate the Architecture\n\n- [ ] Can a new engineer understand where to add a new feature?\n- [ ] Can you delete a feature directory without breaking unrelated features?\n- [ ] Is server state separate from client state?\n- [ ] Are components reusable without bringing business logic along?\n- [ ] Is there one clear way to do common tasks (fetching, forms, navigation)?\n- [ ] Are design tokens used consistently (no hardcoded values)?\n- [ ] Does every library this design adds (state, fetching, routing, UI kit) carry `dependency-management`'s Step 1 verdict: own module, adopt, or ask the user?\n\n## Principles Applied\n\n- **KISS**: Use `useState` until you need something more. Don't reach for Redux on day one.\n- **DRY**: Shared UI components in `components\u002F`, shared hooks in `hooks\u002F`. Feature-specific code in features.\n- **Functional Independence**: Features don't know about each other. Shared dependencies go in `lib\u002F` or `components\u002F`.\n- **YAGNI**: Don't abstract until you have 2+ consumers. A single-use component doesn't need to be in the shared library.\n- **Separation of Concerns**: Components render UI. Hooks manage state and side effects. API modules handle HTTP. Types define shapes. Keep them apart.\n",{"name":5,"description":7},"main","800dc9ad0ca2914d6ad15b8c5159d9b57bb104c2","plugins\u002Fdesigner\u002Fskills\u002Ffrontend-architecture","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills","https:\u002F\u002Fgithub.com\u002FSWEStash","A stash of things we felt like building","2026-11-12 00:14:33",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add SWEStash\u002Fswe-workflow-skills --skill frontend-architecture",{"tool":73,"command":74},"bunx","bunx skills add SWEStash\u002Fswe-workflow-skills --skill frontend-architecture",{"tool":76,"command":77},"pnpm","pnpm dlx skills add SWEStash\u002Fswe-workflow-skills --skill frontend-architecture","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fdesigner\u002Fskills\u002Ffrontend-architecture\u002FSKILL.md",true,[81,87,91],{"path":82,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":86},"evals\u002Fevals.json","REFERENCE","参考文档",3303,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fdesigner\u002Fskills\u002Ffrontend-architecture\u002Fevals\u002Fevals.json",{"path":88,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Fcomponent-patterns.md",8129,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fdesigner\u002Fskills\u002Ffrontend-architecture\u002Freferences\u002Fcomponent-patterns.md",{"path":92,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":93,"sourceHtmlUrl":94},"templates\u002Ffolder-structure.md",6295,"https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fdesigner\u002Fskills\u002Ffrontend-architecture\u002Ftemplates\u002Ffolder-structure.md",[96,135,162,186,215,242],{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":115,"publishedAt":55},"01M6JQFADV3T1MS9V1BNZS1232","writing-skills","Use when authoring, editing, or reviewing a skill in this library — a new SKILL.md, one that under-triggers, or hardening an existing one. Covers description and listing-budget rules, frontmatter, progressive disclosure, the 3-eval rule, and pressure-testing against rationalizations.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-skills\u002FSKILL.md",[102,105,108,109,112],{"categoryNo":103,"categoryName":104,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":106,"categoryName":107,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":110,"categoryName":111,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000036","内容创作者",{"categoryNo":113,"categoryName":114,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000040","财务",[116,117,118,119,120,121,122,123,124,38,125,126,127,128,129,130,131,132,133,134],"writing","writing skills","testing","eval","write","edit","Budget","authoring","new skill","frontmatter","editing","triggers","use","Existing","Rules","write a skill","when","listing","progressive disclosure",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":142,"publishedAt":55},"01M6JQF5DGMXPMQQVZBP8DH9SY","working-agreement","Define and validate how a multi-session project is run — where plans, status and decisions live, session routines, new work, milestone close. README\u002FCONTRIBUTING → project-documentation.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fworking-agreement\u002FSKILL.md",[141],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,127,161],"working agreement","project","definition of done","done","milestone","documentation","work","progress","how","contributing","close","run","sync","status","live","do","README","session","routines",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":169,"publishedAt":55},"01M6JQF0SMRHN82RBSWMABC4J0","verification-before-completion","Evidence gate before any claim that work is done, fixed, passing, or deployed. Route here when a message declares the work finished or asks to commit, push, merge, ship, or close it out, including a brief sign-off, and before git-workflow or release-management act on it. Writing the commit message or PR text itself → git-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[168],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[170,171,172,173,174,175,116,176,146,177,178,179,149,180,153,181,182,183,184,185],"verification","verification before completion","brief","ready","fix","claim","workflow","commit","text","route","message","merge","release","git","act","ship",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":197,"publishedAt":55},"01M6JQEVGE9NJZ11DV60AE6VWC","ui-ux-design","Design user experiences from an engineer's perspective — user flows, wireframes, interaction patterns, responsive strategy, navigation, loading\u002Ferror\u002Fempty states. Triggers: design the UI, user flow, wireframe, how should this screen look, loading state, error state, empty state, responsive design, navigation, page layout, form design, mockup.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fui-ux-design\u002FSKILL.md",[192,193,194],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":195,"categoryName":196,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000032","设计师",[54,198,199,200,41,201,202,203,204,205,206,207,151,208,209,210,211,212,213,214],"ux","ui","ui ux design","states","loading","flows","engineer","interaction","layout","responsive design","screen","flow","patterns","mockup","responsive","form","page",{"skillNo":216,"name":217,"nameZh":6,"description":218,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":219,"categories":220,"keywords":223,"publishedAt":55},"01M6JQEN4HVFTZWQYWGTDS76K9","threat-modeling","Design-time security analysis of a system or feature before it's built — trust boundaries, attack surface, STRIDE per element, abuse cases, prioritized mitigations that become security requirements. Triggers: threat model, STRIDE, trust boundary, attack surface, what could go wrong security-wise, security design review, abuse case, secure this design, security requirements. Reviewing EXISTING code\u002Fconfig for vulnerabilities → security-audit; use this skill while the design is still on the whiteboard.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Fthreat-modeling\u002FSKILL.md",[221,222],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},[224,225,226,227,228,229,54,230,231,232,50,233,234,235,236,237,238,239,240,241],"modeling","threat modeling","threat","model","time","element","whiteboard","security analysis","analysis","review","threat model","audit","security-audit","secure","config","go","security","trust",{"skillNo":243,"name":244,"nameZh":6,"description":245,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":246,"categories":247,"keywords":253,"publishedAt":55},"01M6JQEFT7VT3FQM16170EG9FW","test-suite-design","Design comprehensive test suites for existing code — strategy across unit\u002Fintegration\u002Fe2e, fixtures, factories, helpers. Triggers: add tests, write tests for, increase coverage, test this module, testing strategy, test plan, what tests do I need, test infrastructure, test helpers, this has no tests. Not for TDD — use tdd-workflow.","https:\u002F\u002Fgithub.com\u002FSWEStash\u002Fswe-workflow-skills\u002Fblob\u002Fmain\u002Fskills\u002Ftest-suite-design\u002FSKILL.md",[248,249,250,251,252],{"categoryNo":103,"categoryName":104,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},{"categoryNo":195,"categoryName":196,"taxonomyType":32,"taxonomyTypeDesc":33},[54,254,255,256,257,258,118,259,260,176,50,261,262,120,263,264,158,265,266,127],"test suite","test","test suite design","coverage","unit","write tests","testing strategy","across","plan","add","infrastructure","test plan","for"]