mit einem Klick
clickhouse-pr-description
// Generate PR descriptions for ClickHouse/ClickHouse that match maintainer expectations. Use when creating or updating PR descriptions.
// Generate PR descriptions for ClickHouse/ClickHouse that match maintainer expectations. Use when creating or updating PR descriptions.
Create a ClickHouse git worktree with submodules hardlinked from the main repo. Use when the user wants to create a new worktree for ClickHouse development.
Review a ClickHouse Pull Request for correctness, safety, performance, and compliance. Use when the user wants to review a PR or diff.
Continue work on an existing PR - resolve conflicts, fix CI failures, address reviewer feedback, and push updates. Use when the user wants to pick up and advance a pull request.
Analyze ClickHouse Keeper stress-test results from play.clickhouse.com / keeper_stress_tests data warehouse. Use whenever the user asks about Keeper performance, validates Keeper PRs against stress dashboards, investigates regressions or improvements in Keeper nightlies, asks about specific date windows / SHAs / PR-sets in Keeper stress tests, wants per-PR or window-vs-window comparisons, asks "did this PR break Keeper", asks "what changed in Keeper between dates", or wants a summary report of Keeper stress runs. Triggers on terms like "keeper stress", "keeper PR", "keeper p99", "keeper memory", "keeper rps", "keeper nightly", "keeper-stress-tests", "keeper validation", "keeper regression", or any question referencing the keeper-stress Grafana dashboard. ALWAYS prefer this skill over re-deriving the workflow from scratch — it captures hard-learned lessons about cgroup-vs-Keeper memory, bench-harness confounds, noise floors, and per-PR attribution limits.
Audit open "flaky test" GitHub issues and close those whose tests are no longer failing on master. Cross-references CI history from play.clickhouse.com with git log to attribute fixes.
Edit an auto-generated ClickHouse release changelog into the form that gets committed to CHANGELOG.md. Use when the user has the output of `utils/changelog/changelog.py` and wants it cleaned up and re-categorized for a release.
| name | clickhouse-pr-description |
| description | Generate PR descriptions for ClickHouse/ClickHouse that match maintainer expectations. Use when creating or updating PR descriptions. |
| argument-hint | [PR-number or branch-name] |
| disable-model-invocation | false |
| allowed-tools | Task, Bash(gh:*), Bash(git:*), Read, Glob, Grep, AskUserQuestion |
Generate a good PR description and apply it, with optional confirmation based on user preference.
Plain description of what changed. No prefix conventions like fix(): or feat():.
Exception — .claude/ changes: when the PR only touches files under .claude/ (settings, tools, skills, instructions, etc.), prefix the title with claude: . Example: claude: add fetch_ci_report.js to allowed commands.
Change default stderr_reaction to log_last for executable UDFsFix exception when inserting NULL into non-nullable column via CASTclaude: allow fetch_ci_report.js and grep in Claude Code settingsfix(udf): Change default stderr_reaction — conventional commits, ClickHouse doesn't use themFuzzer fixes — too vague, tells the reviewer nothingImprove error handling and enrich exit code exceptions with stderr context — too vague, doesn't say what was actually changedRead .github/PULL_REQUEST_TEMPLATE.md for the exact template structure.
A good PR description has two parts:
1. Free-form context (above the template, optional but encouraged for non-trivial changes)
Explain to a future reader: what was the problem, why did it need fixing, what approach was taken, what were the results or trade-offs. This is the right place for:
Use plain paragraphs. Headers like ## Motivation, ## Changes, ## Results are fine and helpful — they make the PR easier to navigate for reviewers. Bullet lists are fine. Be as detailed as needed.
2. Template section (mandatory)
Fill in the changelog category (delete the rest of the list) and write the changelog entry when the selected category requires one.
From #96110:
### Changelog category (leave one):
- Backward Incompatible Change
### Changelog entry:
The semantics of the `do_not_merge_across_partitions_select_final` setting were
made more obvious. Previously, the feature could be automatically enabled when
the setting was not explicitly set in the configs. It caused confusion repeatedly
and, unfortunately, led to some issues in production. Now, the rules are simpler:
`do_not_merge_across_partitions_select_final=1` enables the functionality
unconditionally. If `do_not_merge_across_partitions_select_final=0`, then automatic
is used only if the new setting
`enable_automatic_decision_for_merging_across_partitions_for_final=1` and not used
otherwise. To preserve the old behaviour as much as possible, the defaults were set
to `do_not_merge_across_partitions_select_final=0` and
`enable_automatic_decision_for_merging_across_partitions_for_final=1`.
---
The backward-incompatible part is that if someone has
`do_not_merge_across_partitions_select_final=0` explicitly set in the configs,
it no longer protects against the use of automatics. I'm open to discussion on
whether we should conservatively default to disabled automatics.
Note: extra context after --- is fine — reviewers see it, but only the changelog entry above the blank line goes into the CHANGELOG.
The entry is what ends up in the published CHANGELOG. Write it for a user who is upgrading and scanning for what affects them. The PR link and author attribution are appended automatically by tooling — do not include them.
Format: the changelog script (tests/ci/changelog.py) collects all lines after the ### Changelog entry: header up to the first blank line, then joins them with spaces into a single string. This means:
Tense: mixed is fine and natural. "Added X", "Fix a case where...", "The X setting is now Y" are all real examples from the CHANGELOG. Don't force everything into present tense.
Length: match the impact. A small new function can be one sentence. A changed default or backward-incompatible behavior warrants as many sentences as needed, including what users must do to adapt.
Specificity: always name the exact thing that changed. Never write "Fix a bug" or "Improve performance" without saying what specifically.
For backward-incompatible changes: always explain the old behavior, the new behavior, and how to restore the old one if possible.
Real examples from the ClickHouse CHANGELOG:
One sentence, sufficient for a focused addition:
Add
xxh3_128hashing function.
One sentence with enough context:
DATEcolumns from PostgreSQL are now inferred asDate32in ClickHouse (in previous versions they were inferred asDate, which led to overflow of values outside a narrow range). Allow insertingDate32values back to PostgreSQL.
Full migration instructions for a default change:
Deduplication is turned ON for all inserts by default. It was OFF before for async inserts and for MV's, but it was ON for sync inserts. The goal is to have the same defaults for both ways of inserts. If you have deduplication explicitly disabled on your cluster, you have to explicitly set
deduplicate_insert='backward_compatible_choice'to keep the old behavior.
Describes new capability with enough detail to understand when to use it:
Added
OPTIMIZE <table> DRY RUN PARTS <part names>query to simulate merges without committing the result part. It may be useful for testing purposes: verifying merge correctness in the new version, deterministically reproducing merge-related bugs, and reliably benchmarking merge performance.
Reference the issue if one exists: Closes #XXXXX or Fixes #XXXXX at the end.
These patterns make PRs harder to read or signal low effort:
fix(scope): / feat(): / chore(): — ClickHouse doesn't use conventional commitsThis PR ... to start any section — just describe the changeFuzzer fixes, Fix bug, Improvements — always say what specificallyIt's fine to mention AI assistance openly. Co-Authored-By: in commits or acknowledgements in the PR description are acceptable — ClickHouse is open about AI-assisted development.
Before creating or updating the PR, check user memory for a confirmation preference. If no preference is stored and the session is interactive, ask once: "Should I always show you the description for approval before applying it, or just go ahead every time?" Save the answer to memory and apply it from then on. If the session is non-interactive, proceed directly without asking.
If the current repository is a fork (i.e. git remote get-url origin does not contain ClickHouse/ClickHouse), always target the upstream repository. Pass --repo ClickHouse/ClickHouse to gh pr create and set --head <fork-owner>:<branch> so the PR is opened against the canonical repo, not the fork.