/gh-pull-request
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.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/gh-pull-request
Context 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.
SKILL.md
gh-pull-request.SKILL.mdname: 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
Creating a Pull Request for SkyWalking BanyanDB
Branch Rules
**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>
Local Checks Before Creating PR
Run these checks locally before pushing. They mirror the CI `check` job and PR-blocking tests in `.github/workflows/ci.yml`.
Required: Code Generation and Build
make generate
make build
Required: Linting and Formatting
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.
Required: License Headers
make license-check
All source files must have Apache 2.0 license headers.
Required: Update CHANGES.md
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.).
Unit Tests
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/...
Integration Tests
Run these after unit tests pass:
make test-ci PKG=./test/integration/standalone/...
make test-ci PKG=./test/integration/distributed/...
Checks NOT Practical Locally
These run in CI only — no need to run locally:
- **e2e tests** — require Docker + OAP stack (90 min timeout)
- **fodc-e2e tests** — require Kind Kubernetes cluster
- **dependency-review** — GitHub-specific action
- **slow/flaky/property-repair tests** — scheduled, not PR-blocking
Common issues
- **`make lint` fails with field alignment errors**: The linter reports structs with suboptimal field ordering (e.g. `fieldalignment: struct with X pointer bytes could be Y`). Fix them automatically with:
~/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.
- **`make lint` fails with formatting errors**: Run `make format` to auto-fix, then re-run `make lint` to confirm.
- **Test timeout**: Integration tests can be slow; add `TEST_CI_OPTS="--timeout 60m"` if they time out
- **Missing tools**: `make check-req` will tell you what's missing
- **`make lint` or `make check` fails with `buf: not found`**: Install `buf` automatically by running `make -C api generate`, then retry.
- **`make build` fails**: Check if generated files are up to date with `make generate`
Creating the PR
git push -u origin <branch-name>
gh pr create --title "<title>" --body "<body>"
Follow the standard PR format with a summary and test plan.
Read more
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
Creating a Pull Request for SkyWalking BanyanDB
Branch Rules
**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>
Local Checks Before Creating PR
Run these checks locally before pushing. They mirror the CI `check` job and PR-blocking tests in `.github/workflows/ci.yml`.
Required: Code Generation and Build
make generate make build
Required: Linting and Formatting
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.
Required: License Headers
make license-check
All source files must have Apache 2.0 license headers.
Required: Update CHANGES.md
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.).
Unit Tests
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/...
Integration Tests
Run these after unit tests pass:
make test-ci PKG=./test/integration/standalone/... make test-ci PKG=./test/integration/distributed/...
Checks NOT Practical Locally
These run in CI only — no need to run locally:
- **e2e tests** — require Docker + OAP stack (90 min timeout)
- **fodc-e2e tests** — require Kind Kubernetes cluster
- **dependency-review** — GitHub-specific action
- **slow/flaky/property-repair tests** — scheduled, not PR-blocking
Common issues
- **`make lint` fails with field alignment errors**: The linter reports structs with suboptimal field ordering (e.g. `fieldalignment: struct with X pointer bytes could be Y`). Fix them automatically with:
~/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.
- **`make lint` fails with formatting errors**: Run `make format` to auto-fix, then re-run `make lint` to confirm.
- **Test timeout**: Integration tests can be slow; add `TEST_CI_OPTS="--timeout 60m"` if they time out
- **Missing tools**: `make check-req` will tell you what's missing
- **`make lint` or `make check` fails with `buf: not found`**: Install `buf` automatically by running `make -C api generate`, then retry.
- **`make build` fails**: Check if generated files are up to date with `make generate`
Creating the PR
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
Other skills on banyandb-bydbql.
- /bydbql
Generate, validate, and optionally execute read-only BanyanDB BydbQL for STREAM, MEASURE, TRACE, and PROPERTY resources. Use when the user asks to query BanyanDB, translate natural language to BydbQL, inspect BanyanDB schema or data, validate BydbQL, or fetch raw BanyanDB
Open skill - /compiling
Compile and build the SkyWalking BanyanDB project. Use when the user asks to compile, build, or generate code for this project.
Open skill - /vendor-update
Upgrade Go/Node.js vendor dependencies and sync tool versions. Use whenever the user says "upgrade dependencies", "update vendors", "vendor update", "run vendor-upgrade", "bump dependencies", "update packages", or asks to run the `vendor-update` Make target. This skill also
Open skill