[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K319CMY7VVDBEM1EVYZGYY":3,"skill-same:01M6K319CMY7VVDBEM1EVYZGYY":77},{"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":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":53,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M6K319CMY7VVDBEM1EVYZGYY","product-acceptance-verifier-maintainer",null,"Use when implemented Rudder feature, UI, workflow, Desktop, CLI, runtime, release, or regression work needs black-box acceptance verification against user requirements and the running product surface.","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\u002Fproduct-acceptance-verifier-maintainer\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"product acceptance verifier maintainer","verifier","acceptance","product","regression","black","feature","runtime","requirements","use","user","work","cli","box","ui","verification","release","desktop","workflow","2026-11-10 10:12:30",false,"---\nname: product-acceptance-verifier-maintainer\ndescription: \"Use when implemented Rudder feature, UI, workflow, Desktop, CLI, runtime, release, or regression work needs black-box acceptance verification against user requirements and the running product surface.\"\n---\n\n# Product Acceptance Verifier Maintainer\n\nVerify delivered Rudder work from the requirement side. This is an acceptance\nworkflow, not a code-review or implementation workflow.\n\nThe core question is:\n\n> Does the running product do what the user asked, on the real surface where the\n> result is consumed?\n\nDefault to Chinese when the user asks in Chinese. Keep the conclusion early and\nground it in observed behavior.\n\n## Role Boundary\n\nVerifier is black-box by default:\n\n- Start from the user request, acceptance criteria, product contracts, and\n  user-visible or agent-visible workflow.\n- Run commands, start local services, use Browser or Computer Use, inspect\n  logs, query APIs, and read database state when needed.\n- Create disposable dev data when necessary for proof, and record the mutation\n  ledger.\n- Do not edit files, stage changes, commit, push, or fix the bug you find.\n- Do not perform a general diff review unless it is needed to identify the\n  correct product surface or acceptance criteria.\n\nIf acceptance fails, report the failure and stop. The writer or parent workflow\nowns fixes and reruns.\n\n## Use When\n\nUse this skill for:\n\n- final verification after a feature, bug fix, UI change, Desktop change,\n  runtime\u002FCLI change, release, or regression fix\n- user corrections such as \"你真的跑过了吗\", \"我验收结果\", \"功能上真的好了?\"\n- checking whether a code-reviewed change still misses the requested outcome\n- rerunning failed acceptance paths after a writer fixes them\n- black-box verification of product behavior before final handoff\n\nDo not use this skill for:\n\n- pure code review, architecture critique, or PR hygiene; use\n  `agent-work-reviewer-maintainer`\n- unclear requirements before there is an implemented artifact; use the\n  lifecycle router, advisor, or requirements stage first\n- fixing acceptance failures during the same verifier pass\n- release publishing actions; verify release state only after the release owner\n  has produced artifacts or asks for acceptance verification\n\n## Inputs\n\nBuild a compact acceptance packet before running checks:\n\n- user request and any later corrections\n- explicit acceptance criteria, or the missing criteria that block judgment\n- non-goals and changed scope\n- current product contracts under `doc\u002Fproduct\u002F**` when product logic matters\n- target runtime: dev web, packaged Desktop, CLI, agent runtime, release, or\n  another terminal surface\n- related old workflows that could regress\n- author-claimed tests, screenshots, CI, or reviewer findings, labeled as\n  supporting evidence until independently inspected\n\nIf acceptance criteria are ambiguous, return `QUESTION` with the exact missing\ndecision instead of inventing product intent.\n\n## Verification Procedure\n\n### 1. State the acceptance target\n\nName the actor, trigger, system effect, and terminal surface:\n\n- actor: operator, agent, reviewer, CLI user, Desktop user, automation, release\n  consumer\n- trigger: click, command, API action, heartbeat, scheduled run, install, update\n- system effect: persisted issue state, comment, run, artifact, UI state, cost,\n  release asset, or setting\n- terminal surface: UI route, packaged Desktop shell, CLI output, API readback,\n  run-intelligence view, npm\u002FGitHub release state, or screenshot\n\nAlso decide whether the request requires real-environment proof. Mark the run\n`REAL_ENV_REQUIRED` when the user explicitly asks for real\u002Flocal\u002Flive\nverification or challenges prior proof, including phrases such as \"真实环境\",\n\"本地真实环境\", \"真实的本地\", \"在我电脑上\", \"真实飞书\", \"飞书测试\", \"我验收结果\",\n\"你真的跑过了吗\", or \"不是 mock\u002F不是单测\". For `REAL_ENV_REQUIRED`, the named\nterminal surface is the actual local\u002Flive surface, not a substitute.\n\n### 2. Run the product path\n\nUse the strongest safe path available:\n\n- UI\u002Fworkflow: open the local route with Browser or Computer Use, perform the\n  user-visible action, and inspect the resulting state.\n- Desktop: use packaged verification or Computer Use for native shell behavior,\n  menus, update prompts, profile routing, drag\u002Fdrop, and local data paths.\n- CLI\u002Fagent runtime: run the actor command or wakeup when practical, then read\n  back issue\u002Frun\u002Fcomment\u002FAPI\u002FDB state and the terminal CLI\u002FUI surface.\n- Release: verify live npm, tag, GitHub Release, asset, workflow, and install\n  surfaces for the intended channel.\n- Visual acceptance: inspect screenshots or the live rendered route. For\n  alignment or row rhythm, prefer DOM geometry or centerline deltas with\n  production-shaped data.\n\nUnit tests, typecheck, build, CI, or diff review are supporting evidence. They\ndo not replace terminal product behavior when the product path can be exercised.\n\nFor `REAL_ENV_REQUIRED`, do not return `PASS` unless the real requested\nenvironment was exercised successfully. Mocked services, DB-backed integration\ntests, isolated temp databases, synthetic actor-run chains, code inspection, and\nsubstituted local routes can be valuable evidence, but they are not acceptance\nfor the real-environment request. If the real environment is unavailable, unsafe,\nmissing credentials, not configured, or would require user action, return\n`QUESTION` when a user decision can unblock it, or `FAIL` when the delivered\nartifact cannot currently be proven on the requested surface. Label the evidence\nas `substituted`, not `PASS`.\n\n### 3. Check regressions in the nearest old flow\n\nRun the highest-risk adjacent flow when the change touches shared behavior. For\nexample:\n\n- a login validation change also checks registration\n- an issue mutation checks list, detail, and attention state\n- a renderer token checks both display and authoring\u002Fdiscovery path\n- a Desktop startup change checks packaged boot and profile routing\n\nKeep regression checks scoped. Do not turn acceptance into a broad exploratory\nQA sweep unless the user asked for that.\n\n### 4. Record a mutation ledger\n\nWhen verification creates or mutates data, record:\n\n- runtime and `\u002Fapi\u002Fhealth` or equivalent source of truth\n- organization, issue, agent, run, release, approval, or record ids created\n- public API writes versus direct database writes\n- final URL, screenshot path, log path, run id, command, or release URL\n- cleanup status, or why evidence data was intentionally left in place\n\n## Output Contract\n\nReturn exactly one top-level verdict:\n\n- `PASS`: acceptance criteria met with observed product evidence.\n- `FAIL`: observed behavior does not meet acceptance criteria.\n- `QUESTION`: acceptance criteria are missing, contradictory, or unsafe to\n  infer.\n\nFor `REAL_ENV_REQUIRED`, `PASS` means the real requested environment was run and\nobserved. A substituted proof bundle must use `FAIL` or `QUESTION`; never write\n`PASS, but real environment was not run`.\n\nUse this shape:\n\n```markdown\nVerdict: PASS \u002F FAIL \u002F QUESTION\n\nAcceptance target:\n- Actor:\n- Trigger:\n- Expected effect:\n- Terminal surface:\n\nObserved evidence:\n- ...\n\nFailures or questions:\n- Step:\n- Expected:\n- Actual:\n- Evidence:\n- Blocks handoff: yes\u002Fno\n\nRegression checks:\n- ...\n\nMutation ledger:\n- ...\n```\n\nDo not hide skipped checks. If proof was substituted, label it, for example\n`substituted: Browser current-dev for packaged Desktop`.\nIf real-environment proof was required but not run, put it under `Failures or\nquestions` with `Blocks handoff: yes`.\n\n## Validation Cases\n\n### Case: Sort Requirement Drift\n\nInput:\nThe user asked for a list sorted by updated time descending. The implementation\npasses tests and review, but the running UI appears sorted by created time.\n\nExpected behavior:\nRun the UI or API path with records whose created and updated times differ.\nReturn `FAIL` with reproduction steps, expected updated-time order, actual\ncreated-time order, and the observed UI\u002FAPI evidence.\n\nMust not:\nApprove the work because the diff is clean, tests pass, or reviewer accepted the\nsorting implementation.\n\n### Case: UI Fidelity After Review\n\nInput:\nA reviewer accepted a UI diff, but the user asks whether the button spacing,\ncolor, and radius actually match the design or screenshot requirement.\n\nExpected behavior:\nOpen the rendered surface, compare the visible state to the requirement, capture\na screenshot or measurable DOM evidence, and return `PASS`, `FAIL`, or\n`QUESTION` based on observed UI behavior.\n\nMust not:\nUse source CSS inspection as the only acceptance evidence for a layout-sensitive\nUI change.\n\n### Case: Shared Workflow Regression\n\nInput:\nA login fix changed shared validation. Login now works, but registration uses\nthe same validator.\n\nExpected behavior:\nRun the login acceptance path and the nearest registration regression path.\nReturn `FAIL` if registration breaks, even when the requested login path passes.\n\nMust not:\nLimit acceptance to the changed page when the shared workflow risk is obvious\nand cheap to exercise.\n\n### Case: Verifier Must Not Fix\n\nInput:\nDuring acceptance, the verifier finds that the final UI action fails because an\nAPI field is missing.\n\nExpected behavior:\nReturn `FAIL` with reproduction, expected behavior, actual behavior, and the API\nor UI evidence. Stop without editing files.\n\nMust not:\nPatch the API, stage files, commit, push, or continue as the writer.\n\n### Case: Real Feishu Stop Verification Required\n\nInput:\nThe writer fixed a Feishu `\u002Fstop` regression and produced DB-backed runtime\ntests. The user says they tested real Feishu and it still fails, or explicitly\nasks for \"真实的本地 Feishu 环境测试\".\n\nExpected behavior:\nMark the acceptance target as `REAL_ENV_REQUIRED` with terminal surface\n`real local\u002Flive Feishu long-connection chat`. Run that real Feishu path if it\nis configured and safe: send a normal message, immediately send `\u002Fstop`, observe\nthe Feishu chat response, and read back Rudder state\u002Flogs when available. Return\n`PASS` only if that real Feishu path works. If only DB-backed tests, mocks, code\ninspection, or subagents ran, return `QUESTION` or `FAIL` and label them as\nsubstituted evidence with `Blocks handoff: yes`.\n\nMust not:\nReturn `PASS` because Feishu runtime tests passed, because a reviewer accepted\nthe diff, or because the failure was reproduced in an isolated database instead\nof the real Feishu surface the user challenged.\n","# Product Acceptance Verifier Maintainer\n\nVerify delivered Rudder work from the requirement side. This is an acceptance\nworkflow, not a code-review or implementation workflow.\n\nThe core question is:\n\n> Does the running product do what the user asked, on the real surface where the\n> result is consumed?\n\nDefault to Chinese when the user asks in Chinese. Keep the conclusion early and\nground it in observed behavior.\n\n## Role Boundary\n\nVerifier is black-box by default:\n\n- Start from the user request, acceptance criteria, product contracts, and\n  user-visible or agent-visible workflow.\n- Run commands, start local services, use Browser or Computer Use, inspect\n  logs, query APIs, and read database state when needed.\n- Create disposable dev data when necessary for proof, and record the mutation\n  ledger.\n- Do not edit files, stage changes, commit, push, or fix the bug you find.\n- Do not perform a general diff review unless it is needed to identify the\n  correct product surface or acceptance criteria.\n\nIf acceptance fails, report the failure and stop. The writer or parent workflow\nowns fixes and reruns.\n\n## Use When\n\nUse this skill for:\n\n- final verification after a feature, bug fix, UI change, Desktop change,\n  runtime\u002FCLI change, release, or regression fix\n- user corrections such as \"你真的跑过了吗\", \"我验收结果\", \"功能上真的好了?\"\n- checking whether a code-reviewed change still misses the requested outcome\n- rerunning failed acceptance paths after a writer fixes them\n- black-box verification of product behavior before final handoff\n\nDo not use this skill for:\n\n- pure code review, architecture critique, or PR hygiene; use\n  `agent-work-reviewer-maintainer`\n- unclear requirements before there is an implemented artifact; use the\n  lifecycle router, advisor, or requirements stage first\n- fixing acceptance failures during the same verifier pass\n- release publishing actions; verify release state only after the release owner\n  has produced artifacts or asks for acceptance verification\n\n## Inputs\n\nBuild a compact acceptance packet before running checks:\n\n- user request and any later corrections\n- explicit acceptance criteria, or the missing criteria that block judgment\n- non-goals and changed scope\n- current product contracts under `doc\u002Fproduct\u002F**` when product logic matters\n- target runtime: dev web, packaged Desktop, CLI, agent runtime, release, or\n  another terminal surface\n- related old workflows that could regress\n- author-claimed tests, screenshots, CI, or reviewer findings, labeled as\n  supporting evidence until independently inspected\n\nIf acceptance criteria are ambiguous, return `QUESTION` with the exact missing\ndecision instead of inventing product intent.\n\n## Verification Procedure\n\n### 1. State the acceptance target\n\nName the actor, trigger, system effect, and terminal surface:\n\n- actor: operator, agent, reviewer, CLI user, Desktop user, automation, release\n  consumer\n- trigger: click, command, API action, heartbeat, scheduled run, install, update\n- system effect: persisted issue state, comment, run, artifact, UI state, cost,\n  release asset, or setting\n- terminal surface: UI route, packaged Desktop shell, CLI output, API readback,\n  run-intelligence view, npm\u002FGitHub release state, or screenshot\n\nAlso decide whether the request requires real-environment proof. Mark the run\n`REAL_ENV_REQUIRED` when the user explicitly asks for real\u002Flocal\u002Flive\nverification or challenges prior proof, including phrases such as \"真实环境\",\n\"本地真实环境\", \"真实的本地\", \"在我电脑上\", \"真实飞书\", \"飞书测试\", \"我验收结果\",\n\"你真的跑过了吗\", or \"不是 mock\u002F不是单测\". For `REAL_ENV_REQUIRED`, the named\nterminal surface is the actual local\u002Flive surface, not a substitute.\n\n### 2. Run the product path\n\nUse the strongest safe path available:\n\n- UI\u002Fworkflow: open the local route with Browser or Computer Use, perform the\n  user-visible action, and inspect the resulting state.\n- Desktop: use packaged verification or Computer Use for native shell behavior,\n  menus, update prompts, profile routing, drag\u002Fdrop, and local data paths.\n- CLI\u002Fagent runtime: run the actor command or wakeup when practical, then read\n  back issue\u002Frun\u002Fcomment\u002FAPI\u002FDB state and the terminal CLI\u002FUI surface.\n- Release: verify live npm, tag, GitHub Release, asset, workflow, and install\n  surfaces for the intended channel.\n- Visual acceptance: inspect screenshots or the live rendered route. For\n  alignment or row rhythm, prefer DOM geometry or centerline deltas with\n  production-shaped data.\n\nUnit tests, typecheck, build, CI, or diff review are supporting evidence. They\ndo not replace terminal product behavior when the product path can be exercised.\n\nFor `REAL_ENV_REQUIRED`, do not return `PASS` unless the real requested\nenvironment was exercised successfully. Mocked services, DB-backed integration\ntests, isolated temp databases, synthetic actor-run chains, code inspection, and\nsubstituted local routes can be valuable evidence, but they are not acceptance\nfor the real-environment request. If the real environment is unavailable, unsafe,\nmissing credentials, not configured, or would require user action, return\n`QUESTION` when a user decision can unblock it, or `FAIL` when the delivered\nartifact cannot currently be proven on the requested surface. Label the evidence\nas `substituted`, not `PASS`.\n\n### 3. Check regressions in the nearest old flow\n\nRun the highest-risk adjacent flow when the change touches shared behavior. For\nexample:\n\n- a login validation change also checks registration\n- an issue mutation checks list, detail, and attention state\n- a renderer token checks both display and authoring\u002Fdiscovery path\n- a Desktop startup change checks packaged boot and profile routing\n\nKeep regression checks scoped. Do not turn acceptance into a broad exploratory\nQA sweep unless the user asked for that.\n\n### 4. Record a mutation ledger\n\nWhen verification creates or mutates data, record:\n\n- runtime and `\u002Fapi\u002Fhealth` or equivalent source of truth\n- organization, issue, agent, run, release, approval, or record ids created\n- public API writes versus direct database writes\n- final URL, screenshot path, log path, run id, command, or release URL\n- cleanup status, or why evidence data was intentionally left in place\n\n## Output Contract\n\nReturn exactly one top-level verdict:\n\n- `PASS`: acceptance criteria met with observed product evidence.\n- `FAIL`: observed behavior does not meet acceptance criteria.\n- `QUESTION`: acceptance criteria are missing, contradictory, or unsafe to\n  infer.\n\nFor `REAL_ENV_REQUIRED`, `PASS` means the real requested environment was run and\nobserved. A substituted proof bundle must use `FAIL` or `QUESTION`; never write\n`PASS, but real environment was not run`.\n\nUse this shape:\n\n```markdown\nVerdict: PASS \u002F FAIL \u002F QUESTION\n\nAcceptance target:\n- Actor:\n- Trigger:\n- Expected effect:\n- Terminal surface:\n\nObserved evidence:\n- ...\n\nFailures or questions:\n- Step:\n- Expected:\n- Actual:\n- Evidence:\n- Blocks handoff: yes\u002Fno\n\nRegression checks:\n- ...\n\nMutation ledger:\n- ...\n```\n\nDo not hide skipped checks. If proof was substituted, label it, for example\n`substituted: Browser current-dev for packaged Desktop`.\nIf real-environment proof was required but not run, put it under `Failures or\nquestions` with `Blocks handoff: yes`.\n\n## Validation Cases\n\n### Case: Sort Requirement Drift\n\nInput:\nThe user asked for a list sorted by updated time descending. The implementation\npasses tests and review, but the running UI appears sorted by created time.\n\nExpected behavior:\nRun the UI or API path with records whose created and updated times differ.\nReturn `FAIL` with reproduction steps, expected updated-time order, actual\ncreated-time order, and the observed UI\u002FAPI evidence.\n\nMust not:\nApprove the work because the diff is clean, tests pass, or reviewer accepted the\nsorting implementation.\n\n### Case: UI Fidelity After Review\n\nInput:\nA reviewer accepted a UI diff, but the user asks whether the button spacing,\ncolor, and radius actually match the design or screenshot requirement.\n\nExpected behavior:\nOpen the rendered surface, compare the visible state to the requirement, capture\na screenshot or measurable DOM evidence, and return `PASS`, `FAIL`, or\n`QUESTION` based on observed UI behavior.\n\nMust not:\nUse source CSS inspection as the only acceptance evidence for a layout-sensitive\nUI change.\n\n### Case: Shared Workflow Regression\n\nInput:\nA login fix changed shared validation. Login now works, but registration uses\nthe same validator.\n\nExpected behavior:\nRun the login acceptance path and the nearest registration regression path.\nReturn `FAIL` if registration breaks, even when the requested login path passes.\n\nMust not:\nLimit acceptance to the changed page when the shared workflow risk is obvious\nand cheap to exercise.\n\n### Case: Verifier Must Not Fix\n\nInput:\nDuring acceptance, the verifier finds that the final UI action fails because an\nAPI field is missing.\n\nExpected behavior:\nReturn `FAIL` with reproduction, expected behavior, actual behavior, and the API\nor UI evidence. Stop without editing files.\n\nMust not:\nPatch the API, stage files, commit, push, or continue as the writer.\n\n### Case: Real Feishu Stop Verification Required\n\nInput:\nThe writer fixed a Feishu `\u002Fstop` regression and produced DB-backed runtime\ntests. The user says they tested real Feishu and it still fails, or explicitly\nasks for \"真实的本地 Feishu 环境测试\".\n\nExpected behavior:\nMark the acceptance target as `REAL_ENV_REQUIRED` with terminal surface\n`real local\u002Flive Feishu long-connection chat`. Run that real Feishu path if it\nis configured and safe: send a normal message, immediately send `\u002Fstop`, observe\nthe Feishu chat response, and read back Rudder state\u002Flogs when available. Return\n`PASS` only if that real Feishu path works. If only DB-backed tests, mocks, code\ninspection, or subagents ran, return `QUESTION` or `FAIL` and label them as\nsubstituted evidence with `Blocks handoff: yes`.\n\nMust not:\nReturn `PASS` because Feishu runtime tests passed, because a reviewer accepted\nthe diff, or because the failure was reproduced in an isolated database instead\nof the real Feishu surface the user challenged.\n",{"name":5,"description":7},"main","26d5d68bcbc55caeac1dc6a266d973e8c3831f1c","agent-skills-bak\u002Fmaintainer\u002Fproduct-acceptance-verifier-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":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add Undertone0809\u002Frudder --skill product-acceptance-verifier-maintainer",{"tool":63,"command":64},"bunx","bunx skills add Undertone0809\u002Frudder --skill product-acceptance-verifier-maintainer",{"tool":66,"command":67},"pnpm","pnpm dlx skills add Undertone0809\u002Frudder --skill product-acceptance-verifier-maintainer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fagent-skills-bak\u002Fmaintainer\u002Fproduct-acceptance-verifier-maintainer\u002FSKILL.md",true,[71],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Frunbook.md","REFERENCE","参考文档",10456,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002Fagent-skills-bak\u002Fmaintainer\u002Fproduct-acceptance-verifier-maintainer\u002Freferences\u002Frunbook.md",[78,91,104,129,158,184],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":43},"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",[],[85,86,87,88,89,90],"Synthesis","source","source synthesis","concise","synthesize","evidence",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":102,"publishedAt":43},"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",[97],{"categoryNo":98,"categoryName":99,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[103,90,93],"research",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":111,"publishedAt":43},"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",[110],{"categoryNo":98,"categoryName":99,"taxonomyType":100,"taxonomyTypeDesc":101},[112,113,103,114,115,116,87,117,118,119,120,39,121,122,123,124,125,126,127,128],"deep research","deep","state","debugging","triggers","for","with","multi","compare","scoring","Art","reports","analyze","analysis","pipeline","Enterprise","examples",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":138,"publishedAt":43},"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",[135],{"categoryNo":136,"categoryName":137,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000009","前端开发",[131,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157],"static","inline","chart","scenario","access","geometry","map","message","compact","back","never","node","mermaid","network","create","diagram","safe","css","markdown",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":167,"publishedAt":43},"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",[164],{"categoryNo":165,"categoryName":166,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000023","Skill与智能体开发",[168,169,170,171,172,173,174,175,117,176,177,178,179,33,180,181,125,182,183,153],"skill creator","creator","run evals","performance","variance analysis","existing skill","Existing","accuracy","From Scratch","users","optimize","evals","edit","improve","benchmark","run",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":190,"publishedAt":43},"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",[],[191,192,193,86,194,195,196,197,198,199,200,201,35,202,203,204,205,206,153,207],"rudder docs","docs","context","interface","hire","creation","commands","active","do","contracts","ask","coding","configure","how","Tools","actions","tasks"]