[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K31WC9G42XBAVEVB7P5WCF":3,"skill-same:01M6K31WC9G42XBAVEVB7P5WCF":78},{"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":54,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M6K31WC9G42XBAVEVB7P5WCF","rudder-ui-polish-maintainer",null,"Use when implementing screenshot-driven or narrow Rudder UI polish: density, alignment, spacing, labels, cards, menus, hover states, empty states, onboarding steps, redundant pages, compact workflows, screenshots, or small visible interaction fixes.","Undertone0809\u002Frudder","Undertone0809","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F72488598?v=4","01M6K2XANP3QJEF503JX2C693T","Zeeland","01M6K2XATQXEYF7N2QG8KZVEEY",296,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fagent-skills-bak\u002Fmaintainer\u002Frudder-ui-polish-maintainer\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"rudder ui polish maintainer","ui","polish","ui polish","compact","labels","fixes","implementing","spacing","states","interaction","pages","empty","screenshots","alignment","use","onboarding","screenshot","hover","workflows","2026-11-10 10:12:30",false,"---\nname: rudder-ui-polish-maintainer\ndescription: \"Use when implementing screenshot-driven or narrow Rudder UI polish: density, alignment, spacing, labels, cards, menus, hover states, empty states, onboarding steps, redundant pages, compact workflows, screenshots, or small visible interaction fixes.\"\n---\n\n# Rudder UI Polish Maintainer\n\nUse this skill to turn concrete Rudder UI feedback into a scoped, implemented,\nvalidated, and committed change.\n\nThe goal is not a full redesign. The goal is to preserve Rudder's dense,\noperator-focused interface while fixing the specific visual or interaction\nproblem the user noticed.\n\n## Use When\n\nUse this skill for Rudder UI tasks such as:\n\n- screenshot-driven visual polish\n- alignment, line-height, spacing, density, overflow, or hover fixes\n- adding a small status badge, label, icon, menu, or affordance\n- simplifying settings sections or redundant explanatory copy\n- removing a page or route that no longer belongs in the product\n- changing an empty state, onboarding step, tutorial jump, or small workflow\n  surface\n- producing a quick screenshot of the current UI after a local change\n- explaining why a visible surface looks wrong when the user asks \"为什么\"\n  and the likely answer is current CSS\u002Flayout\u002Fdata layering rather than an\n  approved implementation request\n\nUse `build-advisor` first when the user explicitly asks \"你懂我要怎么改吗\",\n\"先说说\", or otherwise wants the product\u002Fdesign direction before edits.\nAfter the direction is accepted, continue here for implementation.\n\nUse `advisor-review-loop-maintainer` instead when the user asks for reviewer\nagents, two rounds, proposal review, or an acceptance gate before handoff.\n\nWhen the user invokes `advisor-review-loop-maintainer` for a small visible fix\nbut only asks to \"修一下\", \"优化一下\", \"去掉这个 button\", \"颜色不对\", or similar,\ntreat this skill as the implementation contract after a short advisor check.\nSay explicitly in the handoff that the work used a lightweight route rather\nthan a full two-reviewer loop.\n\n## Do Not Use When\n\nDo not use this skill for:\n\n- broad architecture refactors or large feature builds\n- pure code review with no UI change\n- data diagnosis where the core question is \"why is this page empty\"; use\n  `rudder-data-path-diagnostician-maintainer`\n- screenshot\u002Fdemo data creation; use `mock-data-maintainer` and then\n  `landing-proof-shots-maintainer` when needed\n- release, CI, Desktop packaging, or browser automation infrastructure issues\n- UI Lab, component inventory, component fixture coverage, or design-system\n  catalog work where the main deliverable is coverage and classification rather\n  than a narrow rendered-state polish fix; route through\n  `development-lifecycle-router-maintainer` first\n\n## Default Workflow\n\n### 1. Resolve intent and mode\n\nClassify the prompt before editing:\n\n- `advice-only`: user asks to discuss, judge, or generate options.\n- `explain-only`: user asks why a visual state looks the way it does, without\n  asking to change it yet.\n- `implement`: user asks to fix, optimize, remove, add, or \"改一下\".\n- `screenshot`: user wants the current rendered UI captured.\n- `review-gated`: user invokes reviewers or says the result must pass review.\n- `component-lab`: user asks to build, expand, or audit UI Lab\u002Fcomponent\n  inventory; route out to the lifecycle\u002Fcomponent-lab workflow first.\n\nIn `advice-only`, produce the smallest useful UI direction and stop. In\n`explain-only`, trace the rendered reason from screenshot to component\u002FCSS\u002Fdata\nsource and stop with the likely fix direction, not a patch. In `implement`,\nmake the code change. If the user gives screenshots plus vague language, infer\nthe concrete pain from the image and surrounding product state.\n\nIn `component-lab`, do not start a narrow polish pass. The owning workflow must\nfirst define component coverage, context-required labeling, route behavior,\ntests, and browser proof. Return to this skill only for a concrete visual fix\ninside an already-scoped component-lab task.\n\n### 2. Build a small evidence packet\n\nGather only the context needed for this UI surface:\n\n- current route, component, and API client involved\n- relevant nearby tests\n- `doc\u002Fengineering\u002FDESIGN.md` for visible UI defaults when the change is layout-sensitive\n- existing components, tokens, icons, and status labels before inventing new UI\n- screenshot or browser state when the user provided or requested visual proof\n\nCheck `git status --short --branch` before editing. Preserve unrelated dirty\nworktree changes.\n\n### 3. Make the smallest coherent UI change\n\nPrefer local product consistency over a generic design pattern:\n\n- reuse existing Rudder components and status vocabulary\n- keep operational screens compact, scannable, and calm\n- remove redundant copy instead of explaining the UI inside the UI\n- avoid wrapping cards inside cards\n- avoid decorative treatment that competes with work content\n- keep controls discoverable but not oversized\n- preserve keyboard, selection, copy, and accessibility behavior when editing\n  input or composer surfaces\n\nWhen adding visible state such as issue status, use real existing data from the\nsurface's context snapshot or API response. Do not hard-code status text just\nto make the UI look right.\n\n### 4. Keep contracts aligned\n\nIf the UI change needs data that is not already present, trace the contract:\n\n- shared type or validator\n- server route or service response\n- UI API client and component props\n- tests and E2E expectations\n\nDo not silently introduce an organization-scoping, permission, or persistence\nchange while doing a visual polish task. If that is needed, call it out and\nscope it as feature work.\n\n### 5. Validate behavior and visual result\n\nRun the narrowest meaningful automated checks first:\n\n- component or page test for the touched surface\n- E2E test when the user-visible workflow changed\n- typecheck\u002Fbuild when shared contracts changed\n\nFor visible UI changes, verify the rendered result with a browser, Desktop\nshell, screenshot, or equivalent visual inspection. Prefer the available\nbrowser automation path for local routes. If browser verification is blocked,\nstate the exact blocker and do not describe the layout as visually proven.\n\nWhen the defect is alignment, line height, avatar\u002Ftext\u002Ftime centering, column\nwidth, or row rhythm, a screenshot alone is often too weak. Use realistic data\nfor the actual object being aligned, such as a real agent avatar instead of a\nplaceholder icon, a long activity label, and the timestamp or action controls\nthat appear in production. Then add at least one measurable proof when\npractical:\n\n- DOM bounding boxes for the avatar, primary text, secondary text, timestamp,\n  and row container\n- centerline or top\u002Fbottom delta showing the items share the intended row axis\n- screenshot with the real fixture state, saved outside the repo\n\nIf Browser or the test harness cannot collect geometry, say that the alignment\nproof is visual-only. Do not claim a row-alignment fix is fully proven from a\nunit test that renders placeholder data instead of the production-shaped row.\n\nFor follow-up corrections from the user, such as \"这颜色不对\", \"没修好\", or\n\"这里还是不对\", inspect the rendered state again before editing further. Treat\nthe user's screenshot as evidence that the previous proof was incomplete, not\nas a reason to keep patching blindly.\n\nStore temporary screenshots outside the repo, for example under `\u002Ftmp`.\n\n### 6. Commit only this task\n\nAfter validation, stage only files changed for this task. Do not include\nunrelated dirty worktree changes. Use a Conventional Commit message such as:\n\n- `fix: align automation settings rows`\n- `feat: show issue status in messenger cards`\n- `chore: remove redundant organizations settings page`\n\nPush the current branch when the repository rules and current branch state\nallow it.\n\n## Output Expectations\n\nFor implementation tasks, hand off with:\n\n- what changed, in product terms\n- key files touched\n- validation run and any blocked checks\n- screenshot path or rendered proof when the change is visual\n- commit hash and push status when committed\n\nFor advice-only tasks, hand off with:\n\n- the product diagnosis\n- the recommended UI direction\n- any explicit non-goals\n- the implementation shape if the user approves edits\n\n## Common Failure Modes\n\n- Over-solving a small screenshot complaint with a broad redesign.\n- Routing every small screenshot complaint through a full advisor\u002Freviewer loop\n  when a lightweight UI-polish pass is enough.\n- Treating a visual issue as pure CSS when the real problem is wrong data,\n  wrong route, or redundant object modeling.\n- Claiming visual verification after browser automation timed out.\n- Claiming an alignment fix from placeholder fixtures when the real surface uses\n  agent avatars, long labels, timestamps, badges, or row actions.\n- Shipping a nice-looking state badge that reads stale or mock data.\n- Mixing unrelated dirty files into the commit.\n- Using `advisor-review-loop-maintainer` for every small UI tweak, slowing down\n  work that only needed a focused polish pass.\n- Treating UI Lab or component-inventory work as a small cosmetic issue and\n  stopping after screenshots or style tweaks without coverage and fixture proof.\n","# Rudder UI Polish Maintainer\n\nUse this skill to turn concrete Rudder UI feedback into a scoped, implemented,\nvalidated, and committed change.\n\nThe goal is not a full redesign. The goal is to preserve Rudder's dense,\noperator-focused interface while fixing the specific visual or interaction\nproblem the user noticed.\n\n## Use When\n\nUse this skill for Rudder UI tasks such as:\n\n- screenshot-driven visual polish\n- alignment, line-height, spacing, density, overflow, or hover fixes\n- adding a small status badge, label, icon, menu, or affordance\n- simplifying settings sections or redundant explanatory copy\n- removing a page or route that no longer belongs in the product\n- changing an empty state, onboarding step, tutorial jump, or small workflow\n  surface\n- producing a quick screenshot of the current UI after a local change\n- explaining why a visible surface looks wrong when the user asks \"为什么\"\n  and the likely answer is current CSS\u002Flayout\u002Fdata layering rather than an\n  approved implementation request\n\nUse `build-advisor` first when the user explicitly asks \"你懂我要怎么改吗\",\n\"先说说\", or otherwise wants the product\u002Fdesign direction before edits.\nAfter the direction is accepted, continue here for implementation.\n\nUse `advisor-review-loop-maintainer` instead when the user asks for reviewer\nagents, two rounds, proposal review, or an acceptance gate before handoff.\n\nWhen the user invokes `advisor-review-loop-maintainer` for a small visible fix\nbut only asks to \"修一下\", \"优化一下\", \"去掉这个 button\", \"颜色不对\", or similar,\ntreat this skill as the implementation contract after a short advisor check.\nSay explicitly in the handoff that the work used a lightweight route rather\nthan a full two-reviewer loop.\n\n## Do Not Use When\n\nDo not use this skill for:\n\n- broad architecture refactors or large feature builds\n- pure code review with no UI change\n- data diagnosis where the core question is \"why is this page empty\"; use\n  `rudder-data-path-diagnostician-maintainer`\n- screenshot\u002Fdemo data creation; use `mock-data-maintainer` and then\n  `landing-proof-shots-maintainer` when needed\n- release, CI, Desktop packaging, or browser automation infrastructure issues\n- UI Lab, component inventory, component fixture coverage, or design-system\n  catalog work where the main deliverable is coverage and classification rather\n  than a narrow rendered-state polish fix; route through\n  `development-lifecycle-router-maintainer` first\n\n## Default Workflow\n\n### 1. Resolve intent and mode\n\nClassify the prompt before editing:\n\n- `advice-only`: user asks to discuss, judge, or generate options.\n- `explain-only`: user asks why a visual state looks the way it does, without\n  asking to change it yet.\n- `implement`: user asks to fix, optimize, remove, add, or \"改一下\".\n- `screenshot`: user wants the current rendered UI captured.\n- `review-gated`: user invokes reviewers or says the result must pass review.\n- `component-lab`: user asks to build, expand, or audit UI Lab\u002Fcomponent\n  inventory; route out to the lifecycle\u002Fcomponent-lab workflow first.\n\nIn `advice-only`, produce the smallest useful UI direction and stop. In\n`explain-only`, trace the rendered reason from screenshot to component\u002FCSS\u002Fdata\nsource and stop with the likely fix direction, not a patch. In `implement`,\nmake the code change. If the user gives screenshots plus vague language, infer\nthe concrete pain from the image and surrounding product state.\n\nIn `component-lab`, do not start a narrow polish pass. The owning workflow must\nfirst define component coverage, context-required labeling, route behavior,\ntests, and browser proof. Return to this skill only for a concrete visual fix\ninside an already-scoped component-lab task.\n\n### 2. Build a small evidence packet\n\nGather only the context needed for this UI surface:\n\n- current route, component, and API client involved\n- relevant nearby tests\n- `doc\u002Fengineering\u002FDESIGN.md` for visible UI defaults when the change is layout-sensitive\n- existing components, tokens, icons, and status labels before inventing new UI\n- screenshot or browser state when the user provided or requested visual proof\n\nCheck `git status --short --branch` before editing. Preserve unrelated dirty\nworktree changes.\n\n### 3. Make the smallest coherent UI change\n\nPrefer local product consistency over a generic design pattern:\n\n- reuse existing Rudder components and status vocabulary\n- keep operational screens compact, scannable, and calm\n- remove redundant copy instead of explaining the UI inside the UI\n- avoid wrapping cards inside cards\n- avoid decorative treatment that competes with work content\n- keep controls discoverable but not oversized\n- preserve keyboard, selection, copy, and accessibility behavior when editing\n  input or composer surfaces\n\nWhen adding visible state such as issue status, use real existing data from the\nsurface's context snapshot or API response. Do not hard-code status text just\nto make the UI look right.\n\n### 4. Keep contracts aligned\n\nIf the UI change needs data that is not already present, trace the contract:\n\n- shared type or validator\n- server route or service response\n- UI API client and component props\n- tests and E2E expectations\n\nDo not silently introduce an organization-scoping, permission, or persistence\nchange while doing a visual polish task. If that is needed, call it out and\nscope it as feature work.\n\n### 5. Validate behavior and visual result\n\nRun the narrowest meaningful automated checks first:\n\n- component or page test for the touched surface\n- E2E test when the user-visible workflow changed\n- typecheck\u002Fbuild when shared contracts changed\n\nFor visible UI changes, verify the rendered result with a browser, Desktop\nshell, screenshot, or equivalent visual inspection. Prefer the available\nbrowser automation path for local routes. If browser verification is blocked,\nstate the exact blocker and do not describe the layout as visually proven.\n\nWhen the defect is alignment, line height, avatar\u002Ftext\u002Ftime centering, column\nwidth, or row rhythm, a screenshot alone is often too weak. Use realistic data\nfor the actual object being aligned, such as a real agent avatar instead of a\nplaceholder icon, a long activity label, and the timestamp or action controls\nthat appear in production. Then add at least one measurable proof when\npractical:\n\n- DOM bounding boxes for the avatar, primary text, secondary text, timestamp,\n  and row container\n- centerline or top\u002Fbottom delta showing the items share the intended row axis\n- screenshot with the real fixture state, saved outside the repo\n\nIf Browser or the test harness cannot collect geometry, say that the alignment\nproof is visual-only. Do not claim a row-alignment fix is fully proven from a\nunit test that renders placeholder data instead of the production-shaped row.\n\nFor follow-up corrections from the user, such as \"这颜色不对\", \"没修好\", or\n\"这里还是不对\", inspect the rendered state again before editing further. Treat\nthe user's screenshot as evidence that the previous proof was incomplete, not\nas a reason to keep patching blindly.\n\nStore temporary screenshots outside the repo, for example under `\u002Ftmp`.\n\n### 6. Commit only this task\n\nAfter validation, stage only files changed for this task. Do not include\nunrelated dirty worktree changes. Use a Conventional Commit message such as:\n\n- `fix: align automation settings rows`\n- `feat: show issue status in messenger cards`\n- `chore: remove redundant organizations settings page`\n\nPush the current branch when the repository rules and current branch state\nallow it.\n\n## Output Expectations\n\nFor implementation tasks, hand off with:\n\n- what changed, in product terms\n- key files touched\n- validation run and any blocked checks\n- screenshot path or rendered proof when the change is visual\n- commit hash and push status when committed\n\nFor advice-only tasks, hand off with:\n\n- the product diagnosis\n- the recommended UI direction\n- any explicit non-goals\n- the implementation shape if the user approves edits\n\n## Common Failure Modes\n\n- Over-solving a small screenshot complaint with a broad redesign.\n- Routing every small screenshot complaint through a full advisor\u002Freviewer loop\n  when a lightweight UI-polish pass is enough.\n- Treating a visual issue as pure CSS when the real problem is wrong data,\n  wrong route, or redundant object modeling.\n- Claiming visual verification after browser automation timed out.\n- Claiming an alignment fix from placeholder fixtures when the real surface uses\n  agent avatars, long labels, timestamps, badges, or row actions.\n- Shipping a nice-looking state badge that reads stale or mock data.\n- Mixing unrelated dirty files into the commit.\n- Using `advisor-review-loop-maintainer` for every small UI tweak, slowing down\n  work that only needed a focused polish pass.\n- Treating UI Lab or component-inventory work as a small cosmetic issue and\n  stopping after screenshots or style tweaks without coverage and fixture proof.\n",{"name":5,"description":7},"main","26d5d68bcbc55caeac1dc6a266d973e8c3831f1c","agent-skills-bak\u002Fmaintainer\u002Frudder-ui-polish-maintainer",31,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder","https:\u002F\u002Frudderhq.dev","https:\u002F\u002Fgithub.com\u002FUndertone0809","Creator of Rudder, Spark Lab. I design SDKs, infra and software for human and the NEW WORLD.","2026-11-08 00:09:15",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add Undertone0809\u002Frudder --skill rudder-ui-polish-maintainer",{"tool":64,"command":65},"bunx","bunx skills add Undertone0809\u002Frudder --skill rudder-ui-polish-maintainer",{"tool":67,"command":68},"pnpm","pnpm dlx skills add Undertone0809\u002Frudder --skill rudder-ui-polish-maintainer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fagent-skills-bak\u002Fmaintainer\u002Frudder-ui-polish-maintainer\u002FSKILL.md",true,[72],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Frunbook.md","REFERENCE","参考文档",9196,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fagent-skills-bak\u002Fmaintainer\u002Frudder-ui-polish-maintainer\u002Freferences\u002Frunbook.md",[79,92,105,131,159,185],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":44},"01M6K33ZG45BN249F4DZRCCSJN","Source Synthesis","Synthesize evidence into a concise conclusion.","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Ftests\u002Fe2e\u002Ffixtures\u002Fcodex-plugin-research\u002Fskills\u002Fsynthesis\u002FSKILL.md",[],[86,87,88,89,90,91],"Synthesis","source","source synthesis","concise","synthesize","evidence",{"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":103,"publishedAt":44},"01M6K33XMZXRM31H2SG618C37F","Evidence Research","Gather and cite evidence before reaching a conclusion.","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Ftests\u002Fe2e\u002Ffixtures\u002Fcodex-plugin-research\u002Fskills\u002Fevidence\u002FSKILL.md",[98],{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[104,91,94],"research",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":112,"publishedAt":44},"01M6K33RHAPNGPCM2FGPWTZQ8G","deep-research","Conducts enterprise-grade research with multi-source synthesis, citation tracking, and verification. Produces citation-backed reports through a structured pipeline with source credibility scoring, and grounds abstract findings in concrete examples, cases, counterexamples, or mini-scenarios when helpful. Triggers on \"deep research\", \"comprehensive analysis\", \"research report\", \"compare X vs Y\", \"analyze trends\", or \"state of the art\". Not for simple lookups, debugging, or questions answerable with 1-2 searches.","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fcommunity-skills\u002Fdeep-research\u002FSKILL.md",[111],{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},[113,114,104,115,116,117,88,118,119,120,121,122,123,124,125,126,127,128,129,130],"deep research","deep","state","debugging","triggers","for","with","multi","compare","verification","scoring","Art","reports","analyze","analysis","pipeline","Enterprise","examples",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":140,"publishedAt":44},"01M6K33JPMYXHY9E4WR0K9EK0V","visualize","Create safe inline visual explanations in Rudder Chat. Use when asked for a chart, plot, diagram, timeline, comparison, static map, simulator, scenario view, or compact visual that materially improves understanding. Prefer Mermaid for static node-and-edge structures; use Rudder's runtime-neutral HTML\u002FSVG\u002FCSS message envelope for custom geometry. Rudder visuals are declarative and scriptless: convert simulator requests to static scenarios or disclosure-based comparisons and never rely on JavaScript, network access, or external assets.","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fvisualize\u002FSKILL.md",[137],{"categoryNo":138,"categoryName":139,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000009","前端开发",[133,141,142,143,144,145,146,147,148,28,149,150,151,152,153,154,155,156,157,158],"static","inline","chart","scenario","access","geometry","map","message","back","never","node","mermaid","network","create","diagram","safe","css","markdown",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":168,"publishedAt":44},"01M6K339S5PWH9RTZZA71CPD32","skill-creator","Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Fskill-creator\u002FSKILL.md",[165],{"categoryNo":166,"categoryName":167,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000023","Skill与智能体开发",[169,170,171,172,173,174,175,176,118,177,178,179,180,39,181,182,127,183,184,154],"skill creator","creator","run evals","performance","variance analysis","existing skill","Existing","accuracy","From Scratch","users","optimize","evals","edit","improve","benchmark","run",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":191,"publishedAt":44},"01M6K333T855082YFXZ4FW0SE7","rudder-docs","Use when the user asks how Rudder works; needs current Rudder docs, exact behavior, commands, contracts, APIs, or source evidence; asks to create, hire, or configure Rudder agents; or asks to scaffold, develop, or verify Rudder plugins. For explicit creation requests, verify the current interface before acting within existing authorization. Do not use for greetings, ordinary work merely running inside Rudder, routine actions already clear from the active context and typed tools, non-Rudder plugin work, or general coding and research tasks that do not ask about Rudder.","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fserver\u002Fresources\u002Fbundled-skills\u002Frudder-docs\u002FSKILL.md",[],[192,193,194,87,195,196,197,198,199,200,201,202,203,204,205,206,207,208,154,209],"rudder docs","docs","context","interface","hire","creation","commands","active","do","contracts","ask","work","coding","configure","how","Tools","actions","tasks"]