一键导入
bundle-checklist
Show a quick reference checklist for Hydrolix bundle configuration. Use when the user needs a quick reminder of bundle configuration patterns.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Show a quick reference checklist for Hydrolix bundle configuration. Use when the user needs a quick reminder of bundle configuration patterns.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Bulk-delete ephemeral test projects on a Hydrolix cluster (default pattern `bundle_verification_*`, produced by the Rust validator's `--guid` flag). Lists matching projects, confirms with the user, then deletes sequentially. Use when the user wants to clean up leftover GUID test projects, or projects matching a name prefix, on a cluster.
Ingest N rows of realistic test data into any Hydrolix table. Automatically finds the transform's sample_data from bundle files, sets timestamps distributed across a given date range, and handles all authentication variants (JWT-only or JWT + table ingest token). Use whenever the user wants to populate a table with test data, seed data for dashboard testing, ingest sample events, or run ingestion tests on any cluster. Trigger on phrases like "ingestar datos de prueba", "ingest sample data", "populate table", "seed the table", "datos de testing", "quiero datos en la tabla", "ingestar en la tabla".
Validate Hydrolix transforms for a project before pushing to the cluster. Runs local schema validation (catches invalid datatype names like "float" that only fail at push time) and API validation (catches SQL errors and sample_data ingestion issues). Use before any hdx push, or standalone when the user wants to check transforms, verify datatype correctness, or pre-flight a deployment. Trigger on phrases like "validate transforms", "check transforms", "verify datatypes", "pre-flight validation".
Create a new project on a Hydrolix cluster and apply any bundle from latest_versions.yaml to it, including Grafana org and dashboards. Trigger when user wants to create a project + apply a bundle on any cluster.
Reset a previously-configured bundle to raw state so CI can re-run the full pipeline. Restores originals, removes pipeline-generated files, and pushes for CI. Use when a bundle needs to be re-processed through automation after pipeline or validator changes.
Commit, push, and open a PR for the current branch. If the PR targets hydrolix/integration-deployment-templates, also sends a Slack notification to
| name | bundle-checklist |
| description | Show a quick reference checklist for Hydrolix bundle configuration. Use when the user needs a quick reminder of bundle configuration patterns. |
| user-invocable | true |
When configuring a Hydrolix integration bundle:
source/bundle_name/
├── bundle.json ← CREATE THIS
├── dashboards/
│ ├── primary_dashboard.json ← FIX: wrapper, UID, vars (NO PREFIX)
│ ├── other_dashboard_1.json ← FIX: wrapper, UID, vars (WITH PREFIX)
│ └── other_dashboard_2.json ← FIX: wrapper, UID, vars (WITH PREFIX)
├── summaries/
│ ├── summary1.sql ← FIX: hardcoded tables → __PROJECT_NAME__.__TABLE_NAME__
│ └── summary2.sql ← FIX: hardcoded tables → __PROJECT_NAME__.__TABLE_NAME__
├── transformations/
│ ├── transform.json
│ └── sample_data.json
└── functions/
├── function1.json
└── function2.json
{"dashboard": { ... }}"uid": "__DASHBOARD_UUID__"${VAR_TIMESTAMP} with timestamp__PROJECT_NAME__.__TABLE_NAME__"query": "__SUMMARY_TABLE_NAME_1__"
NO __PROJECT_NAME__. prefix!
"query": "__PROJECT_NAME__.__SUMMARY_TABLE_NAME_1__"
WITH __PROJECT_NAME__. prefix!
❌ Wrong: Primary dashboard with prefix
"query": "__PROJECT_NAME__.__SUMMARY_TABLE_NAME_1__"
Result: project.project.summary_table (duplicated!)
✅ Correct: Primary dashboard without prefix
"query": "__SUMMARY_TABLE_NAME_1__"
Result: project.summary_table
❌ Wrong: Other dashboard without prefix
"query": "__SUMMARY_TABLE_NAME_1__"
Result: summary_table (missing project!)
✅ Correct: Other dashboard with prefix
"query": "__PROJECT_NAME__.__SUMMARY_TABLE_NAME_1__"
Result: project.summary_table
| What | Primary | Other | Why Different? |
|---|---|---|---|
| Tables | __PROJECT_NAME__.__TABLE_NAME__ | __PROJECT_NAME__.__TABLE_NAME__ | Same for both |
| Summary Tables | __SUMMARY_TABLE_NAME_X__ | __PROJECT_NAME__.__SUMMARY_TABLE_NAME_X__ | Different processing in validator |
{
"dashboard": {
"path": "dashboards/PRIMARY.json" ← Choose main dashboard
},
"other_dashboards": [
{"path": "dashboards/OTHER1.json"},
{"path": "dashboards/OTHER2.json"}
],
"tables": [{
"dashboard_var": "__TABLE_NAME__",
"name": "actual_table_name"
}],
"summary_tables": [{
"dashboard_var": "__SUMMARY_TABLE_NAME_1__",
"name": "actual_summary_name",
"parent_table_name": "parent_table",
"sql": {"path": "summaries/file.sql"}
}],
"ui": {
"source": {
"full_title": "UNIQUE_NAME" ← Must be unique!
}
}
}
After configuration:
# Validate bundle
cd integration-deployment-templates
cargo run -- validate source/bundle_name
# Deploy bundle (if validation passes)
cargo run -- deploy source/bundle_name
Error: Table _local.summary_table does not exist
__PROJECT_NAME__. prefixError: Table project.project.summary_table does not exist
__PROJECT_NAME__. prefix (should not!)Error: Syntax error: failed at position X ('WHERE')
${VAR_*} variables replaced with proper templatesError: failed at position X ('$')
${VAR_*} variables still in dashboardFor full guided process, use: /configure-bundle [path]