Eventmodelers Elixir Fact Kit

Build kit: Elixir · Phoenix · FACT

Turns slices from an [eventmodelers.ai](https://eventmodelers.ai) board into Elixir code, using **event sourcing on [`fact`](https://hex.pm/packages/fact)** — files on disk, no database — and vertical slice architecture.

npx @eventmodelers/cli init --stack elixir-fact \
  --git https://github.com/ortegacmanuel/eventmodelers-elixir-fact-kit

What it installs

.claude/skills/build-*	four skills: state-change, state-view, automation, webhook
.build-kit/CLAUDE.md	the blueprint — "how we build things here"
.build-kit/lib/*.md	the ralph loop prompts
project root	a real Phoenix app: endpoint, router, layouts, assets, supervision tree — compiles and its tests pass as installed
lib/my_app/	the framework: decide, reader, state_change, state_view, fact_event, id
docs/screens/	a worked example of a screen brief

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

**327 lines of Elixir and about 1,400 lines of instructions.** The Elixir is what runs; the instructions are what makes an agent produce the same shape every time.

Phoenix + fact + what, exactly

`fact` is an event store. It gives you two things: **append** and **read**, plus indices by type and by tag. It does *not* tell you how a command decides, what happens when two writes race, how a read model gets built, how a domain struct becomes storable, or where any of it lives.

Those 327 lines are that gap:

module	what it solves
decide.ex	the whole write path: read → fold → decide → append. Optimistic concurrency (DCB), retry on conflict, and a wait until the write is visible to a subsequent read
reader.ex	the read path: uses fact's indices instead of scanning the ledger. Measured: 235 ms → 0.07 ms over 20,000 events
state_change.ex	the contract for a write slice: query,