v0.2.3

Released on 2026-04-12. Full changelog

Breaking Changes

Flag group definitions use pattern syntax instead of arrays (#300)

definitions.flag_groups values have changed from arrays of flag names to pattern strings. The new format uses the same syntax as rule patterns, with aliases separated by | and an optional value pattern suffix.

Before:

definitions:
  flag_groups:
    field-flag: ['-f', '-F', '--field', '--raw-field']

After:

definitions:
  flag_groups:
    field-flag: '-f|-F|--field|--raw-field *'

The * at the end indicates this is a value flag (captures the flag and its value). Omitting it defines a bool flag (captures flag presence only).

New Features

Bool flag groups (#300)

Flag groups can now represent boolean flags (flags without a value). Define a flag group without a value pattern:

definitions:
  flag_groups:
    verbose: '-v|--verbose'

rules:
  - ask: 'command <flag:verbose> *'
    when: 'size(flag_groups["verbose"]) > 0'

Value-restricted flag groups (#300)

Flag group definitions can restrict which values are accepted:

definitions:
  flag_groups:
    method: '-X|--method GET|HEAD|OPTIONS'

rules:
  - allow: 'curl <flag:method> *'

Only GET, HEAD, and OPTIONS will match. Other values like POST will not be captured, causing the rule to be skipped.

<flag:name> no longer requires a trailing value pattern (#300)

The <flag:name> placeholder now stands alone in rule patterns. Whether the flag takes a value is determined by the flag group definition, not by the pattern:

# Before: <flag:name> consumed the next token as a value pattern
- allow: 'gh api graphql <flag:field-flag> * *'

# After: value behavior comes from the definition
- allow: 'gh api graphql <flag:field-flag> *'

See Flag Groups and Configuration Schema for details.