workspace-api_skill

This skill helps you define and evolve typed workspace schemas with versioned migrations for tables and KV stores.
  • TypeScript

4.2k

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

3 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill epicenterhq/epicenter --skill workspace-api

  • SKILL.md9.7 KB

Overview

This skill provides TypeScript-first workspace API patterns for defineTable, defineKv, versioning, and migrations. It enforces type-safe schemas, branded IDs, and clear migration rules so schemas evolve safely over time. Use it to declare tables or KV stores, add versions, and author migrations that always produce the latest shape.

How this skill works

You declare schemas with defineTable() or defineKv() using arktype definitions, either as a single-version shorthand or a builder that chains .version() and .migrate(). Tables require a numeric _v discriminant; KV stores may omit _v or use it as an explicit discriminant. Migrations receive a union of prior versions and must return the latest version output, using switch(row._v) for discrimination.

When to use it

  • Defining a new table or KV store schema.
  • Adding a new schema version for tables or KV stores.
  • Writing migrations that transform older rows to the latest version.
  • Converting shorthand single-version schemas into builder-style multiple versions.
  • Enforcing branded ID types for table primary keys and foreign keys.

Best practices

  • Always include _v (number literal) for tables; arktype enforces this at compile time.
  • Brand every table id and every string foreign key with a unique branded type to prevent ID mixups.
  • Migrate directly to the latest version in one function; do not chain incremental migrations through intermediate versions.
  • Co-locate branded type + arktype pipe with the workspace definition file for clarity and safety.
  • For optional foreign keys use .or('undefined') in the schema; for generated IDs cast via string to the branded type when creating values.

Example use cases

  • Create a users table with a single-version shorthand schema including id and _v.
  • Evolve a posts table: add views in v2 and write a migrate() that sets views for v1 rows.
  • Define a KV store for UI theme settings that starts without _v, then add a v2 with fontSize and a migration.
  • Implement branded ConversationId and ChatMessageId types so functions accept the correct ID types and avoid mixups.
  • Convert a legacy shorthand table to the builder pattern to support future schema versions and migrations.

FAQ

No. KV stores are flexible: _v is optional. You can version by field presence or include _v as an explicit discriminant if you prefer.

Should migrations incrementally step through each version?

No. Migrations should produce the latest version in one operation. Use switch(row._v) and return the latest shape directly to avoid complexity.

Why brand IDs instead of using plain strings?

Branded ID types prevent accidentally passing one table's ID where another is expected. The compiler will catch mismatches that would otherwise compile silently as plain strings.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational
workspace-api skill by epicenterhq/epicenter | VeilStrat