AI agents & skills

LiteORM is built for how software gets written now: through AI coding assistants. Rather than leave your assistant to guess the API from training data — and write subtly wrong code — LiteORM ships Agent Skills: task-scoped instruction files that hand the assistant the exact, current API for one job, so it gets it right the first time. If your day-to-day coding involves an AI assistant, setting this up is the highest-leverage five minutes you’ll spend getting started.

There are three distinct pieces, for three different audiences:

• Agent Skills (skills/) — for an assistant writing application code with LiteORM. This page.
• AGENTS.md — for an agent (or human) contributing to the LiteORM repository itself.
• AI in the studio — for the people using your database: natural-language → SQL inside the embedded admin GUI. See the studio guide.

A skill is a folder under skills/ containing a single SKILL.md: YAML frontmatter (a name and a one-sentence description that states when to use it) followed by a tight, actionable body — the real API as tables and short snippets, plus the pitfalls that matter. Each skill covers one job (writing queries, defining models, migrating a schema, porting from gorm, …), so the assistant loads only what the current task needs.

The description is the trigger: a capable assistant reads the available skills’ descriptions and pulls in the relevant SKILL.md on demand, the way it would consult documentation — except this documentation is written for a machine and pinned to the version of LiteORM you’re using.

Copy the skills/ folder from the LiteORM repository into your AI assistant’s skills (or instructions) directory — the whole folder, or just the individual skill folders you want. Assistants that support the Agent Skills convention (a SKILL.md with name/description frontmatter) then load the right skill automatically based on the task you describe.

If your assistant doesn’t auto-load skills, the files are still useful by hand: paste the relevant SKILL.md into the conversation when you start a task — “writing a migration”, “defining a model with relations”, “porting a gorm struct” — and the assistant has the precise surface in front of it instead of a half-remembered one.

Either way, point your assistant at skills/using-liteorm first: it covers choosing the query vs orm front-end, opening a backend, first CRUD, and the shared Session/transaction model — the orientation every other skill builds on.

Skill	Use it when you’re…
using-liteorm	Starting out: choosing query vs orm, opening a backend, first CRUD, the shared Session/transaction model.
query-builder	Writing explicit, typed queries: predicates, joins, unions, subqueries, EXISTS, Iter streaming, Pluck, aggregates, Raw, the query.Repo.
orm-models	Defining declarative models: structs + tags, AutoMigrate, the orm.Repo, associations (Load/Attach), hooks, soft delete.
migrations	Evolving a schema: additive AutoMigrate, reviewable GenerateMigration/Diff, the migrate runner (Load/New/Up/Down), WritePair.
codegen	Generating typed code: columns from a Go type, models from a live DB, typed Go from annotated SQL, the sqlc plugin, the gorm porter.
porting-from-gorm	Migrating a gorm codebase: running on gorm tags as-is, rewriting to native orm tags, and adjusting for what differs.
sqlite-search	Adding SQLite vector (sqlite-vec), full-text (FTS5), or hybrid (RRF) search.
field-codecs	Transforming a field on the way to/from the DB — JSON/gob, encrypt or compress at rest — without changing its Go type (codec: tag).
large-objects	Storing large/growing binary content in SQLite as streamed io.ReaderAt/io.WriterAt instead of whole []byte (orm.LOB).
encryption	Opening a SQLite database with transparent page-level at-rest encryption — key handling, reopening, constraints.
vault	Storing a whole SQLite database compressed and/or encrypted at rest in a gosqlite vault container.
changesets	Capturing / applying / inverting / concatenating SQLite changesets (the SESSION extension) for audit logs, one-way replication, or undo.
quicsql	Connecting to a remote quicSQL server via the SQLite dialect — the quicsql:// DSN or sqlite.WrapDB, mTLS/keyring, and which features work over the wire.
postgres-advanced	Using Postgres LISTEN/NOTIFY or the typed JSONB / array operators.
logging	Tracing executed SQL while developing, via slog or the colored handler.
observability	Instrumenting with metrics / tracing / audit around every statement — the Observer seam (WithObserver / QueryEvent), distinct from slog logging.
studio	Mounting the embedded database studio, registering models, locking it down.
pitfalls	Avoiding the gotchas around loading, soft delete, types, and dialect-gated operators — proactively or when code misbehaves.

Skills ship alongside the code and are updated with it, so they stay in lockstep with the API — a skill won’t recommend a method that no longer exists or miss one that was just added.

If your agent is working inside the LiteORM repository — adding a feature, fixing a bug — point it at AGENTS.md instead. That’s the contributor onboarding: the architecture in a paragraph, the repository layout, the fragile invariants not to break (the driver-free core, late placeholder rendering, feature-gated dialect operators), the conventions, and the common just tasks. It’s written to make an agent productive in a few minutes without re-deriving how the project is structured.

• Getting started — install and your first query/model.
• Studio — the embedded admin GUI and its built-in natural-language-to-SQL.
• skills/ — the skill files themselves; AGENTS.md — contributor onboarding.