[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MXSCWK2JWVCDFZ5JG91DA8":3,"skill-same:01M6MXSCWK2JWVCDFZ5JG91DA8":70},{"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},"01M6MXSCWK2JWVCDFZ5JG91DA8","prd-writer",null,"Write product requirements documents following OpenLogos methodology. Use when logos\u002Fresources\u002Fprd\u002F1-product-requirements\u002F is empty or the user needs to create\u002Fupdate scenario-driven requirements with GIVEN\u002FWHEN\u002FTHEN acceptance criteria.","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\u002Fplugin\u002Fskills\u002Fprd-writer\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"prd","prd writer","writer","acceptance criteria","with","Product Requirements","resources","driven","scenario","requirements","empty","documents","use","user","write","methodology","product","acceptance","update","create","2026-11-10 10:12:30",false,"---\nname: prd-writer\ndescription: \"Write product requirements documents following OpenLogos methodology. Use when logos\u002Fresources\u002Fprd\u002F1-product-requirements\u002F is empty or the user needs to create\u002Fupdate scenario-driven requirements with GIVEN\u002FWHEN\u002FTHEN acceptance criteria.\"\n---\n\n# Skill: PRD Writer\n\n> Assist in writing scenario-driven requirements documents — starting from user pain points, identifying core business scenarios, and defining GIVEN\u002FWHEN\u002FTHEN acceptance criteria for each scenario. Scenario numbers will carry through all subsequent phases.\n\n## Trigger Conditions\n\n- User requests writing a requirements document, product requirements, or PRD\n- User discusses product positioning, target users, or feature requirements\n- User mentions \"Phase 1\", \"requirements layer\", or \"WHY\"\n- The project is currently in the requirements analysis phase\n\n## Core Capabilities\n\n1. Guide users through product positioning and target user profiling\n2. Extract user pain points and establish causal chains\n3. Identify and define business scenarios from pain points (assigning `S01`, `S02`... numbers)\n4. Write GIVEN\u002FWHEN\u002FTHEN acceptance criteria for each scenario\n5. Prioritize scenarios\n6. Identify constraints and the \"won't-do\" list\n7. Generate scenario-driven requirements documents conforming to the OpenLogos specification\n\n## Execution Steps\n\n### Step 1: Understand Product Positioning\n\nConfirm the following key questions with the user (proactively ask if information is insufficient):\n\n- **One-line positioning**: What is this product? For whom? What problem does it solve?\n- **Target user persona**: Specific enough to describe a real person\n- **Core objectives**: What should the product achieve, and what metrics define success\n\n### Step 2: Extract User Pain Points\n\nGuide the user to identify pain points from the following dimensions:\n\n- How does the user currently do it? (Current state)\n- What difficulties are encountered in the process? (Pain points)\n- What consequences do the difficulties cause? (Impact)\n- How does the user expect it to be resolved? (Expectation)\n\n**Every pain point must have a causal chain**: Because [reason] → leads to [pain point] → results in [consequence]\n\nAssign a number to each pain point (`P01`, `P02`...) for scenario traceability.\n\n### Step 3: Identify and Define Scenarios\n\n**Scenarios are the anchor throughout the entire development lifecycle.** This step is critical.\n\nExtract business scenarios from pain points and requirements. Each scenario is a **complete user action path**:\n\n- **Who** triggers it under **what circumstances**\n- Through **what steps** (must involve multiple interactions, not a single API call)\n- To achieve **what business outcome** (a value the user can perceive)\n\nAssign a globally unique number to each scenario (`S01`, `S02`...). This number will carry through to Phase 2 and Phase 3.\n\nOutput a scenario list table:\n\n```markdown\n| ID   | Scenario Name      | Trigger Condition          | Related Pain Point | Priority |\n|------|--------------------|----------------------------|--------------------|----------|\n| S01  | Email Registration  | New user's first visit     | P01                | P0       |\n| S02  | Password Login      | Registered user returns    | P01                | P0       |\n| S03  | Forgot Password     | User cannot log in         | P02                | P1       |\n```\n\n#### Scenario Granularity Self-Check (MUST Pass)\n\nAfter generating the scenario list, run these 4 tests. **If any test fails, re-organize the scenarios before proceeding.**\n\n1. **Single-API Test**: If a scenario can be completed with just 1 API call, it is NOT a scenario — it is an operation. Merge it into a larger scenario.\n2. **CRUD Test**: If the scenario list contains \"Create X\", \"Read X\", \"Update X\", \"Delete X\" as 4 separate scenarios, the granularity is too fine. Re-organize by user goals (e.g., \"Manager plans weekly tasks\" instead of \"Create task\" + \"Assign task\" + \"Update task\" + \"Delete task\").\n3. **Business Value Test**: Describe in one sentence the value the user gains after completing the scenario. If the answer is merely \"data was written\u002Fread\u002Fdeleted\", there is no real business goal — merge the scenario into a goal-driven one.\n4. **Step Count Test**: A scenario's main path must contain at least 3 user-perceivable steps. Fewer than 3 means the granularity is too fine.\n\n#### ❌ Anti-Pattern: One API = One Scenario\n\n```markdown\n| S01 | Create Task    | User clicks \"New\"       |\n| S02 | Get Task List  | User opens the page      |\n| S03 | Update Task    | User edits a task        |\n| S04 | Delete Task    | User deletes a task      |\n→ This is an API inventory, NOT a scenario list!\n```\n\n#### ✅ Correct: Organize by Business Goals\n\n```markdown\n| S01 | Team Lead Plans Weekly Tasks   | Lead logs in → creates tasks → sets priority & deadline → assigns to members → members receive notifications |\n| S02 | Developer Completes & Delivers | Dev views to-do → updates progress → marks complete → lead is notified and reviews |\n| S03 | Lead Reviews Project Progress  | Lead opens dashboard → filters by status\u002Fmember → exports weekly report |\n```\n\n### Step 4: Write Scenario Acceptance Criteria\n\nWrite acceptance criteria for every P0 and P1 scenario:\n\n```markdown\n### S01: Email Registration\n\n- **Trigger Condition**: New user's first visit, clicks \"Sign Up\"\n- **User Value**: Quickly create an account and start using the product (← P01)\n- **Priority**: P0\n- **Main Path**: User fills in email and password, submits the form, receives a verification email, clicks the link to complete registration\n\n#### Acceptance Criteria\n\n##### Normal: Complete registration flow\n- **GIVEN** the user has not registered before and is on the registration page\n- **WHEN** the user fills in a valid email and password (≥8 characters) and clicks \"Sign Up\"\n- **THEN** the system creates an account, sends a verification email, and the page displays \"Please check your email for verification\"\n\n##### Exception: Email already registered\n- **GIVEN** the email test@example.com is already registered\n- **WHEN** the user attempts to register using test@example.com\n- **THEN** the page displays \"This email is already registered, please log in directly\" and no email is sent\n\n##### Exception: Password does not meet requirements\n- **GIVEN** the user is on the registration page\n- **WHEN** the user fills in a valid email but a password with fewer than 8 characters and clicks \"Sign Up\"\n- **THEN** the page displays \"Password must be at least 8 characters\" and the request is not submitted\n```\n\n**Principles for writing acceptance criteria**:\n\n- Each scenario must have at least 1 normal + 1 exception acceptance criterion\n- GIVEN describes the initial state — specific enough to be reproducible\n- WHEN describes the user action — precise down to the button level\n- THEN describes the expected behavior — specific enough to be verifiable\n- Avoid vague wording: \"fast\", \"friendly\", \"reasonable\" → quantify with concrete metrics\n\n### Step 5: Identify Constraints and Boundaries\n\n- **Technical constraints**: Technology stack limitations, third-party service limitations\n- **Resource constraints**: Team size, time window\n- **\"Won't-do\" list**: Explicitly list features and scenarios that are out of scope for this phase to prevent scope creep\n\n### Step 6: Assemble the Requirements Document\n\nOutput the complete document in the standard structure:\n\n```markdown\n# [Product Name] Requirements Document\n\n> Last updated: [date]\n\n## I. Product Background and Goals\n### 1.1 Product Positioning\n### 1.2 Core Objectives\n### 1.3 Target User Persona\n\n## II. User Pain Point Analysis\n### P01: [Pain Point Name]\nBecause [reason] → leads to [pain point] → results in [consequence]\n### P02: ...\n\n## III. Scenario Overview\n[Scenario list table: ID \u002F Name \u002F Trigger Condition \u002F Related Pain Point \u002F Priority]\n\n## IV. Core Scenario Details\n### S01: [Scenario Name]\n[Trigger Condition + User Value + Priority + Main Path + Acceptance Criteria]\n### S02: ...\n\n## V. Constraints and Boundaries\n### 5.1 Technical Constraints\n### 5.2 Resource and Time Constraints\n### 5.3 \"Won't-Do\" List\n```\n\n## Output Specification\n\n- File format: Markdown\n- Storage location: `logos\u002Fresources\u002Fprd\u002F1-product-requirements\u002F`\n- File naming: `{sequence}-{english-name}.md`, e.g., `01-requirements.md`\n- Every scenario must be traceable to at least one user pain point\n- P0\u002FP1 scenarios must have GIVEN\u002FWHEN\u002FTHEN (≥1 normal + ≥1 exception)\n- Scenario numbers are globally unique and will carry through Phase 2 and Phase 3\n\n## Best Practices\n\n- **Cast a wide net first, then narrow down**: In the first pass, identify as many scenarios as possible, then cut non-core ones during prioritization\n- **Scenarios ≠ Features, Scenarios ≠ APIs**: A scenario is a \"complete path from the user's perspective to achieve a business goal\". A single feature (e.g., \"user authentication\") may contain multiple scenarios (registration, login, password recovery); a single scenario (e.g., \"first purchase\") may span multiple features (browsing, adding to cart, payment). **Never define a single CRUD operation as a standalone scenario.**\n- **Scenario granularity**: Keep granularity moderate in Phase 1. Too fine-grained (\"user creates a record\") is just an API call; too coarse (\"user uses the product\") is unverifiable. Good granularity: the main path of a scenario can be walked through in 1–2 minutes and involves at least 3 distinct steps\n- **Acceptance criteria are the precise expression of requirements**: If you cannot write GIVEN\u002FWHEN\u002FTHEN, the scenario is not yet well thought out\n- **Exception scenarios are equally important**: Users don't always follow the happy path — exception handling often defines the product experience\n- **The \"won't-do\" list is the hardest to write**: Restraint is the most important skill of a product manager\n- **Once a scenario number is assigned, it is never reused**: Even if a scenario is deprecated, its number is not recycled, to avoid confusion\n- **Requirements documents are living documents**: They are continuously updated as the product evolves, with every change tracked through Delta change management\n\n## Recommended Prompts\n\nThe following prompts can be copied directly for use with an AI:\n\n- `Help me write a requirements document`\n- `I want to build a xxx product, help me sort out the requirements`\n- `Help me organize these ideas into a structured requirements document`\n- `Help me add exception scenario acceptance criteria to an existing requirements document`\n","# Skill: PRD Writer\n\n> Assist in writing scenario-driven requirements documents — starting from user pain points, identifying core business scenarios, and defining GIVEN\u002FWHEN\u002FTHEN acceptance criteria for each scenario. Scenario numbers will carry through all subsequent phases.\n\n## Trigger Conditions\n\n- User requests writing a requirements document, product requirements, or PRD\n- User discusses product positioning, target users, or feature requirements\n- User mentions \"Phase 1\", \"requirements layer\", or \"WHY\"\n- The project is currently in the requirements analysis phase\n\n## Core Capabilities\n\n1. Guide users through product positioning and target user profiling\n2. Extract user pain points and establish causal chains\n3. Identify and define business scenarios from pain points (assigning `S01`, `S02`... numbers)\n4. Write GIVEN\u002FWHEN\u002FTHEN acceptance criteria for each scenario\n5. Prioritize scenarios\n6. Identify constraints and the \"won't-do\" list\n7. Generate scenario-driven requirements documents conforming to the OpenLogos specification\n\n## Execution Steps\n\n### Step 1: Understand Product Positioning\n\nConfirm the following key questions with the user (proactively ask if information is insufficient):\n\n- **One-line positioning**: What is this product? For whom? What problem does it solve?\n- **Target user persona**: Specific enough to describe a real person\n- **Core objectives**: What should the product achieve, and what metrics define success\n\n### Step 2: Extract User Pain Points\n\nGuide the user to identify pain points from the following dimensions:\n\n- How does the user currently do it? (Current state)\n- What difficulties are encountered in the process? (Pain points)\n- What consequences do the difficulties cause? (Impact)\n- How does the user expect it to be resolved? (Expectation)\n\n**Every pain point must have a causal chain**: Because [reason] → leads to [pain point] → results in [consequence]\n\nAssign a number to each pain point (`P01`, `P02`...) for scenario traceability.\n\n### Step 3: Identify and Define Scenarios\n\n**Scenarios are the anchor throughout the entire development lifecycle.** This step is critical.\n\nExtract business scenarios from pain points and requirements. Each scenario is a **complete user action path**:\n\n- **Who** triggers it under **what circumstances**\n- Through **what steps** (must involve multiple interactions, not a single API call)\n- To achieve **what business outcome** (a value the user can perceive)\n\nAssign a globally unique number to each scenario (`S01`, `S02`...). This number will carry through to Phase 2 and Phase 3.\n\nOutput a scenario list table:\n\n```markdown\n| ID   | Scenario Name      | Trigger Condition          | Related Pain Point | Priority |\n|------|--------------------|----------------------------|--------------------|----------|\n| S01  | Email Registration  | New user's first visit     | P01                | P0       |\n| S02  | Password Login      | Registered user returns    | P01                | P0       |\n| S03  | Forgot Password     | User cannot log in         | P02                | P1       |\n```\n\n#### Scenario Granularity Self-Check (MUST Pass)\n\nAfter generating the scenario list, run these 4 tests. **If any test fails, re-organize the scenarios before proceeding.**\n\n1. **Single-API Test**: If a scenario can be completed with just 1 API call, it is NOT a scenario — it is an operation. Merge it into a larger scenario.\n2. **CRUD Test**: If the scenario list contains \"Create X\", \"Read X\", \"Update X\", \"Delete X\" as 4 separate scenarios, the granularity is too fine. Re-organize by user goals (e.g., \"Manager plans weekly tasks\" instead of \"Create task\" + \"Assign task\" + \"Update task\" + \"Delete task\").\n3. **Business Value Test**: Describe in one sentence the value the user gains after completing the scenario. If the answer is merely \"data was written\u002Fread\u002Fdeleted\", there is no real business goal — merge the scenario into a goal-driven one.\n4. **Step Count Test**: A scenario's main path must contain at least 3 user-perceivable steps. Fewer than 3 means the granularity is too fine.\n\n#### ❌ Anti-Pattern: One API = One Scenario\n\n```markdown\n| S01 | Create Task    | User clicks \"New\"       |\n| S02 | Get Task List  | User opens the page      |\n| S03 | Update Task    | User edits a task        |\n| S04 | Delete Task    | User deletes a task      |\n→ This is an API inventory, NOT a scenario list!\n```\n\n#### ✅ Correct: Organize by Business Goals\n\n```markdown\n| S01 | Team Lead Plans Weekly Tasks   | Lead logs in → creates tasks → sets priority & deadline → assigns to members → members receive notifications |\n| S02 | Developer Completes & Delivers | Dev views to-do → updates progress → marks complete → lead is notified and reviews |\n| S03 | Lead Reviews Project Progress  | Lead opens dashboard → filters by status\u002Fmember → exports weekly report |\n```\n\n### Step 4: Write Scenario Acceptance Criteria\n\nWrite acceptance criteria for every P0 and P1 scenario:\n\n```markdown\n### S01: Email Registration\n\n- **Trigger Condition**: New user's first visit, clicks \"Sign Up\"\n- **User Value**: Quickly create an account and start using the product (← P01)\n- **Priority**: P0\n- **Main Path**: User fills in email and password, submits the form, receives a verification email, clicks the link to complete registration\n\n#### Acceptance Criteria\n\n##### Normal: Complete registration flow\n- **GIVEN** the user has not registered before and is on the registration page\n- **WHEN** the user fills in a valid email and password (≥8 characters) and clicks \"Sign Up\"\n- **THEN** the system creates an account, sends a verification email, and the page displays \"Please check your email for verification\"\n\n##### Exception: Email already registered\n- **GIVEN** the email test@example.com is already registered\n- **WHEN** the user attempts to register using test@example.com\n- **THEN** the page displays \"This email is already registered, please log in directly\" and no email is sent\n\n##### Exception: Password does not meet requirements\n- **GIVEN** the user is on the registration page\n- **WHEN** the user fills in a valid email but a password with fewer than 8 characters and clicks \"Sign Up\"\n- **THEN** the page displays \"Password must be at least 8 characters\" and the request is not submitted\n```\n\n**Principles for writing acceptance criteria**:\n\n- Each scenario must have at least 1 normal + 1 exception acceptance criterion\n- GIVEN describes the initial state — specific enough to be reproducible\n- WHEN describes the user action — precise down to the button level\n- THEN describes the expected behavior — specific enough to be verifiable\n- Avoid vague wording: \"fast\", \"friendly\", \"reasonable\" → quantify with concrete metrics\n\n### Step 5: Identify Constraints and Boundaries\n\n- **Technical constraints**: Technology stack limitations, third-party service limitations\n- **Resource constraints**: Team size, time window\n- **\"Won't-do\" list**: Explicitly list features and scenarios that are out of scope for this phase to prevent scope creep\n\n### Step 6: Assemble the Requirements Document\n\nOutput the complete document in the standard structure:\n\n```markdown\n# [Product Name] Requirements Document\n\n> Last updated: [date]\n\n## I. Product Background and Goals\n### 1.1 Product Positioning\n### 1.2 Core Objectives\n### 1.3 Target User Persona\n\n## II. User Pain Point Analysis\n### P01: [Pain Point Name]\nBecause [reason] → leads to [pain point] → results in [consequence]\n### P02: ...\n\n## III. Scenario Overview\n[Scenario list table: ID \u002F Name \u002F Trigger Condition \u002F Related Pain Point \u002F Priority]\n\n## IV. Core Scenario Details\n### S01: [Scenario Name]\n[Trigger Condition + User Value + Priority + Main Path + Acceptance Criteria]\n### S02: ...\n\n## V. Constraints and Boundaries\n### 5.1 Technical Constraints\n### 5.2 Resource and Time Constraints\n### 5.3 \"Won't-Do\" List\n```\n\n## Output Specification\n\n- File format: Markdown\n- Storage location: `logos\u002Fresources\u002Fprd\u002F1-product-requirements\u002F`\n- File naming: `{sequence}-{english-name}.md`, e.g., `01-requirements.md`\n- Every scenario must be traceable to at least one user pain point\n- P0\u002FP1 scenarios must have GIVEN\u002FWHEN\u002FTHEN (≥1 normal + ≥1 exception)\n- Scenario numbers are globally unique and will carry through Phase 2 and Phase 3\n\n## Best Practices\n\n- **Cast a wide net first, then narrow down**: In the first pass, identify as many scenarios as possible, then cut non-core ones during prioritization\n- **Scenarios ≠ Features, Scenarios ≠ APIs**: A scenario is a \"complete path from the user's perspective to achieve a business goal\". A single feature (e.g., \"user authentication\") may contain multiple scenarios (registration, login, password recovery); a single scenario (e.g., \"first purchase\") may span multiple features (browsing, adding to cart, payment). **Never define a single CRUD operation as a standalone scenario.**\n- **Scenario granularity**: Keep granularity moderate in Phase 1. Too fine-grained (\"user creates a record\") is just an API call; too coarse (\"user uses the product\") is unverifiable. Good granularity: the main path of a scenario can be walked through in 1–2 minutes and involves at least 3 distinct steps\n- **Acceptance criteria are the precise expression of requirements**: If you cannot write GIVEN\u002FWHEN\u002FTHEN, the scenario is not yet well thought out\n- **Exception scenarios are equally important**: Users don't always follow the happy path — exception handling often defines the product experience\n- **The \"won't-do\" list is the hardest to write**: Restraint is the most important skill of a product manager\n- **Once a scenario number is assigned, it is never reused**: Even if a scenario is deprecated, its number is not recycled, to avoid confusion\n- **Requirements documents are living documents**: They are continuously updated as the product evolves, with every change tracked through Delta change management\n\n## Recommended Prompts\n\nThe following prompts can be copied directly for use with an AI:\n\n- `Help me write a requirements document`\n- `I want to build a xxx product, help me sort out the requirements`\n- `Help me organize these ideas into a structured requirements document`\n- `Help me add exception scenario acceptance criteria to an existing requirements document`\n",{"name":5,"description":7},"master","abf55fdedadaeb660f928aa7258b9ec35d4ab003","plugin\u002Fskills\u002Fprd-writer",9,"https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos","https:\u002F\u002Fgithub.com\u002Fminiidealab","2026-10-18 11:36:11",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add miniidealab\u002Fopenlogos --skill prd-writer",{"tool":62,"command":63},"bunx","bunx skills add miniidealab\u002Fopenlogos --skill prd-writer",{"tool":65,"command":66},"pnpm","pnpm dlx skills add miniidealab\u002Fopenlogos --skill prd-writer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fplugin\u002Fskills\u002Fprd-writer\u002FSKILL.md",true,[],[71,115,126,135,143,151],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":94,"publishedAt":44},"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",[77,82,85,88,91],{"categoryNo":78,"categoryName":79,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":83,"categoryName":84,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":86,"categoryName":87,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":89,"categoryName":90,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000032","设计师",{"categoryNo":92,"categoryName":93,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000033","数据分析师",[95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114],"ui ux","pro","max","ui ux pro max","ui","ux","projects","mode","card","app","tsx","fix","improve","Tailwind","Charts","Animation","design","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":44},"01M6MXWY8HJV93BBR8FPNJXAMV","test-writer","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Ftest-writer\u002FSKILL.md",[120],{"categoryNo":121,"categoryName":122,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000008","测试与质量",[26,124,125],"test writer","test",{"skillNo":127,"name":128,"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":129,"categories":130,"keywords":132,"publishedAt":44},"01M6MXWSAMN9AD3T8F6N099ZGY","test-orchestrator","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Ftest-orchestrator\u002FSKILL.md",[131],{"categoryNo":121,"categoryName":122,"taxonomyType":80,"taxonomyTypeDesc":81},[133,134,125],"orchestrator","test orchestrator",{"skillNo":136,"name":137,"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":138,"categories":139,"keywords":140,"publishedAt":44},"01M6MXWN29FY7K9ASMFRSPWQCN","slice-planner","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fslice-planner\u002FSKILL.md",[],[141,142],"slice planner","planner",{"skillNo":144,"name":145,"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":146,"categories":147,"keywords":148,"publishedAt":44},"01M6MXWFR1C1V66NSRTAM1FZPR","scenario-architect","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fscenario-architect\u002FSKILL.md",[],[149,32,150],"architect","scenario architect",{"skillNo":152,"name":153,"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":154,"categories":155,"keywords":156,"publishedAt":44},"01M6MXWD6ZCGPT4FDT580S8K96","project-init","https:\u002F\u002Fgithub.com\u002Fminiidealab\u002Fopenlogos\u002Fblob\u002Fmaster\u002Fskills\u002Fproject-init\u002FSKILL.md",[],[157,158,159],"project init","init","project"]