2026-10-13 16:45:12 +08:00
---
name : caveman
description : >
2026-10-30 12:40:16 +08:00
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
2026-10-13 16:45:12 +08:00
---
2026-10-30 12:40:16 +08:00
# Compact spec notation
2026-10-13 16:45:12 +08:00
2026-10-30 12:40:16 +08:00
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.
2026-10-13 16:45:12 +08:00
2026-10-30 12:40:16 +08:00
- `→` 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.
2026-10-13 16:45:12 +08:00
2026-10-30 12:40:16 +08:00
Examples:
2026-10-13 16:45:12 +08:00
```text
V2: token expiry ≤ current_time → reject
2026-10-30 12:40:16 +08:00
api: POST /x → 201 {id:string}
T3|~|add auth middleware|V1,I.api
2026-10-13 16:45:12 +08:00
```
2026-10-30 12:40:16 +08:00
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.