34 lines
1.4 KiB
Markdown
34 lines
1.4 KiB
Markdown
---
|
|
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.
|