---
name: caveman
description: >
  Use compact Caveman notation when explicitly requested, or when editing a spec that already adopts that notation. Ordinary requests to be brief use plain English.
scope: global
---

# Compact spec notation

Keep technical statements concise without losing conditions, scope, uncertainty,
or modality. Preserve code, identifiers, paths, URLs, versions, numbers, quoted
strings, and data formats verbatim. Plain English is preferable when symbols make
a statement ambiguous; notation does not determine SPEC.md ownership.

- `→` leads to/becomes; `∀` every; `∃` exists.
- `!` required; `⊥` forbidden; `?` unknown.
- `≤`, `≥`, `≠`, `∈`, `∉` retain mathematical meanings.
- Write optional behavior and missing values (`null`, `nil`) explicitly; do not
  overload unknown/forbidden symbols with those meanings.
- Remove filler and unnecessary articles. Retain negation, quantifiers, honest
  hedges, exception conditions, and words needed to distinguish implement from fix.

Examples:

```text
V2: token expiry ≤ current_time → reject
api: POST /x → 201 {id:string}
T3|~|add auth middleware|V1,I.api
```

Use the project's table format and escape literal pipes as needed. Verify that a
reader can recover the exact behavioral claim; no token-reduction target, special
scan, or automatic compression of human-facing reports is required.