skills/greptimedb-flow/SKILL.md
Guide for creating GreptimeDB flow tasks — continuous aggregation that updates a sink table on the fly as data is ingested. Use when the user asks to build a materialized view, continuous aggregation, stream computation, downsampling job, or rollup. Triggers on phrases like "create flow", "continuous aggregation", "连续聚合", "物化视图", "materialized view", "downsampling", "流式聚合", "time window aggregation".
npx skillsauth add greptimeteam/docs greptimedb-flowInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Create GreptimeDB flow definition to do time window based aggregation on the fly while data ingested into GreptimeDB. This is how GreptimeDB's lightweight streaming engine works.
Flow is also known as:
To create GreptimeDB flow task, we should follow these phases:
First, we read GreptimeDB flow definitions and how it works from the documentation.
There are doc pages available, use WebFetch to load and understand them:
We should try to understand:
Create the flow and sink table DDL.
Strongly recommend providing an explicit CREATE TABLE for the sink
table alongside CREATE FLOW. Flow will auto-create the sink table if it
does not exist, but manual creation keeps full control over:
TIME INDEX is typically the column produced by the time
window function (e.g. date_bin(...) AS time_window).update_at column — the Flow engine automatically appends the update
time to the end of each computation result row. The sink table schema must
include an update_at column.PRIMARY KEY to declare tag columns; together
with the time index they form the unique key the Flow engine uses to
insert or update rows.Minimal example:
CREATE TABLE temp_alerts (
sensor_id INT,
loc STRING,
max_temp DOUBLE,
time_window TIMESTAMP TIME INDEX,
update_at TIMESTAMP,
PRIMARY KEY(sensor_id, loc)
);
CREATE FLOW temp_monitoring
SINK TO temp_alerts
AS
SELECT
sensor_id,
loc,
max(temperature) AS max_temp,
date_bin('10 seconds'::INTERVAL, ts) AS time_window
FROM temp_sensor_data
GROUP BY sensor_id, loc, time_window
HAVING max_temp > 100;
Use CREATE OR REPLACE FLOW to update an existing flow (only the flow
definition is replaced; source and sink tables are untouched). Use
CREATE FLOW IF NOT EXISTS for idempotent creation. The two clauses
cannot be combined — pick one based on intent.
EXPIRE AFTERFor any stateful aggregation (GROUP BY, windowed aggregates), decide how far back in time the flow engine should still update results when new data arrives.
CREATE FLOW IF NOT EXISTS my_flow
SINK TO my_sink_table
EXPIRE AFTER '1 hour'::INTERVAL
AS
SELECT ...;
EXPIRE AFTER is a boundary: rows whose time index is older than the given
interval are considered out of scope — the time windows they fall into are
no longer updated even if late data arrives. It is a performance knob that
keeps the flow running without putting too much pressure on the frontend,
not an in-memory state limiter.
Important caveats:
TTL option if you also want physical data expiration.EXPIRE AFTER, every historical row remains eligible for
recomputation whenever new data arrives; for high-volume source tables
this creates significant load on the frontend.If greptimedb-mcp-server is available, we can use its execute_sql tools to
execute the DDL. Try to generate some sample data, insert into source table,
then verify the sink table via SQL SELECT statements. We can use MySQL style
SELECT statements on GreptimeDB for most cases.
development
[Enterprise only] Guide for creating GreptimeDB Triggers — periodic evaluation rules (SQL or TQL/PromQL via TQL EVAL) that fire Alertmanager-compatible webhooks when conditions are met. Use as an alternative to Prometheus alerting rules, or to host existing PromQL alerts on GreptimeDB. Triggers on phrases like "create trigger", "alerting rule", "告警规则", "trigger webhook", "alertmanager 对接", "migrate prometheus alerts", "promql alert".
devops
Guide for creating a GreptimeDB Pipeline — a processing layer between ingestion and storage that parses, transforms, indexes, and optionally routes log data. Use when the user asks to create a pipeline, parse logs, transform fields, write a pipeline YAML, dryrun a pipeline, or fan out logs to multiple tables. Triggers on phrases like "create pipeline", "解析日志", "log parsing", "transform fields", "GreptimeDB pipeline yaml", "dryrun pipeline", "dispatcher 分流", "VRL processor".
development
Maintainer-only workflow for handling GitHub Secret Scanning alerts on OpenClaw. Use when Codex needs to triage, redact, clean up, and resolve secret leakage found in issue comments, issue bodies, PR comments, or other GitHub content.
development
Maintainer workflow for OpenClaw releases, prereleases, changelog release notes, and publish validation. Use when Codex needs to prepare or verify stable or beta release steps, align version naming, assemble release notes, check release auth requirements, or validate publish-time commands and artifacts.