mock-data-maintainer

Name: mock-data-maintainer
Author: Undertone0809

247stars30forks

How to install mock-data-maintainer?

undertone0809/rudder/mock-data-maintainer

$npx -y skills add Undertone0809/rudder --skill mock-data-maintainer

Installs into the current project.

Summary

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.

Files · 1

View on GitHub

SKILL.md

1	# Mock Data Maintainer
2
3	Use this skill to create mock data that is useful, coherent, and easy to reuse.
4	The goal is not random fake records. The goal is scenario data that supports
5	testing, screenshots, demos, and clear user understanding.
6
7	## First Decision
8
9	Classify the request into one primary intent before generating data:
10
11	1. testing data: local dev, E2E, bug reproduction, contract checks, edge states
12	2. screenshot/demo data: local screenshots, landing proof shots, README, decks
13	3. user-scenario data: explain a workflow, persona, problem, or product value
14	4. static artifact data: CSV, JSON, SQL, Markdown table, or TypeScript fixture
15
16	If the prompt implies multiple intents, produce one shared scenario spine and
17	then adapt outputs for each intent. For example, one Rudder launch-week org can
18	serve local screenshots, workflow explanation, and E2E fixture design.
19
20	## Reference Selection
21
22	Read only the references needed for the request:
23
24	- `references/scenario-index.md`: scenario catalog and selection rules
25	- `references/quality-bar.md`: realism, determinism, privacy, and output rules
26	- `references/rudder-studio-scenario.md`: canonical month-long "Rudder uses
27	Rudder to build and grow Rudder" org, with reusable JSON fixtures and seed
28	script
29	- `references/rudder-landing-demo-org.md`: canonical screenshot-ready Rudder org
30	- `references/rudder-test-fixtures.md`: Rudder testing and edge-state fixtures
31	- `references/rudder-user-scenarios.md`: Rudder user stories and scenario spines
32	- `references/generic-saas-dashboard.md`: SaaS metrics, billing, and ops data
33	- `references/generic-crm-sales.md`: CRM, pipeline, account, and support data
34	- `references/edge-states.md`: empty, error, boundary, permission, and conflict states
35
36	## Bundled Scripts
37
38	Use bundled scripts when the user needs live Rudder data instead of static
39	records:
40
41	- `scripts/capture-landing-proof-shots.ts`: boots an isolated Rudder instance,
42	seeds the canonical landing demo org, and optionally captures proof-shot
43	screenshots. Use `LANDING_SHOTS_SKIP_CAPTURE=1 LANDING_SHOTS_HOLD_OPEN=1`
44	for seed-only local screenshot prep.
45	- `scripts/seed-rudder-studio.ts`: seeds the reusable Rudder Studio org into a
46	running local dev instance. Use it when the user wants a realistic month-long
47	Rudder org, "using Rudder to build Rudder", natural Calendar work history,
48	or durable user-scenario data.
49
50	Prefer these scripts over rewriting the seed flow in a one-off answer.
51
52	## Default Workflow
53
54	1. Identify the data intent and target surface.
55	2. Pick or combine scenarios from the reference catalog.
56	3. Define the scenario spine:
57	- who the user/persona is
58	- what they are trying to do
59	- what conflict, risk, or decision the data should reveal
60	- what changed before and after the workflow
61	4. Ground Rudder scenarios in production-like operator work. Prefer a coherent
62	mix of synthetic records plus sanitized real scenario patterns from Rudder
63	development, release, support, growth, and agent-ops work over generic SaaS
64	examples.
65	5. Define entities and relationships before writing rows.
66	6. Add time, status, priority, budget, ownership, and failure signals where they
67	make the scenario clearer.
68	7. Choose the output form:
69	- live seed command
70	- TypeScript seed script
71	- JSON fixture
72	- CSV
73	- SQL inserts
74	- Markdown scenario brief
75	8. Include usage notes and reset notes.
76
77	## Output Shape
78
79	For non-trivial requests, structure the answer like this:
80
81	```markdown
82	## Scenario
83	- Intent:
84	- User story:
85	- Target surface:
86	- Data shape:
87
88	## Entities
89	- ...
90
91	## States Covered
92	- ...
93
94	## Seed Ledger
95	- Target runtime:
96	- Created or modified records:
97	- Write method:
98	- Proof route/run/log:
99	- Cleanup status:
100
101	## Output
102	...
103
104	## Usage
105	...
106	```
107
108	For code or fixture outputs, include deterministic IDs when useful. For
109	screenshot/demo data, prefer readable names and dense but believable state over
110	opaque generated IDs.
111
112	## Rudder-Specific Rules
113
114	- Keep organization boundaries explicit. Every Rudder entity that belongs to an
115	organization should have a clear org owner.
116	- Keep entities relationally coherent: org -> goals -> projects -> issues ->
117	agents, approvals, chats, heartbeat runs, costs, and activity.
118	- For whole-product user scenarios, prefer a causal scenario spine over
119	component-specific fixtures. Start from real work records, then let Calendar,
120	Dashboard, Messenger, approvals, and cost views reflect those records.
121	- When the user wants "Rudder Studio", "using Rudder to build Rudder", a
122	month-long realistic org, or Calendar data that should emerge from real agent
123	work, use `references/rudder-studio-scenario.md` and the Rudder Studio
124	fixture files instead of inventing a new one-off org.
125	-

People who liked this also viewed

6 picks

Type

mock-data-maintainer

247stars30forks

View on GitHub

How to install mock-data-maintainer?

undertone0809/rudder/mock-data-maintainer

$npx -y skills add Undertone0809/rudder --skill mock-data-maintainer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Mock Data Maintainer
2
3	Use this skill to create mock data that is useful, coherent, and easy to reuse.
4	The goal is not random fake records. The goal is scenario data that supports
5	testing, screenshots, demos, and clear user understanding.
6
7	## First Decision
8
9	Classify the request into one primary intent before generating data:
10
11	1. testing data: local dev, E2E, bug reproduction, contract checks, edge states
12	2. screenshot/demo data: local screenshots, landing proof shots, README, decks
13	3. user-scenario data: explain a workflow, persona, problem, or product value
14	4. static artifact data: CSV, JSON, SQL, Markdown table, or TypeScript fixture
15
16	If the prompt implies multiple intents, produce one shared scenario spine and
17	then adapt outputs for each intent. For example, one Rudder launch-week org can
18	serve local screenshots, workflow explanation, and E2E fixture design.
19
20	## Reference Selection
21
22	Read only the references needed for the request:
23
24	- `references/scenario-index.md`: scenario catalog and selection rules
25	- `references/quality-bar.md`: realism, determinism, privacy, and output rules
26	- `references/rudder-studio-scenario.md`: canonical month-long "Rudder uses
27	Rudder to build and grow Rudder" org, with reusable JSON fixtures and seed
28	script
29	- `references/rudder-landing-demo-org.md`: canonical screenshot-ready Rudder org
30	- `references/rudder-test-fixtures.md`: Rudder testing and edge-state fixtures
31	- `references/rudder-user-scenarios.md`: Rudder user stories and scenario spines
32	- `references/generic-saas-dashboard.md`: SaaS metrics, billing, and ops data
33	- `references/generic-crm-sales.md`: CRM, pipeline, account, and support data
34	- `references/edge-states.md`: empty, error, boundary, permission, and conflict states
35
36	## Bundled Scripts
37
38	Use bundled scripts when the user needs live Rudder data instead of static
39	records:
40
41	- `scripts/capture-landing-proof-shots.ts`: boots an isolated Rudder instance,
42	seeds the canonical landing demo org, and optionally captures proof-shot
43	screenshots. Use `LANDING_SHOTS_SKIP_CAPTURE=1 LANDING_SHOTS_HOLD_OPEN=1`
44	for seed-only local screenshot prep.
45	- `scripts/seed-rudder-studio.ts`: seeds the reusable Rudder Studio org into a
46	running local dev instance. Use it when the user wants a realistic month-long
47	Rudder org, "using Rudder to build Rudder", natural Calendar work history,
48	or durable user-scenario data.
49
50	Prefer these scripts over rewriting the seed flow in a one-off answer.
51
52	## Default Workflow
53
54	1. Identify the data intent and target surface.
55	2. Pick or combine scenarios from the reference catalog.
56	3. Define the scenario spine:
57	- who the user/persona is
58	- what they are trying to do
59	- what conflict, risk, or decision the data should reveal
60	- what changed before and after the workflow
61	4. Ground Rudder scenarios in production-like operator work. Prefer a coherent
62	mix of synthetic records plus sanitized real scenario patterns from Rudder
63	development, release, support, growth, and agent-ops work over generic SaaS
64	examples.
65	5. Define entities and relationships before writing rows.
66	6. Add time, status, priority, budget, ownership, and failure signals where they
67	make the scenario clearer.
68	7. Choose the output form:
69	- live seed command
70	- TypeScript seed script
71	- JSON fixture
72	- CSV
73	- SQL inserts
74	- Markdown scenario brief
75	8. Include usage notes and reset notes.
76
77	## Output Shape
78
79	For non-trivial requests, structure the answer like this:
80
81	```markdown
82	## Scenario
83	- Intent:
84	- User story:
85	- Target surface:
86	- Data shape:
87
88	## Entities
89	- ...
90
91	## States Covered
92	- ...
93
94	## Seed Ledger
95	- Target runtime:
96	- Created or modified records:
97	- Write method:
98	- Proof route/run/log:
99	- Cleanup status:
100
101	## Output
102	...
103
104	## Usage
105	...
106	```
107
108	For code or fixture outputs, include deterministic IDs when useful. For
109	screenshot/demo data, prefer readable names and dense but believable state over
110	opaque generated IDs.
111
112	## Rudder-Specific Rules
113
114	- Keep organization boundaries explicit. Every Rudder entity that belongs to an
115	organization should have a clear org owner.
116	- Keep entities relationally coherent: org -> goals -> projects -> issues ->
117	agents, approvals, chats, heartbeat runs, costs, and activity.
118	- For whole-product user scenarios, prefer a causal scenario spine over
119	component-specific fixtures. Start from real work records, then let Calendar,
120	Dashboard, Messenger, approvals, and cost views reflect those records.
121	- When the user wants "Rudder Studio", "using Rudder to build Rudder", a
122	month-long realistic org, or Calendar data that should emerge from real agent
123	work, use `references/rudder-studio-scenario.md` and the Rudder Studio
124	fixture files instead of inventing a new one-off org.
125	-

People who liked this also viewed

6 picks

Type