Build with your AI agent

If you’re building with an AI coding agent, you don’t have to design and wire up SpiceDB authorization by hand. The spicedb-dev plugin teaches your agent how to design a permission model, generate a schema, write the relationship and permission-check code, audit coverage as your app grows, generate tests, and migrate an existing authorization solution (OpenFGA, Okta FGA, OSO, etc.) onto SpiceDB. It’s useful throughout the lifecycle, from exploration and design through implementation and testing, and can also help debug and harden an authorization setup you already have.

It’s an official AuthZed plugin, distributed through the AuthZed marketplace .

Prerequisites

• An AI coding agent. See Other agents below if you’re not using Claude Code or Codex CLI.

• A running SpiceDB instance for the implementation steps. The fastest option is an in-memory instance with no setup:

  spicedb serve-testing

  This starts SpiceDB on localhost:50051 with no persistence: data is lost on restart, which is fine for development. For a persistent local instance, see Datastores; for a hosted, self-service instance, see AuthZed Cloud .

• The zed CLI installed: the plugin’s schema-validator agent uses it to validate .zed files.

Install the plugin

Claude Code

/plugin marketplace add authzed/authzed-marketplace
/plugin install spicedb-dev@authzed-marketplace

Codex CLI

codex plugin marketplace add authzed/authzed-marketplace
codex plugin add spicedb-dev@authzed-marketplace

Other agents

Claude Code and Codex CLI are the only integrations tested against this plugin. If you’re on a different AGENTS.md-reading harness, the most reliable path is to read the plugin’s skills  directly from the marketplace repository and copy the authorization snippet described in Plan your authorization into your own AGENTS.md by hand. That gets you the plugin’s guidance without depending on slash-command support.

What the plugin can do

• Design a permission model interactively, starting from entities it finds in your existing data model (Prisma, Django, Go structs, GraphQL, or SQL)
• Generate a SpiceDB schema from that model, and validate any .zed file for anti-patterns
• Implement authorization in code: relationship writes (WriteRelationships, DeleteRelationships) and permission checks (CheckPermission, BulkCheckPermission, LookupResources, LookupSubjects) in Go, TypeScript, Python, C#, Java, Rust, and Ruby
• Audit permission coverage across your codebase: for every permission in your schema, see whether a check exists in code, and catch unfiltered list endpoints, which is useful for debugging and hardening an authorization setup you didn’t build with the plugin, too
• Generate tests: positive, negative, and hierarchical-inheritance test fixtures and integration tests, generated from your schema
• Migrate from an existing authorization solution (OpenFGA, Okta FGA, OSO, etc.): convert the model, the relationship data, the application code, and the tests, then verify the migration with a differential test harness before cutover

Plan your authorization

Start any new project with:

/spicedb-dev:plan

This scopes the work and produces authorization-plan.md. It also writes an authorization snippet into your project’s CLAUDE.md (or AGENTS.md) — the single most effective step, since it means your agent considers SpiceDB writes and checks automatically whenever it generates or modifies a handler, without you invoking a command every time.

Build a feature end to end

After generating a schema, deploy it to your SpiceDB instance:

zed schema write schema.zed --endpoint localhost:50051 --token my-token

Migrating to SpiceDB

If you already run an existing authorization solution (OpenFGA, Okta FGA, OSO, etc.):

/spicedb-dev:migrate /path/to/your/project

This analyzes your project and holds a single pre-flight gate: every decision that can’t be made mechanically (tenancy shape, identifier encoding, permission naming) is asked once, up front, and recorded. From there it converts the schema, migrates relationship data, rewrites client call sites, and converts your tests, phase by phase. It will not push, open a pull request, or work on your default branch, and it won’t run your cutover for you — a generated differential test harness lets you dual-run SpiceDB beside your existing system and confirm the two agree before you flip over.

Learn more