Caveman
Write SPEC.md and spec-adjacent docs in compressed caveman grammar to cut agent tokens while keeping paths, code, and invariants exact.
Overview
Caveman is an agent skill most often used in Build (also Validate scope, Ship review) that encodes SPEC.md in symbol-heavy fragments to cut tokens ~75% without altering code or identifiers.
Install
npx skills add https://github.com/juliusbrussee/blueprint --skill cavemanWhat is this skill?
- Grammar drops articles, filler, aux verbs, hedging; fragments allowed
- Symbol table (→, ∴, ∀, !, ?, ⊥, etc.) replaces verbose connectives
- Preserve verbatim: code, paths, URLs, identifiers, numbers, quoted strings, SQL/JSON/YAML
- Invariant shape: V<n>: subject relation condition for traceable rules
- Scoped to SPEC.md and spec prose—not code, commits, PRs, or error strings
- ~75% token cut vs prose (per SKILL.md)
- Dedicated symbol grammar with →, ∴, ∀, !, ?, ⊥, and related operators
- Invariant template: V<n>: subject relation condition
Adoption & trust: 197k installs on skills.sh; 1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your SPEC.md ballooned in token size so every /spec and /build turn re-reads expensive prose the agent already understood.
Who is it for?
Indie builders using blueprint /spec → /build → /check who want durable, machine-readable specs without paying full English token cost each turn.
Skip if: First-draft ideation before requirements exist, external-facing marketing copy, or contexts where stakeholders need full prose instead of encoded specs.
When should I use this skill?
Any write to SPEC.md or when user says caveman, compress this, or be brief; loaded by /spec, /build, /check.
What do I get? / Deliverables
SPEC.md and backprop entries shrink to caveman grammar with intact paths and invariants, ready for blueprint /build and /check to consume.
- Caveman-encoded SPEC.md sections
- Invariant V-lines and symbol-keyed constraints
- Compressed backprop entries for spec-adjacent prose
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
SPEC.md is the canonical plan artifact during build planning, but the same encoding is invoked from /spec and /check hooks across the blueprint flow. PM subphase is where specs, invariants, and task-shaped prose live before and during implementation.
Where it fits
Encode scoped requirements into SPEC.md before /build locks file-level tasks.
Refresh SPEC.md mid-sprint with V-line invariants without re-expanding to full English.
Compress spec-referencing architecture notes that must stay aligned with SPEC.md sections.
Append /check backprop entries in caveman so review findings stay grep-friendly and token-cheap.
How it compares
Spec compression encoding for agent repos—not a generic summarize skill and not a replacement for approving requirements in plain language.
Common Questions / FAQ
Who is caveman for?
Solo builders on juliusbrussee blueprint (or similar spec-driven stacks) who repeatedly write or update SPEC.md with coding agents.
When should I use caveman?
When writing SPEC.md during Validate (scope), during Build (pm) implementation specs, or when /check reviews need the same compressed format; say caveman or compress this on any spec-adjacent write.
Is caveman safe to install?
It only changes how text is written—review Security Audits on this page and ensure compressed specs are still human-auditable before you rely on them for compliance.
SKILL.md
READMESKILL.md - Caveman
# caveman — spec encoding Applies to SPEC.md writes, spec-referencing prose, backprop entries. Does NOT apply to code, error strings, commit messages, PR descriptions. ## GRAMMAR - Drop articles (a, an, the). - Drop filler (just, really, basically, simply, actually). - Drop aux verbs where fragment works (is, are, was, were, being). - Drop pleasantries. - No hedging (skip "might", "perhaps", "could be worth"). - Fragments fine. - Short synonyms: fix > implement, big > extensive, run > execute. ## SYMBOLS Prefer over words: ``` → leads to / becomes / on <x> ∴ therefore / fix ∀ for all / every ∃ exists / some ! must / required ? may / optional / unknown ⊥ never / forbidden / nil ≠ not equal ∈ in ∉ not in ≤ at most ≥ at least & and | or § section reference ``` ## PRESERVE VERBATIM Never compress: - Code blocks, snippets, one-liners with backticks. - Paths: `src/auth/mw.go`. - URLs. - Identifiers: function names, variable names, env vars. - Numbers and versions. - Error message strings. - SQL, regex, JSON, YAML. - Quoted strings. ## SHAPES **Invariant**: ``` V<n>: <subject> <relation> <condition> V1: ∀ req → auth check before handler V2: token expiry ≤ current_time → reject ``` **Bug row** (pipe table under §B): ``` id|date|cause|fix B1|2026-04-20|token `<` not `≤`|V2 ``` **Task row** (pipe table under §T): ``` id|status|task|cites T3|x|add auth mw|V1,I.api ``` Status: `x` done, `~` wip, `.` todo. Escape literal `|` as `\|`. **Interface**: ``` <kind>: <name> → <shape> api: POST /x → 200 {id:string} cmd: `foo bar <arg>` → stdout JSON env: FOO_KEY ! set ``` ## EXAMPLES **Bad**: > The system should ensure that every incoming request is properly authenticated before being forwarded to its corresponding handler function. **Good**: > V1: ∀ req → auth check before handler **Bad**: > We discovered that the token expiration check in the middleware was using a strict less-than comparison operator, which meant tokens were being rejected at the exact moment of their expiry. **Good**: > B1: token `<` not `≤` → reject @ expiry boundary. **Bad**: > The POST endpoint at /x accepts a JSON body and returns a 200 response with an object containing the created id. **Good**: > api: POST /x → 200 {id} ## BOUNDARIES - User asks for prose explanation → switch to normal English. - Spec documents for external review (RFC, pitch) → normal English. - Commit message → normal English (git readers expect it). - Diff comment in code → normal English. ## WHEN UNSURE If cutting a word loses a fact, keep it. Caveman is compression, not amputation.