{"owner":"risingwavelabs","repo":"risingwave","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# Coding Agent Instructions for RisingWave\n\n## Project Overview\n\nRisingWave is a Postgres-compatible streaming database that offers the simplest and most cost-effective way to process, analyze, and manage real-time event data — with built-in support for the Apache Iceberg™ open table format.\n\nRisingWave components are developed in Rust and split into several crates:\n\n1. `config` - Default configurations for servers\n2. `prost` - Generated protobuf rust code (grpc and message definitions)\n3. `stream` - Stream compute engine\n4. `batch` - Batch compute engine for queries against materialized views\n5. `frontend` - SQL query planner and scheduler\n6. `storage` - Cloud native storage engine\n7. `meta` - Meta engine\n8. `utils` - Independent util crates\n9. `cmd` - All binaries, `cmd_all` contains the all-in-one binary `risingwave`\n10. `risedevtool` - Developer tool for RisingWave\n\n## Coding Style\n\n- Always write code comments in English.\n- Write simple, easy-to-read and easy-to-maintain code.\n- Use `cargo fmt` to format the code if needed.\n- Follow existing code patterns and conventions in the repository.\n\n## Build, Run, Test\n\nYou may need to learn how to build and test RisingWave when implementing features or fixing bugs.\n\n### Build & Check\n\n- Use `./risedev b` to build the project.\n- Use `./risedev c` to check if the code follow rust-clippy rules, coding styles, etc.\n- After changing config definitions or defaults under `src/common/src/config`, run `./risedev generate-example-config` to update `src/config/example.toml` and `src/config/docs.md`.\n\n### Unit Test\n\n- Integration tests and unit tests are valid Rust/Tokio tests, you can locate and run those related in a standard Rust way.\n- Parser tests: use `./risedev update-parser-test` to regenerate expected output.\n- Planner tests: use `./risedev run-planner-test [name]` to run and `./risedev do-apply-planner-test` (or `./risedev dapt`) to update expected output.\n\n### End-to-End Test\n\n- Use `./risedev d` to run a RisingWave instance in the background via tmux.\n  - It builds RisingWave binaries if necessary. The build process can take up to 10 minutes, depending on the incremental build results. Use a large timeout for this step, and be patient.\n  - It kills the previous instance, if exists.\n  - Optionally pass a profile name (see `risedev.yml` and for local profile see `risedev-profiles.user.yml`) to choose external services or components. By default it uses `default`.\n  - This runs in the background so you do not need a separate terminal.\n  - You can connect right after the command finishes.\n  - Logs are written to files in `.risingwave/log` folder.\n- Use `./risedev k` to stop a RisingWave instance started by `./risedev d`.\n- Only when a RisingWave instance is running, you can use `./risedev psql -c \"<your query>\"` to run SQL queries in RW.\n- Only when a RisingWave instance is running, you can use `./risedev slt './path/to/e2e-test-file.slt'` to run end-to-end SLT tests.\n  - File globs like `/**/*.slt` is allowed.\n  - Failed run may leave some objects in the database that interfere with next run. Use `./risedev slt-clean ./path/to/e2e-test-file.slt` to reset the database before running tests.\n- The preferred way to write tests is to write tests in SQLLogicTest format.\n- Tests are put in `./e2e_test` folder.\n\n### Sandbox escalation\n\nWhen sandboxing is enabled, these commands need `require_escalated` because they bind or connect to local TCP sockets:\n\n- `./risedev d` and `./risedev p` (uses local ports and tmux sockets)\n- `./risedev psql ...` or direct `psql -h localhost -p 4566 ...` (local TCP connection)\n- `./risedev slt './path/to/e2e-test-file.slt'` (connects to local TCP via psql protocol)\n- Any command that checks running services via local TCP (for example, health checks or custom SQL clients)\n\n## Pull Request Submission Labels\n\nPR labels in this repository can affect CI coverage and documentation follow-up. To keep normal coding work lightweight, load the detailed label protocol only at PR submission time.\n\nWhen opening or updating a pull request, changing PR labels, or marking a PR ready for review:\n\n1. Read `.agents/PR_LABELING.md`.\n2. Inspect the current PR labels and draft state before adding anything:\n   `gh pr view <PR> --json isDraft,labels,title,body,files`\n3. Add only validated missing labels. Do not remove labels that existed before the current agent operation unless explicitly instructed by a maintainer. An agent may remove a label it just added if validation shows it was a mistake, but it must report the correction.\n4. In the final PR report, list labels added, labels intentionally not added, local tests run, and CI labels requested.\n\n## Connector Development\n\nSee `docs/dev/src/connector/intro.md`.\n\n## Repo Skills\n\n- Use `$risingwave-rust-analyzer` for RisingWave-specific `rust-analyzer` CLI and LSP workflows, especially when a task needs fast semantic inspection, structural search/replace, or crate-specific feature guidance. Skill path: `.agents/skills/risingwave-rust-analyzer/SKILL.md`.\n- Use `$fix-buildkite-ci` for Buildkite triage and focused CI fixes. Skill path: `.agents/skills/fix-buildkite-ci/SKILL.md`.\n- Use `$risingwave-slt-authoring` when creating, reviewing, or fixing RisingWave SQLLogicTest (`.slt`/`.slt.serial`) files, especially tests with `system ok`, connector fixtures, CI coverage, madsim, or flaky/idempotent behavior. Skill path: `.agents/skills/risingwave-slt-authoring/SKILL.md`.\n"},"files":{"AGENTS.md":"# Coding Agent Instructions for RisingWave\n\n## Project Overview\n\nRisingWave is a Postgres-compatible streaming database that offers the simplest and most cost-effective way to process, analyze, and manage real-time event data — with built-in support for the Apache Iceberg™ open table format.\n\nRisingWave components are developed in Rust and split into several crates:\n\n1. `config` - Default configurations for servers\n2. `prost` - Generated protobuf rust code (grpc and message definitions)\n3. `stream` - Stream compute engine\n4. `batch` - Batch compute engine for queries against materialized views\n5. `frontend` - SQL query planner and scheduler\n6. `storage` - Cloud native storage engine\n7. `meta` - Meta engine\n8. `utils` - Independent util crates\n9. `cmd` - All binaries, `cmd_all` contains the all-in-one binary `risingwave`\n10. `risedevtool` - Developer tool for RisingWave\n\n## Coding Style\n\n- Always write code comments in English.\n- Write simple, easy-to-read and easy-to-maintain code.\n- Use `cargo fmt` to format the code if needed.\n- Follow existing code patterns and conventions in the repository.\n\n## Build, Run, Test\n\nYou may need to learn how to build and test RisingWave when implementing features or fixing bugs.\n\n### Build & Check\n\n- Use `./risedev b` to build the project.\n- Use `./risedev c` to check if the code follow rust-clippy rules, coding styles, etc.\n- After changing config definitions or defaults under `src/common/src/config`, run `./risedev generate-example-config` to update `src/config/example.toml` and `src/config/docs.md`.\n\n### Unit Test\n\n- Integration tests and unit tests are valid Rust/Tokio tests, you can locate and run those related in a standard Rust way.\n- Parser tests: use `./risedev update-parser-test` to regenerate expected output.\n- Planner tests: use `./risedev run-planner-test [name]` to run and `./risedev do-apply-planner-test` (or `./risedev dapt`) to update expected output.\n\n### End-to-End Test\n\n- Use `./risedev d` to run a RisingWave instance in the background via tmux.\n  - It builds RisingWave binaries if necessary. The build process can take up to 10 minutes, depending on the incremental build results. Use a large timeout for this step, and be patient.\n  - It kills the previous instance, if exists.\n  - Optionally pass a profile name (see `risedev.yml` and for local profile see `risedev-profiles.user.yml`) to choose external services or components. By default it uses `default`.\n  - This runs in the background so you do not need a separate terminal.\n  - You can connect right after the command finishes.\n  - Logs are written to files in `.risingwave/log` folder.\n- Use `./risedev k` to stop a RisingWave instance started by `./risedev d`.\n- Only when a RisingWave instance is running, you can use `./risedev psql -c \"<your query>\"` to run SQL queries in RW.\n- Only when a RisingWave instance is running, you can use `./risedev slt './path/to/e2e-test-file.slt'` to run end-to-end SLT tests.\n  - File globs like `/**/*.slt` is allowed.\n  - Failed run may leave some objects in the database that interfere with next run. Use `./risedev slt-clean ./path/to/e2e-test-file.slt` to reset the database before running tests.\n- The preferred way to write tests is to write tests in SQLLogicTest format.\n- Tests are put in `./e2e_test` folder.\n\n### Sandbox escalation\n\nWhen sandboxing is enabled, these commands need `require_escalated` because they bind or connect to local TCP sockets:\n\n- `./risedev d` and `./risedev p` (uses local ports and tmux sockets)\n- `./risedev psql ...` or direct `psql -h localhost -p 4566 ...` (local TCP connection)\n- `./risedev slt './path/to/e2e-test-file.slt'` (connects to local TCP via psql protocol)\n- Any command that checks running services via local TCP (for example, health checks or custom SQL clients)\n\n## Pull Request Submission Labels\n\nPR labels in this repository can affect CI coverage and documentation follow-up. To keep normal coding work lightweight, load the detailed label protocol only at PR submission time.\n\nWhen opening or updating a pull request, changing PR labels, or marking a PR ready for review:\n\n1. Read `.agents/PR_LABELING.md`.\n2. Inspect the current PR labels and draft state before adding anything:\n   `gh pr view <PR> --json isDraft,labels,title,body,files`\n3. Add only validated missing labels. Do not remove labels that existed before the current agent operation unless explicitly instructed by a maintainer. An agent may remove a label it just added if validation shows it was a mistake, but it must report the correction.\n4. In the final PR report, list labels added, labels intentionally not added, local tests run, and CI labels requested.\n\n## Connector Development\n\nSee `docs/dev/src/connector/intro.md`.\n\n## Repo Skills\n\n- Use `$risingwave-rust-analyzer` for RisingWave-specific `rust-analyzer` CLI and LSP workflows, especially when a task needs fast semantic inspection, structural search/replace, or crate-specific feature guidance. Skill path: `.agents/skills/risingwave-rust-analyzer/SKILL.md`.\n- Use `$fix-buildkite-ci` for Buildkite triage and focused CI fixes. Skill path: `.agents/skills/fix-buildkite-ci/SKILL.md`.\n- Use `$risingwave-slt-authoring` when creating, reviewing, or fixing RisingWave SQLLogicTest (`.slt`/`.slt.serial`) files, especially tests with `system ok`, connector fixtures, CI coverage, madsim, or flaky/idempotent behavior. Skill path: `.agents/skills/risingwave-slt-authoring/SKILL.md`.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Coding Agent Instructions for RisingWave\n\n## Project Overview\n\nRisingWave is a Postgres-compatible streaming database that offers the simplest and most cost-effective way to process, analyze, and manage real-time event data — with built-in support for the Apache Iceberg™ open table format.\n\nRisingWave components are developed in Rust and split into several crates:\n\n1. `config` - Default configurations for servers\n2. `prost` - Generated protobuf rust code (grpc and message definitions)\n3. `stream` - Stream compute engine\n4. `batch` - Batch compute engine for queries against materialized views\n5. `frontend` - SQL query planner and scheduler\n6. `storage` - Cloud native storage engine\n7. `meta` - Meta engine\n8. `utils` - Independent util crates\n9. `cmd` - All binaries, `cmd_all` contains the all-in-one binary `risingwave`\n10. `risedevtool` - Developer tool for RisingWave\n\n## Coding Style\n\n- Always write code comments in English.\n- Write simple, easy-to-read and easy-to-maintain code.\n- Use `cargo fmt` to format the code if needed.\n- Follow existing code patterns and conventions in the repository.\n\n## Build, Run, Test\n\nYou may need to learn how to build and test RisingWave when implementing features or fixing bugs.\n\n### Build & Check\n\n- Use `./risedev b` to build the project.\n- Use `./risedev c` to check if the code follow rust-clippy rules, coding styles, etc.\n- After changing config definitions or defaults under `src/common/src/config`, run `./risedev generate-example-config` to update `src/config/example.toml` and `src/config/docs.md`.\n\n### Unit Test\n\n- Integration tests and unit tests are valid Rust/Tokio tests, you can locate and run those related in a standard Rust way.\n- Parser tests: use `./risedev update-parser-test` to regenerate expected output.\n- Planner tests: use `./risedev run-planner-test [name]` to run and `./risedev do-apply-planner-test` (or `./risedev dapt`) to update expected output.\n\n### End-to-End Test\n\n- Use `./risedev d` to run a RisingWave instance in the background via tmux.\n  - It builds RisingWave binaries if necessary. The build process can take up to 10 minutes, depending on the incremental build results. Use a large timeout for this step, and be patient.\n  - It kills the previous instance, if exists.\n  - Optionally pass a profile name (see `risedev.yml` and for local profile see `risedev-profiles.user.yml`) to choose external services or components. By default it uses `default`.\n  - This runs in the background so you do not need a separate terminal.\n  - You can connect right after the command finishes.\n  - Logs are written to files in `.risingwave/log` folder.\n- Use `./risedev k` to stop a RisingWave instance started by `./risedev d`.\n- Only when a RisingWave instance is running, you can use `./risedev psql -c \"<your query>\"` to run SQL queries in RW.\n- Only when a RisingWave instance is running, you can use `./risedev slt './path/to/e2e-test-file.slt'` to run end-to-end SLT tests.\n  - File globs like `/**/*.slt` is allowed.\n  - Failed run may leave some objects in the database that interfere with next run. Use `./risedev slt-clean ./path/to/e2e-test-file.slt` to reset the database before running tests.\n- The preferred way to write tests is to write tests in SQLLogicTest format.\n- Tests are put in `./e2e_test` folder.\n\n### Sandbox escalation\n\nWhen sandboxing is enabled, these commands need `require_escalated` because they bind or connect to local TCP sockets:\n\n- `./risedev d` and `./risedev p` (uses local ports and tmux sockets)\n- `./risedev psql ...` or direct `psql -h localhost -p 4566 ...` (local TCP connection)\n- `./risedev slt './path/to/e2e-test-file.slt'` (connects to local TCP via psql protocol)\n- Any command that checks running services via local TCP (for example, health checks or custom SQL clients)\n\n## Pull Request Submission Labels\n\nPR labels in this repository can affect CI coverage and documentation follow-up. To keep normal coding work lightweight, load the detailed label protocol only at PR submission time.\n\nWhen opening or updating a pull request, changing PR labels, or marking a PR ready for review:\n\n1. Read `.agents/PR_LABELING.md`.\n2. Inspect the current PR labels and draft state before adding anything:\n   `gh pr view <PR> --json isDraft,labels,title,body,files`\n3. Add only validated missing labels. Do not remove labels that existed before the current agent operation unless explicitly instructed by a maintainer. An agent may remove a label it just added if validation shows it was a mistake, but it must report the correction.\n4. In the final PR report, list labels added, labels intentionally not added, local tests run, and CI labels requested.\n\n## Connector Development\n\nSee `docs/dev/src/connector/intro.md`.\n\n## Repo Skills\n\n- Use `$risingwave-rust-analyzer` for RisingWave-specific `rust-analyzer` CLI and LSP workflows, especially when a task needs fast semantic inspection, structural search/replace, or crate-specific feature guidance. Skill path: `.agents/skills/risingwave-rust-analyzer/SKILL.md`.\n- Use `$fix-buildkite-ci` for Buildkite triage and focused CI fixes. Skill path: `.agents/skills/fix-buildkite-ci/SKILL.md`.\n- Use `$risingwave-slt-authoring` when creating, reviewing, or fixing RisingWave SQLLogicTest (`.slt`/`.slt.serial`) files, especially tests with `system ok`, connector fixtures, CI coverage, madsim, or flaky/idempotent behavior. Skill path: `.agents/skills/risingwave-slt-authoring/SKILL.md`.\n","category":"root","tokens":1365}]}