[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7CSNB32HS9CFWM5KMHYSKMB":3,"skill-same:01M7CSNB32HS9CFWM5KMHYSKMB":72},{"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":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":30,"ownerHtmlUrl":31,"ownerBlogUrl":6,"ownerDescription":32,"updatedAt":33,"install":34,"resources":47},"01M7CSNB32HS9CFWM5KMHYSKMB","nemo-mbridge-perf-moe-optimization-workflow",null,"Systematic workflow for MoE training optimization in Megatron Bridge, based on the Megatron-Core MoE paper. Covers the Three Walls framework, parallel folding, recompute strategy, dispatcher choice, and CUDA-graph bring-up.","YYC-Cube\u002FYYC3-Knowledge-Base","YYC-Cube","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F235006543?v=4","01M79J2PH4SWD2X0825X6PN748","yyc3","01M79J2PHVK3F6ZBYT8K2SCZCW",1,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemo-mbridge-perf-moe-optimization-workflow\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: nemo-mbridge-perf-moe-optimization-workflow\ndescription: Systematic workflow for MoE training optimization in Megatron Bridge, based on the Megatron-Core MoE paper. Covers the Three Walls framework, parallel folding, recompute strategy, dispatcher choice, and CUDA-graph bring-up.\nlicense: Apache-2.0\nwhen_to_use: Full MoE throughput tuning sweep, or diagnosing a MoE throughput regression after a commit or config change; 'optimize MoE throughput', 'MoE perf tuning', 'Three Walls', 'memory wall', 'communication wall', 'compute wall'.\n---\n\n# MoE Training Optimization Workflow\n\nStable docs: @docs\u002Ftraining\u002Fmoe-optimization.md\nCard: @skills\u002Fnemo-mbridge-perf-moe-optimization-workflow\u002Fcard.yaml\nSource: [Scalable Training of MoE Models with Megatron Core](https:\u002F\u002Farxiv.org\u002Fabs\u002F2603.07685)\n\n## Quick Reference\n\nThink in terms of the paper's Three Walls:\n\n- memory wall\n- communication wall\n- compute and host-overhead wall\n\nMoE tuning is iterative. Fixing one wall usually exposes the next one, so the\nbest workflow is: fit first, scale second, profile third, then retune.\n\n## First Answer Checklist\n\nFor MoE optimization workflow prompts, present the response in this order:\n\n1. **Fit**: make the model memory-feasible first. Use the smallest model\n   parallelism that fits, prefer selective recompute before full recompute, add\n   offloading only after recompute and parallelism are insufficient, and use\n   `--fake-init-process-group` to sanity-check large layouts.\n2. **Scale**: maximize DP after the model fits, keep hot communication inside\n   the fastest interconnect, use PP plus VPP for multi-node scaling, prefer EP\n   over extra TP for expert layers, and add CP when long context makes attention\n   memory dominant.\n3. **Profile**: identify the dominant wall: memory, communication, host\n   overhead, or compute.\n4. **Retune**: change dispatcher, overlap, FP8 mode, CUDA graphs, or recompute\n   based on the profiled bottleneck.\n5. Include the exact Parallel Folding meshes: `Attention: TP x CP x DP x PP`\n   and `MoE: ETP x EP x EDP x PP`.\n6. Include the default mappings: `alltoall` for safe bring-up,\n   `flex` + `deepep` for H100\u002FB200-style systems, `flex` + `hybridep` for\n   GB200\u002FGB300\u002FNVL72 systems, Hopper to FP8 blockwise, Blackwell to MXFP8, and\n   dropless MoE TE-scoped CUDA graphs over `attn`, `moe_router`, and\n   `moe_preprocess`.\n\n## Phase 1: Make The Run Memory-Feasible\n\nStart with a configuration that fits reliably before chasing throughput.\n\nRecommended order:\n\n1. Use the smallest amount of model parallelism that still fits.\n2. Turn on selective recompute before falling back to full recompute.\n3. Add offloading only when recompute and parallelism are still insufficient.\n4. Use `--fake-init-process-group` to sanity-check large parallel layouts on a\n   single GPU before burning cluster time.\n\n### Recompute guidance\n\nPrefer selective recompute for MoE runs:\n\n- good first choices: `layernorm`, `core_attn`, `moe_act`, `mlp`, or\n  model-specific modules (`shared_experts`, `mla_up_proj`)\n- use full recompute only when the run still does not fit\n- revisit recompute after enabling CUDA graphs, because some graph scopes and\n  full recompute paths do not mix well\n\nAs a rule of thumb, fine-grained recompute often recovers most of the needed\nmemory while keeping throughput much closer to the non-recompute baseline than\nfull-layer recompute does.\n\n## Phase 2: Choose Parallelism For Scale\n\nPriority order:\n\n1. Maximize DP once the model fits.\n2. Keep the hot communication path inside the fast interconnect when possible.\n3. Use PP, plus VPP if needed, for multi-node scaling.\n4. Prefer EP over extra TP for expert layers.\n5. Add CP for long context once sequence length makes attention memory dominant.\n\n### Parallel Folding\n\nParallel Folding decouples attention and MoE parallelism so you do not have to\npick a single compromise layout:\n\n```text\nAttention: TP × CP × DP × PP\nMoE:       ETP × EP × EDP × PP\n```\n\nKey knobs:\n\n- `--expert-model-parallel-size`\n- `--expert-tensor-parallel-size`\n\nUse it when attention prefers some TP or CP, but expert layers benefit from a\nlarger EP degree than the dense layers can tolerate.\n\n## Phase 3: Profile The Dominant Bottleneck\n\n| Bottleneck | What it looks like | Primary fixes |\n|---|---|---|\n| Memory | Run fits only with aggressive full recompute or OOMs during warmup | selective recompute, FP8, offloading, better PP layout |\n| Communication | Nsight shows large all-to-all or collective blocks | DeepEP or HybridEP, EP overlap, DP\u002FTP overlap, better PP layout |\n| Host overhead | GPU gaps, launch-bound traces, Python overhead | CUDA graphs, `--manual-gc`, higher MBS, CPU affinity tuning |\n| Compute | Low SM utilization after comm and host issues are addressed | grouped GEMM, fusion work, FP8, dispatcher-specific kernel tuning |\n\n## Dispatcher And Overlap Guidance\n\nUse dispatcher choice as a bottleneck fix, not as the first tuning knob.\n\n- `moe_token_dispatcher_type=\"alltoall\"`: safest bring-up path, fine for\n  smaller EP sizes\n- `moe_token_dispatcher_type=\"flex\"` + `moe_flex_dispatcher_backend=\"deepep\"`:\n  strong default for H100 and B200 style deployments\n- `moe_token_dispatcher_type=\"flex\"` + `moe_flex_dispatcher_backend=\"hybridep\"`:\n  strongest starting point on GB200 or GB300 NVL72 systems\n\nIf the all-to-all path is visible in profiles, combine dispatcher tuning with:\n\n- `--overlap-moe-expert-parallel-comm`\n- `--overlap-grad-reduce`\n- `--tp-comm-overlap`\n\n## FP8 Recipe Quick Decision\n\n| Platform | Recommended starting recipe |\n|---|---|\n| Hopper | FP8 blockwise |\n| Blackwell | MXFP8 |\n| Blackwell, speed-first exploration | NVFP4 after the BF16 or FP8 path is stable |\n\nKeep the router in FP32. The largest wins usually come from expert GEMMs and\nother heavy matrix math, not from trying to quantize every small MoE component.\n\n## CUDA Graphs For MoE\n\nFor dropless MoE, start with partial TE-scoped graphs:\n\n- `attn`\n- `moe_router`\n- `moe_preprocess`\n\nThat path usually gives a meaningful step-time win while keeping the dynamic\nexpert work outside the graph. Expect a moderate speedup when launch overhead is\nvisible, but budget several extra GB of memory and verify that shapes remain\nstatic.\n\nUse full-iteration graphs only for graph-friendly workloads such as drop-and-pad\nor tightly controlled static-shape experiments.\n\nRelated references:\n\n- @skills\u002Fnemo-mbridge-perf-cuda-graphs\u002FSKILL.md\n- @docs\u002Ftraining\u002Fcuda-graphs.md\n- @docs\u002Ftraining\u002Factivation-recomputation.md\n\n## Pitfalls\n\n1. **Do not optimize in the wrong order**: fitting the model and selecting sane\n   parallelism matter more than micro-optimizations.\n\n2. **Platform changes the limiting wall**: H100-class runs often feel more\n   communication-bound, while GB200 or GB300 runs often expose CPU or launch\n   overhead earlier.\n\n3. **FP8 MFU can look misleadingly low**: compare absolute throughput as well as\n   MFU when switching precision modes.\n\n4. **CUDA graphs and recompute interact**: TE-scoped graphs are usually paired\n   with selective recompute, not blanket full recompute.\n\n5. **Parallel Folding is not optional at large scale**: once attention and expert\n   layers want clearly different layouts, a single shared TP or EP plan becomes\n   a tax on both.\n","# MoE Training Optimization Workflow\n\nStable docs: @docs\u002Ftraining\u002Fmoe-optimization.md\nCard: @skills\u002Fnemo-mbridge-perf-moe-optimization-workflow\u002Fcard.yaml\nSource: [Scalable Training of MoE Models with Megatron Core](https:\u002F\u002Farxiv.org\u002Fabs\u002F2603.07685)\n\n## Quick Reference\n\nThink in terms of the paper's Three Walls:\n\n- memory wall\n- communication wall\n- compute and host-overhead wall\n\nMoE tuning is iterative. Fixing one wall usually exposes the next one, so the\nbest workflow is: fit first, scale second, profile third, then retune.\n\n## First Answer Checklist\n\nFor MoE optimization workflow prompts, present the response in this order:\n\n1. **Fit**: make the model memory-feasible first. Use the smallest model\n   parallelism that fits, prefer selective recompute before full recompute, add\n   offloading only after recompute and parallelism are insufficient, and use\n   `--fake-init-process-group` to sanity-check large layouts.\n2. **Scale**: maximize DP after the model fits, keep hot communication inside\n   the fastest interconnect, use PP plus VPP for multi-node scaling, prefer EP\n   over extra TP for expert layers, and add CP when long context makes attention\n   memory dominant.\n3. **Profile**: identify the dominant wall: memory, communication, host\n   overhead, or compute.\n4. **Retune**: change dispatcher, overlap, FP8 mode, CUDA graphs, or recompute\n   based on the profiled bottleneck.\n5. Include the exact Parallel Folding meshes: `Attention: TP x CP x DP x PP`\n   and `MoE: ETP x EP x EDP x PP`.\n6. Include the default mappings: `alltoall` for safe bring-up,\n   `flex` + `deepep` for H100\u002FB200-style systems, `flex` + `hybridep` for\n   GB200\u002FGB300\u002FNVL72 systems, Hopper to FP8 blockwise, Blackwell to MXFP8, and\n   dropless MoE TE-scoped CUDA graphs over `attn`, `moe_router`, and\n   `moe_preprocess`.\n\n## Phase 1: Make The Run Memory-Feasible\n\nStart with a configuration that fits reliably before chasing throughput.\n\nRecommended order:\n\n1. Use the smallest amount of model parallelism that still fits.\n2. Turn on selective recompute before falling back to full recompute.\n3. Add offloading only when recompute and parallelism are still insufficient.\n4. Use `--fake-init-process-group` to sanity-check large parallel layouts on a\n   single GPU before burning cluster time.\n\n### Recompute guidance\n\nPrefer selective recompute for MoE runs:\n\n- good first choices: `layernorm`, `core_attn`, `moe_act`, `mlp`, or\n  model-specific modules (`shared_experts`, `mla_up_proj`)\n- use full recompute only when the run still does not fit\n- revisit recompute after enabling CUDA graphs, because some graph scopes and\n  full recompute paths do not mix well\n\nAs a rule of thumb, fine-grained recompute often recovers most of the needed\nmemory while keeping throughput much closer to the non-recompute baseline than\nfull-layer recompute does.\n\n## Phase 2: Choose Parallelism For Scale\n\nPriority order:\n\n1. Maximize DP once the model fits.\n2. Keep the hot communication path inside the fast interconnect when possible.\n3. Use PP, plus VPP if needed, for multi-node scaling.\n4. Prefer EP over extra TP for expert layers.\n5. Add CP for long context once sequence length makes attention memory dominant.\n\n### Parallel Folding\n\nParallel Folding decouples attention and MoE parallelism so you do not have to\npick a single compromise layout:\n\n```text\nAttention: TP × CP × DP × PP\nMoE:       ETP × EP × EDP × PP\n```\n\nKey knobs:\n\n- `--expert-model-parallel-size`\n- `--expert-tensor-parallel-size`\n\nUse it when attention prefers some TP or CP, but expert layers benefit from a\nlarger EP degree than the dense layers can tolerate.\n\n## Phase 3: Profile The Dominant Bottleneck\n\n| Bottleneck | What it looks like | Primary fixes |\n|---|---|---|\n| Memory | Run fits only with aggressive full recompute or OOMs during warmup | selective recompute, FP8, offloading, better PP layout |\n| Communication | Nsight shows large all-to-all or collective blocks | DeepEP or HybridEP, EP overlap, DP\u002FTP overlap, better PP layout |\n| Host overhead | GPU gaps, launch-bound traces, Python overhead | CUDA graphs, `--manual-gc`, higher MBS, CPU affinity tuning |\n| Compute | Low SM utilization after comm and host issues are addressed | grouped GEMM, fusion work, FP8, dispatcher-specific kernel tuning |\n\n## Dispatcher And Overlap Guidance\n\nUse dispatcher choice as a bottleneck fix, not as the first tuning knob.\n\n- `moe_token_dispatcher_type=\"alltoall\"`: safest bring-up path, fine for\n  smaller EP sizes\n- `moe_token_dispatcher_type=\"flex\"` + `moe_flex_dispatcher_backend=\"deepep\"`:\n  strong default for H100 and B200 style deployments\n- `moe_token_dispatcher_type=\"flex\"` + `moe_flex_dispatcher_backend=\"hybridep\"`:\n  strongest starting point on GB200 or GB300 NVL72 systems\n\nIf the all-to-all path is visible in profiles, combine dispatcher tuning with:\n\n- `--overlap-moe-expert-parallel-comm`\n- `--overlap-grad-reduce`\n- `--tp-comm-overlap`\n\n## FP8 Recipe Quick Decision\n\n| Platform | Recommended starting recipe |\n|---|---|\n| Hopper | FP8 blockwise |\n| Blackwell | MXFP8 |\n| Blackwell, speed-first exploration | NVFP4 after the BF16 or FP8 path is stable |\n\nKeep the router in FP32. The largest wins usually come from expert GEMMs and\nother heavy matrix math, not from trying to quantize every small MoE component.\n\n## CUDA Graphs For MoE\n\nFor dropless MoE, start with partial TE-scoped graphs:\n\n- `attn`\n- `moe_router`\n- `moe_preprocess`\n\nThat path usually gives a meaningful step-time win while keeping the dynamic\nexpert work outside the graph. Expect a moderate speedup when launch overhead is\nvisible, but budget several extra GB of memory and verify that shapes remain\nstatic.\n\nUse full-iteration graphs only for graph-friendly workloads such as drop-and-pad\nor tightly controlled static-shape experiments.\n\nRelated references:\n\n- @skills\u002Fnemo-mbridge-perf-cuda-graphs\u002FSKILL.md\n- @docs\u002Ftraining\u002Fcuda-graphs.md\n- @docs\u002Ftraining\u002Factivation-recomputation.md\n\n## Pitfalls\n\n1. **Do not optimize in the wrong order**: fitting the model and selecting sane\n   parallelism matter more than micro-optimizations.\n\n2. **Platform changes the limiting wall**: H100-class runs often feel more\n   communication-bound, while GB200 or GB300 runs often expose CPU or launch\n   overhead earlier.\n\n3. **FP8 MFU can look misleadingly low**: compare absolute throughput as well as\n   MFU when switching precision modes.\n\n4. **CUDA graphs and recompute interact**: TE-scoped graphs are usually paired\n   with selective recompute, not blanket full recompute.\n\n5. **Parallel Folding is not optional at large scale**: once attention and expert\n   layers want clearly different layouts, a single shared TP or EP plan becomes\n   a tax on both.\n",{"name":5,"license":15,"description":7,"when_to_use":24},"Full MoE throughput tuning sweep, or diagnosing a MoE throughput regression after a commit or config change; 'optimize MoE throughput', 'MoE perf tuning', 'Three Walls', 'memory wall', 'communication wall', 'compute wall'.","main","87afe6ce96220accf50a345dea46784c8c9f210e","YYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemo-mbridge-perf-moe-optimization-workflow",0,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base","https:\u002F\u002Fkb.yyc3.top\u002F","https:\u002F\u002Fgithub.com\u002FYYC-Cube","万象归元于云枢 | 深栈智启新纪元","2026-11-10 10:37:32",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add YYC-Cube\u002FYYC3-Knowledge-Base --skill nemo-mbridge-perf-moe-optimization-workflow",{"tool":40,"command":41},"bunx","bunx skills add YYC-Cube\u002FYYC3-Knowledge-Base --skill nemo-mbridge-perf-moe-optimization-workflow",{"tool":43,"command":44},"pnpm","pnpm dlx skills add YYC-Cube\u002FYYC3-Knowledge-Base --skill nemo-mbridge-perf-moe-optimization-workflow","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemo-mbridge-perf-moe-optimization-workflow\u002FSKILL.md",true,[48,54,58,62,66],{"path":49,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":52,"sourceHtmlUrl":53},"BENCHMARK.md","REFERENCE","参考文档",4429,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemo-mbridge-perf-moe-optimization-workflow\u002FBENCHMARK.md",{"path":55,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":56,"sourceHtmlUrl":57},"card.yaml",5140,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemo-mbridge-perf-moe-optimization-workflow\u002Fcard.yaml",{"path":59,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":60,"sourceHtmlUrl":61},"evals\u002Fevals.json",1840,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemo-mbridge-perf-moe-optimization-workflow\u002Fevals\u002Fevals.json",{"path":63,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":64,"sourceHtmlUrl":65},"skill-card.md",3900,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemo-mbridge-perf-moe-optimization-workflow\u002Fskill-card.md",{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"skill.oms.sig","OTHER","其他",4841,"https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-Skills-技能包\u002FYYC3-Skills-技能包-skills\u002Fskills\u002Fnemo-mbridge-perf-moe-optimization-workflow\u002Fskill.oms.sig",[73,81,88,95,102,109],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":77,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":19},"01M7CTDWHERCXPQCP0K03A86AS","vercel-sandbox","Run agent-browser + Chrome inside Vercel Sandbox microVMs for browser automation from any Vercel-deployed app. Use when the user needs browser automation in a Vercel app (Next.js, SvelteKit, Nuxt, Remix, Astro, etc.), wants to run headless Chrome without binary size limits, needs persistent browser sessions across commands, or wants ephemeral isolated browser environments. Triggers include \"Vercel Sandbox browser\", \"microVM Chrome\", \"agent-browser in sandbox\", \"browser automation on Vercel\", or any task requiring Chrome in a Vercel Sandbox.","MIT","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-WebSpec-Web标准\u002FYYC3-WebSpec-Web标准-standards\u002Fbrowser-agent\u002Fskills\u002Fvercel-sandbox\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":77,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":19},"01M7CTD8D2BNJY54S65M47HEJA","slack","Interact with Slack workspaces using browser automation. Use when the user needs to check unread channels, navigate Slack, send messages, extract data, find information, search conversations, or automate any Slack task. Triggers include \"check my Slack\", \"what channels have unreads\", \"send a message to\", \"search Slack for\", \"extract from Slack\", \"find who said\", or any task requiring programmatic Slack interaction.","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-WebSpec-Web标准\u002FYYC3-WebSpec-Web标准-standards\u002Fbrowser-agent\u002Fskills\u002Fslack\u002FSKILL.md",[],[],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":77,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":19},"01M7CTCSSB8ZP3Q58C3YZDZK1W","electron","Automate Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify, etc.) using agent-browser via Chrome DevTools Protocol. Use when the user needs to interact with an Electron app, automate a desktop app, connect to a running app, control a native app, or test an Electron application. Triggers include \"automate Slack app\", \"control VS Code\", \"interact with Discord app\", \"test this Electron app\", \"connect to desktop app\", or any task requiring automation of a native Electron application.","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-WebSpec-Web标准\u002FYYC3-WebSpec-Web标准-standards\u002Fbrowser-agent\u002Fskills\u002Felectron\u002FSKILL.md",[],[],{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":77,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":19},"01M7CTCBJY76688V4DCZGWFHGQ","dogfood","Systematically explore and test a web application to find bugs, UX issues, and other problems. Use when asked to \"dogfood\", \"QA\", \"exploratory test\", \"find issues\", \"bug hunt\", \"test this app\u002Fsite\u002Fplatform\", or review the quality of a web application. Produces a structured report with full reproduction evidence -- step-by-step screenshots, repro videos, and detailed repro steps for every issue -- so findings can be handed directly to the responsible teams.","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-WebSpec-Web标准\u002FYYC3-WebSpec-Web标准-standards\u002Fbrowser-agent\u002Fskills\u002Fdogfood\u002FSKILL.md",[],[],{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":77,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":19},"01M7CTC4H0FFGVEAQR9PA4GA1A","agent-browser","Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to \"open a website\", \"fill out a form\", \"click a button\", \"take a screenshot\", \"scrape data from a page\", \"test this web app\", \"login to a site\", \"automate browser actions\", or any task requiring programmatic web interaction.","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-WebSpec-Web标准\u002FYYC3-WebSpec-Web标准-standards\u002Fbrowser-agent\u002Fskills\u002Fagent-browser\u002FSKILL.md",[],[],{"skillNo":110,"name":111,"nameZh":6,"description":112,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":77,"licenseFileUrl":6,"sourceHtmlUrl":113,"categories":114,"keywords":115,"publishedAt":19},"01M7CTBKVFYBG78FDSABSDJTTQ","shadcn","Manages shadcn components and projects — adding, searching, fixing, debugging, styling, and composing UI, including chat interfaces. Provides project context, component docs, and usage examples. Applies when working with shadcn\u002Fui, component registries, presets, --preset codes, or any project with a components.json file. Also triggers for \"shadcn init\", \"create an app with --preset\", \"switch to --preset\", and for building a design system or applying a DESIGN.md or brand spec to shadcn\u002Fui.","https:\u002F\u002Fgithub.com\u002FYYC-Cube\u002FYYC3-Knowledge-Base\u002Fblob\u002Fmain\u002FYYC3-UI-界面组件\u002FYYC3-UI-界面组件-ui\u002Fskills\u002Fshadcn\u002FSKILL.md",[],[]]