Finds, October 2026

This is the first of a monthly series: tools I use or am trying out, each checked against its latest release on the day I publish, and each with the one thing I would check before adopting it.

At a glance

Notes and knowledge

qmd 2.8.3. On-device search over Markdown: BM25, vector search and an LLM re-ranker, run locally through node-llama-cpp, with a CLI, JSON output and an MCP server. OKF Vault Kit, one of my CronAI Labs tools (alpha, v0.1.0), is wired to it. Caveat: "local" starts with a download. The first qmd embed or qmd query fetches up to three GGUF models from Hugging Face, about 2 GB together, into ~/.cache/qmd/models/ by default; plain keyword search with qmd search needs none. Its HTTP mode has no authentication, so keep it on loopback.

Open Knowledge Format 0.2. A spec for knowledge as a directory of Markdown files with YAML frontmatter, plus optional fields for provenance, trust and freshness such as sources, verified and stale_after. My engineering notes are an OKF bundle, and so is OKF Vault Kit. Caveat: type is the only required key, so "OKF-conformant" promises very little. If you consume a bundle, check for the fields you rely on, such as verified or stale_after, instead of trusting the label. The spec has moved to its own repository; the copy under knowledge-catalog/okf has been a frozen snapshot since 21 August.

Git and releases

gh-stack 0.2.1. The GitHub CLI extension for stacked pull requests; the feature itself became generally available on 6 October. It creates the branches, keeps them rebased and sets each PR's base. Caveat: without a merge queue, a stack lands on the base branch in one operation, so main gets one push and push-triggered CI and release jobs run on the tip only. In schriftsatz, a six-PR stack shipped as one release; each layer had passed CI as a pull request, but the five commits below the tip were never built on main. Whether that is a bug or the point depends on your pipeline; my notes on stacked pull requests have the measurements.

git-cliff 2.14.2. Generates changelogs from Conventional Commits and computes the next semver; schriftsatz derives each release's version and notes from it. Caveat: when nothing since the newest tag is releasable, git-cliff --bumped-version prints the current version, warns "There is nothing to bump", and exits 0. I reproduced that with 2.14.2 on a tag followed by one ci: commit, which my config skips. A job that tags whatever it prints will try to cut the same release twice, so compare the output with your newest tag first:

next=$(git-cliff --bumped-version)
latest=$(git tag -l 'v[0-9]*' --sort=-v:refname | head -1)
if [ "$next" = "$latest" ]; then
  echo "nothing to release: $next is already the newest tag"
  exit 0
fi

jj 0.46.0. A Git-compatible VCS where the working copy is a commit and every operation goes into an undoable log. I am still evaluating it, for an Obsidian vault I sync between devices. Caveat: check your sync tool before jj git init, which creates a colocated workspace by default. Obsidian Sync skips every dot folder except .obsidian, but the Sync Engine community plugin (formerly WebDAV Sync) excludes .git by default and not .jj, so add .jj to its exclusion rules.

Checks in CI

gitleaks 8.30.1. Scans git history, not just the working tree, so a secret committed and later deleted still shows up. In the three-secret fixture test recorded in alfred-little-snitch-control's secret-scanning decision, it caught all three. The three scanners in MegaLinter's cupcake flavor, as MegaLinter configures them, caught two (betterleaks), two (secretlint) and none (trufflehog, which MegaLinter runs with --only-verified). Caveat: gitleaks fails open. If git refuses the repository, gitleaks logs the git error, reports 0 commits scanned and no leaks found, and exits 0. That holds for detect --source, deprecated since 8.19.0 but still working, and for its replacement gitleaks git: I reproduced it with both in 8.30.1, on a repository whose format version git rejects. My CI asserts the commit count instead of trusting the exit code; the same check for gitleaks git:

set -o pipefail
gitleaks git --redact --no-banner --no-color . 2>&1 | tee gitleaks.log || exit 1
commits=$(sed -n 's/.*[[:space:]]\([0-9][0-9]*\) commits scanned.*/\1/p' gitleaks.log | head -1)
if [ -z "$commits" ] || [ "$commits" -eq 0 ]; then
  echo "gitleaks scanned ${commits:-no} commits: it did not read the repository" >&2
  exit 1
fi

lychee 0.24.2. A link checker for Markdown, HTML and websites, written in Rust. I run it weekly, off the pull-request path, so a dead external link never blocks an unrelated change. Caveat: a site behind a Cloudflare challenge page answers 403 with a JavaScript challenge that no plain HTTP client can pass, so the check fails on a link that works in a browser. Mine failed seven weekly runs in a row before I looked. The response header tells you which case you have:

curl -sS -D - -o /dev/null "$URL" | grep -i cf-mitigated
# cf-mitigated: challenge  -> the client is the problem, not the link

Exclude that host with --exclude and leave a comment saying why. Accepting 403 everywhere would hide links that really were revoked.

Agents and runtimes

container 1.5.0. Apple's CLI for running Linux containers from OCI images as lightweight VMs on Apple silicon. Apple supports it only on macOS 26; it also runs on macOS 15 with documented limitations, one of which is that the --network option errors there. VaultOre (working v0.1, pre-release) has it as an engine option next to Docker, Podman and Colima. Caveat, and a bug in my own code: on this engine VaultOre refuses network-denied cells, and network: deny is its default, so every default workflow refuses to run. Its runtime and README assume there is no --network none. There has been one since 0.6.0 in October 2025; the release notes announced it, but it never reached --help or the command reference. Policy, not sandbox covers what VaultOre's container permissions do and don't isolate.

skills 1.7.2. npx skills add owner/repo installs agent skills into Claude Code, Codex, Cursor, OpenCode and, by its own count, 75 more agents. Kev, which I wrote up in Kev: open decision models that answer with probabilities, distributes its fine-tuning and deploy skills this way. Caveat: a skill is code your agent will run. The Agent Skills specification allows a scripts/ directory of executable code and an allowed-tools field that pre-approves tools, so review a skill as you would a dependency. The CLI also sends anonymous usage telemetry unless you set DISABLE_TELEMETRY=1.