[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71SYJ1B45ZKM8J96AZ3TS0H":3,"skill-same:01M71SYJ1B45ZKM8J96AZ3TS0H":71},{"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":55,"ownerDescription":6,"updatedAt":56,"install":57,"resources":70},"01M71SYJ1B45ZKM8J96AZ3TS0H","yt-analyze",null,"Fetch YouTrack task + comments via MCP, critically analyze relevance and requirements, produce concise summary of what to implement, and build an implementation plan mapped to codebase. Trigger - YouTrack issue ID or request to \"analyze task\", \"plan task\", \"break down YT issue\".","Artawower\u002Fkaizen","Artawower","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F16963833?v=4","01M71SV5H0DRR8KXVGD4R51Z99","Art","01M71SV5J1B97T7349GGXQCYXT",2,"GPL-3.0","https:\u002F\u002Fgithub.com\u002FArtawower\u002Fkaizen\u002Fblob\u002Fmaster\u002Fdotfiles\u002Fdot_agents\u002Fskills\u002Fyt-analyze\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"yt analyze","yt","analyze","task","implement","requirements","comments","break down","produce","trigger","down","youtrack","issue","break","request","plan","plan task","MCP","implementation plan","fetch","2026-11-10 13:02:02",false,"---\nname: yt-analyze\ndescription: Fetch YouTrack task + comments via MCP, critically analyze relevance and requirements, produce concise summary of what to implement, and build an implementation plan mapped to codebase. Trigger - YouTrack issue ID or request to \"analyze task\", \"plan task\", \"break down YT issue\".\n---\n\n## What I do\n\nDeep analysis of a YouTrack task end-to-end:\n1. Fetch task description, comments, linked issues, and metadata via YouTrack MCP\n2. Critically evaluate: is the task still relevant? Are requirements clear? Are there contradictions?\n3. Distill a concise implementation brief from noisy discussion threads\n4. Map the problem\u002Ffeature to specific files and modules in the current codebase\n5. Produce an actionable implementation plan with concrete steps\n\n## When to use me\n\n- User provides a YouTrack issue ID and wants to understand what to build\n- User asks to \"analyze task\", \"plan YT issue\", \"what does PROJ-123 need\"\n- User wants to start working on a task but needs clarity first\n- User wants to evaluate if a task is still relevant before investing effort\n\n## WORKFLOW\n\n### STEP 1: Fetch task data\n\nUse YouTrack MCP tools to gather all context:\n\n```\n1. youtrack_get_issue(issueId: \"\u003CISSUE_ID>\")\n   → Extract: summary, description, customFields (State, Type, Priority, Assignee),\n     project key, tags, votes, resolved status, created\u002Fupdated dates\n\n2. youtrack_get_issue_comments(issueId: \"\u003CISSUE_ID>\", limit: 10)\n   → Extract: all comment texts, authors, timestamps\n   → Note: comments are chronological — later comments may override earlier decisions\n\n3. youtrack_get_issue(issueId: \"\u003CPARENT_OR_LINKED>\") — if linked issues exist\n   → Check linkedIssueCounts in the original issue\n   → Fetch parent task or key linked issues for broader context\n```\n\nIf the issue has image attachments in description or comments, analyze them for UI mockups, error screenshots, or diagrams.\n\nIf the issue is not found, tell the user and stop.\n\n### STEP 2: Critical analysis\n\nApply structured critical thinking to all gathered data. Answer each question explicitly:\n\n#### 2a. Relevance check\n\n- **Is this still relevant?** Compare created date, last activity, current State.\n  If no activity for 6+ months and State is still Open — flag as potentially stale.\n- **Has it been superseded?** Check if comments mention \"moved to\", \"duplicate of\", \"replaced by\".\n- **Is it already partially done?** Look for comments mentioning PRs, commits, branches, partial implementations.\n- **Does the current codebase already solve this?** Search the codebase for keywords from the task description.\n\n#### 2b. Requirements clarity\n\n- **Are requirements specific enough to implement?** Can you write code from the description alone?\n- **Are there contradictions?** Between description and comments, between different commenters, between title and body.\n- **Are there hidden assumptions?** What does the task assume about the system that might not be true?\n- **What's NOT specified?** Error handling, edge cases, backwards compatibility, performance, mobile\u002Fdesktop.\n- **What questions remain unanswered in the thread?** Flag open questions that were asked but never answered.\n\n#### 2c. Scope assessment\n\n- **What's the minimum viable implementation?** Strip to core value.\n- **What's the full scope if done properly?** Including tests, docs, migrations.\n- **Are there scope creep signals?** Comments adding \"also do X\", \"while you're at it\".\n- **Estimated effort?** T-shirt size: XS (\u003C1h), S (1-4h), M (4-16h), L (16-40h), XL (40h+).\n\n### STEP 3: Produce implementation brief\n\nSynthesize all data into a concise brief. This is the KEY deliverable — distill noisy threads into clarity.\n\nFormat:\n\n```\n## Task Brief: {ISSUE_ID} — {SUMMARY}\n\n**Type**: {Bug|Feature|Improvement|Task}\n**Priority**: {Critical|Major|Normal|Minor}\n**Relevance**: {Current|Stale|Superseded|Partially done}\n**Estimated effort**: {XS|S|M|L|XL}\n\n### What needs to happen\n{2-5 sentences. Concrete, specific. What the user\u002Fsystem should do differently after this is implemented.}\n\n### Acceptance criteria\n1. {Specific, testable criterion}\n2. {Specific, testable criterion}\n3. ...\n\n### What's explicitly out of scope\n- {Thing mentioned but not part of this task}\n\n### Open questions (if any)\n- {Question that needs answering before implementation}\n\n### Key context from discussion\n- {Important decision or clarification from comments, with author attribution}\n```\n\n### STEP 4: Map to codebase\n\nSearch the current codebase to identify exactly where changes are needed.\n\n**Search strategy:**\n1. Extract key terms from the task (feature names, UI elements, API endpoints, error messages)\n2. Search codebase for these terms using grep\u002Ffind\u002FAST tools\n3. For each hit, determine: is this the place to modify, or just a reference?\n4. Map the dependency chain: if file A changes, what else is affected?\n\n**What to identify:**\n- **Entry points**: Which files\u002Ffunctions are the starting point for this change?\n- **Core logic**: Where does the main business logic live?\n- **UI components**: Which components need modification? (if frontend)\n- **API layer**: Which endpoints\u002Fhandlers are involved? (if backend)\n- **Data layer**: Any schema\u002Fmodel\u002Fstore changes needed?\n- **Tests**: Which existing test files cover this area?\n- **Config**: Any environment\u002Fbuild config changes needed?\n\nIf the project has AGENTS.md — read it first to understand architecture, conventions, and file organization.\n\n### STEP 5: Build implementation plan\n\nCreate a step-by-step plan that a developer (or AI agent) can follow sequentially.\n\nFormat:\n\n```\n## Implementation Plan: {ISSUE_ID}\n\n### Affected files\n| File | Change type | Description |\n|------|-------------|-------------|\n| src\u002Fauth\u002Flogin.ts | Modify | Add token refresh logic |\n| src\u002Fauth\u002Frefresh.ts | Create | New refresh token handler |\n| src\u002Fauth\u002Flogin.spec.ts | Modify | Add refresh tests |\n\n### Steps (in order)\n\n#### Step 1: {Short title}\n**Files**: `src\u002Fpath\u002Fto\u002Ffile.ts`\n**What**: {Specific change description — what to add\u002Fmodify\u002Fremove}\n**Why**: {How this connects to the requirement}\n**Watch out**: {Gotchas, edge cases, things to not break}\n\n#### Step 2: {Short title}\n...\n\n### Verification\n1. {How to verify step 1 works}\n2. {How to verify step 2 works}\n3. {Final integration check}\n\n### Risks\n- {What could go wrong}\n- {What might break}\n```\n\n**Plan rules:**\n- Each step = 1 logical unit of work (can be committed independently)\n- Steps are ordered by dependency (step 2 may depend on step 1)\n- Each step names specific files and functions\n- Total steps: 3-10 (if more — the task is too large, suggest splitting)\n- Include a verification method for each step\n\n### STEP 6: Present to user\n\nShow the full analysis:\n1. Implementation Brief (STEP 3)\n2. Codebase Mapping (STEP 4)\n3. Implementation Plan (STEP 5)\n\nIf critical issues were found in STEP 2 (stale, contradictions, missing requirements):\n- Show them FIRST, before the plan\n- Ask: \"Should I proceed with the plan despite these issues, or do you want to resolve them first?\"\n\n### STEP 7: Ask for action\n\n```\nWhat would you like to do?\n- \"start\" — begin implementing step 1 of the plan\n- \"refine\" — adjust the plan (specify what to change)\n- \"comment\" — post the analysis as a comment on the YT task\n- \"subtasks\" — create subtasks in YT from the plan steps\n- \"done\" — analysis complete, no further action\n```\n\nWait for user response. Do NOT proceed without explicit instruction.\n\n### STEP 8: Execute action (if requested)\n\n#### If \"start\":\n1. Begin implementing Step 1 from the plan\n2. Follow the plan sequentially\n3. Mark completed steps\n\n#### If \"comment\":\nPost the Implementation Brief as a YouTrack comment:\n```\nyoutrack_add_issue_comment(\n  issueId: \"\u003CISSUE_ID>\",\n  text: \"\u003CImplementation Brief markdown>\"\n)\n```\n\n#### If \"subtasks\":\nFor each plan step, create a subtask:\n```\nyoutrack_create_issue(\n  project: \"\u003CPROJECT_KEY>\",\n  summary: \"Step N: \u003Cstep title>\",\n  description: \"\u003Cstep details + affected files + verification>\",\n  parentIssue: \"\u003CISSUE_ID>\",\n  customFields: { \"Type\": \"Task\" }\n)\n```\n\n## Hard rules\n\n- NEVER modify YouTrack tasks without explicit user permission (no auto-update of State, Assignee, etc.)\n- NEVER create subtasks without explicit user permission\n- NEVER start implementing without explicit user permission\n- If YouTrack MCP is not configured or auth fails — tell user and stop\n- Answer in the same language the user uses\n- Be honest about uncertainty: if requirements are unclear, SAY SO — don't guess\n- Don't invent requirements that aren't in the task or comments\n- Distinguish between FACTS (from task data) and INFERENCES (your analysis) — label them\n- When mapping to codebase: verify files exist before listing them in the plan\n- If the codebase doesn't match the task context (wrong repo) — warn the user\n","## What I do\n\nDeep analysis of a YouTrack task end-to-end:\n1. Fetch task description, comments, linked issues, and metadata via YouTrack MCP\n2. Critically evaluate: is the task still relevant? Are requirements clear? Are there contradictions?\n3. Distill a concise implementation brief from noisy discussion threads\n4. Map the problem\u002Ffeature to specific files and modules in the current codebase\n5. Produce an actionable implementation plan with concrete steps\n\n## When to use me\n\n- User provides a YouTrack issue ID and wants to understand what to build\n- User asks to \"analyze task\", \"plan YT issue\", \"what does PROJ-123 need\"\n- User wants to start working on a task but needs clarity first\n- User wants to evaluate if a task is still relevant before investing effort\n\n## WORKFLOW\n\n### STEP 1: Fetch task data\n\nUse YouTrack MCP tools to gather all context:\n\n```\n1. youtrack_get_issue(issueId: \"\u003CISSUE_ID>\")\n   → Extract: summary, description, customFields (State, Type, Priority, Assignee),\n     project key, tags, votes, resolved status, created\u002Fupdated dates\n\n2. youtrack_get_issue_comments(issueId: \"\u003CISSUE_ID>\", limit: 10)\n   → Extract: all comment texts, authors, timestamps\n   → Note: comments are chronological — later comments may override earlier decisions\n\n3. youtrack_get_issue(issueId: \"\u003CPARENT_OR_LINKED>\") — if linked issues exist\n   → Check linkedIssueCounts in the original issue\n   → Fetch parent task or key linked issues for broader context\n```\n\nIf the issue has image attachments in description or comments, analyze them for UI mockups, error screenshots, or diagrams.\n\nIf the issue is not found, tell the user and stop.\n\n### STEP 2: Critical analysis\n\nApply structured critical thinking to all gathered data. Answer each question explicitly:\n\n#### 2a. Relevance check\n\n- **Is this still relevant?** Compare created date, last activity, current State.\n  If no activity for 6+ months and State is still Open — flag as potentially stale.\n- **Has it been superseded?** Check if comments mention \"moved to\", \"duplicate of\", \"replaced by\".\n- **Is it already partially done?** Look for comments mentioning PRs, commits, branches, partial implementations.\n- **Does the current codebase already solve this?** Search the codebase for keywords from the task description.\n\n#### 2b. Requirements clarity\n\n- **Are requirements specific enough to implement?** Can you write code from the description alone?\n- **Are there contradictions?** Between description and comments, between different commenters, between title and body.\n- **Are there hidden assumptions?** What does the task assume about the system that might not be true?\n- **What's NOT specified?** Error handling, edge cases, backwards compatibility, performance, mobile\u002Fdesktop.\n- **What questions remain unanswered in the thread?** Flag open questions that were asked but never answered.\n\n#### 2c. Scope assessment\n\n- **What's the minimum viable implementation?** Strip to core value.\n- **What's the full scope if done properly?** Including tests, docs, migrations.\n- **Are there scope creep signals?** Comments adding \"also do X\", \"while you're at it\".\n- **Estimated effort?** T-shirt size: XS (\u003C1h), S (1-4h), M (4-16h), L (16-40h), XL (40h+).\n\n### STEP 3: Produce implementation brief\n\nSynthesize all data into a concise brief. This is the KEY deliverable — distill noisy threads into clarity.\n\nFormat:\n\n```\n## Task Brief: {ISSUE_ID} — {SUMMARY}\n\n**Type**: {Bug|Feature|Improvement|Task}\n**Priority**: {Critical|Major|Normal|Minor}\n**Relevance**: {Current|Stale|Superseded|Partially done}\n**Estimated effort**: {XS|S|M|L|XL}\n\n### What needs to happen\n{2-5 sentences. Concrete, specific. What the user\u002Fsystem should do differently after this is implemented.}\n\n### Acceptance criteria\n1. {Specific, testable criterion}\n2. {Specific, testable criterion}\n3. ...\n\n### What's explicitly out of scope\n- {Thing mentioned but not part of this task}\n\n### Open questions (if any)\n- {Question that needs answering before implementation}\n\n### Key context from discussion\n- {Important decision or clarification from comments, with author attribution}\n```\n\n### STEP 4: Map to codebase\n\nSearch the current codebase to identify exactly where changes are needed.\n\n**Search strategy:**\n1. Extract key terms from the task (feature names, UI elements, API endpoints, error messages)\n2. Search codebase for these terms using grep\u002Ffind\u002FAST tools\n3. For each hit, determine: is this the place to modify, or just a reference?\n4. Map the dependency chain: if file A changes, what else is affected?\n\n**What to identify:**\n- **Entry points**: Which files\u002Ffunctions are the starting point for this change?\n- **Core logic**: Where does the main business logic live?\n- **UI components**: Which components need modification? (if frontend)\n- **API layer**: Which endpoints\u002Fhandlers are involved? (if backend)\n- **Data layer**: Any schema\u002Fmodel\u002Fstore changes needed?\n- **Tests**: Which existing test files cover this area?\n- **Config**: Any environment\u002Fbuild config changes needed?\n\nIf the project has AGENTS.md — read it first to understand architecture, conventions, and file organization.\n\n### STEP 5: Build implementation plan\n\nCreate a step-by-step plan that a developer (or AI agent) can follow sequentially.\n\nFormat:\n\n```\n## Implementation Plan: {ISSUE_ID}\n\n### Affected files\n| File | Change type | Description |\n|------|-------------|-------------|\n| src\u002Fauth\u002Flogin.ts | Modify | Add token refresh logic |\n| src\u002Fauth\u002Frefresh.ts | Create | New refresh token handler |\n| src\u002Fauth\u002Flogin.spec.ts | Modify | Add refresh tests |\n\n### Steps (in order)\n\n#### Step 1: {Short title}\n**Files**: `src\u002Fpath\u002Fto\u002Ffile.ts`\n**What**: {Specific change description — what to add\u002Fmodify\u002Fremove}\n**Why**: {How this connects to the requirement}\n**Watch out**: {Gotchas, edge cases, things to not break}\n\n#### Step 2: {Short title}\n...\n\n### Verification\n1. {How to verify step 1 works}\n2. {How to verify step 2 works}\n3. {Final integration check}\n\n### Risks\n- {What could go wrong}\n- {What might break}\n```\n\n**Plan rules:**\n- Each step = 1 logical unit of work (can be committed independently)\n- Steps are ordered by dependency (step 2 may depend on step 1)\n- Each step names specific files and functions\n- Total steps: 3-10 (if more — the task is too large, suggest splitting)\n- Include a verification method for each step\n\n### STEP 6: Present to user\n\nShow the full analysis:\n1. Implementation Brief (STEP 3)\n2. Codebase Mapping (STEP 4)\n3. Implementation Plan (STEP 5)\n\nIf critical issues were found in STEP 2 (stale, contradictions, missing requirements):\n- Show them FIRST, before the plan\n- Ask: \"Should I proceed with the plan despite these issues, or do you want to resolve them first?\"\n\n### STEP 7: Ask for action\n\n```\nWhat would you like to do?\n- \"start\" — begin implementing step 1 of the plan\n- \"refine\" — adjust the plan (specify what to change)\n- \"comment\" — post the analysis as a comment on the YT task\n- \"subtasks\" — create subtasks in YT from the plan steps\n- \"done\" — analysis complete, no further action\n```\n\nWait for user response. Do NOT proceed without explicit instruction.\n\n### STEP 8: Execute action (if requested)\n\n#### If \"start\":\n1. Begin implementing Step 1 from the plan\n2. Follow the plan sequentially\n3. Mark completed steps\n\n#### If \"comment\":\nPost the Implementation Brief as a YouTrack comment:\n```\nyoutrack_add_issue_comment(\n  issueId: \"\u003CISSUE_ID>\",\n  text: \"\u003CImplementation Brief markdown>\"\n)\n```\n\n#### If \"subtasks\":\nFor each plan step, create a subtask:\n```\nyoutrack_create_issue(\n  project: \"\u003CPROJECT_KEY>\",\n  summary: \"Step N: \u003Cstep title>\",\n  description: \"\u003Cstep details + affected files + verification>\",\n  parentIssue: \"\u003CISSUE_ID>\",\n  customFields: { \"Type\": \"Task\" }\n)\n```\n\n## Hard rules\n\n- NEVER modify YouTrack tasks without explicit user permission (no auto-update of State, Assignee, etc.)\n- NEVER create subtasks without explicit user permission\n- NEVER start implementing without explicit user permission\n- If YouTrack MCP is not configured or auth fails — tell user and stop\n- Answer in the same language the user uses\n- Be honest about uncertainty: if requirements are unclear, SAY SO — don't guess\n- Don't invent requirements that aren't in the task or comments\n- Distinguish between FACTS (from task data) and INFERENCES (your analysis) — label them\n- When mapping to codebase: verify files exist before listing them in the plan\n- If the codebase doesn't match the task context (wrong repo) — warn the user\n",{"name":5,"description":7},"master","cbded6c96796a063405af105d5b3209ab6219407","dotfiles\u002Fdot_agents\u002Fskills\u002Fyt-analyze",0,"https:\u002F\u002Fgithub.com\u002FArtawower\u002Fkaizen","https:\u002F\u002Fgithub.com\u002FArtawower","workationmode.com","2026-11-10 19:23:03",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add Artawower\u002Fkaizen --skill yt-analyze",{"tool":63,"command":64},"bunx","bunx skills add Artawower\u002Fkaizen --skill yt-analyze",{"tool":66,"command":67},"pnpm","pnpm dlx skills add Artawower\u002Fkaizen --skill yt-analyze","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FArtawower\u002Fkaizen\u002Fblob\u002Fmaster\u002Fdotfiles\u002Fdot_agents\u002Fskills\u002Fyt-analyze\u002FSKILL.md",true,[],[72,92,116,136,162,182],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":44},"01M71SYF7RSTEXKDWPXJ08EVQG","youtrack-task","Analyzes a YouTrack issue, reviews comments and attachments, and proposes or creates actionable subtasks. Use when the user gives a YouTrack issue ID and wants synthesis, decomposition, or follow-up tasks.","https:\u002F\u002Fgithub.com\u002FArtawower\u002Fkaizen\u002Fblob\u002Fmaster\u002Fdotfiles\u002Fdot_agents\u002Fskills\u002Fyoutrack-task\u002FSKILL.md",[],[79,35,27,80,81,82,83,84,85,36,86,87,88,30,89,90,91],"youtrack task","id","reviews","attachments","decomposition","actionable","up","follow-up","use","when","tasks","Synthesis","user",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":44},"01M71SYCE94601T6DA5G2GDKYA","youtrack-search","Searches YouTrack from natural language or native query syntax and returns a concise report with the most relevant issues. Use when the user wants to find issues, triage work, or translate a plain-language query into YouTrack search.","https:\u002F\u002Fgithub.com\u002FArtawower\u002Fkaizen\u002Fblob\u002Fmaster\u002Fdotfiles\u002Fdot_agents\u002Fskills\u002Fyoutrack-search\u002FSKILL.md",[],[99,100,35,101,102,103,104,105,87,88,106,107,108,109,110,111,112,113,114,115],"search","youtrack search","natural language","relevant","translate","issues","plain-language","query","with","work","concise","native","find","report","syntax","triage","plain",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":130,"publishedAt":44},"01M71SYAXN8EA6DDXEZWVY872S","writing-for-agents","Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.","https:\u002F\u002Fgithub.com\u002FArtawower\u002Fkaizen\u002Fblob\u002Fmaster\u002Fdotfiles\u002Fdot_agents\u002Fskills\u002Fwriting-for-agents\u002FSKILL.md",[122,125],{"categoryNo":123,"categoryName":124,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":126,"categoryName":127,"taxonomyType":128,"taxonomyTypeDesc":129},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[131,132,133,134,87,135,88],"writing for agents","for","writing","editing","documents",{"skillNo":137,"name":138,"nameZh":6,"description":139,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":140,"categories":141,"keywords":145,"publishedAt":44},"01M71SY8ZKMWPF8ZAENT7MQE28","write-a-prd","Create a PRD through user interview, codebase exploration, and module design, then submit as a GitHub issue. Use when user wants to write a PRD, create a product requirements document, or plan a new feature.","https:\u002F\u002Fgithub.com\u002FArtawower\u002Fkaizen\u002Fblob\u002Fmaster\u002Fdotfiles\u002Fdot_agents\u002Fskills\u002Fwrite-a-prd\u002FSKILL.md",[142],{"categoryNo":143,"categoryName":144,"taxonomyType":128,"taxonomyTypeDesc":129},"01JBSEEDCAT000000000000031","产品经理",[146,147,148,149,150,151,152,153,154,155,156,87,157,88,158,159,29,160,161,39],"write","write a prd","prd","interview","as","exploration","feature","submit","design","module","new","document","user interview","codebase exploration","create","new feature",{"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":168,"publishedAt":44},"01M71SY6J9F119TJSMA2YBEP5P","vitest","Plan and write Vitest tests for changed code. Analyses git diff, checks existing tests, produces a concrete test plan using flat test structure (no describe\u002Fit blocks). Use when adding tests for new\u002Fchanged code, improving Vitest coverage, or asking what to test after a change.","https:\u002F\u002Fgithub.com\u002FArtawower\u002Fkaizen\u002Fblob\u002Fmaster\u002Fdotfiles\u002Fdot_agents\u002Fskills\u002Fvitest\u002FSKILL.md",[],[164,169,170,171,132,172,156,87,173,174,88,175,176,177,39,178,179,146,180,181],"coverage","test plan","diff","tests","Existing","adding tests","code","test","structure","change","flat","blocks","git",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":189,"publishedAt":44},"01M71SY0V0FBDY99Y0Y5GCARTY","skill-reviewer","Analyzes pi skills — both remote (URL\u002FGitHub) and local (installed on disk). Fetches the skill, runs a security audit, summarizes what it does and which problems it solves, then polls multiple AI models for a multi-model consensus rating. Use this skill whenever the user shares a link to a skill and wants to know if it's safe and worth installing, asks to review or evaluate a skill from GitHub, asks to audit an already installed local skill, says something like 'check this skill', 'review my skills', 'should I install this', 'audit this skill', or wants a second opinion on a skill's quality. Also triggers on 'проанализируй скилл', 'проверь скилл по ссылке', 'оцени скилл', 'проверь локальный скилл' — works in both English and Russian.","https:\u002F\u002Fgithub.com\u002FArtawower\u002Fkaizen\u002Fblob\u002Fmaster\u002Fdotfiles\u002Fdot_agents\u002Fskills\u002Fskill-reviewer\u002FSKILL.md",[188],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209],"skill reviewer","reviewer","which","consensus","model","security audit","rating","russian","local","remote","URL","disk","review","english","audit","safe","install","a skill","ai models","my"]