[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K2YTFXM73HB03G65EZ3JB6":3,"skill-same:01M6K2YTFXM73HB03G65EZ3JB6":148},{"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},"01M6K2YTFXM73HB03G65EZ3JB6","mock-data-maintainer",null,"Use when creating realistic Rudder mock, demo, seed, fixture, screenshot, test, CSV, JSON, SQL, TypeScript, or scenario data for local development, demos, screenshots, product explanations, and workflow validation.","Undertone0809\u002Frudder","Undertone0809","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F72488598?v=4","01M6K2XANP3QJEF503JX2C693T","Zeeland","01M6K2XATQXEYF7N2QG8KZVEEY",297,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-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],"mock data maintainer","mock data","mock","data","json","for","local development","fixture","local","seed","use","typescript","csv","demo","product","validation","development","sql","test","workflow","2026-11-10 10:12:30",false,"---\nname: mock-data-maintainer\ndescription: \"Use when creating realistic Rudder mock, demo, seed, fixture, screenshot, test, CSV, JSON, SQL, TypeScript, or scenario data for local development, demos, screenshots, product explanations, and workflow validation.\"\n---\n\n# Mock Data Maintainer\n\nUse this skill to create mock data that is useful, coherent, and easy to reuse.\nThe goal is not random fake records. The goal is scenario data that supports\ntesting, screenshots, demos, and clear user understanding.\n\n## First Decision\n\nClassify the request into one primary intent before generating data:\n\n1. testing data: local dev, E2E, bug reproduction, contract checks, edge states\n2. screenshot\u002Fdemo data: local screenshots, landing proof shots, README, decks\n3. user-scenario data: explain a workflow, persona, problem, or product value\n4. static artifact data: CSV, JSON, SQL, Markdown table, or TypeScript fixture\n\nIf the prompt implies multiple intents, produce one shared scenario spine and\nthen adapt outputs for each intent. For example, one Rudder launch-week org can\nserve local screenshots, workflow explanation, and E2E fixture design.\n\n## Reference Selection\n\nRead only the references needed for the request:\n\n- `references\u002Fscenario-index.md`: scenario catalog and selection rules\n- `references\u002Fquality-bar.md`: realism, determinism, privacy, and output rules\n- `references\u002Frudder-studio-scenario.md`: canonical month-long \"Rudder uses\n  Rudder to build and grow Rudder\" org, with reusable JSON fixtures and seed\n  script\n- `references\u002Frudder-landing-demo-org.md`: canonical screenshot-ready Rudder org\n- `references\u002Frudder-test-fixtures.md`: Rudder testing and edge-state fixtures\n- `references\u002Frudder-user-scenarios.md`: Rudder user stories and scenario spines\n- `references\u002Fgeneric-saas-dashboard.md`: SaaS metrics, billing, and ops data\n- `references\u002Fgeneric-crm-sales.md`: CRM, pipeline, account, and support data\n- `references\u002Fedge-states.md`: empty, error, boundary, permission, and conflict states\n\n## Bundled Scripts\n\nUse bundled scripts when the user needs live Rudder data instead of static\nrecords:\n\n- `scripts\u002Fcapture-landing-proof-shots.ts`: boots an isolated Rudder instance,\n  seeds the canonical landing demo org, and optionally captures proof-shot\n  screenshots. Use `LANDING_SHOTS_SKIP_CAPTURE=1 LANDING_SHOTS_HOLD_OPEN=1`\n  for seed-only local screenshot prep.\n- `scripts\u002Fseed-rudder-studio.ts`: seeds the reusable Rudder Studio org into a\n  running local dev instance. Use it when the user wants a realistic month-long\n  Rudder org, \"using Rudder to build Rudder\", natural Calendar work history,\n  or durable user-scenario data.\n\nPrefer these scripts over rewriting the seed flow in a one-off answer.\n\n## Default Workflow\n\n1. Identify the data intent and target surface.\n2. Pick or combine scenarios from the reference catalog.\n3. Define the scenario spine:\n   - who the user\u002Fpersona is\n   - what they are trying to do\n   - what conflict, risk, or decision the data should reveal\n   - what changed before and after the workflow\n4. Ground Rudder scenarios in production-like operator work. Prefer a coherent\n   mix of synthetic records plus sanitized real scenario patterns from Rudder\n   development, release, support, growth, and agent-ops work over generic SaaS\n   examples.\n5. Define entities and relationships before writing rows.\n6. Add time, status, priority, budget, ownership, and failure signals where they\n   make the scenario clearer.\n7. Choose the output form:\n   - live seed command\n   - TypeScript seed script\n   - JSON fixture\n   - CSV\n   - SQL inserts\n   - Markdown scenario brief\n8. Include usage notes and reset notes.\n\n## Output Shape\n\nFor non-trivial requests, structure the answer like this:\n\n```markdown\n## Scenario\n- Intent:\n- User story:\n- Target surface:\n- Data shape:\n\n## Entities\n- ...\n\n## States Covered\n- ...\n\n## Seed Ledger\n- Target runtime:\n- Created or modified records:\n- Write method:\n- Proof route\u002Frun\u002Flog:\n- Cleanup status:\n\n## Output\n...\n\n## Usage\n...\n```\n\nFor code or fixture outputs, include deterministic IDs when useful. For\nscreenshot\u002Fdemo data, prefer readable names and dense but believable state over\nopaque generated IDs.\n\n## Rudder-Specific Rules\n\n- Keep organization boundaries explicit. Every Rudder entity that belongs to an\n  organization should have a clear org owner.\n- Keep entities relationally coherent: org -> goals -> projects -> issues ->\n  agents, approvals, chats, heartbeat runs, costs, and activity.\n- For whole-product user scenarios, prefer a causal scenario spine over\n  component-specific fixtures. Start from real work records, then let Calendar,\n  Dashboard, Messenger, approvals, and cost views reflect those records.\n- When the user wants \"Rudder Studio\", \"using Rudder to build Rudder\", a\n  month-long realistic org, or Calendar data that should emerge from real agent\n  work, use `references\u002Frudder-studio-scenario.md` and the Rudder Studio\n  fixture files instead of inventing a new one-off org.\n- For screenshots, make data visually legible across pages. Avoid empty shells.\n- For product screenshots, seed the underlying run\u002Foutput evidence too: dashboards,\n  agent detail pages, Calendar, Messenger, and charts should be downstream of\n  coherent issues, heartbeat runs, run logs, comments, approvals, costs, and\n  calendar events instead of isolated component fixtures.\n- For screenshot and demo requests, prefer Desktop-shell capture when the\n  product claim is about the installed app, local operator workflow, or\n  production-like Rudder use. Browser capture is acceptable for narrow web UI\n  checks, but the final dataset should still work inside the Desktop shell.\n- Dashboard, Calendar, and agent run screenshots must include non-empty\n  transcript\u002Foutput evidence. If a seeded page would show empty transcript,\n  empty run output, or decorative calendar-only blocks, treat the seed as\n  incomplete.\n- Capture flows must validate the specific screenshot surface before claiming\n  success. Use selectors and content assertions for the meaningful records on\n  each page, and fail or report blocked if the page is empty, stale, or showing\n  the wrong scenario.\n- For testing, include deterministic setup and reset strategy.\n- For workflow explanation, include persona, motivation, conflict, decision\n  point, and outcome.\n- For live `prod_local` or Desktop demo org seeds, target selection is part of\n  the data task. Verify the active runtime and database before writing; stale\n  config defaults are not enough.\n- Whole-org demo seeds should prefer API creation for the organization, then\n  scoped database insertion for richer downstream evidence if the API surface is\n  incomplete.\n- If the user asks for actual landing screenshots, use this skill's bundled\n  `scripts\u002Fcapture-landing-proof-shots.ts` after selecting the scenario. Do not\n  route to a separate landing-proof skill.\n\n## Live Rudder Instance Seed Rules\n\nWhen seeding data into a running Rudder instance, verify the target before any\nwrite.\n\n1. Confirm the live API target with `\u002Fapi\u002Fhealth`.\n   - For prod Desktop or local production data, require `localEnv=prod_local`\n     and `instanceId=default`.\n   - For dev data, require `localEnv=dev` and `instanceId=dev`.\n2. Do not trust stale config files alone. Prefer live runtime descriptors,\n   `\u002Fapi\u002Fhealth`, and active process or database connections.\n3. If API creation is available, use it for top-level organization creation so\n   normal service-side defaults, memberships, labels, activity, and policies are\n   applied.\n4. Use direct database writes only for seed entities that do not have complete\n   public API coverage, and keep them scoped to the verified organization id.\n5. If a temporary probe write is needed, name it clearly, record its id, delete\n   it immediately, and verify deletion before continuing.\n6. For destructive reseed, require explicit user authority or create a pending\n   approval record that makes the destructive operation visible in the seeded\n   organization.\n7. Never modify repo source files just to seed live data unless the user\n   explicitly asks for a reusable seed script or fixture.\n\nRequired readback for whole-organization Rudder demo seeds:\n\n- organization appears in `\u002Fapi\u002Forgs`\n- expected agents exist\n- expected goals, projects, and issues exist\n- pending approvals exist when requested\n- chat conversation exists when requested\n- activity log contains representative events\n- heartbeat runs and cost summary exist when requested\n- primary UI route returns 200\n- report organization id, URL key, counts, and verification evidence\n\nFor testing seeds, especially seeds used to prove a workflow fix, include a\nseed and mutation ledger even when the data is temporary:\n\n- target runtime and `\u002Fapi\u002Fhealth` payload or equivalent source of truth\n- organization URL key and id\n- issue, agent, run, approval, comment, cost, activity, or release records\n  created or modified\n- whether each write used public API creation, scoped database insertion, or a\n  script\n- final route URL, run id, screenshot, log, or API readback used for proof\n- cleanup status, or why the seeded records were kept as durable evidence\n\nIf the seed is meant to support a product-proof run, design it around the actor\nand trigger that will exercise the workflow. Do not create isolated rows that\nmake the final page look correct while bypassing the actual operator or agent\npath being reviewed.\n\n## Quality Bar\n\nGood mock data has:\n\n- a coherent story across all records\n- enough density to make UI states meaningful\n- edge states where testing needs them\n- deterministic values where automation needs them\n- plausible names, statuses, timestamps, and amounts\n- no real personal data, real customer secrets, or copied private records\n\nAvoid:\n\n- lorem ipsum rows without relationships\n- generic use-case copy that could describe any SaaS or task board\n- perfect happy-path-only data\n- overfitting to one component when the user needs a whole workflow\n- mixing production-looking secrets into examples\n- changing schema or app behavior just to make mock data easier\n\n## Hand-Off\n\nEnd with the concrete artifact or command the user can use immediately. If the\ndata is meant for local screenshots, include the exact route or local URL to\nopen after seeding. If the data is meant for tests, include the fixture entry\npoint and reset expectation.\n\n## Regression Checks\n\nUse these checks when updating this skill or screenshot\u002Fdemo fixtures:\n\n### Case: Use-case-led Rudder screenshot data\n\nInput: user asks for Rudder screenshots or demo data that should feel like real\noperator work.\n\nExpected behavior: choose Landing Demo Org or Rudder Studio, ground the\nscenario in sanitized Rudder-shaped work, seed issues\u002Fruns\u002Flogs\u002Fcosts\u002Fapprovals\nbefore deriving Dashboard, Calendar, Messenger, and agent-detail views.\n\nMust not: return generic SaaS use cases, isolated component rows, or empty page\nfixtures.\n\n### Case: Desktop-shell product evidence\n\nInput: user needs screenshots proving the installed local Rudder experience.\n\nExpected behavior: prefer Desktop-shell capture or coordinate with the\nscreenshot skill that can capture Desktop shell; browser screenshots are only\nsupporting evidence for narrow route checks.\n\nMust not: present browser-only proof as sufficient for a Desktop product claim.\n\n### Case: Prod Desktop demo org seed\n\nInput: user asks to create a new organization in prod using a source document as\ninitialization data.\n\nExpected behavior: verify `\u002Fapi\u002Fhealth` reports `localEnv=prod_local` and\n`instanceId=default`; create the organization through the API when possible;\nseed scoped relational data for agents, goals, projects, issues, approvals,\nchats, activity, runs, costs, and calendar evidence as requested; validate API\nreadback and the primary UI route; report the organization id, URL key, counts,\nand verification evidence.\n\nMust not: write to the dev database, rely only on stale config ports, leave\ntemporary probe records behind, or claim success from database counts without\nAPI readback.\n\n### Case: Existing demo org collision\n\nInput: user asks to reseed an organization that may already exist.\n\nExpected behavior: detect existing organizations by name, URL key, and issue\nprefix; classify the operation as additive or destructive; require explicit\nauthority or create a pending approval record before replacing existing seeded\nrecords; keep all changes scoped to the verified target organization.\n\nMust not: silently duplicate organizations, overwrite existing data without a\nvisible approval or explicit instruction, or use a matching issue prefix in the\nwrong runtime.\n\n### Case: Static fixture only\n\nInput: user asks for a JSON, SQL, CSV, or Markdown fixture and says not to write\nto local Rudder.\n\nExpected behavior: produce the requested static artifact and include usage or\nreset notes when relevant.\n\nMust not: call the Rudder API, connect to a database, create probe records, or\nmutate prod or dev state.\n\n### Case: Screenshot capture validation\n\nInput: a capture script or manual flow saves Dashboard, Calendar, chat,\napproval, or agent run screenshots.\n\nExpected behavior: assert page selectors plus scenario-specific text and\nnon-empty transcript\u002Foutput evidence before declaring success.\n\nMust not: silently save screenshots when the page loaded but the scenario data,\nrun output, transcript, or Calendar work history is missing.\n","# Mock Data Maintainer\n\nUse this skill to create mock data that is useful, coherent, and easy to reuse.\nThe goal is not random fake records. The goal is scenario data that supports\ntesting, screenshots, demos, and clear user understanding.\n\n## First Decision\n\nClassify the request into one primary intent before generating data:\n\n1. testing data: local dev, E2E, bug reproduction, contract checks, edge states\n2. screenshot\u002Fdemo data: local screenshots, landing proof shots, README, decks\n3. user-scenario data: explain a workflow, persona, problem, or product value\n4. static artifact data: CSV, JSON, SQL, Markdown table, or TypeScript fixture\n\nIf the prompt implies multiple intents, produce one shared scenario spine and\nthen adapt outputs for each intent. For example, one Rudder launch-week org can\nserve local screenshots, workflow explanation, and E2E fixture design.\n\n## Reference Selection\n\nRead only the references needed for the request:\n\n- `references\u002Fscenario-index.md`: scenario catalog and selection rules\n- `references\u002Fquality-bar.md`: realism, determinism, privacy, and output rules\n- `references\u002Frudder-studio-scenario.md`: canonical month-long \"Rudder uses\n  Rudder to build and grow Rudder\" org, with reusable JSON fixtures and seed\n  script\n- `references\u002Frudder-landing-demo-org.md`: canonical screenshot-ready Rudder org\n- `references\u002Frudder-test-fixtures.md`: Rudder testing and edge-state fixtures\n- `references\u002Frudder-user-scenarios.md`: Rudder user stories and scenario spines\n- `references\u002Fgeneric-saas-dashboard.md`: SaaS metrics, billing, and ops data\n- `references\u002Fgeneric-crm-sales.md`: CRM, pipeline, account, and support data\n- `references\u002Fedge-states.md`: empty, error, boundary, permission, and conflict states\n\n## Bundled Scripts\n\nUse bundled scripts when the user needs live Rudder data instead of static\nrecords:\n\n- `scripts\u002Fcapture-landing-proof-shots.ts`: boots an isolated Rudder instance,\n  seeds the canonical landing demo org, and optionally captures proof-shot\n  screenshots. Use `LANDING_SHOTS_SKIP_CAPTURE=1 LANDING_SHOTS_HOLD_OPEN=1`\n  for seed-only local screenshot prep.\n- `scripts\u002Fseed-rudder-studio.ts`: seeds the reusable Rudder Studio org into a\n  running local dev instance. Use it when the user wants a realistic month-long\n  Rudder org, \"using Rudder to build Rudder\", natural Calendar work history,\n  or durable user-scenario data.\n\nPrefer these scripts over rewriting the seed flow in a one-off answer.\n\n## Default Workflow\n\n1. Identify the data intent and target surface.\n2. Pick or combine scenarios from the reference catalog.\n3. Define the scenario spine:\n   - who the user\u002Fpersona is\n   - what they are trying to do\n   - what conflict, risk, or decision the data should reveal\n   - what changed before and after the workflow\n4. Ground Rudder scenarios in production-like operator work. Prefer a coherent\n   mix of synthetic records plus sanitized real scenario patterns from Rudder\n   development, release, support, growth, and agent-ops work over generic SaaS\n   examples.\n5. Define entities and relationships before writing rows.\n6. Add time, status, priority, budget, ownership, and failure signals where they\n   make the scenario clearer.\n7. Choose the output form:\n   - live seed command\n   - TypeScript seed script\n   - JSON fixture\n   - CSV\n   - SQL inserts\n   - Markdown scenario brief\n8. Include usage notes and reset notes.\n\n## Output Shape\n\nFor non-trivial requests, structure the answer like this:\n\n```markdown\n## Scenario\n- Intent:\n- User story:\n- Target surface:\n- Data shape:\n\n## Entities\n- ...\n\n## States Covered\n- ...\n\n## Seed Ledger\n- Target runtime:\n- Created or modified records:\n- Write method:\n- Proof route\u002Frun\u002Flog:\n- Cleanup status:\n\n## Output\n...\n\n## Usage\n...\n```\n\nFor code or fixture outputs, include deterministic IDs when useful. For\nscreenshot\u002Fdemo data, prefer readable names and dense but believable state over\nopaque generated IDs.\n\n## Rudder-Specific Rules\n\n- Keep organization boundaries explicit. Every Rudder entity that belongs to an\n  organization should have a clear org owner.\n- Keep entities relationally coherent: org -> goals -> projects -> issues ->\n  agents, approvals, chats, heartbeat runs, costs, and activity.\n- For whole-product user scenarios, prefer a causal scenario spine over\n  component-specific fixtures. Start from real work records, then let Calendar,\n  Dashboard, Messenger, approvals, and cost views reflect those records.\n- When the user wants \"Rudder Studio\", \"using Rudder to build Rudder\", a\n  month-long realistic org, or Calendar data that should emerge from real agent\n  work, use `references\u002Frudder-studio-scenario.md` and the Rudder Studio\n  fixture files instead of inventing a new one-off org.\n- For screenshots, make data visually legible across pages. Avoid empty shells.\n- For product screenshots, seed the underlying run\u002Foutput evidence too: dashboards,\n  agent detail pages, Calendar, Messenger, and charts should be downstream of\n  coherent issues, heartbeat runs, run logs, comments, approvals, costs, and\n  calendar events instead of isolated component fixtures.\n- For screenshot and demo requests, prefer Desktop-shell capture when the\n  product claim is about the installed app, local operator workflow, or\n  production-like Rudder use. Browser capture is acceptable for narrow web UI\n  checks, but the final dataset should still work inside the Desktop shell.\n- Dashboard, Calendar, and agent run screenshots must include non-empty\n  transcript\u002Foutput evidence. If a seeded page would show empty transcript,\n  empty run output, or decorative calendar-only blocks, treat the seed as\n  incomplete.\n- Capture flows must validate the specific screenshot surface before claiming\n  success. Use selectors and content assertions for the meaningful records on\n  each page, and fail or report blocked if the page is empty, stale, or showing\n  the wrong scenario.\n- For testing, include deterministic setup and reset strategy.\n- For workflow explanation, include persona, motivation, conflict, decision\n  point, and outcome.\n- For live `prod_local` or Desktop demo org seeds, target selection is part of\n  the data task. Verify the active runtime and database before writing; stale\n  config defaults are not enough.\n- Whole-org demo seeds should prefer API creation for the organization, then\n  scoped database insertion for richer downstream evidence if the API surface is\n  incomplete.\n- If the user asks for actual landing screenshots, use this skill's bundled\n  `scripts\u002Fcapture-landing-proof-shots.ts` after selecting the scenario. Do not\n  route to a separate landing-proof skill.\n\n## Live Rudder Instance Seed Rules\n\nWhen seeding data into a running Rudder instance, verify the target before any\nwrite.\n\n1. Confirm the live API target with `\u002Fapi\u002Fhealth`.\n   - For prod Desktop or local production data, require `localEnv=prod_local`\n     and `instanceId=default`.\n   - For dev data, require `localEnv=dev` and `instanceId=dev`.\n2. Do not trust stale config files alone. Prefer live runtime descriptors,\n   `\u002Fapi\u002Fhealth`, and active process or database connections.\n3. If API creation is available, use it for top-level organization creation so\n   normal service-side defaults, memberships, labels, activity, and policies are\n   applied.\n4. Use direct database writes only for seed entities that do not have complete\n   public API coverage, and keep them scoped to the verified organization id.\n5. If a temporary probe write is needed, name it clearly, record its id, delete\n   it immediately, and verify deletion before continuing.\n6. For destructive reseed, require explicit user authority or create a pending\n   approval record that makes the destructive operation visible in the seeded\n   organization.\n7. Never modify repo source files just to seed live data unless the user\n   explicitly asks for a reusable seed script or fixture.\n\nRequired readback for whole-organization Rudder demo seeds:\n\n- organization appears in `\u002Fapi\u002Forgs`\n- expected agents exist\n- expected goals, projects, and issues exist\n- pending approvals exist when requested\n- chat conversation exists when requested\n- activity log contains representative events\n- heartbeat runs and cost summary exist when requested\n- primary UI route returns 200\n- report organization id, URL key, counts, and verification evidence\n\nFor testing seeds, especially seeds used to prove a workflow fix, include a\nseed and mutation ledger even when the data is temporary:\n\n- target runtime and `\u002Fapi\u002Fhealth` payload or equivalent source of truth\n- organization URL key and id\n- issue, agent, run, approval, comment, cost, activity, or release records\n  created or modified\n- whether each write used public API creation, scoped database insertion, or a\n  script\n- final route URL, run id, screenshot, log, or API readback used for proof\n- cleanup status, or why the seeded records were kept as durable evidence\n\nIf the seed is meant to support a product-proof run, design it around the actor\nand trigger that will exercise the workflow. Do not create isolated rows that\nmake the final page look correct while bypassing the actual operator or agent\npath being reviewed.\n\n## Quality Bar\n\nGood mock data has:\n\n- a coherent story across all records\n- enough density to make UI states meaningful\n- edge states where testing needs them\n- deterministic values where automation needs them\n- plausible names, statuses, timestamps, and amounts\n- no real personal data, real customer secrets, or copied private records\n\nAvoid:\n\n- lorem ipsum rows without relationships\n- generic use-case copy that could describe any SaaS or task board\n- perfect happy-path-only data\n- overfitting to one component when the user needs a whole workflow\n- mixing production-looking secrets into examples\n- changing schema or app behavior just to make mock data easier\n\n## Hand-Off\n\nEnd with the concrete artifact or command the user can use immediately. If the\ndata is meant for local screenshots, include the exact route or local URL to\nopen after seeding. If the data is meant for tests, include the fixture entry\npoint and reset expectation.\n\n## Regression Checks\n\nUse these checks when updating this skill or screenshot\u002Fdemo fixtures:\n\n### Case: Use-case-led Rudder screenshot data\n\nInput: user asks for Rudder screenshots or demo data that should feel like real\noperator work.\n\nExpected behavior: choose Landing Demo Org or Rudder Studio, ground the\nscenario in sanitized Rudder-shaped work, seed issues\u002Fruns\u002Flogs\u002Fcosts\u002Fapprovals\nbefore deriving Dashboard, Calendar, Messenger, and agent-detail views.\n\nMust not: return generic SaaS use cases, isolated component rows, or empty page\nfixtures.\n\n### Case: Desktop-shell product evidence\n\nInput: user needs screenshots proving the installed local Rudder experience.\n\nExpected behavior: prefer Desktop-shell capture or coordinate with the\nscreenshot skill that can capture Desktop shell; browser screenshots are only\nsupporting evidence for narrow route checks.\n\nMust not: present browser-only proof as sufficient for a Desktop product claim.\n\n### Case: Prod Desktop demo org seed\n\nInput: user asks to create a new organization in prod using a source document as\ninitialization data.\n\nExpected behavior: verify `\u002Fapi\u002Fhealth` reports `localEnv=prod_local` and\n`instanceId=default`; create the organization through the API when possible;\nseed scoped relational data for agents, goals, projects, issues, approvals,\nchats, activity, runs, costs, and calendar evidence as requested; validate API\nreadback and the primary UI route; report the organization id, URL key, counts,\nand verification evidence.\n\nMust not: write to the dev database, rely only on stale config ports, leave\ntemporary probe records behind, or claim success from database counts without\nAPI readback.\n\n### Case: Existing demo org collision\n\nInput: user asks to reseed an organization that may already exist.\n\nExpected behavior: detect existing organizations by name, URL key, and issue\nprefix; classify the operation as additive or destructive; require explicit\nauthority or create a pending approval record before replacing existing seeded\nrecords; keep all changes scoped to the verified target organization.\n\nMust not: silently duplicate organizations, overwrite existing data without a\nvisible approval or explicit instruction, or use a matching issue prefix in the\nwrong runtime.\n\n### Case: Static fixture only\n\nInput: user asks for a JSON, SQL, CSV, or Markdown fixture and says not to write\nto local Rudder.\n\nExpected behavior: produce the requested static artifact and include usage or\nreset notes when relevant.\n\nMust not: call the Rudder API, connect to a database, create probe records, or\nmutate prod or dev state.\n\n### Case: Screenshot capture validation\n\nInput: a capture script or manual flow saves Dashboard, Calendar, chat,\napproval, or agent run screenshots.\n\nExpected behavior: assert page selectors plus scenario-specific text and\nnon-empty transcript\u002Foutput evidence before declaring success.\n\nMust not: silently save screenshots when the page loaded but the scenario data,\nrun output, transcript, or Calendar work history is missing.\n",{"name":5,"description":7},"main","26d5d68bcbc55caeac1dc6a266d973e8c3831f1c",".agents\u002Fskills\u002Fmaintainer\u002Fmock-data-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 mock-data-maintainer",{"tool":64,"command":65},"bunx","bunx skills add Undertone0809\u002Frudder --skill mock-data-maintainer",{"tool":67,"command":68},"pnpm","pnpm dlx skills add Undertone0809\u002Frudder --skill mock-data-maintainer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-maintainer\u002FSKILL.md",true,[72,78,82,86,90,94,98,102,106,110,114,118,122,126,130,134,138,144],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"data\u002Frudder-studio\u002Fagents.json","REFERENCE","参考文档",3011,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-maintainer\u002Fdata\u002Frudder-studio\u002Fagents.json",{"path":79,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":80,"sourceHtmlUrl":81},"data\u002Frudder-studio\u002Fapprovals.json",2810,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-maintainer\u002Fdata\u002Frudder-studio\u002Fapprovals.json",{"path":83,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":84,"sourceHtmlUrl":85},"data\u002Frudder-studio\u002Fcalendar.json",2588,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-maintainer\u002Fdata\u002Frudder-studio\u002Fcalendar.json",{"path":87,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":88,"sourceHtmlUrl":89},"data\u002Frudder-studio\u002Fchats.json",2774,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-maintainer\u002Fdata\u002Frudder-studio\u002Fchats.json",{"path":91,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":92,"sourceHtmlUrl":93},"data\u002Frudder-studio\u002Fissues.json",21215,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-maintainer\u002Fdata\u002Frudder-studio\u002Fissues.json",{"path":95,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":96,"sourceHtmlUrl":97},"data\u002Frudder-studio\u002Fscenario.json",5127,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-maintainer\u002Fdata\u002Frudder-studio\u002Fscenario.json",{"path":99,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":100,"sourceHtmlUrl":101},"references\u002Fedge-states.md",1152,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-maintainer\u002Freferences\u002Fedge-states.md",{"path":103,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":104,"sourceHtmlUrl":105},"references\u002Fgeneric-crm-sales.md",1085,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-maintainer\u002Freferences\u002Fgeneric-crm-sales.md",{"path":107,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":108,"sourceHtmlUrl":109},"references\u002Fgeneric-saas-dashboard.md",1215,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-maintainer\u002Freferences\u002Fgeneric-saas-dashboard.md",{"path":111,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":112,"sourceHtmlUrl":113},"references\u002Fquality-bar.md",4142,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-maintainer\u002Freferences\u002Fquality-bar.md",{"path":115,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":116,"sourceHtmlUrl":117},"references\u002Frudder-landing-demo-org.md",5658,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-maintainer\u002Freferences\u002Frudder-landing-demo-org.md",{"path":119,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":120,"sourceHtmlUrl":121},"references\u002Frudder-studio-scenario.md",6392,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-maintainer\u002Freferences\u002Frudder-studio-scenario.md",{"path":123,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":124,"sourceHtmlUrl":125},"references\u002Frudder-test-fixtures.md",2205,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-maintainer\u002Freferences\u002Frudder-test-fixtures.md",{"path":127,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":128,"sourceHtmlUrl":129},"references\u002Frudder-user-scenarios.md",3671,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-maintainer\u002Freferences\u002Frudder-user-scenarios.md",{"path":131,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":132,"sourceHtmlUrl":133},"references\u002Frunbook.md",13339,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-maintainer\u002Freferences\u002Frunbook.md",{"path":135,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":136,"sourceHtmlUrl":137},"references\u002Fscenario-index.md",2279,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-maintainer\u002Freferences\u002Fscenario-index.md",{"path":139,"resourceType":140,"resourceTypeDesc":141,"sizeBytes":142,"sourceHtmlUrl":143},"scripts\u002Fcapture-landing-proof-shots.ts","SCRIPT","脚本",70501,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-maintainer\u002Fscripts\u002Fcapture-landing-proof-shots.ts",{"path":145,"resourceType":140,"resourceTypeDesc":141,"sizeBytes":146,"sourceHtmlUrl":147},"scripts\u002Fseed-rudder-studio.ts",34309,"https:\u002F\u002Fgithub.com\u002FUndertone0809\u002Frudder\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmaintainer\u002Fmock-data-maintainer\u002Fscripts\u002Fseed-rudder-studio.ts",[149,162,175,200,229,255],{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":155,"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",[],[156,157,158,159,160,161],"Synthesis","source","source synthesis","concise","synthesize","evidence",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":173,"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",[168],{"categoryNo":169,"categoryName":170,"taxonomyType":171,"taxonomyTypeDesc":172},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[174,161,164],"research",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":182,"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",[181],{"categoryNo":169,"categoryName":170,"taxonomyType":171,"taxonomyTypeDesc":172},[183,184,174,185,186,187,158,29,188,189,190,191,192,193,194,195,196,197,198,199],"deep research","deep","state","debugging","triggers","with","multi","compare","verification","scoring","Art","reports","analyze","analysis","pipeline","Enterprise","examples",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":209,"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",[206],{"categoryNo":207,"categoryName":208,"taxonomyType":171,"taxonomyTypeDesc":172},"01JBSEEDCAT000000000000009","前端开发",[202,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228],"static","inline","chart","scenario","access","geometry","map","message","compact","back","never","node","mermaid","network","create","diagram","safe","css","markdown",{"skillNo":230,"name":231,"nameZh":6,"description":232,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":233,"categories":234,"keywords":238,"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",[235],{"categoryNo":236,"categoryName":237,"taxonomyType":171,"taxonomyTypeDesc":172},"01JBSEEDCAT000000000000023","Skill与智能体开发",[239,240,241,242,243,244,245,246,29,247,248,249,250,34,251,252,196,253,254,224],"skill creator","creator","run evals","performance","variance analysis","existing skill","Existing","accuracy","From Scratch","users","optimize","evals","edit","improve","benchmark","run",{"skillNo":256,"name":257,"nameZh":6,"description":258,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":259,"categories":260,"keywords":261,"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",[],[262,263,264,157,265,266,267,268,269,270,271,272,273,274,275,276,277,278,224,279],"rudder docs","docs","context","interface","hire","creation","commands","active","do","contracts","ask","work","coding","configure","how","Tools","actions","tasks"]