ワンクリックで
kwdb-schema-design
Design KWDB schemas and minimal DDL for relational, time-series, and mixed workloads.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Design KWDB schemas and minimal DDL for relational, time-series, and mixed workloads.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
KaiwuDB 数据库源码编译和构建技能。用于从源码构建、编译或测试 KaiwuDB (KWDB)。使用 CMake 构建系统处理构建配置、单元测试、代码检查和安装。触发条件:(1) 编译询问:"编译 KaiwuDB"、"构建 kwdbts2"、"cmake 构建"、"清理构建";(2) C++ 单元测试询问:"C++ 单元测试"、"运行C++单元测试"、"run C++ unittest";(3) Go 单元测试询问:"golang 单元测试"、"Go 单元测试"、"run golang test"。重要:执行任何操作前必须向用户确认所有配置选项,不得跳过询问步骤。
Automates end-to-end anomaly detection for time-series data stored in KaiwuDB / KWDB. Use this skill whenever the user mentions: - anomaly detection, outliers, or unusual patterns in KWDB / KaiwuDB time-series data - inspecting sensor metrics, IoT telemetry, or monitoring data for spikes, dips, or drift - "find anomalies", "detect outliers", "3-sigma check", "STL decomposition", or "time-series anomaly" - analyzing historical trends, abnormal points, or data quality issues in TS tables Even if the user does not explicitly say "anomaly", trigger this skill when they ask to inspect, validate, or flag unusual values in time-series columns (integer, float, double).
Optimize SQL query performance for KaiwuDB time-series and relational engines. Covers: EXPLAIN analysis, time-series optimization, pagination, cross-model queries. Trigger keywords: optimize query, slow query, explain, execution plan, performance, 性能, 查询优化. NOT for: DDL, schema design, deployment, DML writes.
Use when diagnosing KWDB incidents from logs, metrics, or system evidence, especially crashes, OOM, slow SQL, restarts, and cluster-wide availability symptoms.
Run KaiwuDB inspection and health-check tasks. Use this skill for database health checks, metrics collection, anomaly detection, and inspection report generation.
Describe what the skill does and when it should trigger.
| name | kwdb-schema-design |
| description | Design KWDB schemas and generate DDL for relational, time-series, and mixed workloads. Covers: CREATE/ALTER/DROP TABLE, INDEX, VIEW, constraints, partitioning, retention, tags. Trigger keywords: KWDB, schema, table, index, time-series, sensor, IoT, metrics, TAGS, PRIMARY TAGS, RETENTIONS, primary key, foreign key, DDL. NOT for: DML queries, deployment, backup, performance tuning. |
| version | 0.4.1 |
This applies even when:
Reading reference files directly ≠ Skill invocation. The Skill tool triggers the complete workflow (classify → gather requirements → design → DDL → validate) and ensures guardrails are followed. Skip this step = skip the workflow.
Tier 1 (Always Read) - Core rules, scope, and examples:
references/key-rules.md - Decision tree and core rulesreferences/disambiguation.md - Clarifying questionsreferences/_scope.md - Skill boundaries (IN/OUT of scope)references/_examples.md - Complete dialogue examplesreferences/_contributing.md - How to add new referencesreferences/_sections.md - Tier definitions and categoriesTier 2 (High-Frequency DDL) - Read when designing tables/indexes/constraints:
references/table-ddl-ref.md - CREATE/ALTER/DROP TABLEreferences/index-ddl-ref.md - CREATE/DROP INDEXreferences/constraint-ref.md - CHECK, UNIQUE, FOREIGN KEYTier 3 (Medium-Frequency DDL) - Read when needed:
references/view-ref.md - Views and Materialized Viewsreferences/sequence-ref.md - Sequences and auto-incrementreferences/partitioning-ref.md - LIST, RANGE, HASH partitioningreferences/retention-ref.md - Time-series retention policiesTier 4 (Low-Frequency DDL) - Only when explicitly requested:
references/trigger-ref.md - Triggersreferences/procedure-ref.md - Stored procedures and functionsreferences/database-ref.md - Database and schema operationsreferences/privilege-ref.md - User, role, and permission managementShould trigger (explicit KWDB):
Should trigger (implicit - schema keywords):
Should trigger (time-series keywords):
Should trigger (relational keywords):
Should trigger (financial/trading keywords):
Should NOT trigger:
| Category | Operations |
|---|---|
| Tables | CREATE TABLE, ALTER TABLE, DROP TABLE |
| Indexes | CREATE INDEX, ALTER INDEX, DROP INDEX |
| Constraints | PRIMARY KEY, UNIQUE, CHECK, FOREIGN KEY |
| Views | CREATE VIEW, DROP VIEW |
| Materialized Views | CREATE MATERIALIZED VIEW, REFRESH, DROP |
| Sequences | CREATE SEQUENCE, nextval(), setval() |
| Time-Series | Tags, Primary Tags, Retention |
| Partitioning | LIST, RANGE, HASH (relational), HASHPOINT (time-series) |
Request → RELATIONAL / TIME-SERIES / MIXED
Ask if unclear. Never skip this step.
Use disambiguation.md to ask:
Apply rules from key-rules.md and relevant tier-2/3 references:
Output minimal, executable DDL:
Include validation step:
SHOW CREATE TABLE to verify syntaxSHOW COLUMNS to verify structureSHOW INDEX to verify indexes## Intent
[Brief description of what the schema does]
## Workload Type
[relational / time-series / mixed]
## Assumptions
[Any assumptions made - retention, primary key strategy, etc.]
## Design
[Table structure with column types and rationale]
## DDL
```sql
-- minimal executable DDL
[How to verify the DDL works]
## Guardrails
1. **Never output DDL before classifying workload type**
2. **Never assume retention without stating it** (time-series)
3. **Never create speculative indexes** (label as optional)
4. **Prefer minimal schema** over comprehensive
5. **State all assumptions** when information is incomplete
6. **Validate DDL** before finishing
7. **FK columns must be indexed**
8. **Use appropriate types** (DECIMAL for money, not FLOAT)
## Error Handling
- If requirements unclear: ask clarifying questions first
- If DDL might be wrong: suggest validation steps
- If feature not supported: explain KWDB limitation
- If ambiguous request: classify workload type first