From spicedb-dev
Use when designing SpiceDB schemas, modeling permission hierarchies, or choosing between RBAC/ReBAC/multi-tenant patterns - guides resource/relation/permission design with pattern examples and anti-pattern checks
npx claudepluginhub authzed/authzed-marketplace --plugin spicedb-devThis skill uses the workspace's default tool permissions.
This skill guides the design of effective SpiceDB schemas for authorization systems. Use this when modeling permissions, relationships, and access control for applications.
examples/basic-rebac.yamlexamples/caveats.yamlexamples/docs-style-sharing.yamlexamples/entitlements.yamlexamples/github-style.zedexamples/github.yamlexamples/google-docs-style.zedexamples/google-iam.yamlexamples/multi-tenant-saas.zedexamples/superuser.yamlexamples/user-defined-roles.yamlreferences/anti-patterns.mdreferences/patterns.mdreferences/schema-evolution.mdImplements structured self-debugging workflow for AI agent failures: capture errors, diagnose patterns like loops or context overflow, apply contained recoveries, and generate introspection reports.
Monitors deployed URLs for regressions in HTTP status, console errors, performance metrics, content, network, and APIs after deploys, merges, or upgrades.
Provides React and Next.js patterns for component composition, compound components, state management, data fetching, performance optimization, forms, routing, and accessible UIs.
This skill guides the design of effective SpiceDB schemas for authorization systems. Use this when modeling permissions, relationships, and access control for applications.
SpiceDB uses a schema language to define:
Good schema design requires understanding the application's domain, identifying resources and their relationships, and modeling permissions that reflect business requirements.
| Need to... | Read This |
|---|---|
| Find a pattern for your use case | references/patterns.md |
| Check if a design is an anti-pattern | references/anti-patterns.md |
| See a working GitHub-style schema | examples/github-style.zed or examples/github.yaml |
| See a Google Docs-style schema | examples/google-docs-style.zed or examples/docs-style-sharing.yaml |
| See a multi-tenant SaaS schema | examples/multi-tenant-saas.zed |
| See a minimal two-role ReBAC schema | examples/basic-rebac.yaml |
| See caveats / ABAC (IP allowlist, rate limits) | examples/caveats.yaml |
| See SaaS feature entitlements / plan gating | examples/entitlements.yaml |
| See platform-level superuser / admin bypass | examples/superuser.yaml |
| See user-defined roles (like JIRA project roles) | examples/user-defined-roles.yaml |
| See Google IAM-style role hierarchy | examples/google-iam.yaml |
| Evolve an existing schema safely | references/schema-evolution.md |
Use this skill when:
To run an interactive permission model design session, use /spicedb-dev:design-model.
It scans your codebase for existing models, asks about resources and access patterns, and
produces permission-model.md. This skill provides pattern guidance and anti-pattern checks
during that session -- no separate invocation needed.
Add use typechecking at the top of your schema to enable compile-time type checking of
permissions. Annotate permissions with their return subject type:
use typechecking
definition document {
relation viewer: user
relation admin: serviceaccount
permission view: user = viewer // Annotated return type
// permission edit: user = admin // This FAILS type-check: admin is serviceaccount, not user
}
Without use typechecking, permission edit = admin & viewer silently compiles but always
returns false when admin and viewer are different subject types. Type checking surfaces
this at schema write time.
See references/anti-patterns.md for the full anti-pattern reference with ❌/✅ examples.
Key anti-patterns: permission explosion, confusing relations with permissions, excessive nesting,
wildcard overuse, caveat misuse, schema bloat, missing hierarchy, circular dependencies.
If you find yourself:
references/patterns.mdreferences/anti-patterns.md.zed files -- use /spicedb-dev:generate-schema for that/spicedb-dev:implement-spicedb-checks or /spicedb-dev:implement-spicedb-relationships for that/spicedb-dev:test-permissions for thatspicedb-best-practices skill for thatSchema design is iterative. Follow this workflow:
For detailed patterns and advanced techniques, consult:
references/patterns.md - Comprehensive pattern library with detailed examplesreferences/anti-patterns.md - Common mistakes and how to fix themWorking schema examples in examples/. Files ending in .yaml use the zed validate
format and include relationships, assertions, and validation alongside the schema --
they can be run with zed validate <file.yaml>. Files ending in .zed are schema-only.
Plugin-authored examples:
examples/github-style.zed - Repository permissions modelexamples/google-docs-style.zed - Document sharing modelexamples/multi-tenant-saas.zed - SaaS with tenant isolationAuthZed community examples (source: https://github.com/authzed/examples/tree/main/schemas):
examples/basic-rebac.yaml - Minimal writer/reader patternexamples/caveats.yaml - ABAC with IP allowlists and rate limitingexamples/docs-style-sharing.yaml - Group hierarchies (parent-of and child-of patterns)examples/entitlements.yaml - SaaS plan/feature gatingexamples/github.yaml - GitHub-style orgs, teams, repos (canonical AuthZed version)examples/superuser.yaml - Platform admin bypass patternexamples/user-defined-roles.yaml - Runtime-created roles (JIRA-style)examples/google-iam.yaml - Google IAM-style role hierarchy (trimmed; see source for full)After designing, validate the schema:
zed validate schema.zedUse the schema-validator agent to automatically check schemas for issues and best practices.
Workflow summary: Identify resources → Map relations → Define permissions → Consider caveats → Validate with scenarios → Refine iteratively. Start simple; add complexity only when a concrete scenario requires it.