bydbql
Generate, validate, and optionally execute read-only BanyanDB BydbQL for STREAM, MEASURE, TRACE, and PROPERTY resources. Use when the user asks to query…
Create a GitHub pull request for SkyWalking BanyanDB. Use when the user asks to create a PR, submit changes, or open a pull request.
$ npx -y skills add apache/skywalking-banyandb --skill gh-pull-request --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/gh-pull-requestContext preview
The summary Claude sees to decide when to auto-load this skill.
Create a GitHub pull request for SkyWalking BanyanDB. Use when the user asks to create a PR, submit changes, or open a pull request.
name: gh-pull-request description: Create a GitHub pull request for SkyWalking BanyanDB. Use when the user asks to create a PR, submit changes, or open a pull request. allowed-tools: Bash, Read, Grep, Glob
**Always create a PR from a new branch.** Never push directly to `main`. This is the same convention as the main Apache SkyWalking repo (https://github.com/apache/skywalking).
git checkout -b <descriptive-branch-name>
Run these checks locally before pushing. They mirror the CI `check` job and PR-blocking tests in `.github/workflows/ci.yml`.
make generate make build
make lint make check
`make check` verifies formatting (gofumpt), go mod tidy, and ensures no uncommitted generated file diffs.
**Why this order:** `build` must succeed before `lint` so generated code exists. `check` validates consistency after linting.
**After `make lint` passes:** If lint introduced any fixes (e.g. auto-formatting, field alignment corrections), commit those changes before running `make check`. Do NOT update CHANGES.md for these fixup commits — just stage all modified tracked files and commit with a message like `chore: fix lint issues`. Then run `make check` on the clean tree.
make license-check
All source files must have Apache 2.0 license headers.
Add a one-line entry under the current development version section in `CHANGES.md` (at the repo root). Place it under the appropriate subsection (`### Features`, `### Bug Fixes`, etc.).
Run these test packages. Each can run in parallel if the user's machine has enough cores, but it's fine to run them sequentially:
make test-ci PKG=./banyand/... make test-ci PKG=./bydbctl/... make test-ci PKG=./pkg/... make test-ci PKG=./fodc/...
The CI uses these options: `--vv --fail-fast --label-filter \!slow` with coverage flags. For local runs, use a simplified form unless the user asks for full CI parity:
TEST_CI_OPTS="--vv --fail-fast --label-filter \!slow" make test-ci PKG=./banyand/...
Run these after unit tests pass:
make test-ci PKG=./test/integration/standalone/... make test-ci PKG=./test/integration/distributed/...
These run in CI only — no need to run locally:
~/go/bin/fieldalignment -fix ./path/to/package/...
Parse the lint output to find which packages have alignment issues, run `fieldalignment -fix` on those packages, then re-run `make lint` to confirm they're resolved.
git push -u origin <branch-name> gh pr create --title "<title>" --body "<body>"
Follow the standard PR format with a summary and test plan.
BanyanDB, as an observability database, aims to ingest, analyze and store Metrics, Tracing and Logging data. It's designed to handle observability data generated by observability platform and APM system, like Apache SkyWalking etc.
Repo: apache/skywalking-banyandb
Generate, validate, and optionally execute read-only BanyanDB BydbQL for STREAM, MEASURE, TRACE, and PROPERTY resources. Use when the user asks to query…
Compile and build the SkyWalking BanyanDB project. Use when the user asks to compile, build, or generate code for this project.
Size-audit, write, and split BanyanDB issues that somebody else or an automated TDD workflow can implement. Use whenever the user asks to file or revise an…
Upgrade Go/Node.js vendor dependencies and sync tool versions. Use whenever the user says "upgrade dependencies", "update vendors", "vendor update", "run…