create-kit

Name: create-kit
Author: rustyrazorblade

40stars7forks

How to install create-kit?

rustyrazorblade/skills/create-kit

$npx -y skills add rustyrazorblade/skills --skill create-kit

Installs into the current project.

Summary

Create a new easy-db-lab kit (kit.yaml + K8s manifests, metrics, dashboards, docs) for any database or workload. Detects internal (the easy-db-lab repo) vs external (your own project) mode, researches the workload, grounds the work in a per-kit TODO.md, drafts for review, and wri

Files · 1

View on GitHub

SKILL.md

1	# create-kit
2
3	Author a new easy-db-lab kit — a self-contained package (`kit.yaml` + manifest
4	templates + dashboards + docs) that installs, starts, stops, and observes a database or
5	workload on an easy-db-lab cluster. No Kotlin is required; kits register dynamically from
6	their `kit.yaml`.
7
8	This skill works for both:
9	- Internal kit development — inside the easy-db-lab repository (`src/main/resources/.../kits/`).
10	- External kit development — a kit that lives in your own project and is registered with
11	`easy-db-lab kit source add`.
12
13	The skill detects which mode applies and adapts paths and the schema source accordingly.
14
15	## Input
16
17	The argument after `/create-kit` is the workload name (e.g. "ScyllaDB", "Kafka", "Redis").
18	An optional second argument is the output path. If no workload name is given, ask for one.
19
20	---
21
22	## Step 0 — Detect mode and resolve paths
23
24	Check whether the current directory is the easy-db-lab repository:
25
26	```bash
27	test -d src/main/resources/com/rustyrazorblade/easydblab/kits && echo INTERNAL \|\| echo EXTERNAL
28	```
29
30	Internal mode (the path exists):
31	- Kit directory: `src/main/resources/com/rustyrazorblade/easydblab/kits/<name>/`
32	- Authoritative schema source: read the local files
33	`docs/development/kits.md` and `src/main/kotlin/com/rustyrazorblade/easydblab/services/KitConfig.kt`.
34	They are version-matched to this checkout — trust them over the cheat-sheet below.
35
36	External mode (the path does not exist):
37	- Kit directory: `./kits/<name>/` by default. If the user passed an output path, use it.
38	The kit's parent directory (`./kits`) is what gets registered with `kit source add`.
39	- Authoritative schema source: `WebFetch` the published guide
40	`https://rustyrazorblade.github.io/easy-db-lab/development/kits.html`
41	whenever you need anything beyond the cheat-sheet below. (Repo:
42	`https://github.com/rustyrazorblade/easy-db-lab/`.)
43
44	`<name>` is the kebab-case kit name. State the detected mode and resolved kit directory to
45	the user before proceeding.
46
47	---
48
49	## Step 1 — Research the workload
50
51	Use WebSearch and/or context7 to determine:
52
53	- The canonical Helm chart (repo URL, chart name, current stable version), or an operator/CRD
54	that must be installed first (operator chart → then the custom resource).
55	- The primary Kubernetes resource kind the workload creates (`StatefulSet`, `Deployment`, or a
56	custom CR) and the readiness condition to wait on (pod labels, conditions).
57	- Whether the workload is stateful (needs `platform-pvs` for local storage) or stateless.
58	- Metrics: does it expose a Prometheus endpoint? Port and path? Or is it JVM-based
59	(OTel/Pyroscope java agent), or does the chart ship its own OTLP pipeline (`helm-native`)?
60	- Endpoints / wire protocols: what ports clients connect on (HTTP, JDBC, native, CQL,
61	PostgreSQL/MySQL wire), and whether it exposes a SQL interface (declare the `sql` capability
62	so bench kits like sysbench can target it).
63	- JVM?: if yes, plan Pyroscope java-agent injection in the `start` phase.
64	- Integration with existing kits: does this workload need a backing store or data source
65	another kit provides (e.g. Temporal needs PostgreSQL/Cassandra; Trino/Presto register catalogs
66	for ClickHouse/Cassandra/TiDB)? Or is it a bench/consumer kit that targets a running database?
67	Check `easy-db-lab kit list` / the kits dir for what already exists, then pick a wiring
68	mechanism (see Integrating with other kits below).
69
70	Summarize findings in 3–5 bullets — including the recommended `metrics.type`, whether
71	Pyroscope injection is needed, and any cross-kit integration — before grounding the work.
72
73	### Integrating with other kits
74
75	Three mechanisms wire kits together — pick by the relationship:
76
77	- kit-ref arg (`--target`) — a kit that targets a user-chosen running kit (bench/consumer
78	kits). Declare `{ flag: --target, variable: TARGET, type: kit-ref, capability: sql }`. At
79	start, `KitEndpointResolver` reads the target kit's endpoints and injects `TARGET_*` env vars
80	(`TARGET_PG_HOST/PORT/USER/DATABASE`, `TARGET_JDBC_URL`, `TARGET_MYSQL_HOST`, …) into every
81	phase; the installed dir becomes `<kit>-<target>`. Reference: `sysbench`.
82	- Hooks (`post-workload-start` / `post-workload-stop`) — a kit that reacts when another
83	kit starts or stops (e.g. registering a connector/catalog). Optionally scope with
84	`workloads: [postgres, clickhouse]` (the YAML field is `workloads`, not `kits`); omit to fire
85	fo

People who liked this also viewed

6 picks

Type

create-kit

40stars7forks

View on GitHub

How to install create-kit?

rustyrazorblade/skills/create-kit

$npx -y skills add rustyrazorblade/skills --skill create-kit

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# create-kit
2
3	Author a new easy-db-lab kit — a self-contained package (`kit.yaml` + manifest
4	templates + dashboards + docs) that installs, starts, stops, and observes a database or
5	workload on an easy-db-lab cluster. No Kotlin is required; kits register dynamically from
6	their `kit.yaml`.
7
8	This skill works for both:
9	- Internal kit development — inside the easy-db-lab repository (`src/main/resources/.../kits/`).
10	- External kit development — a kit that lives in your own project and is registered with
11	`easy-db-lab kit source add`.
12
13	The skill detects which mode applies and adapts paths and the schema source accordingly.
14
15	## Input
16
17	The argument after `/create-kit` is the workload name (e.g. "ScyllaDB", "Kafka", "Redis").
18	An optional second argument is the output path. If no workload name is given, ask for one.
19
20	---
21
22	## Step 0 — Detect mode and resolve paths
23
24	Check whether the current directory is the easy-db-lab repository:
25
26	```bash
27	test -d src/main/resources/com/rustyrazorblade/easydblab/kits && echo INTERNAL \|\| echo EXTERNAL
28	```
29
30	Internal mode (the path exists):
31	- Kit directory: `src/main/resources/com/rustyrazorblade/easydblab/kits/<name>/`
32	- Authoritative schema source: read the local files
33	`docs/development/kits.md` and `src/main/kotlin/com/rustyrazorblade/easydblab/services/KitConfig.kt`.
34	They are version-matched to this checkout — trust them over the cheat-sheet below.
35
36	External mode (the path does not exist):
37	- Kit directory: `./kits/<name>/` by default. If the user passed an output path, use it.
38	The kit's parent directory (`./kits`) is what gets registered with `kit source add`.
39	- Authoritative schema source: `WebFetch` the published guide
40	`https://rustyrazorblade.github.io/easy-db-lab/development/kits.html`
41	whenever you need anything beyond the cheat-sheet below. (Repo:
42	`https://github.com/rustyrazorblade/easy-db-lab/`.)
43
44	`<name>` is the kebab-case kit name. State the detected mode and resolved kit directory to
45	the user before proceeding.
46
47	---
48
49	## Step 1 — Research the workload
50
51	Use WebSearch and/or context7 to determine:
52
53	- The canonical Helm chart (repo URL, chart name, current stable version), or an operator/CRD
54	that must be installed first (operator chart → then the custom resource).
55	- The primary Kubernetes resource kind the workload creates (`StatefulSet`, `Deployment`, or a
56	custom CR) and the readiness condition to wait on (pod labels, conditions).
57	- Whether the workload is stateful (needs `platform-pvs` for local storage) or stateless.
58	- Metrics: does it expose a Prometheus endpoint? Port and path? Or is it JVM-based
59	(OTel/Pyroscope java agent), or does the chart ship its own OTLP pipeline (`helm-native`)?
60	- Endpoints / wire protocols: what ports clients connect on (HTTP, JDBC, native, CQL,
61	PostgreSQL/MySQL wire), and whether it exposes a SQL interface (declare the `sql` capability
62	so bench kits like sysbench can target it).
63	- JVM?: if yes, plan Pyroscope java-agent injection in the `start` phase.
64	- Integration with existing kits: does this workload need a backing store or data source
65	another kit provides (e.g. Temporal needs PostgreSQL/Cassandra; Trino/Presto register catalogs
66	for ClickHouse/Cassandra/TiDB)? Or is it a bench/consumer kit that targets a running database?
67	Check `easy-db-lab kit list` / the kits dir for what already exists, then pick a wiring
68	mechanism (see Integrating with other kits below).
69
70	Summarize findings in 3–5 bullets — including the recommended `metrics.type`, whether
71	Pyroscope injection is needed, and any cross-kit integration — before grounding the work.
72
73	### Integrating with other kits
74
75	Three mechanisms wire kits together — pick by the relationship:
76
77	- kit-ref arg (`--target`) — a kit that targets a user-chosen running kit (bench/consumer
78	kits). Declare `{ flag: --target, variable: TARGET, type: kit-ref, capability: sql }`. At
79	start, `KitEndpointResolver` reads the target kit's endpoints and injects `TARGET_*` env vars
80	(`TARGET_PG_HOST/PORT/USER/DATABASE`, `TARGET_JDBC_URL`, `TARGET_MYSQL_HOST`, …) into every
81	phase; the installed dir becomes `<kit>-<target>`. Reference: `sysbench`.
82	- Hooks (`post-workload-start` / `post-workload-stop`) — a kit that reacts when another
83	kit starts or stops (e.g. registering a connector/catalog). Optionally scope with
84	`workloads: [postgres, clickhouse]` (the YAML field is `workloads`, not `kits`); omit to fire
85	fo

People who liked this also viewed

6 picks

Type