docs: add benchmarks page and reproducible benchmark suite by jdx · Pull Request #766 · jdx/hk

jdx · 2026-03-23T12:13:06Z

Summary

Adds a benchmarks documentation page comparing hk vs lefthook vs pre-commit
Creates a reproducible benchmark suite with codegen for a ~210-file synthetic project
Demonstrates hk's key advantage: safe parallel execution via file-level read/write locks
10 linters with overlapping file globs (trailing-whitespace and newlines touch all files)
Highlights check_diff as the fastest fix path unique to hk

Files

benchmark/generate-project.sh — generates synthetic project with JS, Python, JSON, YAML, CSS, MD, and shell files
benchmark/run.sh — hyperfine-based runner with chart generation
benchmark/parallel/ — config files for hk, lefthook, and pre-commit
docs/benchmarks.md — documentation page with methodology and results
docs/.vitepress/config.mts — sidebar entry

Test plan

Run benchmark/generate-project.sh /tmp/hk-bench to verify codegen
Run benchmark/run.sh /tmp/hk-bench to verify benchmarks execute
Review docs/benchmarks.md renders correctly in VitePress

🤖 Generated with Claude Code

Note

Low Risk
Low risk: changes are isolated to new benchmarking scripts/configs and documentation, with no modifications to core hook execution logic. Main risk is repo noise/bloat (committed benchmark outputs and an apparently stray empty scripts/task_1.sh) and the maintenance cost of keeping benchmark numbers current.

Overview
Adds a reproducible benchmarking suite under benchmark/ that generates a large synthetic multi-language repo and runs hyperfine comparisons across hk, lefthook, pre-commit, and prek, exporting JSON results and generating docs/public/benchmark.png plus docs/public/benchmark-data.json.

Introduces benchmark configs for each tool (benchmark/parallel/hk.pkl, lefthook.yml, .pre-commit-config.yaml) targeting overlapping linters (including all-files whitespace/newline fixers) to demonstrate safe parallelism.

Updates docs by adding a new Benchmarks page (dynamic table driven by benchmark-data.json) and a Why hk? explainer, and wires both into the VitePress sidebar.

^{Written by Cursor Bugbot for commit 4dca868. This will update automatically on new commits. Configure here.}

gemini-code-assist · 2026-03-23T12:13:22Z

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a new documentation page and a robust benchmark suite to demonstrate hk's performance advantages over other git hook managers like lefthook and pre-commit. The suite generates a diverse synthetic project and runs multiple linters to showcase hk's efficient parallel execution and file-level locking capabilities, providing clear evidence of its speed and safety.

Highlights

New Benchmarks Documentation: A new documentation page has been added that compares hk against lefthook and pre-commit for git hook management, focusing on performance.
Reproducible Benchmark Suite: A comprehensive and reproducible benchmark suite has been introduced, capable of generating a synthetic project with approximately 210 files across multiple programming languages and running various linters.
Demonstration of hk's Parallel Execution: The benchmarks highlight hk's unique advantage of safe parallel execution through file-level read/write locks, preventing race conditions even with overlapping file globs for linters like trailing-whitespace and newlines.
Fastest Fix Path with check_diff: The check_diff feature of hk is showcased as the fastest fix path, allowing hk to apply diffs directly without needing to run the fixer tools, which is supported by several linters like black, ruff-format, jq, yq, and shfmt.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist

Code Review

This pull request introduces an excellent and comprehensive benchmark suite to compare hk with other tools, along with detailed documentation. The scripts for generating the test project and running the benchmarks are well-structured. My review focuses on ensuring the correctness of the benchmark setup and improving script portability. I've identified a critical issue in the lefthook configuration that would lead to inaccurate results, a bug in the benchmark reporting script, and a couple of opportunities to enhance script portability.

gemini-code-assist · 2026-03-23T12:14:55Z

+    - name: black
+      run: black {staged_files}
+      glob: "*.py"
+    - name: ruff-format
+      run: ruff format --quiet --force-exclude {staged_files}
+      glob: "*.{py,pyi}"
+    - name: ruff-check
+      run: ruff check --force-exclude --fix {staged_files}
+      glob: "*.py"
+    - name: jq
+      run: >
+        for f in {staged_files}; do
+          tmp=$(mktemp); jq . "$f" > "$tmp" && mv "$tmp" "$f";
+        done
+      glob: "*.json"
+    - name: yq
+      run: >
+        for f in {staged_files}; do
+          tmp=$(mktemp); yq eval '.' "$f" > "$tmp" && mv "$tmp" "$f";
+        done
+      glob: "*.{yml,yaml}"
+    - name: shfmt
+      run: shfmt -w {staged_files}
+      glob: "*.{sh,bash}"
+    - name: trailing-whitespace
+      run: sed -i 's/[[:space:]]*$//' {staged_files}
+    - name: newlines
+      run: >
+        for f in {staged_files}; do
+          [ -s "$f" ] && [ -n "$(tail -c 1 "$f")" ] && echo >> "$f";
+        done
+    - name: prettier
+      run: prettier --write {staged_files}
+      glob: "*.{js,ts,css,md}"
+    - name: eslint
+      run: eslint --fix {staged_files}
+      glob: "*.{js,ts}"


There are two issues in this lefthook configuration:

Non-recursive globs (Critical): The glob patterns are not recursive (e.g., *.py only matches files in the root directory). The synthetic project creates files in subdirectories, so these linters will not run on most files. This will lead to incorrect and misleadingly fast benchmark results for lefthook. You should use recursive globs (e.g., **/*.py).

Non-portable sed command (Medium): The sed -i command for trailing-whitespace is not portable and will fail on macOS/BSD systems. Using perl is a more portable alternative.

The suggestion below fixes both issues.

- name: black run: black {staged_files} glob: "**/*.py" - name: ruff-format run: ruff format --quiet --force-exclude {staged_files} glob: "**/*.{py,pyi}" - name: ruff-check run: ruff check --force-exclude --fix {staged_files} glob: "**/*.py" - name: jq run: > for f in {staged_files}; do tmp=$(mktemp); jq . "$f" > "$tmp" && mv "$tmp" "$f"; done glob: "**/*.json" - name: yq run: > for f in {staged_files}; do tmp=$(mktemp); yq eval '.' "$f" > "$tmp" && mv "$tmp" "$f"; done glob: "**/*.{yml,yaml}" - name: shfmt run: shfmt -w {staged_files} glob: "**/*.{sh,bash}" - name: trailing-whitespace run: perl -pi -e 's/[[:space:]]*$//' {staged_files} - name: newlines run: > for f in {staged_files}; do [ -s "$f" ] && [ -n "$(tail -c 1 "$f")" ] && echo >> "$f"; done - name: prettier run: prettier --write {staged_files} glob: "**/*.{js,ts,css,md}" - name: eslint run: eslint --fix {staged_files} glob: "**/*.{js,ts}"

gemini-code-assist · 2026-03-23T12:14:55Z

+            if other_time > 0:
+                speedup = other_time / hk_time
+                if speedup > 1.1:
+                    print(f"{scenarios.keys().__iter__().__next__()}: hk is {speedup:.1f}x faster than {tool}")


There's a bug in how the scenario name is printed in the speedup annotations. scenarios.keys().__iter__().__next__() will always return the first scenario's name. To fix this, you should get the scenario name corresponding to the current loop iteration i.

Suggested change

print(f"{scenarios.keys().__iter__().__next__()}: hk is {speedup:.1f}x faster than {tool}")

print(f"{list(scenarios.keys())[i].replace('\n', ' ')}: hk is {speedup:.1f}x faster than {tool}")

gemini-code-assist · 2026-03-23T12:14:55Z

+        types: [shell]
+      - id: trailing-whitespace
+        name: trailing-whitespace
+        entry: bash -c 'sed -i "s/[[:space:]]*$//" "$@"'


The sed -i command without a backup file extension is not portable and will fail on macOS/BSD systems. For better portability, consider using perl -pi -e which provides consistent in-place editing across different platforms.

entry: perl -pi -e 's/[[:space:]]*$//'

greptile-apps · 2026-03-23T12:18:44Z

Greptile Summary

This PR adds a reproducible benchmarking suite (benchmark/) and two new documentation pages (docs/benchmarks.md, docs/why-hk.md) that showcase hk's parallel, file-locked execution model against lefthook, pre-commit, and prek. The changes are documentation and tooling only — no runtime behavior is affected.

Issues found:

scripts/task_1.sh accidentally committed — a single blank-line file was committed to the repository root's scripts/ directory; it is a stray artifact from the benchmark project generator and should be removed.
docs/benchmarks.md file-count comment is wrong — the Reproducing code block comments "~700 files" but the actual default project size is ~6,000 files.
benchmark/results/no-changes.json is committed but orphaned — run.sh no longer generates this file and it is not shown in the docs or chart. Notably, it contains the one scenario where lefthook (~15 ms) is faster than hk (~77 ms) due to Pkl startup overhead; either documenting this trade-off or removing the stale file would improve transparency.
Inconsistent hk exit codes in staged-changes results — hk exits [0, 0, 1, 1, 1] across five staged runs while all other tools are consistent, hinting at possible stash-state leakage between hyperfine iterations that could skew the reported mean.

Confidence Score: 4/5

Safe to merge after removing the accidental scripts/task_1.sh artifact; remaining issues are documentation/methodology concerns that don't block the merge.
All changes are docs and benchmarking scripts with zero impact on runtime behavior. The one clear bug (scripts/task_1.sh stray artifact) is trivial to fix. The other findings (wrong file-count comment, orphaned no-changes.json, inconsistent exit codes) are transparency/methodology points worth addressing but not blockers.
scripts/task_1.sh (accidental artifact), benchmark/results/no-changes.json (orphaned / omitted scenario)

Important Files Changed

Filename	Overview
scripts/task_1.sh	Single blank-line file accidentally committed to the repo root's scripts/ directory — a leftover artifact from the benchmark project generator that should not be here.
benchmark/run.sh	Hyperfine-based benchmark runner; minor issue with a redundant eval of STAGE_SCRIPT before STAGED_COUNT is computed, and the no-changes benchmark is absent even though its result JSON is committed.
benchmark/results/staged-changes.json	hk's exit codes are inconsistent across the five staged-changes runs ([0, 0, 1, 1, 1]) while all other tools are consistent, suggesting possible stash-state leakage between hyperfine iterations that may skew mean timings.
benchmark/results/no-changes.json	Committed results file that is not regenerated by the current run.sh and not surfaced in the docs; the data shows hk ~5× slower than lefthook in the no-changes scenario (77 ms vs 15 ms), which goes unmentioned.
docs/benchmarks.md	New VitePress benchmarks page with dynamic data loading; one comment in the Reproducing section incorrectly says "~700 files" instead of "~6,000 files".
benchmark/generate-project.sh	Generates a large synthetic multi-language project for benchmarking; straightforward codegen with correct defaults totalling ~6,158 files.
docs/why-hk.md	New documentation page explaining hk's parallel execution model, stash strategy, and comparison with other hook managers; well-written and accurate.
docs/.vitepress/config.mts	Adds two sidebar entries for the new Benchmarks and Why hk? pages; no issues.
benchmark/parallel/hk.pkl	Pkl config for the benchmark's hk run; correctly sets up both a fix-mode pre-commit hook and a check-only hook with appropriate builtins.
benchmark/results/all-files.json	All-files benchmark results; hk shows 3.1s mean vs 20.8s for lefthook and 10.6s for pre-commit/prek. hk exit codes are all 1 (files modified) while lefthook is all 0, which is consistent with each tool's fix-mode semantics.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[benchmark/generate-project.sh] -->|generates ~6,000 files| B[/tmp/hk-bench/]
    B --> C[benchmark/run.sh]
    C -->|hyperfine --prepare| D{Reset repo state}
    D -->|each iteration| E[Run hk / lefthook / pre-commit / prek]
    E --> F[all-files.json]
    E --> G[staged-changes.json]
    C -->|uv run matplotlib| H[docs/public/benchmark.png]
    C -->|json.dump| I[docs/public/benchmark-data.json]
    F --> J[benchmark/results/]
    G --> J
    K[no-changes.json] -.->|committed but not generated by run.sh| J
    I --> L[docs/benchmarks.md]
    H --> L
    L -->|VitePress renders| M[Published Docs Site]

Comments Outside Diff (5)

scripts/task_1.sh, line 1 (link)

Accidental artifact committed to repo root

scripts/task_1.sh (a single blank line) appears to have been accidentally committed to the main repository's scripts/ directory. The benchmark/generate-project.sh script generates scripts/task_*.sh files in the output project directory (e.g., /tmp/hk-bench/scripts/task_1.sh), not in the repo root. This file should be removed from the repository.
docs/benchmarks.md, line 1397 (link)

Incorrect file count in comment

The comment says ~700 files, but the default parameters in generate-project.sh produce ~6,158 files (NUM_JS=500, NUM_PY=4000, NUM_JSON=500, NUM_YAML=250, NUM_CSS=200, NUM_MD=200, NUM_SH=500), matching the actual file-count.txt value of 6158 and the "~6,000 files" claim two lines above the setup list.
benchmark/results/no-changes.json, line 1-5 (link)

No-changes benchmark is committed but absent from run.sh and docs

no-changes.json is committed with results but the current run.sh only generates all-files.json and staged-changes.json — there is no third benchmark command for the "no changes" scenario. As a result, re-running benchmark/run.sh will not regenerate this file and it will gradually diverge from the other results.

More importantly, the no-changes data shows a scenario where hk (77 ms) is ~5× slower than lefthook (15 ms) due to hk's Pkl config evaluation overhead. Since these results are committed but never surfaced in the chart or the docs page, readers who reproduce the benchmarks will only see two scenarios. Consider either:
1. Adding a no-changes benchmark back to run.sh and documenting it in docs/benchmarks.md (noting that hk has higher startup overhead, which is an honest trade-off), or
2. Removing no-changes.json from the repo if the scenario is intentionally excluded.
benchmark/run.sh, line 1090-1091 (link)

Redundant first eval before computing STAGED_COUNT

$STAGE_SCRIPT is evaluated twice in a row: once unconditionally on line 1090, then again inside the subshell that computes STAGED_COUNT on line 1091. The subshell immediately opens with git reset --hard HEAD -q, undoing any staging from the first eval before re-staging for the count. The first call is effectively a no-op relative to the state the benchmark actually starts with. Consider removing the standalone eval "$STAGE_SCRIPT" on line 1090 to avoid confusion.
benchmark/results/staged-changes.json, line 71-78 (link)

Inconsistent hk exit codes across staged-changes runs

hk's recorded exit codes are [0, 0, 1, 1, 1] — the first two runs exited cleanly while the last three found (or fixed) issues. Every other tool (lefthook, pre-commit, prek) is perfectly consistent across all five runs. Since hyperfine --prepare resets the repo before each run via $STAGE_SCRIPT, each run should see the same dirty staged files and produce the same exit code.

The mixed exit codes suggest that the stash/restore cycle (stash = "patch-file") is not fully resetting working-tree state between --prepare runs, or that the --prepare script itself is racing with hk's stash restoration. This could mean some benchmark iterations measured hk on an already-clean staging area, artificially lowering its reported mean and inflating the speedup numbers. It may be worth using HK_STASH=false for the staged benchmark (or a hook without stashing) to get a cleaner comparison, similar to the all-files run.

_{Reviews (15): Last reviewed commit: "docs: add benchmarks page, why-hk compar..." | Re-trigger Greptile}

cursor · 2026-03-23T14:24:09Z

@@ -0,0 +1 @@
+


Accidentally committed empty scripts/task_1.sh file

Low Severity

An empty scripts/task_1.sh file was added to the main repository's scripts/ directory. This appears to be a leftover from running benchmark/generate-project.sh (which creates scripts/task_${i}.sh files in the target directory). It doesn't belong in the source repo.

cursor · 2026-03-23T15:18:08Z

+
+# Stage all files
+git add -A
+git commit -q -m "generated benchmark project"


Generate script fails on re-run, missing --allow-empty

Medium Severity

Running generate-project.sh twice on the same directory fails because git commit on line 402 lacks --allow-empty. The generated content is deterministic, so re-running produces identical files. git add -A stages nothing new, and git commit exits with code 1 ("nothing to commit"), which triggers set -euo pipefail and aborts the script before printing the summary.

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 3 total unresolved issues (including 2 from previous reviews).

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

…mark suite Add comprehensive benchmarks comparing hk vs lefthook, pre-commit, and prek with 10 linters on a ~6000-file synthetic project. hk's safe parallel execution via file-level read/write locks gives it a major advantage: - All files (6158): hk 3.1s vs prek 10.5s (3.3x) vs pre-commit 10.6s (3.4x) vs lefthook 20.8s (6.6x) - Staged (500 files, 50 dirty): hk 416ms vs lefthook 717ms (1.7x) vs prek 740ms (1.8x) vs pre-commit 807ms (1.9x) Includes: - benchmark/generate-project.sh: codegen for synthetic projects - benchmark/run.sh: hyperfine runner with chart and JSON data generation - benchmark/parallel/: configs for hk, lefthook, pre-commit (10 linters) - docs/benchmarks.md: results page with dynamic Vue tables from benchmark-data.json - docs/why-hk.md: comparisons page covering parallelism, smart stashing, check_diff, plugin security, built-in Rust utilities - docs/.vitepress/config.mts: sidebar entries Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

@hituzi-no-sippo

### 🚀 Features - **(betterleaks)** add betterleaks config to hk builtin config by [@hituzi-no-sippo](https://github.com/hituzi-no-sippo) in [#750](#750) - **(builtins)** add google-java-format to builtins by [@timothysparg](https://github.com/timothysparg) in [#777](#777) - **(builtins)** add dclint to builtins by [@timothysparg](https://github.com/timothysparg) in [#779](#779) - **(config)** set default value for exclude to List() by [@timothysparg](https://github.com/timothysparg) in [#781](#781) - **(core)** add required field to prevent unconfigured steps from running by [@timothysparg](https://github.com/timothysparg) in [#785](#785) - **(gitleaks)** add gitleaks config to hk builtin config by [@hituzi-no-sippo](https://github.com/hituzi-no-sippo) in [#749](#749) - **(mdschema)** add mdschema config to hk builtin config by [@hituzi-no-sippo](https://github.com/hituzi-no-sippo) in [#748](#748) - **(pkl)** add pklr as opt-in pkl backend by [@jdx](https://github.com/jdx) in [#769](#769) - add pklr as opt-in pkl backend by [@jdx](https://github.com/jdx) in [#768](#768) ### 🐛 Bug Fixes - **(docs)** replace invalid /latest/ pkl package URIs with versioned format by [@jdx](https://github.com/jdx) in [#770](#770) - **(stage)** do not stage pre-existing untracked files by [@jdx](https://github.com/jdx) in [#788](#788) ### 📚 Documentation - add benchmarks page and reproducible benchmark suite by [@jdx](https://github.com/jdx) in [#766](#766) - add recommended setup section to mise integration by [@timothysparg](https://github.com/timothysparg) in [#780](#780) ### 📦️ Dependency Updates - lock file maintenance by [@renovate[bot]](https://github.com/renovate[bot]) in [#762](#762) - update rust crate pklr to 0.4 by [@renovate[bot]](https://github.com/renovate[bot]) in [#776](#776) - update apple-actions/import-codesign-certs digest to fe74d46 by [@renovate[bot]](https://github.com/renovate[bot]) in [#774](#774) - update anthropics/claude-code-action digest to 094bd24 by [@renovate[bot]](https://github.com/renovate[bot]) in [#773](#773) - update taiki-e/upload-rust-binary-action digest to 0e34102 by [@renovate[bot]](https://github.com/renovate[bot]) in [#775](#775) - bump usage to 3.2.0 and pkl to 0.31.1, add windows platforms by [@jdx](https://github.com/jdx) in [#787](#787) - lock file maintenance by [@renovate[bot]](https://github.com/renovate[bot]) in [#786](#786) ### New Contributors - @timothysparg made their first contribution in [#781](#781)  --- > [!NOTE] > **Medium Risk** > Primarily a version/documentation bump, but it also updates the Rust dependency lockfile (e.g., `hyper` and `windows-sys`), which could introduce build/runtime regressions. > > **Overview** > Bumps hk to **v1.40.0** and publishes the corresponding release notes in `CHANGELOG.md`. > > Updates generated CLI/docs and all Pkl package URL references in docs/examples to point at `v1.40.0`, and refreshes `Cargo.lock` with dependency updates/removals consistent with the new release. > > <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit da00ab8. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>  Co-authored-by: mise-en-dev <123107610+mise-en-dev@users.noreply.github.com>

This MR contains the following updates: | Package | Update | Change | |---|---|---| | [hk](https://github.com/jdx/hk) | minor | `1.39.0` → `1.40.0` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>jdx/hk (hk)</summary> ### [`v1.40.0`](https://github.com/jdx/hk/blob/HEAD/CHANGELOG.md#1400---2026-04-01) [Compare Source](jdx/hk@v1.39.0...v1.40.0) ##### 🚀 Features - **(betterleaks)** add betterleaks config to hk builtin config by [@hituzi-no-sippo](https://github.com/hituzi-no-sippo) in [#750](jdx/hk#750) - **(builtins)** add google-java-format to builtins by [@timothysparg](https://github.com/timothysparg) in [#777](jdx/hk#777) - **(builtins)** add dclint to builtins by [@timothysparg](https://github.com/timothysparg) in [#779](jdx/hk#779) - **(config)** set default value for exclude to List() by [@timothysparg](https://github.com/timothysparg) in [#781](jdx/hk#781) - **(core)** add required field to prevent unconfigured steps from running by [@timothysparg](https://github.com/timothysparg) in [#785](jdx/hk#785) - **(gitleaks)** add gitleaks config to hk builtin config by [@hituzi-no-sippo](https://github.com/hituzi-no-sippo) in [#749](jdx/hk#749) - **(mdschema)** add mdschema config to hk builtin config by [@hituzi-no-sippo](https://github.com/hituzi-no-sippo) in [#748](jdx/hk#748) - **(pkl)** add pklr as opt-in pkl backend by [@jdx](https://github.com/jdx) in [#769](jdx/hk#769) - add pklr as opt-in pkl backend by [@jdx](https://github.com/jdx) in [#768](jdx/hk#768) ##### 🐛 Bug Fixes - **(docs)** replace invalid /latest/ pkl package URIs with versioned format by [@jdx](https://github.com/jdx) in [#770](jdx/hk#770) - **(stage)** do not stage pre-existing untracked files by [@jdx](https://github.com/jdx) in [#788](jdx/hk#788) ##### 📚 Documentation - add benchmarks page and reproducible benchmark suite by [@jdx](https://github.com/jdx) in [#766](jdx/hk#766) - add recommended setup section to mise integration by [@timothysparg](https://github.com/timothysparg) in [#780](jdx/hk#780) ##### 📦️ Dependency Updates - lock file maintenance by [@renovate\[bot\]](https://github.com/renovate\[bot]) in [#762](jdx/hk#762) - update rust crate pklr to 0.4 by [@renovate\[bot\]](https://github.com/renovate\[bot]) in [#776](jdx/hk#776) - update apple-actions/import-codesign-certs digest to [`fe74d46`](jdx/hk@fe74d46) by [@renovate\[bot\]](https://github.com/renovate\[bot]) in [#774](jdx/hk#774) - update anthropics/claude-code-action digest to [`094bd24`](jdx/hk@094bd24) by [@renovate\[bot\]](https://github.com/renovate\[bot]) in [#773](jdx/hk#773) - update taiki-e/upload-rust-binary-action digest to [`0e34102`](jdx/hk@0e34102) by [@renovate\[bot\]](https://github.com/renovate\[bot]) in [#775](jdx/hk#775) - bump usage to 3.2.0 and pkl to 0.31.1, add windows platforms by [@jdx](https://github.com/jdx) in [#787](jdx/hk#787) - lock file maintenance by [@renovate\[bot\]](https://github.com/renovate\[bot]) in [#786](jdx/hk#786) ##### New Contributors - [@timothysparg](https://github.com/timothysparg) made their first contribution in [#781](jdx/hk#781) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

gemini-code-assist Bot reviewed Mar 23, 2026

View reviewed changes