Docs

Documentation

The concepts you need to model a system in Skimabase, from your first project to generated code. Each section is short; the app’s own labels are used throughout.

Getting started

  1. Download Skimabase and move it to Applications.
  2. Open it and continue with Google to sign in.
  3. Choose New Project (⌘N) to create one, or Open Project (⌘O) to open an existing folder.
  4. Add entities, then open the Schema Graph to see how they relate.

The workspace has an Explorer on the left, editor tabs in the middle, the Inspector on the right, and Problems and Output in the bottom panel. ⌘P opens Quick Open and ⌘⇧P opens the Command Palette.

Projects

A project is a folder. A new project contains a schema-studio.yaml manifest and a src/schema directory. Skimabase adds a .schema-studio directory as needed for graph layout, Derived outputs and local state such as AI history.

FleetOps/
├── schema-studio.yaml
├── src/
│   └── schema/
│       ├── Organization.yaml
│       ├── Vehicle.yaml
│       └── Driver.yaml
└── .schema-studio/
    ├── layouts/schema.json
    ├── derived/
    └── local/

The manifest names the project and points to the schema sources:

version: 1

project:
  name: FleetOps
  description: Fleet operations platform

sources:
  schema: src/schema

Only files under src/schema are compiled. Layout, Derived output and local state are kept apart from the model, so moving a node on the graph never changes it.

Schemas

The schema is every entity in src/schema, compiled together. Skimabasevalidates it as you type, and lists errors in Problems with the file and location they come from.

The Changes view compares the current schema with the last saved version. Each change is classified by risk:

  • safe: adding an entity or an optional field, renaming, or making a field optional.
  • review: adding a required field, making a field required, or changing defaults, enum values, relation targets, cardinality or constraints.
  • destructive: removing an entity or field, and most type changes.

Entities

Each entity lives in its own YAML file. It has a stable id, a name, and fields. Fields carry their own IDs, so renaming an entity or field is understood as a rename, not a removal followed by an addition.

id: order
name: Order
fields:
  status:
    id: order.status
    type: enum
    required: true
    values: [draft, placed, cancelled]
  notes:
    id: order.notes
    type: string
  organization:
    type: relation
    target: Organization
    cardinality: one
    required: true
  customer:
    type: relation
    target: Customer
    cardinality: one

Supported field types:

string text number int32 int64 float32 float64 decimal boolean date datetime uuid json enum relation

You can edit entities as YAML, or on the Schema Graph, where adding fields and relations, renaming and deleting write back to the same files. Deleting asks for confirmation.

Relationships

A relationship is a field with type: relation, a target entity, and a cardinality of one or many. In the example above, Order.organization is a required link to one Organization.

On the Schema Graph, each relation is drawn from the field that owns it. Select an entity to see, in the Inspector, every field elsewhere that references it. In large models, Relations Only shows just the relation fields, and Auto Layout arranges the entities.

Connections

Connections compare your model with a real system.

  • PostgreSQL and Supabase PostgreSQL: test the connection, inspect the database, and compare actual with desired. You can review and apply a plan that creates missing enums, tables, unique constraints and foreign keys. Apply never runs on save, compile or inspect.
  • SharePoint: read-only inspection. Nothing is written to SharePoint.

The Migration view plans a migration to a SQL Server 2022 compatible target and previews the T-SQL. It is preview only; no SQL is executed.

Passwords are kept in memory while the app runs and are not saved.

Generators

A generator turns the schema into code for one stack. Add one from Add Generator… in the Derived group of the Explorer, then pick a preset and adjust its configuration.

GeneratorBuilt-in presets
NestJSNestJS Standard, NestJS Contracts (DTOs and entities only)
TypeScript TypesStandard
Zod ValidationStandard
OpenAPI DocumentOpenAPI 3.1

Presets can be built in or defined for a project. Each generator has a version; when it changes, existing output is marked Out of date with the reason Generator updated.

Derived outputs

A Derived output is the result of Schema + Generator + Preset + Generator Version. Outputs are read-only projections stored in .schema-studio/derived, and the files carry a “Do not edit by hand” banner.

Each output shows its status:

  • Up to date: matches the current inputs.
  • Out of date: with the reason, such as Schema changed, Configuration changed, Preset changed or Generator updated.
  • Not generated, Disabled, Schema has errors or Invalid configuration.

Skimabase never regenerates outputs automatically. Use Preview Changes… to see which files would be added, modified or removed, then Regenerate. The same inputs always produce the same files.