[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K31FFF5GMEE254T5T0FCSS":3,"skill-same:01M6K31FFF5GMEE254T5T0FCSS":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},"01M6K31FFF5GMEE254T5T0FCSS","rudder-data-path-diagnostician-maintainer",null,"Use when Rudder pages or product surfaces show missing, stale, sparse, empty, slow, or wrong data, including Calendar, runs, issues, dashboard counts, chat output, prod\u002Flocal org data, API\u002FUI\u002FDB mismatches, or “这个数据从哪来”.","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-data-path-diagnostician-maintainer\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"rudder data path diagnostician maintainer","path","data","chat","output","org","missing","db","pages","empty","local","dashboard","show","surfaces","stale","calendar","use","api","product","issues","2026-11-10 10:12:30",false,"---\nname: rudder-data-path-diagnostician-maintainer\ndescription: \"Use when Rudder pages or product surfaces show missing, stale, sparse, empty, slow, or wrong data, including Calendar, runs, issues, dashboard counts, chat output, prod\u002Flocal org data, API\u002FUI\u002FDB mismatches, or “这个数据从哪来”.\"\n---\n\n# Rudder Data Path Diagnostician Maintainer\n\nUse this skill when the user's real problem is that a Rudder surface does not\nshow the data they expected.\n\nThe goal is to produce an evidence-backed data lineage and root cause, not to\nguess from the screenshot. Most failures in this class are caused by one of:\n\n- wrong runtime or organization\n- empty source records\n- filtering or date-window mismatch\n- derived data that is not generated from the records the user expected\n- API\u002Fservice aggregation gap\n- UI rendering or state merge bug\n- stale seed\u002Fdemo assumptions\n\nThis skill also has an explanation mode. When the user asks \"这个数据从哪来\" or\n\"现在的渲染逻辑是怎样的\" and the data is no longer missing, explain the\nlineage from UI query to API route, service aggregation, derived records, and\nrendering states. In explanation mode, read-only source tracing may be enough;\ndo not force database inspection when code and API contracts already answer the\nquestion.\n\n## Use When\n\nUse this skill for questions like:\n\n- \"为什么 Calendar 没数据\"\n- \"这个 Dashboard 怎么是空的\"\n- \"prod z studio 下这里怎么没有 run \u002F issue \u002F calendar\"\n- \"这个 UI 的数据从哪里来\"\n- \"看起来应该有数据，但页面没有显示\"\n- \"这个数字和数据库\u002FAPI 对不上\"\n- \"是不是 seed 数据没有写进去\"\n\nThis skill is useful across dev, prod-local Desktop, worktree previews, and\nlocal production-style instances.\n\n## Do Not Use When\n\nDo not use this skill for:\n\n- a single agent run transcript failure; use `debug-run-transcript-maintainer`\n- creating demo or screenshot data from scratch; use `mock-data-maintainer`\n- pure UI polish where the data is already known; use\n  `rudder-ui-polish-maintainer`\n- CI, release, npm, Desktop packaging, or Chrome automation infrastructure\n- destructive cleanup of organizations or databases unless the user explicitly\n  authorizes that separate operation\n\n## Default Workflow\n\n### 1. Confirm the symptom and target environment\n\nStart by pinning down:\n\n- surface: page, route, tab, card, chart, or screenshot region\n- expected data: what the user believes should appear\n- actual data: what is visible or returned\n- runtime: dev, prod-local Desktop, worktree preview, or remote deployment\n- organization: org id, URL key, display name, or selected org\n- date window, filters, and selected project\u002Fagent when relevant\n\nClassify the mode before deep inspection:\n\n- `diagnosis`: expected data is missing, stale, sparse, or wrong.\n- `explanation`: the user wants the rendering or derivation logic after the\n  visible symptom is resolved.\n\nIn explanation mode, keep the answer focused on the current code path and\nsource hierarchy. Still name any assumptions about runtime, org, or date window\nwhen those affect the answer.\n\nVerify the live target before trusting assumptions:\n\n```bash\ncurl -sS \u003Cbase-url>\u002Fapi\u002Fhealth\ncurl -sS \u003Cbase-url>\u002Fapi\u002Forgs\n```\n\nFor prod-local or Desktop investigations, require evidence that the active\nruntime is the expected local environment before inspecting or writing data.\n\n### 2. Identify the UI data request\n\nFind the component and data hook or API client that feeds the surface. Record:\n\n- query key or effect dependency\n- endpoint path and parameters\n- selected org\u002Fproject\u002Fagent\u002Fdate filters\n- fallback, loading, error, and empty-state behavior\n- client-side merge or normalization logic\n\nDo not stop at \"the component renders an empty array.\" Trace where that array\ncomes from.\n\n### 3. Inspect the API and service chain\n\nFollow the endpoint into server code:\n\n- route path and auth\u002Forg access checks\n- request validators and default date windows\n- service function and aggregation logic\n- derived sources such as heartbeat runs, automation runs, activity, messenger\n  context snapshots, calendar projections, cost rows, or external sync tables\n- response shape and filtering rules\n\nCompare route behavior to the UI expectation. Many bugs are not missing rows;\nthey are mismatched assumptions about which source is authoritative.\n\n### 4. Read source data safely\n\nUse read-only API calls or SQL queries first. Verify:\n\n- records exist for the selected organization\n- timestamps fall inside the UI date window\n- statuses match the service filters\n- linked ids are present and point to the expected issue, agent, project, run,\n  automation, or conversation\n- soft-deleted, archived, hidden, or permission-gated rows are not being\n  mistaken for visible data\n\nKeep every query organization-scoped. Do not write, reseed, or delete data\nwhile diagnosing unless the user explicitly changes the task from diagnosis to\nrepair.\n\n### 5. Classify the root cause\n\nUse one primary classification:\n\n- `wrong-target`: the browser or process is pointed at the wrong instance or org\n- `source-empty`: the source table\u002FAPI has no matching records\n- `filter-window`: data exists but the selected date\u002Fstatus\u002Fproject\u002Fagent\n  window excludes it\n- `derived-gap`: source records exist but the derived feed is not generated or\n  linked\n- `contract-gap`: API response lacks data the UI needs\n- `render-gap`: API response is correct but UI state\u002Frendering hides it\n- `seed-gap`: demo or fixture data was expected but not seeded into this target\n- `sync-gap`: external provider or import has not produced local records\n\nIf multiple causes contribute, identify the first broken boundary and the\ndownstream symptoms separately.\n\n### 6. Recommend or implement the fix\n\nBy default, report the diagnosis and fix options. Implement only when the user\nasked to fix it or the next safe code change is obvious.\n\nFix choices should match the cause:\n\n- wrong target: point the browser\u002Fprocess at the right runtime and verify\n- source empty or seed gap: use `mock-data-maintainer` or a scoped seed path\n- filter-window: adjust UI defaults or make filters visible\n- derived gap: fix service aggregation or generation logic\n- contract gap: sync shared\u002Fserver\u002FUI contract and tests\n- render gap: fix component state\u002Frendering and verify visually\n- sync gap: repair provider sync or report external prerequisite\n\nFor user-visible behavior changes, add or update E2E coverage when the repo\nrules require it.\n\n## Output Shape\n\nKeep the final answer concrete:\n\n```markdown\nRoot cause: \u003Cclassification and one-sentence cause>\n\nEvidence:\n- UI requested ...\n- API returned ...\n- Source data shows ...\n- Service logic does ...\n\nFix:\n- ...\n\nValidation:\n- ...\n```\n\nWhen useful, include a short lineage:\n\n```text\nCalendar page -> GET \u002Fapi\u002Forgs\u002F:orgId\u002Fcalendar\u002Fevents\n  -> calendar_events rows\n  -> heartbeat_runs projections\n  -> projected heartbeat schedules\n```\n\n## Safety Rules\n\n- Diagnosis is read-only by default.\n- Verify runtime and organization before any write.\n- Never use unscoped SQL against production-like data.\n- Do not invent demo records to make a bug disappear.\n- Do not conflate \"no persisted rows\" with \"no product data\" when the surface\n  intentionally derives events from runs, schedules, or activity.\n- If the user provides a screenshot, use it to locate the symptom, not as proof\n  of the backend state.\n\n## Handoff Rules\n\nIf code changed, follow normal Rudder validation, commit, and push rules. Stage\nonly files changed for this task and keep unrelated dirty worktree changes out\nof the commit.\n\nIf no code changed, hand off the exact current state and next repair command or\nfile path. Do not claim the issue is fixed when only the data lineage was\nexplained.\n","# Rudder Data Path Diagnostician Maintainer\n\nUse this skill when the user's real problem is that a Rudder surface does not\nshow the data they expected.\n\nThe goal is to produce an evidence-backed data lineage and root cause, not to\nguess from the screenshot. Most failures in this class are caused by one of:\n\n- wrong runtime or organization\n- empty source records\n- filtering or date-window mismatch\n- derived data that is not generated from the records the user expected\n- API\u002Fservice aggregation gap\n- UI rendering or state merge bug\n- stale seed\u002Fdemo assumptions\n\nThis skill also has an explanation mode. When the user asks \"这个数据从哪来\" or\n\"现在的渲染逻辑是怎样的\" and the data is no longer missing, explain the\nlineage from UI query to API route, service aggregation, derived records, and\nrendering states. In explanation mode, read-only source tracing may be enough;\ndo not force database inspection when code and API contracts already answer the\nquestion.\n\n## Use When\n\nUse this skill for questions like:\n\n- \"为什么 Calendar 没数据\"\n- \"这个 Dashboard 怎么是空的\"\n- \"prod z studio 下这里怎么没有 run \u002F issue \u002F calendar\"\n- \"这个 UI 的数据从哪里来\"\n- \"看起来应该有数据，但页面没有显示\"\n- \"这个数字和数据库\u002FAPI 对不上\"\n- \"是不是 seed 数据没有写进去\"\n\nThis skill is useful across dev, prod-local Desktop, worktree previews, and\nlocal production-style instances.\n\n## Do Not Use When\n\nDo not use this skill for:\n\n- a single agent run transcript failure; use `debug-run-transcript-maintainer`\n- creating demo or screenshot data from scratch; use `mock-data-maintainer`\n- pure UI polish where the data is already known; use\n  `rudder-ui-polish-maintainer`\n- CI, release, npm, Desktop packaging, or Chrome automation infrastructure\n- destructive cleanup of organizations or databases unless the user explicitly\n  authorizes that separate operation\n\n## Default Workflow\n\n### 1. Confirm the symptom and target environment\n\nStart by pinning down:\n\n- surface: page, route, tab, card, chart, or screenshot region\n- expected data: what the user believes should appear\n- actual data: what is visible or returned\n- runtime: dev, prod-local Desktop, worktree preview, or remote deployment\n- organization: org id, URL key, display name, or selected org\n- date window, filters, and selected project\u002Fagent when relevant\n\nClassify the mode before deep inspection:\n\n- `diagnosis`: expected data is missing, stale, sparse, or wrong.\n- `explanation`: the user wants the rendering or derivation logic after the\n  visible symptom is resolved.\n\nIn explanation mode, keep the answer focused on the current code path and\nsource hierarchy. Still name any assumptions about runtime, org, or date window\nwhen those affect the answer.\n\nVerify the live target before trusting assumptions:\n\n```bash\ncurl -sS \u003Cbase-url>\u002Fapi\u002Fhealth\ncurl -sS \u003Cbase-url>\u002Fapi\u002Forgs\n```\n\nFor prod-local or Desktop investigations, require evidence that the active\nruntime is the expected local environment before inspecting or writing data.\n\n### 2. Identify the UI data request\n\nFind the component and data hook or API client that feeds the surface. Record:\n\n- query key or effect dependency\n- endpoint path and parameters\n- selected org\u002Fproject\u002Fagent\u002Fdate filters\n- fallback, loading, error, and empty-state behavior\n- client-side merge or normalization logic\n\nDo not stop at \"the component renders an empty array.\" Trace where that array\ncomes from.\n\n### 3. Inspect the API and service chain\n\nFollow the endpoint into server code:\n\n- route path and auth\u002Forg access checks\n- request validators and default date windows\n- service function and aggregation logic\n- derived sources such as heartbeat runs, automation runs, activity, messenger\n  context snapshots, calendar projections, cost rows, or external sync tables\n- response shape and filtering rules\n\nCompare route behavior to the UI expectation. Many bugs are not missing rows;\nthey are mismatched assumptions about which source is authoritative.\n\n### 4. Read source data safely\n\nUse read-only API calls or SQL queries first. Verify:\n\n- records exist for the selected organization\n- timestamps fall inside the UI date window\n- statuses match the service filters\n- linked ids are present and point to the expected issue, agent, project, run,\n  automation, or conversation\n- soft-deleted, archived, hidden, or permission-gated rows are not being\n  mistaken for visible data\n\nKeep every query organization-scoped. Do not write, reseed, or delete data\nwhile diagnosing unless the user explicitly changes the task from diagnosis to\nrepair.\n\n### 5. Classify the root cause\n\nUse one primary classification:\n\n- `wrong-target`: the browser or process is pointed at the wrong instance or org\n- `source-empty`: the source table\u002FAPI has no matching records\n- `filter-window`: data exists but the selected date\u002Fstatus\u002Fproject\u002Fagent\n  window excludes it\n- `derived-gap`: source records exist but the derived feed is not generated or\n  linked\n- `contract-gap`: API response lacks data the UI needs\n- `render-gap`: API response is correct but UI state\u002Frendering hides it\n- `seed-gap`: demo or fixture data was expected but not seeded into this target\n- `sync-gap`: external provider or import has not produced local records\n\nIf multiple causes contribute, identify the first broken boundary and the\ndownstream symptoms separately.\n\n### 6. Recommend or implement the fix\n\nBy default, report the diagnosis and fix options. Implement only when the user\nasked to fix it or the next safe code change is obvious.\n\nFix choices should match the cause:\n\n- wrong target: point the browser\u002Fprocess at the right runtime and verify\n- source empty or seed gap: use `mock-data-maintainer` or a scoped seed path\n- filter-window: adjust UI defaults or make filters visible\n- derived gap: fix service aggregation or generation logic\n- contract gap: sync shared\u002Fserver\u002FUI contract and tests\n- render gap: fix component state\u002Frendering and verify visually\n- sync gap: repair provider sync or report external prerequisite\n\nFor user-visible behavior changes, add or update E2E coverage when the repo\nrules require it.\n\n## Output Shape\n\nKeep the final answer concrete:\n\n```markdown\nRoot cause: \u003Cclassification and one-sentence cause>\n\nEvidence:\n- UI requested ...\n- API returned ...\n- Source data shows ...\n- Service logic does ...\n\nFix:\n- ...\n\nValidation:\n- ...\n```\n\nWhen useful, include a short lineage:\n\n```text\nCalendar page -> GET \u002Fapi\u002Forgs\u002F:orgId\u002Fcalendar\u002Fevents\n  -> calendar_events rows\n  -> heartbeat_runs projections\n  -> projected heartbeat schedules\n```\n\n## Safety Rules\n\n- Diagnosis is read-only by default.\n- Verify runtime and organization before any write.\n- Never use unscoped SQL against production-like data.\n- Do not invent demo records to make a bug disappear.\n- Do not conflate \"no persisted rows\" with \"no product data\" when the surface\n  intentionally derives events from runs, schedules, or activity.\n- If the user provides a screenshot, use it to locate the symptom, not as proof\n  of the backend state.\n\n## Handoff Rules\n\nIf code changed, follow normal Rudder validation, commit, and push rules. Stage\nonly files changed for this task and keep unrelated dirty worktree changes out\nof the commit.\n\nIf no code changed, hand off the exact current state and next repair command or\nfile path. Do not claim the issue is fixed when only the data lineage was\nexplained.\n",{"name":5,"description":7},"main","26d5d68bcbc55caeac1dc6a266d973e8c3831f1c","agent-skills-bak\u002Fmaintainer\u002Frudder-data-path-diagnostician-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-data-path-diagnostician-maintainer",{"tool":64,"command":65},"bunx","bunx skills add Undertone0809\u002Frudder --skill rudder-data-path-diagnostician-maintainer",{"tool":67,"command":68},"pnpm","pnpm dlx skills add Undertone0809\u002Frudder --skill rudder-data-path-diagnostician-maintainer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fagent-skills-bak\u002Fmaintainer\u002Frudder-data-path-diagnostician-maintainer\u002FSKILL.md",true,[72],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Frunbook.md","REFERENCE","参考文档",7657,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fagent-skills-bak\u002Fmaintainer\u002Frudder-data-path-diagnostician-maintainer\u002Freferences\u002Frunbook.md",[79,92,105,131,160,186],{"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,149,150,151,152,153,154,155,156,157,158,159],"static","inline","chart","scenario","access","geometry","map","message","compact","back","never","node","mermaid","network","create","diagram","safe","css","markdown",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":169,"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",[166],{"categoryNo":167,"categoryName":168,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000023","Skill与智能体开发",[170,171,172,173,174,175,176,177,118,178,179,180,181,40,182,183,127,184,185,155],"skill creator","creator","run evals","performance","variance analysis","existing skill","Existing","accuracy","From Scratch","users","optimize","evals","edit","improve","benchmark","run",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":192,"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",[],[193,194,195,87,196,197,198,199,200,201,202,203,204,205,206,207,208,209,155,210],"rudder docs","docs","context","interface","hire","creation","commands","active","do","contracts","ask","work","coding","configure","how","Tools","actions","tasks"]