Skilj Build Kit

Build kit: Rust · skilj

Turns slices from an [eventmodelers.ai](https://eventmodelers.ai) board into Rust code, using **event sourcing on [`skilj`](https://codeberg.org/gklijs/SklilJ)** — Postgres-backed, Dynamic Consistency Boundaries (DCB) instead of classic aggregate-per-stream, GraphQL and REST surfaces built in.

npx @eventmodelers/cli init --stack skilj \
  --git https://codeberg.org/gklijs/skilj-build-kit

What it installs

.claude/skills/build-*	four skills: state-change, state-view, automation, webhook
.claude/skills/skilj, skilj-event-modeling	skilj's own reference skills, vendored — see "Keeping the vendored skills in sync" below
.build-kit/CLAUDE.md	the blueprint — "how we build things here"
.build-kit/AGENTS.md	seeded lessons, read before every slice
.build-kit/lib/*.md	the ralph loop prompts
Cargo.toml, src/	the framework: one worked bounded context (wallet), boot code
docs/screens/	a worked example of a screen brief

The shared skills — `connect`, `learn-eventmodelers-api`, `update-slice-status`, `request-feedback`, `load-slice` — come from the CLI itself.

skilj + what, exactly

`skilj` already *is* the read/fold/decide/append plumbing some other Build-Kits' own frameworks hand-roll (optimistic DCB concurrency, tag indices, a REST+GraphQL wire surface generated automatically once a type is registered). A consuming app never writes that layer — only `EventType`/`CommandType`/`Projection` trait implementations.

That also means this kit is thinner than some others in one specific way: **there's no separate "Context" wrapper layer to write for the ordinary case.** Once a `CommandType` opts into `rest_trigger_allowed()`, its wire endpoint already exists. Two places this actually costs something instead of saving it, both covered explicitly in `build-state-change`/`build-webhook`:

• A board's "generated" field has no framework-level home. skilj has no hoo