juliusbrussee/cavekit
5 skills12.5k installs5.7k starsGitHub
Install
npx skills add https://github.com/juliusbrussee/cavekitSkills in this repo
1Cavemancaveman is a spec-encoding skill from cavekit loaded by /spec, /build, and /check commands. It cuts tokens roughly 75% versus prose while staying precise, applying a grammar that drops articles, filler words, aux verbs, pleasantries, and hedging while allowing sentence fragments. caveman applies to SPEC.md writes, spec-referencing prose, and backprop entries but not code, error strings, commit messages, or PR descriptions. Developers reach for caveman when writing SPEC.md or when users say caveman, compress this, or be brief. The skill keeps agent context windows efficient without losing spec precision during automated build and check workflows.2.6kinstalls2BuildThe cavekit build skill implements SPEC.md tasks in a single-thread plan-then-execute loop without sub-agents. LOAD reads SPEC.md or stops to invoke the spec skill, loads FORMAT.md once, honors section R external facts, and parses section T.n, --next, or --all open rows. High blast-radius auth or payments work may require review; trivial reversible tasks skip ceremony. PLAN cites section V invariants and section I interfaces, lists files, names exact verification tests per invariant, and names the oracle command before approval unless auto mode. EXECUTE flips section T status dot to tilde, edits code, runs verification, marks x on pass, or invokes backprop on failure without blind retries. Spec wrong or unspecified edges route through the spec skill with bug cause. WRITE POLICY allows only section T status flips; other spec edits use the spec skill. Commits after each task use T n goal plus invariant cites. Verification requires oracle exit zero, named tests passing, and a full suite at end.2.5kinstalls3SpecCavekit spec is the sole mutator of SPEC.md at repo root, creating, amending, distilling, or backpropagating bugs per FORMAT.md caveman encoding rules. Dispatch modes are NEW for ideas without a spec, DISTILL to infer spec from existing code, BACKPROP for bug entries, and AMEND for targeted section edits. NEW extracts goal constraints interfaces invariants tasks and an empty section B header, optionally ingesting grill research review and deepen handoffs into the right sections without rewriting unrelated content. BACKPROP parses bug descriptions, finds root cause, drafts new invariants when they would catch recurrence, appends section B rows, and shows a diff before applying. DISTILL walks the repo to infer sections from README stack public APIs tests and TODOs, flagging uncertain items with question marks. Output preserves identifiers, keeps numbering monotonic, and never auto-builds after writing.2.5kinstalls4CheckCavekit check is a read-only drift detector that diffs SPEC.md against current code and reports violations grouped by severity without writing anything. It loads SPEC.md, parses args for section V invariants, section I interfaces, section T tasks, or all three, then classifies each item as hold, violate, unverifiable, match, drift, missing, extra, or stale. Invariant checks translate each V row into a verifiable claim, grep relevant files, and record file line evidence. Interface checks compare declared shapes to implementations. Task checks flag stale x rows when claimed work is absent. Reports use caveman format with summary counts and one-line remedy hints per class, but never invoke fixes automatically. Run after each build and before ship because drift caught here is a diff while drift in production is a bug entry.2.5kinstalls5BackpropThe backprop skill implements a bug-to-spec protocol for Spec-Driven Development. When a test fails, a user reports a bug, a post-mortem runs, or /check flags a VIOLATE with a known root cause, the agent traces the failure to file and line, analyzes whether a new section V invariant would catch recurrence, and drafts spec edits in sections B and V. Step three proposes the change using a template row and testable invariant line. Step four adds a failing test named after the invariant before fixing code. Step five verifies the fix and full suite, then logs one commit combining spec, test, and code with message backprop section B plus section V and one-line cause. Good invariants are testable, behavior-scoped, and positively stated. Skip new section V for mechanical typos, one-time migrations, or external dependency issues, but still record section B. Output is always section B entry, usually section V, test when added, code fix, and one commit with no dashboards.2.4kinstalls