spicedb-dev review, pricing and limits

For engineers who would rather script SpiceDB authorization than hand-write it, spicedb-dev turns an agent into an authorization pair-programmer. Its underlying database has 7,077 GitHub stars and backs production authorization at OpenAI and Netflix; the plugin itself is new and still lightly starred.

spicedb-dev is a free Claude Code and Codex CLI plugin from AuthZed covering SpiceDB authorization: planning, permission modeling, schema generation, implementation, coverage auditing, and a phased migration off OpenFGA, Okta FGA or Oso Cloud. It runs against SpiceDB, Apache-2.0-licensed and inspired by Google Zanzibar.

Maker: AuthZed · Protocol: CUSTOM · Auth: none

Compatible agents: Claude Code, Codex CLI

Required runtime: Claude Code or Codex CLI with plugin support, SpiceDB CLI (`zed`) for schema validation, A local or hosted SpiceDB instance for any command beyond planning (e.g. `spicedb serve-testing` locally)

About spicedb-dev

spicedb-dev is a free, open source Claude Code and Codex CLI plugin published by AuthZed, the company behind SpiceDB, the Apache-2.0-licensed, Google Zanzibar-inspired permissions database with 7,077 GitHub stars. Rather than a single prompt, it packages a set of slash commands and bundled Claude Skills that walk an agent through the authorization lifecycle: planning, permission modeling, schema generation, implementation, testing, coverage auditing, and a phased migration off OpenFGA, Okta FGA or Oso Cloud.

Each command is a scoped step, not a do-everything wrapper. The plan and design-model commands interview the agent about the application, first scanning any existing Prisma, Django, Rails or SQL schema, and write authorization-plan.md and permission-model.md as shareable artifacts. The generate-schema command turns that model into a SpiceDB .zed file and runs schema validation automatically through a dedicated schema-validator agent. Nothing calls a hosted API by default; local testing runs against a spicedb serve-testing process and the zed CLI, so no AuthZed account or API key is required for the planning, design or code-generation commands.

It installs into Claude Code or Codex CLI via a single marketplace add command. The migration commands are the most involved part of the toolkit: a pre-flight gate batches every decision (tenancy model, identifier strategy, data rewrite rules) into one migration-map.json, which four downstream phases then read from, so a team migrating a live OpenFGA deployment does not re-decide the same tradeoffs command by command. A separate coverage command is the standalone use case for teams that already run SpiceDB: it cross-references a .zed schema against real permission-check calls in Go, TypeScript or Python code to flag permissions with no enforcing code.

SpiceDB itself is free and self-hostable under Apache-2.0. AuthZed also sells a managed Cloud tier billed by usage, plus quoted Self-Hosted and Dedicated Cloud enterprise plans, per AuthZed's published pricing page; none of that is required to use the plugin's planning, design or code-generation commands against a local test instance.

The authzed-marketplace repository that hosts the plugin was created in March 2026 and was still being pushed to in mid-September 2026, days before this listing, putting it in active, ongoing development rather than a one-off release.

Key Features

• 15 commands cover the full authorization lifecycle: From a first planning session through schema design, code implementation, testing and coverage auditing, to a full migration off another authorization system.
• 8 bundled Claude Skills modules: authorization-planner, authorization-testing, migrating-to-spicedb, openfga-to-spicedb, oso-to-spicedb, spicedb-best-practices, spicedb-client-integration and spicedb-schema-design give the agent reusable SpiceDB expertise beyond a single command's prompt.
• Migration decisions are gated in one batch: The migrate command resolves tenancy model, identifier strategy and data-rewrite rules once into migration-map.json, so the four downstream phases stay consistent instead of re-deciding the same tradeoffs.
• Coverage auditing against real code, not just the schema: audit-coverage cross-references a .zed schema against actual permission-check calls in Go, TypeScript or Python source to flag endpoints with no enforcing code.
• Generated tests are runnable, not just prose: test-permissions and migrate-tests both emit language-specific test files (Go, TypeScript, Python or SpiceDB validation YAML) with JSON relationship fixtures.
• No hosted account required for local development: The planning, design, schema-generation and validation commands run entirely against a local `spicedb serve-testing` process and the open-source `zed` CLI.

Use Cases

• Bootstrap authorization for a new multi-tenant feature: Run /spicedb-dev:plan and /spicedb-dev:design-model to turn a plain-English app description into a scoped permission model and a phased implementation plan before writing any schema.
• Migrate off OpenFGA without hand-rewriting every call site: Run the phased /spicedb-dev:migrate pipeline to convert the authorization model, migrate live relationship data, rewrite OpenFGA client calls to SpiceDB, and regenerate the test suite.
• Find authorization checks that were never actually implemented: Run /spicedb-dev:audit-coverage against a .zed schema to get a permission-by-permission matrix of which endpoints have a check call in code and which are silently unprotected.
• Generate a real regression test suite for a new permission model: Run /spicedb-dev:test-permissions to produce language-specific positive and negative test cases plus JSON relationship fixtures instead of writing SpiceDB test data by hand.

Install

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

Requirements

• Claude Code or Codex CLI with plugin support enabled
• SpiceDB CLI (`zed`) installed locally for schema validation
• A running SpiceDB instance for any command past planning/design (local `spicedb serve-testing` works; no AuthZed Cloud account needed)

Actions

Plan

Scopes an application's authorization needs, classifies complexity, and writes a phased authorization-plan.md naming the exact next commands to run.

/spicedb-dev:plan "multi-tenant SaaS with teams, projects, and role-based sharing"

• app-description (string): Free-text description of the application; the command also asks clarifying questions interactively if omitted.

Design Model

Runs an interactive session that maps an application's resources, relationships and permissions into a structured permission model, reusing any existing database schema it can find.

/spicedb-dev:design-model "project management tool with orgs, teams, and shared documents"

• app-description (string): Free-text description of the app; the command also scans for existing Prisma, Django, Rails or SQL schemas.

Generate Schema

Converts a permission-model.md document into a SpiceDB .zed schema file and runs validation automatically.

/spicedb-dev:generate-schema permission-model.md schema.zed

• model-file (string): Path to the permission model document; the command searches the project if omitted.
• output-file (string): Path to write the generated .zed schema.

Validate Schema

Runs the schema-validator agent over a .zed file for syntax errors, naming convention issues and anti-patterns, without needing a live SpiceDB instance.

/spicedb-dev:validate-schema schema.zed

• schema-file (string): Path to the .zed file; the command searches the current directory if omitted.

Implement SpiceDB

Router command that adds SpiceDB relationship writes, permission checks, or both to application code, running writes before checks when both are needed.

/spicedb-dev:implement-spicedb checks

• mode (string): checks or relationships; the command asks interactively if omitted.

Implement SpiceDB Relationships

Adds SpiceDB relationship writes and deletes to application code in Go, TypeScript or Python, enforcing primary-database-first write ordering.

/spicedb-dev:implement-spicedb-relationships src/services/permissions.ts

• target-files (string): Files or directories to modify.

Implement SpiceDB Checks

Adds permission check and lookup calls (single, bulk, resource lookup, subject lookup) to application code across Go, TypeScript or Python, with fail-safe deny-on-error handling.

/spicedb-dev:implement-spicedb-checks src/api/documents.go

• target-files (string): Files or directories to modify.

Audit Coverage

Compares a SpiceDB schema's declared permissions against actual permission-check calls in the codebase and produces a coverage matrix of protected versus unprotected endpoints.

/spicedb-dev:audit-coverage schema.zed

• schema-file (string): Path to the .zed schema to audit against.

Test Permissions

Generates language-specific test suites plus JSON relationship fixtures from a SpiceDB schema, covering direct, hierarchical and revoked access scenarios.

/spicedb-dev:test-permissions schema.zed tests/authz

• schema-file (string): Path to the .zed schema.
• output-dir (string): Directory to write generated tests and fixtures into.

Migrate

Phase 0 entry point for migrating an application from OpenFGA, Okta FGA or Oso Cloud to SpiceDB: launches a migration-analyzer agent, batches every migration decision into one gate, and writes a migration-map.json the downstream phases read from.

/spicedb-dev:migrate ./my-app ./migration-out

• project-dir (string): Path to the application being migrated.
• output-dir (string): Directory to write migration-map.json and migration-plan.md.

Migrate Schema

Phase 1 of the migration pipeline: converts the source system's authorization model into a SpiceDB .zed schema, using decisions from migration-map.json when present.

/spicedb-dev:migrate-schema fga-model.json ./migration-out

• model-file (string): Source authorization model file.
• output-dir (string): Directory to write the generated schema and updated migration record.

Migrate Data

Phase 3 of the migration pipeline: extracts, transforms, loads and verifies relationship data from a live source store into SpiceDB, with a mandatory dry run and independent recount before any live write.

/spicedb-dev:migrate-data my-openfga-store ./migration-out

• store-id (string) — required: Identifier of the live source authorization store to read from.
• output-dir (string): Directory holding migration-map.json and where outputs are written.

Migrate Code

Phase 4 of the migration pipeline: vendors a SpiceDB client into the project and rewrites OpenFGA or Oso Cloud call sites into SpiceDB equivalents, leaving TODO markers where manual review is required.

/spicedb-dev:migrate-code ./my-app ./migration-out

• project-dir (string): Path to the application whose call sites are being rewritten.
• output-dir (string): Directory holding migration-map.json.

Migrate Tests

Phase 5 of the migration pipeline: converts a source system's test fixtures and assertions into SpiceDB validation YAML, validated through the zed CLI.

/spicedb-dev:migrate-tests fga_test.json ./migration-out

• test-file (string): Path to the source test or assertion file.
• output-dir (string): Directory to write the converted validation YAML.

Migrate Verify

Generates a differential test harness that dual-runs SpiceDB alongside the live source system, safely diffing authorization decisions and converting confirmed agreements into regression tests before cutover.

/spicedb-dev:migrate-verify ./my-app ./migration-out

• project-dir (string): Path to the application under migration.
• output-dir (string): Directory to write the generated harness into.

How to Invoke

Installed as a Claude Code / Codex CLI plugin marketplace entry. Exposed as 15 named slash commands (e.g. /spicedb-dev:plan, /spicedb-dev:generate-schema, /spicedb-dev:audit-coverage) the agent runs directly, backed by 8 bundled Claude Skills modules for SpiceDB-specific expertise.

Pricing

The spicedb-dev plugin itself is free and open source (Apache-2.0), as is self-hosted SpiceDB. AuthZed's managed offerings on top of SpiceDB (Cloud, Self-Hosted, Dedicated Cloud) are separate paid tiers, not a requirement to use the plugin.

Strengths

• A single toolkit spans the entire authorization workflow, from a first plan session through schema design and testing to a full pipeline for moving off a competing authorization system.
• Free and self-hostable; the planning, design and schema-generation commands work entirely offline against a local spicedb serve-testing instance, no license required.
• The underlying SpiceDB database it plugs into has 7,077 GitHub stars and is used in production for authorization at named companies including OpenAI and Netflix, per AuthZed's published case studies.
• 8 bundled Claude Skills modules give the agent SpiceDB-specific expertise (schema design, client integration, conversion packs for 3 competing systems) beyond what a single command prompt could hold.

Weaknesses

• audit-coverage relies on pattern matching against string literals in the docs' own words; runtime-computed or variable-stored permission names are not detected.
• The migration pipeline is gated and sequential (migrate then migrate-schema, migrate-data, migrate-code, migrate-tests in order); skipping the phase 0 decision gate halts every downstream phase rather than guessing.
• The authzed-marketplace repository that hosts the plugin itself had 2 GitHub stars as of September 2026; it is a new, lightly-adopted packaging of a mature underlying database.
• Most commands assume a Go, TypeScript or Python codebase; other languages get no generated code or tests.

View the official spicedb-dev skill page