v0.1.3

Released on 2026-03-09. Full changelog

Highlights

Path specification in GitHub shorthand references (#167)

Presets can now reference a specific file within a GitHub repository using the github:owner/repo/path@ref syntax. This allows a single repository to host multiple preset configurations that can be imported individually:

runok.yml

extends:
  - 'github:fohte/runok-presets/presets/claude-code.yml@v1'
  - 'github:fohte/runok-presets/presets/git.yml@v1'

Previously, only the repository root could be referenced, requiring one preset file per repository.

See Extends for details.

Relative path resolution based on config file location (#166)

Relative paths in config files (e.g., in extends or definitions.paths) are now resolved relative to the config file’s parent directory, not the current working directory. This makes configurations portable — they work the same way regardless of where you invoke runok:

runok.yml

# In ~/projects/my-app/runok.yml
extends:
  # Before: resolved relative to cwd (broken if run from a subdirectory)
  # After: always resolved relative to ~/projects/my-app/
  - './presets/strict.yml'

See File Discovery for details.

New Features

• Add file-based locking for concurrent preset cache access, preventing cache corruption when multiple runok instances run in parallel (e.g., multiple Claude Code sessions evaluating commands simultaneously) (#168)

Bug Fixes

Config file discovery now traverses ancestor directories (#165)

Running runok check from a subdirectory failed to find the project’s runok.yml because config discovery only looked in the current directory. It now traverses parent directories upward until it finds a config file:

# Before: failed to find runok.yml
cd ~/projects/my-app/src && runok check -- git status  # → error: no config

# After: finds ~/projects/my-app/runok.yml
cd ~/projects/my-app/src && runok check -- git status  # → works

Preset rules via extends now load correctly (#174)

Rules defined in presets referenced via extends were silently ignored — the preset file was fetched and cached, but its rules were not merged into the effective configuration. All inherited rules now load as expected.

Order-independent matching for flag-only negation (#171)

Flag negation patterns like find !-delete * were position-dependent, so they only worked when the negated flag was checked at a specific position. Negation is now order-independent, matching regardless of where flags appear in the command.