[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MXAWFAQDJNPD3RDVDPC54W":3,"skill-same:01M6MXAWFAQDJNPD3RDVDPC54W":75},{"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":31,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":6,"ownerHtmlUrl":59,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":60,"install":61,"resources":74},"01M6MXAWFAQDJNPD3RDVDPC54W","api-designer",null,"Design OpenAPI specifications derived from scenario sequence diagrams. Use when scenarios exist in 2-scenario-implementation\u002F but logos\u002Fresources\u002Fapi\u002F is empty. All description and summary values in YAML must be double-quoted.","miniidealab\u002Fopenlogos","miniidealab","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F4251156?v=4","01M6MX6BM454XESZCRPBQQHKRT","FredHuang","01M6MX6BR4417H4QA658D4GW9X",581,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Flogos\u002Fchanges\u002Farchive\u002F20260829-2333-release-0-14-1-local\u002Fdeployment-artifacts-20260830T0554Z\u002Fcandidate-unpack\u002Fpackage\u002Fclaude-plugin-template\u002Fskills\u002Fapi-designer\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"api","designer","api designer","sequence","design","values","specifications","resources","scenario","empty","but","summary","diagrams","implementation","use","openapi","yaml","2026-11-10 10:12:30",false,"---\nname: api-designer\ndescription: \"Design OpenAPI specifications derived from scenario sequence diagrams. Use when scenarios exist in 2-scenario-implementation\u002F but logos\u002Fresources\u002Fapi\u002F is empty. All description and summary values in YAML must be double-quoted.\"\n---\n\n# Skill: API Designer\n\n> Design OpenAPI 3.0+ YAML specifications based on sequence diagrams, letting APIs emerge naturally from scenarios rather than being defined in isolation. Every endpoint is traceable to a Step number in the sequence diagrams, ensuring \"no scenario, no API design.\"\n\n## Trigger Conditions\n\n- User requests API design or API documentation\n- User mentions \"Phase 3 Step 2\" or \"API design\"\n- Scenario sequence diagrams already exist and API specifications need to be refined\n- User provides a specific API endpoint that needs detailed design\n\n## Prerequisites\n\n- `logos\u002Fresources\u002Fprd\u002F3-technical-plan\u002F2-scenario-implementation\u002F` contains scenario sequence diagrams\n- `logos\u002Fresources\u002Fprd\u002F3-technical-plan\u002F1-architecture\u002F` contains the architecture overview (confirming frontend-backend separation approach, authentication scheme, etc.)\n- `tech_stack` in `logos-project.yaml` is filled in\n\nIf the sequence diagram directory is empty, prompt the user to complete Phase 3 Step 1 (scenario-architect) first.\n\n## Core Capabilities\n\n1. Extract all cross-system-boundary API calls from sequence diagrams\n2. Deduplicate, merge, and group by domain to form an endpoint inventory\n3. Design OpenAPI 3.0+ YAML specifications (paths, parameters, request bodies, response structures)\n4. Define a unified error response format and error code system\n5. Design authentication schemes (Bearer Token \u002F API Key \u002F Cookie)\n6. Design standardized parameters for pagination, sorting, and filtering\n\n## Execution Steps\n\n### Step 1: Read Scenario Context\n\nRead the following files to establish complete context:\n\n- **Scenario sequence diagrams** (`logos\u002Fresources\u002Fprd\u002F3-technical-plan\u002F2-scenario-implementation\u002F`): Extract all cross-system-boundary arrows\n- **Architecture overview** (`logos\u002Fresources\u002Fprd\u002F3-technical-plan\u002F1-architecture\u002F`): Confirm authentication scheme, frontend-backend separation approach, API gateway, etc.\n- **`logos-project.yaml`**: Read `tech_stack` to confirm backend framework and deployment approach\n\n### Step 2: Extract Endpoint Inventory\n\nTraverse all scenario sequence diagrams and collect every cross-system-boundary call arrow:\n\n1. Identify \"cross-system-boundary\" arrows — client to server, server to external service, inter-service calls\n2. For each arrow, extract: HTTP method, path, source scenario number, and Step number\n3. Deduplicate and merge — the same endpoint may appear in multiple scenarios (e.g., `POST \u002Fapi\u002Fauth\u002Flogin` may appear in both S02 and S03)\n4. Output an endpoint inventory summary for user confirmation:\n\n```markdown\nIdentified N API endpoints from sequence diagrams:\n\n| # | Method | Path | Source Scenario | Domain |\n|---|--------|------|-----------------|--------|\n| 1 | POST | \u002Fapi\u002Fauth\u002Fregister | S01 Step 2 | auth |\n| 2 | POST | \u002Fapi\u002Fauth\u002Flogin | S02 Step 1 | auth |\n| 3 | GET  | \u002Fapi\u002Fprojects | S04 Step 1 | projects |\n```\n\n### Step 3: Group by Domain\n\nGroup endpoints by business domain, with each group corresponding to a YAML file:\n\n- `auth.yaml` — Authentication-related (registration, login, logout, password reset)\n- `projects.yaml` — CRUD for core business entities\n- `billing.yaml` — Payment and subscriptions\n\nGrouping principles:\n- Operations on the same data entity go together\n- Authentication\u002Fauthorization is a separate group\n- Third-party service callbacks (e.g., payment callbacks) go under the corresponding business domain\n\n### Step 4: Design Unified Conventions\n\nBefore generating specific endpoints, establish global conventions:\n\n**Authentication scheme** (read from architecture overview):\n\n```yaml\ncomponents:\n  securitySchemes:\n    bearerAuth:\n      type: http\n      scheme: bearer\n      bearerFormat: JWT\n```\n\n**Unified error response**:\n\n```yaml\ncomponents:\n  schemas:\n    ErrorResponse:\n      type: object\n      required: [code, message]\n      properties:\n        code:\n          type: string\n          description: Machine-readable error code (e.g., EMAIL_EXISTS)\n        message:\n          type: string\n          description: Human-readable error description\n        details:\n          type: object\n          description: Additional error information (e.g., field-level validation errors)\n```\n\n**Pagination parameters** (applicable to list endpoints):\n\n```yaml\nparameters:\n  - name: page\n    in: query\n    schema: { type: integer, minimum: 1, default: 1 }\n  - name: per_page\n    in: query\n    schema: { type: integer, minimum: 1, maximum: 100, default: 20 }\n```\n\n### Step 5: Design Detailed Specification per Endpoint\n\nDesign a complete OpenAPI specification for each endpoint, **output by domain**, pausing after each domain for user review:\n\nEach endpoint must include:\n- `operationId`: Unique identifier for code generation\n- `summary`: One-sentence description\n- `description`: Annotate the source sequence diagram step (e.g., `Source: S01 Step 2 → Step 3`)\n- `requestBody`: Schema including all fields (with required, types, validation rules such as minLength\u002Fformat)\n- `responses`: Cover the normal response + all known exceptions (extracted from EX use cases in sequence diagrams)\n\n**Example**:\n\n```yaml\npaths:\n  \u002Fapi\u002Fauth\u002Fregister:\n    post:\n      operationId: register\n      summary: User registration\n      description: \"Source: S01 Step 2 → Step 3\"\n      requestBody:\n        required: true\n        content:\n          application\u002Fjson:\n            schema:\n              type: object\n              required: [email, password]\n              properties:\n                email: { type: string, format: email }\n                password: { type: string, minLength: 8 }\n      responses:\n        '201':\n          description: Registration successful, verification email sent\n          content:\n            application\u002Fjson:\n              schema:\n                type: object\n                properties:\n                  userId: { type: string, format: uuid }\n                  message: { type: string }\n        '409':\n          description: \"Email already registered (EX-2.1)\"\n          content:\n            application\u002Fjson:\n              schema:\n                $ref: '#\u002Fcomponents\u002Fschemas\u002FErrorResponse'\n        '422':\n          description: Request parameter validation failed\n          content:\n            application\u002Fjson:\n              schema:\n                $ref: '#\u002Fcomponents\u002Fschemas\u002FErrorResponse'\n```\n\n### Step 6: Verify Traceability Completeness\n\nAfter output is complete, perform a traceability check:\n\n1. **Forward check**: Every cross-system arrow in the sequence diagrams has a corresponding API endpoint\n2. **Reverse check**: Every API endpoint's `description` annotates the source Step\n3. **Exception coverage**: Every EX use case in the sequence diagrams has a corresponding HTTP error response\n\nIf gaps are found, supplement them before outputting the final version.\n\n## Output Specification\n\n- File format: OpenAPI 3.1 YAML\n- Storage location: `logos\u002Fresources\u002Fapi\u002F`\n- Split by domain: `auth.yaml`, `projects.yaml`, `billing.yaml`\n- Each file contains complete `openapi`, `info`, `paths`, and `components` sections\n- Error responses uniformly reference `$ref: '#\u002Fcomponents\u002Fschemas\u002FErrorResponse'`\n- Every endpoint's `description` must annotate the source sequence diagram step\n\n## YAML Formatting Rules (MUST Follow)\n\nYAML is whitespace- and character-sensitive. AI-generated YAML frequently breaks due to unquoted special characters. **Strictly follow these rules:**\n\n1. **Always double-quote `description` and `summary` values** — any string containing `:`, `→`, `#`, `&`, `*`, `!`, `>`, `|`, `%`, `@`, `` ` ``, `{`, `}`, `[`, or `]` MUST be wrapped in `\"...\"`.\n   ```yaml\n   # ❌ WRONG — colon + arrow breaks YAML parsing\n   description: Source: S05 Step 1 → Step 4.\n\n   # ✅ CORRECT\n   description: \"Source: S05 Step 1 → Step 4.\"\n   ```\n2. **Always quote response status code keys** — use `'201'` not `201` to prevent YAML interpreting them as integers.\n3. **Self-check after generation** — after generating each YAML file, mentally re-parse it to verify no unquoted special characters exist. Pay special attention to `description` fields that reference scenario steps (they always contain `:`).\n4. **When in doubt, quote it** — quoting a safe string is harmless; leaving a dangerous string unquoted breaks the entire file.\n\n## Best Practices\n\n- **APIs emerge from sequence diagrams**: If an API cannot be traced back to a sequence diagram, it most likely should not exist. Design sequence diagrams first, then APIs — not the other way around\n- **Path naming**: RESTful style, use plural nouns, `\u002Fapi\u002F{resource}`\n- **Version prefix**: Do not add a version prefix initially (`\u002Fapi\u002Fauth\u002Fregister`); add `\u002Fapi\u002Fv2\u002F` when versioning becomes necessary\n- **Status code semantics**: Strictly follow HTTP status code semantics — 200 success, 201 created, 400 bad request, 401 unauthorized, 403 forbidden, 404 not found, 409 conflict, 422 validation failed, 500 server error\n- **Idempotent design**: PUT\u002FDELETE operations must be idempotent\n- **Sensitive data**: Do not include plaintext sensitive information such as passwords or tokens in responses\n- **Output by domain**: Do not output all endpoints at once — output in batches by domain, letting the user review each batch before continuing\n- **Consistent field naming**: Field names in the API should be consistent with column names in the subsequent DB design (or have explicit mapping rules) to avoid unnecessary field transformations in the code layer\n\n## Recommended Prompts\n\nThe following prompts can be copied directly for use with the AI:\n\n- `Help me design APIs`\n- `Generate OpenAPI YAML based on the sequence diagrams`\n- `Help me design the API specifications related to S01`\n- `Help me extract all cross-system calls from the sequence diagrams into APIs`\n","# Skill: API Designer\n\n> Design OpenAPI 3.0+ YAML specifications based on sequence diagrams, letting APIs emerge naturally from scenarios rather than being defined in isolation. Every endpoint is traceable to a Step number in the sequence diagrams, ensuring \"no scenario, no API design.\"\n\n## Trigger Conditions\n\n- User requests API design or API documentation\n- User mentions \"Phase 3 Step 2\" or \"API design\"\n- Scenario sequence diagrams already exist and API specifications need to be refined\n- User provides a specific API endpoint that needs detailed design\n\n## Prerequisites\n\n- `logos\u002Fresources\u002Fprd\u002F3-technical-plan\u002F2-scenario-implementation\u002F` contains scenario sequence diagrams\n- `logos\u002Fresources\u002Fprd\u002F3-technical-plan\u002F1-architecture\u002F` contains the architecture overview (confirming frontend-backend separation approach, authentication scheme, etc.)\n- `tech_stack` in `logos-project.yaml` is filled in\n\nIf the sequence diagram directory is empty, prompt the user to complete Phase 3 Step 1 (scenario-architect) first.\n\n## Core Capabilities\n\n1. Extract all cross-system-boundary API calls from sequence diagrams\n2. Deduplicate, merge, and group by domain to form an endpoint inventory\n3. Design OpenAPI 3.0+ YAML specifications (paths, parameters, request bodies, response structures)\n4. Define a unified error response format and error code system\n5. Design authentication schemes (Bearer Token \u002F API Key \u002F Cookie)\n6. Design standardized parameters for pagination, sorting, and filtering\n\n## Execution Steps\n\n### Step 1: Read Scenario Context\n\nRead the following files to establish complete context:\n\n- **Scenario sequence diagrams** (`logos\u002Fresources\u002Fprd\u002F3-technical-plan\u002F2-scenario-implementation\u002F`): Extract all cross-system-boundary arrows\n- **Architecture overview** (`logos\u002Fresources\u002Fprd\u002F3-technical-plan\u002F1-architecture\u002F`): Confirm authentication scheme, frontend-backend separation approach, API gateway, etc.\n- **`logos-project.yaml`**: Read `tech_stack` to confirm backend framework and deployment approach\n\n### Step 2: Extract Endpoint Inventory\n\nTraverse all scenario sequence diagrams and collect every cross-system-boundary call arrow:\n\n1. Identify \"cross-system-boundary\" arrows — client to server, server to external service, inter-service calls\n2. For each arrow, extract: HTTP method, path, source scenario number, and Step number\n3. Deduplicate and merge — the same endpoint may appear in multiple scenarios (e.g., `POST \u002Fapi\u002Fauth\u002Flogin` may appear in both S02 and S03)\n4. Output an endpoint inventory summary for user confirmation:\n\n```markdown\nIdentified N API endpoints from sequence diagrams:\n\n| # | Method | Path | Source Scenario | Domain |\n|---|--------|------|-----------------|--------|\n| 1 | POST | \u002Fapi\u002Fauth\u002Fregister | S01 Step 2 | auth |\n| 2 | POST | \u002Fapi\u002Fauth\u002Flogin | S02 Step 1 | auth |\n| 3 | GET  | \u002Fapi\u002Fprojects | S04 Step 1 | projects |\n```\n\n### Step 3: Group by Domain\n\nGroup endpoints by business domain, with each group corresponding to a YAML file:\n\n- `auth.yaml` — Authentication-related (registration, login, logout, password reset)\n- `projects.yaml` — CRUD for core business entities\n- `billing.yaml` — Payment and subscriptions\n\nGrouping principles:\n- Operations on the same data entity go together\n- Authentication\u002Fauthorization is a separate group\n- Third-party service callbacks (e.g., payment callbacks) go under the corresponding business domain\n\n### Step 4: Design Unified Conventions\n\nBefore generating specific endpoints, establish global conventions:\n\n**Authentication scheme** (read from architecture overview):\n\n```yaml\ncomponents:\n  securitySchemes:\n    bearerAuth:\n      type: http\n      scheme: bearer\n      bearerFormat: JWT\n```\n\n**Unified error response**:\n\n```yaml\ncomponents:\n  schemas:\n    ErrorResponse:\n      type: object\n      required: [code, message]\n      properties:\n        code:\n          type: string\n          description: Machine-readable error code (e.g., EMAIL_EXISTS)\n        message:\n          type: string\n          description: Human-readable error description\n        details:\n          type: object\n          description: Additional error information (e.g., field-level validation errors)\n```\n\n**Pagination parameters** (applicable to list endpoints):\n\n```yaml\nparameters:\n  - name: page\n    in: query\n    schema: { type: integer, minimum: 1, default: 1 }\n  - name: per_page\n    in: query\n    schema: { type: integer, minimum: 1, maximum: 100, default: 20 }\n```\n\n### Step 5: Design Detailed Specification per Endpoint\n\nDesign a complete OpenAPI specification for each endpoint, **output by domain**, pausing after each domain for user review:\n\nEach endpoint must include:\n- `operationId`: Unique identifier for code generation\n- `summary`: One-sentence description\n- `description`: Annotate the source sequence diagram step (e.g., `Source: S01 Step 2 → Step 3`)\n- `requestBody`: Schema including all fields (with required, types, validation rules such as minLength\u002Fformat)\n- `responses`: Cover the normal response + all known exceptions (extracted from EX use cases in sequence diagrams)\n\n**Example**:\n\n```yaml\npaths:\n  \u002Fapi\u002Fauth\u002Fregister:\n    post:\n      operationId: register\n      summary: User registration\n      description: \"Source: S01 Step 2 → Step 3\"\n      requestBody:\n        required: true\n        content:\n          application\u002Fjson:\n            schema:\n              type: object\n              required: [email, password]\n              properties:\n                email: { type: string, format: email }\n                password: { type: string, minLength: 8 }\n      responses:\n        '201':\n          description: Registration successful, verification email sent\n          content:\n            application\u002Fjson:\n              schema:\n                type: object\n                properties:\n                  userId: { type: string, format: uuid }\n                  message: { type: string }\n        '409':\n          description: \"Email already registered (EX-2.1)\"\n          content:\n            application\u002Fjson:\n              schema:\n                $ref: '#\u002Fcomponents\u002Fschemas\u002FErrorResponse'\n        '422':\n          description: Request parameter validation failed\n          content:\n            application\u002Fjson:\n              schema:\n                $ref: '#\u002Fcomponents\u002Fschemas\u002FErrorResponse'\n```\n\n### Step 6: Verify Traceability Completeness\n\nAfter output is complete, perform a traceability check:\n\n1. **Forward check**: Every cross-system arrow in the sequence diagrams has a corresponding API endpoint\n2. **Reverse check**: Every API endpoint's `description` annotates the source Step\n3. **Exception coverage**: Every EX use case in the sequence diagrams has a corresponding HTTP error response\n\nIf gaps are found, supplement them before outputting the final version.\n\n## Output Specification\n\n- File format: OpenAPI 3.1 YAML\n- Storage location: `logos\u002Fresources\u002Fapi\u002F`\n- Split by domain: `auth.yaml`, `projects.yaml`, `billing.yaml`\n- Each file contains complete `openapi`, `info`, `paths`, and `components` sections\n- Error responses uniformly reference `$ref: '#\u002Fcomponents\u002Fschemas\u002FErrorResponse'`\n- Every endpoint's `description` must annotate the source sequence diagram step\n\n## YAML Formatting Rules (MUST Follow)\n\nYAML is whitespace- and character-sensitive. AI-generated YAML frequently breaks due to unquoted special characters. **Strictly follow these rules:**\n\n1. **Always double-quote `description` and `summary` values** — any string containing `:`, `→`, `#`, `&`, `*`, `!`, `>`, `|`, `%`, `@`, `` ` ``, `{`, `}`, `[`, or `]` MUST be wrapped in `\"...\"`.\n   ```yaml\n   # ❌ WRONG — colon + arrow breaks YAML parsing\n   description: Source: S05 Step 1 → Step 4.\n\n   # ✅ CORRECT\n   description: \"Source: S05 Step 1 → Step 4.\"\n   ```\n2. **Always quote response status code keys** — use `'201'` not `201` to prevent YAML interpreting them as integers.\n3. **Self-check after generation** — after generating each YAML file, mentally re-parse it to verify no unquoted special characters exist. Pay special attention to `description` fields that reference scenario steps (they always contain `:`).\n4. **When in doubt, quote it** — quoting a safe string is harmless; leaving a dangerous string unquoted breaks the entire file.\n\n## Best Practices\n\n- **APIs emerge from sequence diagrams**: If an API cannot be traced back to a sequence diagram, it most likely should not exist. Design sequence diagrams first, then APIs — not the other way around\n- **Path naming**: RESTful style, use plural nouns, `\u002Fapi\u002F{resource}`\n- **Version prefix**: Do not add a version prefix initially (`\u002Fapi\u002Fauth\u002Fregister`); add `\u002Fapi\u002Fv2\u002F` when versioning becomes necessary\n- **Status code semantics**: Strictly follow HTTP status code semantics — 200 success, 201 created, 400 bad request, 401 unauthorized, 403 forbidden, 404 not found, 409 conflict, 422 validation failed, 500 server error\n- **Idempotent design**: PUT\u002FDELETE operations must be idempotent\n- **Sensitive data**: Do not include plaintext sensitive information such as passwords or tokens in responses\n- **Output by domain**: Do not output all endpoints at once — output in batches by domain, letting the user review each batch before continuing\n- **Consistent field naming**: Field names in the API should be consistent with column names in the subsequent DB design (or have explicit mapping rules) to avoid unnecessary field transformations in the code layer\n\n## Recommended Prompts\n\nThe following prompts can be copied directly for use with the AI:\n\n- `Help me design APIs`\n- `Generate OpenAPI YAML based on the sequence diagrams`\n- `Help me design the API specifications related to S01`\n- `Help me extract all cross-system calls from the sequence diagrams into APIs`\n",{"name":5,"description":7},"master","abf55fdedadaeb660f928aa7258b9ec35d4ab003","logos\u002Fchanges\u002Farchive\u002F20260829-2333-release-0-14-1-local\u002Fdeployment-artifacts-20260830T0554Z\u002Fcandidate-unpack\u002Fpackage\u002Fclaude-plugin-template\u002Fskills\u002Fapi-designer",9,"https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos","https:\u002F\u002Fgithub.com\u002Fminiidealab","2026-10-18 11:36:11",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add miniidealab\u002Fopenlogos --skill api-designer",{"tool":67,"command":68},"bunx","bunx skills add miniidealab\u002Fopenlogos --skill api-designer",{"tool":70,"command":71},"pnpm","pnpm dlx skills add miniidealab\u002Fopenlogos --skill api-designer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Flogos\u002Fchanges\u002Farchive\u002F20260829-2333-release-0-14-1-local\u002Fdeployment-artifacts-20260830T0554Z\u002Fcandidate-unpack\u002Fpackage\u002Fclaude-plugin-template\u002Fskills\u002Fapi-designer\u002FSKILL.md",true,[],[76,115,127,136,144,152],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":95,"publishedAt":49},"01M6MXX45142DGRFD9ZYPT5YC9","ui-ux-pro-max","UI\u002FUX design intelligence. 67 styles, 96 palettes, 57 font pairings, 25 charts, 13 stacks (React, Next.js, Vue, Svelte, SwiftUI, React Native, Flutter, Tailwind, shadcn\u002Fui). Actions: plan, build, create, design, implement, review, fix, improve, optimize, enhance, refactor, check UI\u002FUX code. Projects: website, landing page, dashboard, admin panel, e-commerce, SaaS, portfolio, blog, mobile app, .html, .tsx, .vue, .svelte. Elements: button, modal, navbar, sidebar, card, table, form, chart. Styles: glassmorphism, claymorphism, minimalism, brutalism, neumorphism, bento grid, dark mode, responsive, skeuomorphism, flat design. Topics: color palette, accessibility, animation, layout, typography, font pairing, spacing, hover, shadow, gradient. Integrations: shadcn\u002Fui MCP for component search and examples.","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fui-ux-pro-max\u002FSKILL.md",[82,85,86,89,92],{"categoryNo":83,"categoryName":84,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":87,"categoryName":88,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":90,"categoryName":91,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师",{"categoryNo":93,"categoryName":94,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000033","数据分析师",[96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,36,112,113,114],"ui ux","pro","max","ui ux pro max","ui","ux","projects","mode","card","app","tsx","fix","improve","Tailwind","Charts","Animation","actions","MCP","search",{"skillNo":116,"name":117,"nameZh":6,"description":6,"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":49},"01M6MXWY8HJV93BBR8FPNJXAMV","test-writer","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Ftest-writer\u002FSKILL.md",[120],{"categoryNo":121,"categoryName":122,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[124,125,126],"writer","test writer","test",{"skillNo":128,"name":129,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":133,"publishedAt":49},"01M6MXWSAMN9AD3T8F6N099ZGY","test-orchestrator","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Ftest-orchestrator\u002FSKILL.md",[132],{"categoryNo":121,"categoryName":122,"taxonomyType":21,"taxonomyTypeDesc":22},[134,135,126],"orchestrator","test orchestrator",{"skillNo":137,"name":138,"nameZh":6,"description":6,"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":141,"publishedAt":49},"01M6MXWN29FY7K9ASMFRSPWQCN","slice-planner","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fslice-planner\u002FSKILL.md",[],[142,143],"slice planner","planner",{"skillNo":145,"name":146,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":149,"publishedAt":49},"01M6MXWFR1C1V66NSRTAM1FZPR","scenario-architect","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fscenario-architect\u002FSKILL.md",[],[150,40,151],"architect","scenario architect",{"skillNo":153,"name":154,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":49},"01M6MXWD6ZCGPT4FDT580S8K96","project-init","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fproject-init\u002FSKILL.md",[],[158,159,160],"project init","init","project"]