[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K31KFTGSX9X4HN88H1YVHD":3,"skill-same:01M6K31KFTGSX9X4HN88H1YVHD":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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":48,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6K31KFTGSX9X4HN88H1YVHD","rudder-desktop-dev-recovery-maintainer",null,"Use when Rudder local Desktop development, Electron shell, embedded Postgres, ~\u002F.rudder instance state, dev startup, update\u002Finstall smoke, packaged boot, or release-blocking local Desktop validation fails or needs recovery.","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-desktop-dev-recovery-maintainer\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"rudder desktop dev recovery maintainer","desktop","dev","recovery","startup","local","postgres","embedded","smoke","use","install","shell","electron","state","validation","release","update","development","boot","2026-11-10 10:12:30",false,"---\nname: rudder-desktop-dev-recovery-maintainer\ndescription: \"Use when Rudder local Desktop development, Electron shell, embedded Postgres, ~\u002F.rudder instance state, dev startup, update\u002Finstall smoke, packaged boot, or release-blocking local Desktop validation fails or needs recovery.\"\n---\n\n# Rudder Desktop Dev Recovery Maintainer\n\nUse this skill to get the local Rudder Desktop development path back to a known\nworking state.\n\nThis is not the release runbook. It is the recovery layer for local Desktop\nstartup, dev-shell runtime, embedded database state, update\u002Finstall smoke, and\nthe handoff point before release work.\n\n## Use When\n\nUse this skill for prompts like:\n\n- \"`pnpm dev` 好像桌面端跑不起来了\"\n- \"Desktop dev shell 起不来\"\n- \"API 能访问，但桌面端没起来\"\n- \"`pnpm dev` starts the API but Electron exits during a UI build\u002Ftypecheck\"\n- \"embedded Postgres \u002F `~\u002F.rudder` 状态是不是乱了\"\n- \"update 最新版失败，先 debug 一下\"\n- \"桌面端问题修完之后再发版\"\n- \"我本地 Desktop 是不是指到错的 instance\"\n\nAlso use this when a release request is blocked by local Desktop validation.\nFix the local Desktop blocker first, then route the release to\n`release-maintainer`.\n\n## Do Not Use When\n\nDo not use this skill for:\n\n- npm\u002FGitHub Release\u002Ftag\u002Fdist-tag publishing; use `release-maintainer`\n- packaged-app verification after code changes with no startup failure; follow\n  the normal Desktop validation workflow\n- stopping only a known repo-local dev runtime; use\n  `stop-rudder-dev-maintainer`\n- ordinary web UI data diagnosis; use `rudder-data-path-diagnostician-maintainer`\n- review-only of a Desktop feature; use `agent-work-reviewer-maintainer`\n\nIf the user's first request is \"发版\" and Desktop is already healthy, do not\nroute through this skill.\n\n## Default Workflow\n\n### 1. Classify the failure mode\n\nStart with a short state packet:\n\n- `git status --short --branch`\n- requested command, for example `pnpm dev`, `pnpm desktop:dev`, or\n  `pnpm desktop:verify`\n- whether the failure is API server, Vite middleware, Electron shell, embedded\n  Postgres, UI build\u002Ftypecheck, packaged smoke, update download, or app launch\n- exact stderr\u002Fstdout excerpt and exit code\n- currently listening ports around `3100`\n- relevant `~\u002F.rudder\u002Finstances\u002F*` path when the process prints one\n- whether the failing file is committed, modified, untracked, or part of a\n  broader dirty feature set\n\nDo not guess from memory when the command can be rerun safely.\n\n### 2. Read the local Desktop contract\n\nRead only the relevant docs and scripts:\n\n- `doc\u002Fengineering\u002FDEVELOPING.md`\n- `doc\u002Fengineering\u002FDESKTOP.md`\n- `doc\u002FREADME.md` for navigation when needed\n- `desktop\u002Fpackage.json`\n- root `package.json` scripts\n- `desktop\u002Fscripts\u002Fsmoke.mjs` for packaged-smoke expectations\n- `scripts\u002Fprod-desktop.mjs` only when the failure is prod-local or installer\n  related\n\nWhen docs and scripts disagree, scripts are the executable truth for the active\ndiagnosis. Record the mismatch as a docs follow-up if it matters.\n\n### 3. Verify the active runtime before repairing\n\nCheck the local server and org list when the API is expected to be running:\n\n```bash\ncurl -sS http:\u002F\u002F127.0.0.1:3100\u002Fapi\u002Fhealth\ncurl -sS http:\u002F\u002F127.0.0.1:3100\u002Fapi\u002Forgs\n```\n\nIf the Desktop shell is pointed at another base URL, use that URL instead.\n\nCommon causes to distinguish:\n\n- no server process is running\n- wrong port or stale process owns the port\n- embedded Postgres failed to initialize\n- dev server is up but Electron did not launch\n- Electron launched but cannot reach the server\n- API\u002Fserver is healthy, but Desktop launch is blocked because `@rudderhq\u002Fui`\n  build\u002Ftypecheck fails on dirty WIP, incomplete fixtures, or an untracked\n  companion feature file\n- Desktop profile or instance id points to unexpected data\n- update metadata resolves but asset download\u002Fchecksum\u002Finstall fails\n- update helper or CLI child process writes progress after its parent pipe is\n  closed, causing `EPIPE`, `ERR_STREAM_DESTROYED`, `broken pipe`, or an Electron\n  main-process error dialog during restart\n- packaged smoke differs from dev-shell behavior\n\n### 4. Repair narrowly\n\nPrefer the smallest repair that matches the cause:\n\n- stop only the repo-local stale process when it blocks the port\n- reinstall dependencies only when package state or lockfile evidence points\n  there\n- fix script\u002Fconfig code when the failure is reproducible from a clean command\n- for dirty-WIP compile failures, build a changed-file ownership packet before\n  editing: failing path, related untracked files, likely source session or\n  feature group, and whether a narrow fixture repair would leave a companion\n  feature half-committed\n- reset `~\u002F.rudder\u002Finstances\u002Fdev` only when the user accepts data loss or the\n  instance is disposable and the task explicitly targets dev state\n- keep release publishing untouched until local Desktop state is green\n\nDo not delete `~\u002F.rudder`, change npm auth, move GitHub dist-tags, or install a\nnew app globally as a \"dev recovery\" shortcut.\n\nIf the compile blocker belongs to a larger unrelated feature already dirty in\nthe worktree, fix only the minimum needed to unblock the requested dev run, and\ndo not commit a lone companion file unless the whole feature group is in scope.\nIf a safe narrow repair is not possible, report the ownership packet and the\nexact blocked command instead of sweeping unrelated WIP into the recovery.\n\n### 5. Validate the right path\n\nValidation depends on what failed:\n\n- dev server\u002FAPI: health and org API calls\n- Desktop dev shell: launch evidence plus logs that the shell reached the API\n- dirty-WIP compile failure: rerun the failing package build or typecheck and\n  the original startup command far enough to prove the blocked layer has moved\n- packaged startup, profile isolation, migrations, installer assets, or\n  prod-local data path: `pnpm desktop:verify`\n- update\u002Fdownload path: dry-run is not enough when the issue is download,\n  checksum, extraction, or launch; run the strongest safe non-dry-run local\n  check available and state platform limitations\n- update restart path: if the failure appears after clicking \"Restart to\n  update\", reproduce or simulate the pipe lifecycle. Check the old app process,\n  update child process, progress JSON\u002Fstdout\u002Fstderr handling, installed app path,\n  and whether the child handles closed output streams as a normal shutdown case.\n\nIf code changed, run the narrow relevant tests first, then the repo baseline\nwhen feasible:\n\n```bash\npnpm -r typecheck\npnpm test:run\npnpm build\n```\n\nFor Desktop startup, migration, profile routing, or packaging changes, do not\nclaim done without packaged verification or an explicit blocker.\n\n#### Closed Progress Pipe \u002F Update Child Recovery\n\nUse this branch when the UI update flow starts a helper process or CLI mode and\nthe error appears after the parent app exits or restarts.\n\nEvidence to collect:\n\n- installed app path, for example `\u002FUsers\u002Fzeeland\u002FApplications\u002FRudder.app`\n- exact update action clicked: automatic prompt, About check, download, or\n  \"Restart to update\"\n- old version, target version, and whether the app reopened\n- stderr\u002Fdialog text including `EPIPE`, `ERR_STREAM_DESTROYED`, `write after\n  end`, `broken pipe`, or uncaught exception text\n- code paths that write progress JSON, flush stdout\u002Fstderr, or install\u002Frelaunch\n  the app\n\nRepair pattern:\n\n- Treat closed stdout\u002Fstderr\u002Fprogress pipes during update handoff as expected\n  when the parent app has exited.\n- Add a shared broken-pipe predicate rather than scattering string checks.\n- Guard process-level `uncaughtException` and `unhandledRejection` only for\n  known broken-pipe shutdown errors; do not swallow arbitrary exceptions.\n- Add a regression test that closes or destroys the progress reader before the\n  helper writes\u002Fflushed output, and assert the update path exits quietly or\n  reports success as appropriate.\n- Finish with packaged or installed-app verification. If a full in-app update\n  drill is too expensive, state that limitation and provide the strongest local\n  substitute plus the exact remaining manual drill.\n\n### 6. Handoff or escalate\n\nIf the user also asked to release after recovery:\n\n1. finish the local Desktop repair\n2. record validation evidence\n3. route the release portion to `release-maintainer`\n\nKeep the handoff concrete:\n\n```markdown\nRoot cause: ...\n\nRepair:\n- ...\n\nValidation:\n- ...\n\nNext route:\n- release-maintainer for version ...\n```\n\n## Common Failure Modes\n\n- Treating local `pnpm dev` breakage as a release problem before reproducing the\n  local command.\n- Resetting `~\u002F.rudder` too early and losing the user's useful local state.\n- Looking only at API health when the Electron shell is the broken layer.\n- Looking only at Electron logs when embedded Postgres never started.\n- Claiming update install is fixed from a dry-run that never downloads or\n  launches the app.\n- Treating `EPIPE` during update restart as a generic release failure before\n  checking whether the parent progress pipe intentionally closed.\n- Treating a dirty-WIP TypeScript or fixture failure as Desktop\u002FPostgres\n  corruption just because it surfaced during `pnpm dev`.\n- Mixing unrelated dirty package changes into a Desktop recovery commit.\n\n## Safety Rules\n\n- Preserve unrelated dirty worktree files.\n- Do not destroy local Rudder data without explicit authorization.\n- Do not publish, tag, move dist-tags, or create GitHub Releases from this\n  skill.\n- Prefer exact command output and log excerpts over guesses.\n- If the fix changes Desktop startup, profile routing, migrations, packaging,\n  or update behavior, require packaged verification before final handoff unless\n  blocked.\n","# Rudder Desktop Dev Recovery Maintainer\n\nUse this skill to get the local Rudder Desktop development path back to a known\nworking state.\n\nThis is not the release runbook. It is the recovery layer for local Desktop\nstartup, dev-shell runtime, embedded database state, update\u002Finstall smoke, and\nthe handoff point before release work.\n\n## Use When\n\nUse this skill for prompts like:\n\n- \"`pnpm dev` 好像桌面端跑不起来了\"\n- \"Desktop dev shell 起不来\"\n- \"API 能访问，但桌面端没起来\"\n- \"`pnpm dev` starts the API but Electron exits during a UI build\u002Ftypecheck\"\n- \"embedded Postgres \u002F `~\u002F.rudder` 状态是不是乱了\"\n- \"update 最新版失败，先 debug 一下\"\n- \"桌面端问题修完之后再发版\"\n- \"我本地 Desktop 是不是指到错的 instance\"\n\nAlso use this when a release request is blocked by local Desktop validation.\nFix the local Desktop blocker first, then route the release to\n`release-maintainer`.\n\n## Do Not Use When\n\nDo not use this skill for:\n\n- npm\u002FGitHub Release\u002Ftag\u002Fdist-tag publishing; use `release-maintainer`\n- packaged-app verification after code changes with no startup failure; follow\n  the normal Desktop validation workflow\n- stopping only a known repo-local dev runtime; use\n  `stop-rudder-dev-maintainer`\n- ordinary web UI data diagnosis; use `rudder-data-path-diagnostician-maintainer`\n- review-only of a Desktop feature; use `agent-work-reviewer-maintainer`\n\nIf the user's first request is \"发版\" and Desktop is already healthy, do not\nroute through this skill.\n\n## Default Workflow\n\n### 1. Classify the failure mode\n\nStart with a short state packet:\n\n- `git status --short --branch`\n- requested command, for example `pnpm dev`, `pnpm desktop:dev`, or\n  `pnpm desktop:verify`\n- whether the failure is API server, Vite middleware, Electron shell, embedded\n  Postgres, UI build\u002Ftypecheck, packaged smoke, update download, or app launch\n- exact stderr\u002Fstdout excerpt and exit code\n- currently listening ports around `3100`\n- relevant `~\u002F.rudder\u002Finstances\u002F*` path when the process prints one\n- whether the failing file is committed, modified, untracked, or part of a\n  broader dirty feature set\n\nDo not guess from memory when the command can be rerun safely.\n\n### 2. Read the local Desktop contract\n\nRead only the relevant docs and scripts:\n\n- `doc\u002Fengineering\u002FDEVELOPING.md`\n- `doc\u002Fengineering\u002FDESKTOP.md`\n- `doc\u002FREADME.md` for navigation when needed\n- `desktop\u002Fpackage.json`\n- root `package.json` scripts\n- `desktop\u002Fscripts\u002Fsmoke.mjs` for packaged-smoke expectations\n- `scripts\u002Fprod-desktop.mjs` only when the failure is prod-local or installer\n  related\n\nWhen docs and scripts disagree, scripts are the executable truth for the active\ndiagnosis. Record the mismatch as a docs follow-up if it matters.\n\n### 3. Verify the active runtime before repairing\n\nCheck the local server and org list when the API is expected to be running:\n\n```bash\ncurl -sS http:\u002F\u002F127.0.0.1:3100\u002Fapi\u002Fhealth\ncurl -sS http:\u002F\u002F127.0.0.1:3100\u002Fapi\u002Forgs\n```\n\nIf the Desktop shell is pointed at another base URL, use that URL instead.\n\nCommon causes to distinguish:\n\n- no server process is running\n- wrong port or stale process owns the port\n- embedded Postgres failed to initialize\n- dev server is up but Electron did not launch\n- Electron launched but cannot reach the server\n- API\u002Fserver is healthy, but Desktop launch is blocked because `@rudderhq\u002Fui`\n  build\u002Ftypecheck fails on dirty WIP, incomplete fixtures, or an untracked\n  companion feature file\n- Desktop profile or instance id points to unexpected data\n- update metadata resolves but asset download\u002Fchecksum\u002Finstall fails\n- update helper or CLI child process writes progress after its parent pipe is\n  closed, causing `EPIPE`, `ERR_STREAM_DESTROYED`, `broken pipe`, or an Electron\n  main-process error dialog during restart\n- packaged smoke differs from dev-shell behavior\n\n### 4. Repair narrowly\n\nPrefer the smallest repair that matches the cause:\n\n- stop only the repo-local stale process when it blocks the port\n- reinstall dependencies only when package state or lockfile evidence points\n  there\n- fix script\u002Fconfig code when the failure is reproducible from a clean command\n- for dirty-WIP compile failures, build a changed-file ownership packet before\n  editing: failing path, related untracked files, likely source session or\n  feature group, and whether a narrow fixture repair would leave a companion\n  feature half-committed\n- reset `~\u002F.rudder\u002Finstances\u002Fdev` only when the user accepts data loss or the\n  instance is disposable and the task explicitly targets dev state\n- keep release publishing untouched until local Desktop state is green\n\nDo not delete `~\u002F.rudder`, change npm auth, move GitHub dist-tags, or install a\nnew app globally as a \"dev recovery\" shortcut.\n\nIf the compile blocker belongs to a larger unrelated feature already dirty in\nthe worktree, fix only the minimum needed to unblock the requested dev run, and\ndo not commit a lone companion file unless the whole feature group is in scope.\nIf a safe narrow repair is not possible, report the ownership packet and the\nexact blocked command instead of sweeping unrelated WIP into the recovery.\n\n### 5. Validate the right path\n\nValidation depends on what failed:\n\n- dev server\u002FAPI: health and org API calls\n- Desktop dev shell: launch evidence plus logs that the shell reached the API\n- dirty-WIP compile failure: rerun the failing package build or typecheck and\n  the original startup command far enough to prove the blocked layer has moved\n- packaged startup, profile isolation, migrations, installer assets, or\n  prod-local data path: `pnpm desktop:verify`\n- update\u002Fdownload path: dry-run is not enough when the issue is download,\n  checksum, extraction, or launch; run the strongest safe non-dry-run local\n  check available and state platform limitations\n- update restart path: if the failure appears after clicking \"Restart to\n  update\", reproduce or simulate the pipe lifecycle. Check the old app process,\n  update child process, progress JSON\u002Fstdout\u002Fstderr handling, installed app path,\n  and whether the child handles closed output streams as a normal shutdown case.\n\nIf code changed, run the narrow relevant tests first, then the repo baseline\nwhen feasible:\n\n```bash\npnpm -r typecheck\npnpm test:run\npnpm build\n```\n\nFor Desktop startup, migration, profile routing, or packaging changes, do not\nclaim done without packaged verification or an explicit blocker.\n\n#### Closed Progress Pipe \u002F Update Child Recovery\n\nUse this branch when the UI update flow starts a helper process or CLI mode and\nthe error appears after the parent app exits or restarts.\n\nEvidence to collect:\n\n- installed app path, for example `\u002FUsers\u002Fzeeland\u002FApplications\u002FRudder.app`\n- exact update action clicked: automatic prompt, About check, download, or\n  \"Restart to update\"\n- old version, target version, and whether the app reopened\n- stderr\u002Fdialog text including `EPIPE`, `ERR_STREAM_DESTROYED`, `write after\n  end`, `broken pipe`, or uncaught exception text\n- code paths that write progress JSON, flush stdout\u002Fstderr, or install\u002Frelaunch\n  the app\n\nRepair pattern:\n\n- Treat closed stdout\u002Fstderr\u002Fprogress pipes during update handoff as expected\n  when the parent app has exited.\n- Add a shared broken-pipe predicate rather than scattering string checks.\n- Guard process-level `uncaughtException` and `unhandledRejection` only for\n  known broken-pipe shutdown errors; do not swallow arbitrary exceptions.\n- Add a regression test that closes or destroys the progress reader before the\n  helper writes\u002Fflushed output, and assert the update path exits quietly or\n  reports success as appropriate.\n- Finish with packaged or installed-app verification. If a full in-app update\n  drill is too expensive, state that limitation and provide the strongest local\n  substitute plus the exact remaining manual drill.\n\n### 6. Handoff or escalate\n\nIf the user also asked to release after recovery:\n\n1. finish the local Desktop repair\n2. record validation evidence\n3. route the release portion to `release-maintainer`\n\nKeep the handoff concrete:\n\n```markdown\nRoot cause: ...\n\nRepair:\n- ...\n\nValidation:\n- ...\n\nNext route:\n- release-maintainer for version ...\n```\n\n## Common Failure Modes\n\n- Treating local `pnpm dev` breakage as a release problem before reproducing the\n  local command.\n- Resetting `~\u002F.rudder` too early and losing the user's useful local state.\n- Looking only at API health when the Electron shell is the broken layer.\n- Looking only at Electron logs when embedded Postgres never started.\n- Claiming update install is fixed from a dry-run that never downloads or\n  launches the app.\n- Treating `EPIPE` during update restart as a generic release failure before\n  checking whether the parent progress pipe intentionally closed.\n- Treating a dirty-WIP TypeScript or fixture failure as Desktop\u002FPostgres\n  corruption just because it surfaced during `pnpm dev`.\n- Mixing unrelated dirty package changes into a Desktop recovery commit.\n\n## Safety Rules\n\n- Preserve unrelated dirty worktree files.\n- Do not destroy local Rudder data without explicit authorization.\n- Do not publish, tag, move dist-tags, or create GitHub Releases from this\n  skill.\n- Prefer exact command output and log excerpts over guesses.\n- If the fix changes Desktop startup, profile routing, migrations, packaging,\n  or update behavior, require packaged verification before final handoff unless\n  blocked.\n",{"name":5,"description":7},"main","26d5d68bcbc55caeac1dc6a266d973e8c3831f1c","agent-skills-bak\u002Fmaintainer\u002Frudder-desktop-dev-recovery-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":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add Undertone0809\u002Frudder --skill rudder-desktop-dev-recovery-maintainer",{"tool":58,"command":59},"bunx","bunx skills add Undertone0809\u002Frudder --skill rudder-desktop-dev-recovery-maintainer",{"tool":61,"command":62},"pnpm","pnpm dlx skills add Undertone0809\u002Frudder --skill rudder-desktop-dev-recovery-maintainer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fagent-skills-bak\u002Fmaintainer\u002Frudder-desktop-dev-recovery-maintainer\u002FSKILL.md",true,[66],{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"references\u002Frunbook.md","REFERENCE","参考文档",9630,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fagent-skills-bak\u002Fmaintainer\u002Frudder-desktop-dev-recovery-maintainer\u002Freferences\u002Frunbook.md",[73,86,99,124,153,179],{"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":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":38},"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",[],[80,81,82,83,84,85],"Synthesis","source","source synthesis","concise","synthesize","evidence",{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":97,"publishedAt":38},"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",[92],{"categoryNo":93,"categoryName":94,"taxonomyType":95,"taxonomyTypeDesc":96},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[98,85,88],"research",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":106,"publishedAt":38},"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",[105],{"categoryNo":93,"categoryName":94,"taxonomyType":95,"taxonomyTypeDesc":96},[107,108,98,32,109,110,82,111,112,113,114,115,116,117,118,119,120,121,122,123],"deep research","deep","debugging","triggers","for","with","multi","compare","verification","scoring","Art","reports","analyze","analysis","pipeline","Enterprise","examples",{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":133,"publishedAt":38},"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",[130],{"categoryNo":131,"categoryName":132,"taxonomyType":95,"taxonomyTypeDesc":96},"01JBSEEDCAT000000000000009","前端开发",[126,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152],"static","inline","chart","scenario","access","geometry","map","message","compact","back","never","node","mermaid","network","create","diagram","safe","css","markdown",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":162,"publishedAt":38},"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",[159],{"categoryNo":160,"categoryName":161,"taxonomyType":95,"taxonomyTypeDesc":96},"01JBSEEDCAT000000000000023","Skill与智能体开发",[163,164,165,166,167,168,169,170,111,171,172,173,174,28,175,176,120,177,178,148],"skill creator","creator","run evals","performance","variance analysis","existing skill","Existing","accuracy","From Scratch","users","optimize","evals","edit","improve","benchmark","run",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":38},"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",[],[186,187,188,81,189,190,191,192,193,194,195,196,197,198,199,200,201,202,148,203],"rudder docs","docs","context","interface","hire","creation","commands","active","do","contracts","ask","work","coding","configure","how","Tools","actions","tasks"]