[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6HQW6BB1Q8W04YTNETRWVV1":3,"skill-same:01M6HQW6BB1Q8W04YTNETRWVV1":64},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":49,"install":50,"resources":63},"01M6HQW6BB1Q8W04YTNETRWVV1","stakeholder-comms",null,"Draft stakeholder updates tailored to audience — executives, engineering, customers, or cross-functional partners. Use when writing weekly status updates, monthly reports, launch announcements, risk communications, or decision documentation.","welflau\u002Fai-dev-system","welflau","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F7010385?v=4","01M6HPTDGF18RFY07M229P8CTM","01M6HPTDMRMZCJPYBFEA9XVVYT",3,"MIT","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcb_teams_marketplace\u002Fplugins\u002Fproduct-management\u002Fskills\u002Fstakeholder-comms\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"stakeholder comms","comms","reports","when","weekly","updates","functional","communications","monthly","draft","writing","status updates","use","decision","risk","engineering","partners","documentation","status","launch","2026-11-10 10:12:30",false,"---\nname: stakeholder-comms\ndescription: Draft stakeholder updates tailored to audience — executives, engineering, customers, or cross-functional partners. Use when writing weekly status updates, monthly reports, launch announcements, risk communications, or decision documentation.\n---\n\n# Stakeholder Communications Skill\n\nYou are an expert at product management communications — status updates, stakeholder management, risk communication, decision documentation, and meeting facilitation. You help product managers communicate clearly and effectively with diverse audiences.\n\n## Update Templates by Audience\n\n### Executive \u002F Leadership Update\nExecutives want: strategic context, progress against goals, risks that need their help, decisions that need their input.\n\n**Format**:\n```\nStatus: [Green \u002F Yellow \u002F Red]\n\nTL;DR: [One sentence — the most important thing to know]\n\nProgress:\n- [Outcome achieved, tied to goal\u002FOKR]\n- [Milestone reached, with impact]\n- [Key metric movement]\n\nRisks:\n- [Risk]: [Mitigation plan]. [Ask if needed].\n\nDecisions needed:\n- [Decision]: [Options with recommendation]. Need by [date].\n\nNext milestones:\n- [Milestone] — [Date]\n```\n\n**Tips for executive updates**:\n- Lead with the conclusion, not the journey. Executives want \"we shipped X and it moved Y metric\" not \"we had 14 standups and resolved 23 tickets.\"\n- Keep it under 200 words. If they want more, they will ask.\n- Status color should reflect YOUR genuine assessment, not what you think they want to hear. Yellow is not a failure — it is good risk management.\n- Only include risks you want help with. Do not list risks you are already handling unless they need to know.\n- Asks must be specific: \"Decision on X by Friday\" not \"support needed.\"\n\n### Engineering Team Update\nEngineers want: clear priorities, technical context, blockers resolved, decisions that affect their work.\n\n**Format**:\n```\nShipped:\n- [Feature\u002Ffix] — [Link to PR\u002Fticket]. [Impact if notable].\n\nIn progress:\n- [Item] — [Owner]. [Expected completion]. [Blockers if any].\n\nDecisions:\n- [Decision made]: [Rationale]. [Link to ADR if exists].\n- [Decision needed]: [Context]. [Options]. [Recommendation].\n\nPriority changes:\n- [What changed and why]\n\nComing up:\n- [Next items] — [Context on why these are next]\n```\n\n**Tips for engineering updates**:\n- Link to specific tickets, PRs, and documents. Engineers want to click through for details.\n- When priorities change, explain why. Engineers are more bought in when they understand the reason.\n- Be explicit about what is blocking them and what you are doing to unblock it.\n- Do not waste their time with information that does not affect their work.\n\n### Cross-Functional Partner Update\nPartners (design, marketing, sales, support) want: what is coming that affects them, what they need to prepare for, how to give input.\n\n**Format**:\n```\nWhat's coming:\n- [Feature\u002Flaunch] — [Date]. [What this means for your team].\n\nWhat we need from you:\n- [Specific ask] — [Context]. By [date].\n\nDecisions made:\n- [Decision] — [How it affects your team].\n\nOpen for input:\n- [Topic we'd love feedback on] — [How to provide it].\n```\n\n### Customer \u002F External Update\nCustomers want: what is new, what is coming, how it benefits them, how to get started.\n\n**Format**:\n```\nWhat's new:\n- [Feature] — [Benefit in customer terms]. [How to use it \u002F link].\n\nComing soon:\n- [Feature] — [Expected timing]. [Why it matters to you].\n\nKnown issues:\n- [Issue] — [Status]. [Workaround if available].\n\nFeedback:\n- [How to share feedback or request features]\n```\n\n**Tips for customer updates**:\n- No internal jargon. No ticket numbers. No technical implementation details.\n- Frame everything in terms of what the customer can now DO, not what you built.\n- Be honest about timelines but do not overcommit. \"Later this quarter\" is better than a date you might miss.\n- Only mention known issues if they are customer-impacting and you have a resolution plan.\n\n## Status Reporting Framework\n\n### Green \u002F Yellow \u002F Red Status\n\n**Green** (On Track):\n- Progressing as planned\n- No significant risks or blockers\n- On track to meet commitments and deadlines\n- Use Green when things are genuinely going well — not as a default\n\n**Yellow** (At Risk):\n- Progress is slower than planned, or a risk has materialized\n- Mitigation is underway but outcome is uncertain\n- May miss commitments without intervention or scope adjustment\n- Use Yellow proactively — the earlier you flag risk, the more options you have\n\n**Red** (Off Track):\n- Significantly behind plan\n- Major blocker or risk without clear mitigation\n- Will miss commitments without significant intervention (scope cut, resource addition, timeline extension)\n- Use Red when you genuinely need help. Do not wait until it is too late.\n\n### When to Change Status\n- Move to Yellow at the FIRST sign of risk, not when you are sure things are bad\n- Move to Red when you have exhausted your own options and need escalation\n- Move back to Green only when the risk is genuinely resolved, not just paused\n- Document what changed when you change status — \"Moved to Yellow because [reason]\"\n\n## Risk Communication\n\n### ROAM Framework for Risk Management\n- **Resolved**: Risk is no longer a concern. Document how it was resolved.\n- **Owned**: Risk is acknowledged and someone is actively managing it. State the owner and the mitigation plan.\n- **Accepted**: Risk is known but we are choosing to proceed without mitigation. Document the rationale.\n- **Mitigated**: Actions have reduced the risk to an acceptable level. Document what was done.\n\n### Communicating Risks Effectively\n1. **State the risk clearly**: \"There is a risk that [thing] happens because [reason]\"\n2. **Quantify the impact**: \"If this happens, the consequence is [impact]\"\n3. **State the likelihood**: \"This is [likely\u002Fpossible\u002Funlikely] because [evidence]\"\n4. **Present the mitigation**: \"We are managing this by [actions]\"\n5. **Make the ask**: \"We need [specific help] to further reduce this risk\"\n\n### Common Mistakes in Risk Communication\n- Burying risks in good news. Lead with risks when they are important.\n- Being vague: \"There might be some delays\" — specify what, how long, and why.\n- Presenting risks without mitigations. Every risk should come with a plan.\n- Waiting too long. A risk communicated early is a planning input. A risk communicated late is a fire drill.\n\n## Decision Documentation (ADRs)\n\n### Architecture Decision Record Format\nDocument important decisions for future reference:\n\n```\n# [Decision Title]\n\n## Status\n[Proposed \u002F Accepted \u002F Deprecated \u002F Superseded by ADR-XXX]\n\n## Context\nWhat is the situation that requires a decision? What forces are at play?\n\n## Decision\nWhat did we decide? State the decision clearly and directly.\n\n## Consequences\nWhat are the implications of this decision?\n- Positive consequences\n- Negative consequences or tradeoffs accepted\n- What this enables or prevents in the future\n\n## Alternatives Considered\nWhat other options were evaluated?\nFor each: what was it, why was it rejected?\n```\n\n### When to Write an ADR\n- Strategic product decisions (which market segment to target, which platform to support)\n- Significant technical decisions (architecture choices, vendor selection, build vs buy)\n- Controversial decisions where people disagreed (document the rationale for future reference)\n- Decisions that constrain future options (choosing a technology, signing a partnership)\n- Decisions you expect people to question later (capture the context while it is fresh)\n\n### Tips for Decision Documentation\n- Write ADRs close to when the decision is made, not weeks later\n- Include who was involved in the decision and who made the final call\n- Document the context generously — future readers will not have today's context\n- It is okay to document decisions that were wrong in hindsight — add a \"superseded by\" link\n- Keep them short. One page is better than five.\n\n## Meeting Facilitation\n\n### Stand-up \u002F Daily Sync\n**Purpose**: Surface blockers, coordinate work, maintain momentum.\n**Format**: Each person shares:\n- What they accomplished since last sync\n- What they are working on next\n- What is blocking them\n\n**Facilitation tips**:\n- Keep it to 15 minutes. If discussions emerge, take them offline.\n- Focus on blockers — this is the highest-value part of standup\n- Track blockers and follow up on resolution\n- Cancel standup if there is nothing to sync on. Respect people's time.\n\n### Sprint \u002F Iteration Planning\n**Purpose**: Commit to work for the next sprint. Align on priorities and scope.\n**Format**:\n1. Review: what shipped last sprint, what carried over, what was cut\n2. Priorities: what are the most important things to accomplish this sprint\n3. Capacity: how much can the team take on (account for PTO, on-call, meetings)\n4. Commitment: select items from the backlog that fit capacity and priorities\n5. Dependencies: flag any cross-team or external dependencies\n\n**Facilitation tips**:\n- Come with a proposed priority order. Do not ask the team to prioritize from scratch.\n- Push back on overcommitment. It is better to commit to less and deliver reliably.\n- Ensure every item has a clear owner and clear acceptance criteria.\n- Flag items that are underscoped or have hidden complexity.\n\n### Retrospective\n**Purpose**: Reflect on what went well, what did not, and what to change.\n**Format**:\n1. Set the stage: remind the team of the goal and create psychological safety\n2. Gather data: what went well, what did not go well, what was confusing\n3. Generate insights: identify patterns and root causes\n4. Decide actions: pick 1-3 specific improvements to try next sprint\n5. Close: thank people for honest feedback\n\n**Facilitation tips**:\n- Create psychological safety. People must feel safe to be honest.\n- Focus on systems and processes, not individuals.\n- Limit to 1-3 action items. More than that and nothing changes.\n- Follow up on previous retro action items. If you never follow up, people stop engaging.\n- Vary the retro format occasionally to prevent staleness.\n\n### Stakeholder Review \u002F Demo\n**Purpose**: Show progress, gather feedback, build alignment.\n**Format**:\n1. Context: remind stakeholders of the goal and what they saw last time\n2. Demo: show what was built. Use real product, not slides.\n3. Metrics: share any early data or feedback\n4. Feedback: structured time for questions and input\n5. Next steps: what is coming next and when the next review will be\n\n**Facilitation tips**:\n- Demo the real product whenever possible. Slides are not demos.\n- Frame feedback collection: \"What feedback do you have on X?\" is better than \"Any thoughts?\"\n- Capture feedback visibly and commit to addressing it (or explaining why not)\n- Set expectations about what kind of feedback is actionable at this stage\n","# Stakeholder Communications Skill\n\nYou are an expert at product management communications — status updates, stakeholder management, risk communication, decision documentation, and meeting facilitation. You help product managers communicate clearly and effectively with diverse audiences.\n\n## Update Templates by Audience\n\n### Executive \u002F Leadership Update\nExecutives want: strategic context, progress against goals, risks that need their help, decisions that need their input.\n\n**Format**:\n```\nStatus: [Green \u002F Yellow \u002F Red]\n\nTL;DR: [One sentence — the most important thing to know]\n\nProgress:\n- [Outcome achieved, tied to goal\u002FOKR]\n- [Milestone reached, with impact]\n- [Key metric movement]\n\nRisks:\n- [Risk]: [Mitigation plan]. [Ask if needed].\n\nDecisions needed:\n- [Decision]: [Options with recommendation]. Need by [date].\n\nNext milestones:\n- [Milestone] — [Date]\n```\n\n**Tips for executive updates**:\n- Lead with the conclusion, not the journey. Executives want \"we shipped X and it moved Y metric\" not \"we had 14 standups and resolved 23 tickets.\"\n- Keep it under 200 words. If they want more, they will ask.\n- Status color should reflect YOUR genuine assessment, not what you think they want to hear. Yellow is not a failure — it is good risk management.\n- Only include risks you want help with. Do not list risks you are already handling unless they need to know.\n- Asks must be specific: \"Decision on X by Friday\" not \"support needed.\"\n\n### Engineering Team Update\nEngineers want: clear priorities, technical context, blockers resolved, decisions that affect their work.\n\n**Format**:\n```\nShipped:\n- [Feature\u002Ffix] — [Link to PR\u002Fticket]. [Impact if notable].\n\nIn progress:\n- [Item] — [Owner]. [Expected completion]. [Blockers if any].\n\nDecisions:\n- [Decision made]: [Rationale]. [Link to ADR if exists].\n- [Decision needed]: [Context]. [Options]. [Recommendation].\n\nPriority changes:\n- [What changed and why]\n\nComing up:\n- [Next items] — [Context on why these are next]\n```\n\n**Tips for engineering updates**:\n- Link to specific tickets, PRs, and documents. Engineers want to click through for details.\n- When priorities change, explain why. Engineers are more bought in when they understand the reason.\n- Be explicit about what is blocking them and what you are doing to unblock it.\n- Do not waste their time with information that does not affect their work.\n\n### Cross-Functional Partner Update\nPartners (design, marketing, sales, support) want: what is coming that affects them, what they need to prepare for, how to give input.\n\n**Format**:\n```\nWhat's coming:\n- [Feature\u002Flaunch] — [Date]. [What this means for your team].\n\nWhat we need from you:\n- [Specific ask] — [Context]. By [date].\n\nDecisions made:\n- [Decision] — [How it affects your team].\n\nOpen for input:\n- [Topic we'd love feedback on] — [How to provide it].\n```\n\n### Customer \u002F External Update\nCustomers want: what is new, what is coming, how it benefits them, how to get started.\n\n**Format**:\n```\nWhat's new:\n- [Feature] — [Benefit in customer terms]. [How to use it \u002F link].\n\nComing soon:\n- [Feature] — [Expected timing]. [Why it matters to you].\n\nKnown issues:\n- [Issue] — [Status]. [Workaround if available].\n\nFeedback:\n- [How to share feedback or request features]\n```\n\n**Tips for customer updates**:\n- No internal jargon. No ticket numbers. No technical implementation details.\n- Frame everything in terms of what the customer can now DO, not what you built.\n- Be honest about timelines but do not overcommit. \"Later this quarter\" is better than a date you might miss.\n- Only mention known issues if they are customer-impacting and you have a resolution plan.\n\n## Status Reporting Framework\n\n### Green \u002F Yellow \u002F Red Status\n\n**Green** (On Track):\n- Progressing as planned\n- No significant risks or blockers\n- On track to meet commitments and deadlines\n- Use Green when things are genuinely going well — not as a default\n\n**Yellow** (At Risk):\n- Progress is slower than planned, or a risk has materialized\n- Mitigation is underway but outcome is uncertain\n- May miss commitments without intervention or scope adjustment\n- Use Yellow proactively — the earlier you flag risk, the more options you have\n\n**Red** (Off Track):\n- Significantly behind plan\n- Major blocker or risk without clear mitigation\n- Will miss commitments without significant intervention (scope cut, resource addition, timeline extension)\n- Use Red when you genuinely need help. Do not wait until it is too late.\n\n### When to Change Status\n- Move to Yellow at the FIRST sign of risk, not when you are sure things are bad\n- Move to Red when you have exhausted your own options and need escalation\n- Move back to Green only when the risk is genuinely resolved, not just paused\n- Document what changed when you change status — \"Moved to Yellow because [reason]\"\n\n## Risk Communication\n\n### ROAM Framework for Risk Management\n- **Resolved**: Risk is no longer a concern. Document how it was resolved.\n- **Owned**: Risk is acknowledged and someone is actively managing it. State the owner and the mitigation plan.\n- **Accepted**: Risk is known but we are choosing to proceed without mitigation. Document the rationale.\n- **Mitigated**: Actions have reduced the risk to an acceptable level. Document what was done.\n\n### Communicating Risks Effectively\n1. **State the risk clearly**: \"There is a risk that [thing] happens because [reason]\"\n2. **Quantify the impact**: \"If this happens, the consequence is [impact]\"\n3. **State the likelihood**: \"This is [likely\u002Fpossible\u002Funlikely] because [evidence]\"\n4. **Present the mitigation**: \"We are managing this by [actions]\"\n5. **Make the ask**: \"We need [specific help] to further reduce this risk\"\n\n### Common Mistakes in Risk Communication\n- Burying risks in good news. Lead with risks when they are important.\n- Being vague: \"There might be some delays\" — specify what, how long, and why.\n- Presenting risks without mitigations. Every risk should come with a plan.\n- Waiting too long. A risk communicated early is a planning input. A risk communicated late is a fire drill.\n\n## Decision Documentation (ADRs)\n\n### Architecture Decision Record Format\nDocument important decisions for future reference:\n\n```\n# [Decision Title]\n\n## Status\n[Proposed \u002F Accepted \u002F Deprecated \u002F Superseded by ADR-XXX]\n\n## Context\nWhat is the situation that requires a decision? What forces are at play?\n\n## Decision\nWhat did we decide? State the decision clearly and directly.\n\n## Consequences\nWhat are the implications of this decision?\n- Positive consequences\n- Negative consequences or tradeoffs accepted\n- What this enables or prevents in the future\n\n## Alternatives Considered\nWhat other options were evaluated?\nFor each: what was it, why was it rejected?\n```\n\n### When to Write an ADR\n- Strategic product decisions (which market segment to target, which platform to support)\n- Significant technical decisions (architecture choices, vendor selection, build vs buy)\n- Controversial decisions where people disagreed (document the rationale for future reference)\n- Decisions that constrain future options (choosing a technology, signing a partnership)\n- Decisions you expect people to question later (capture the context while it is fresh)\n\n### Tips for Decision Documentation\n- Write ADRs close to when the decision is made, not weeks later\n- Include who was involved in the decision and who made the final call\n- Document the context generously — future readers will not have today's context\n- It is okay to document decisions that were wrong in hindsight — add a \"superseded by\" link\n- Keep them short. One page is better than five.\n\n## Meeting Facilitation\n\n### Stand-up \u002F Daily Sync\n**Purpose**: Surface blockers, coordinate work, maintain momentum.\n**Format**: Each person shares:\n- What they accomplished since last sync\n- What they are working on next\n- What is blocking them\n\n**Facilitation tips**:\n- Keep it to 15 minutes. If discussions emerge, take them offline.\n- Focus on blockers — this is the highest-value part of standup\n- Track blockers and follow up on resolution\n- Cancel standup if there is nothing to sync on. Respect people's time.\n\n### Sprint \u002F Iteration Planning\n**Purpose**: Commit to work for the next sprint. Align on priorities and scope.\n**Format**:\n1. Review: what shipped last sprint, what carried over, what was cut\n2. Priorities: what are the most important things to accomplish this sprint\n3. Capacity: how much can the team take on (account for PTO, on-call, meetings)\n4. Commitment: select items from the backlog that fit capacity and priorities\n5. Dependencies: flag any cross-team or external dependencies\n\n**Facilitation tips**:\n- Come with a proposed priority order. Do not ask the team to prioritize from scratch.\n- Push back on overcommitment. It is better to commit to less and deliver reliably.\n- Ensure every item has a clear owner and clear acceptance criteria.\n- Flag items that are underscoped or have hidden complexity.\n\n### Retrospective\n**Purpose**: Reflect on what went well, what did not, and what to change.\n**Format**:\n1. Set the stage: remind the team of the goal and create psychological safety\n2. Gather data: what went well, what did not go well, what was confusing\n3. Generate insights: identify patterns and root causes\n4. Decide actions: pick 1-3 specific improvements to try next sprint\n5. Close: thank people for honest feedback\n\n**Facilitation tips**:\n- Create psychological safety. People must feel safe to be honest.\n- Focus on systems and processes, not individuals.\n- Limit to 1-3 action items. More than that and nothing changes.\n- Follow up on previous retro action items. If you never follow up, people stop engaging.\n- Vary the retro format occasionally to prevent staleness.\n\n### Stakeholder Review \u002F Demo\n**Purpose**: Show progress, gather feedback, build alignment.\n**Format**:\n1. Context: remind stakeholders of the goal and what they saw last time\n2. Demo: show what was built. Use real product, not slides.\n3. Metrics: share any early data or feedback\n4. Feedback: structured time for questions and input\n5. Next steps: what is coming next and when the next review will be\n\n**Facilitation tips**:\n- Demo the real product whenever possible. Slides are not demos.\n- Frame feedback collection: \"What feedback do you have on X?\" is better than \"Any thoughts?\"\n- Capture feedback visibly and commit to addressing it (or explaining why not)\n- Set expectations about what kind of feedback is actionable at this stage\n",{"name":5,"description":7},"main","18d0e63d1313ca87098f614aa7c1e2dcf6de79c7","backend\u002Fskills\u002Fmarketplace\u002Fcb_teams_marketplace\u002Fplugins\u002Fproduct-management\u002Fskills\u002Fstakeholder-comms",1,"https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system","https:\u002F\u002Fgithub.com\u002Fwelflau","2026-11-12 14:55:20",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add welflau\u002Fai-dev-system --skill stakeholder-comms",{"tool":56,"command":57},"bunx","bunx skills add welflau\u002Fai-dev-system --skill stakeholder-comms",{"tool":59,"command":60},"pnpm","pnpm dlx skills add welflau\u002Fai-dev-system --skill stakeholder-comms","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcb_teams_marketplace\u002Fplugins\u002Fproduct-management\u002Fskills\u002Fstakeholder-comms\u002FSKILL.md",true,[],[65,99,130,155,181,205],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":69,"licenseFileUrl":70,"sourceHtmlUrl":71,"categories":72,"keywords":78,"publishedAt":38},"01M6HSTDP4M3JFXEBK91VFB4PA","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fplugins\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fplugins\u002Fweb-artifacts-builder\u002FSKILL.md",[73],{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",[79,80,81,82,83,84,85,86,87,88,89,90,91,92,30,93,94,95,96,97,98],"web artifacts builder","web","artifacts","artifacts builder","builder","frontend","css","components","react","routing","state management","state","file","Tailwind","single-file","simple","ui components","multi","for","single",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":69,"licenseFileUrl":103,"sourceHtmlUrl":104,"categories":105,"keywords":115,"publishedAt":38},"01M6HSDXH0JSP8R3QTNY9XZ8HN","frontend-design","Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML\u002FCSS layouts, or when styling\u002Fbeautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fplugins\u002Ffrontend-design\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fplugins\u002Ffrontend-design\u002FSKILL.md",[106,107,110],{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},{"categoryNo":108,"categoryName":109,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":111,"categoryName":112,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[84,116,117,85,80,86,87,118,119,120,81,121,122,123,30,124,125,126,127,128,129,21],"design","frontend design","react components","create","code","examples","applications","landing","ui design","pages","aesthetics","web ui","with","generic",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":69,"licenseFileUrl":134,"sourceHtmlUrl":135,"categories":136,"keywords":138,"publishedAt":38},"01M6HSA77QYVP7A72HREGTDN2C","algorithmic-art","Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fplugins\u002Falgorithmic-art\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fplugins\u002Falgorithmic-art\u002FSKILL.md",[137],{"categoryNo":108,"categoryName":109,"taxonomyType":76,"taxonomyTypeDesc":77},[139,140,141,119,120,142,143,144,145,30,146,147,148,149,128,150,151,152,153,154,21],"algorithmic art","Art","algorithmic","flow","js","work","interactive","generative art","exploration","systems","users","Existing","request","generative","copyright","fields",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":69,"licenseFileUrl":159,"sourceHtmlUrl":160,"categories":161,"keywords":163,"publishedAt":38},"01M6HS9HE0X390Y6RQKTY1YNGJ","theme-factory","Toolkit for styling artifacts with a theme. These artifacts can be slides, docs, reportings, HTML landing pages, etc. There are 10 pre-set themes with colors\u002Ffonts that you can apply to any artifact that has been creating, or can generate a new theme on-the-fly.","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fexternal_plugins\u002Ftheme-factory\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fexternal_plugins\u002Ftheme-factory\u002FSKILL.md",[162],{"categoryNo":108,"categoryName":109,"taxonomyType":76,"taxonomyTypeDesc":77},[164,165,166,167,168,169,81,170,171,172,123,173,174,125,175,128,176,177,178,97,179,180],"theme factory","factory","theme","docs","toolkit","generate","SET","fly","slides","styling","artifact","themes","you","fonts","can","apply","new",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":190,"publishedAt":38},"01M6HS74GASM6FJ77F83EY679E","browsing","Use when you need direct browser control - teaches Chrome DevTools Protocol for controlling existing browser sessions, multi-tab management, form automation, and content extraction via use_browser MCP tool","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fexternal_plugins\u002Fsuperpowers-chrome\u002Fskills\u002Fbrowsing\u002FSKILL.md",[187],{"categoryNo":188,"categoryName":189,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000023","Skill与智能体开发",[183,191,192,193,194,195,196,197,198,199,200,30,201,202,203,204,96,176,97,150],"MCP","automation","chrome","sessions","protocol","browser","devtools","chrome devtools","tool","direct","browser control","control","via","form",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":69,"licenseFileUrl":209,"sourceHtmlUrl":210,"categories":211,"keywords":218,"publishedAt":38},"01M6HS6BZT2CKDNQ6YF20DXN4T","slack-gif-creator","Knowledge and utilities for creating animated GIFs optimized for Slack. Provides constraints, validation tools, and animation concepts. Use when users request animated GIFs for Slack like \"make me a GIF of X doing Y for Slack.\"","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fexternal_plugins\u002Fslack-gif-creator\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fwelflau\u002Fai-dev-system\u002Fblob\u002Fmain\u002Fbackend\u002Fskills\u002Fmarketplace\u002Fcodebuddy-plugins-official\u002Fexternal_plugins\u002Fslack-gif-creator\u002FSKILL.md",[212,215],{"categoryNo":213,"categoryName":214,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000005","邮件与沟通",{"categoryNo":216,"categoryName":217,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000016","图像与多媒体",[219,220,221,222,223,224,225,226,227,30,228,149,229,230,231,97,151,21],"slack gif creator","slack","gif","creator","validation","Tools","constraints","Animation","knowledge","me","make","Utilities","concepts"]