Skip to main content
skill CX Codex

astrale-domain — Claude Code skill: what it does, how to install

Guides creation, testing, schema design, and deployment of Astrale Domains. Keeps agents aligned with kernel boundaries and SDK import rules.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add astrale-os/cli --skill astrale-domain -a claude-code
Open on GitHub

What astrale-domain does

The skill organizes Astrale Domain engineering into phased stages: foundation, schema, callables, views, datasets, and testing. It uses an intent router to read only the necessary documents from references/, preventing the agent from relying on unverified API syntax.

Kernel isolation rules are enforced strictly. Domain code must import Core and DSL primitives exclusively through designated @astrale-os/sdk/* subpaths, never directly from @astrale-os/kernel-core or @astrale-os/kernel-dsl. Handlers execute only admitted calls: authorization belongs to Schema policies and callable auth modes, forbidding secondary auth layers in action logic.

Policy scopes require intentional node extents such as node(), polymorphic node(Class), or node.exact(Class). Any platform-level hurdles or unexpected SDK behaviors are directed to astrale issue.

What it helps with

  • scaffold new Astrale Domains according to the phased lifecycle
  • configure Schema-level access policies using explicit node extents
  • implement runtime handlers without direct kernel core imports
  • build representative test datasets under tests/ for Studio verification
  • plan schema migrations and data backfills

Example prompts for the agent

  • Scaffold a new domain following the schema and policy guidelines.
  • Implement an integration provider handler without creating a duplicate auth check.
  • Generate demo dataset fixtures under tests/ for Studio policy testing.

How to install astrale-domain

1Skills CLI (Vercel)

npx skills add astrale-os/cli --skill astrale-domain -a claude-code

2Manually: put the files in place

~/.claude/skills/astrale-domain/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/astrale-domain/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about astrale-domain

How do I install astrale-domain in Claude Code?

Run npx skills add astrale-os/cli --skill astrale-domain -a claude-code. The skill file installs to ~/.claude/skills/astrale-domain/SKILL.md.

What does the astrale-domain skill do?

It provides workflow phases and architectural constraints for building Astrale Domains, covering schemas, policies, runtime callables, views, and migrations.

What are the SDK import restrictions for an Astrale Domain?

Domain source code must import Core and DSL values only through @astrale-os/sdk/* semantic subpaths. Direct imports from @astrale-os/kernel-core, @astrale-os/kernel-dsl, or root SDK barrels are prohibited.

Source text

SKILL.md · Apache-2.0
---
name: astrale-domain
description: "Create, modify, test, migrate, or debug Astrale Domains: Schema, Policies, Action/Workflow runtime, integrations, Views, Datasets, and deployment. For a new Domain follow the phased workflow; for focused work load only the relevant references."
---

# Astrale Domain

Load detailed domain knowledge from the references that matches the goal.

## Kernel boundary

- Use Schema, executable evidence, and the SDK's Domain linter as guardrails.
- Domain source imports Core and DSL authoring values only through the matching semantic
  `@astrale-os/sdk/*` subpath. Do not import `@astrale-os/kernel-core` or
  `@astrale-os/kernel-dsl` directly, and do not replace them with a flat SDK root barrel.
- Keep authorization in Schema-owned Policy and callable `auth` mode; handlers execute only admitted
  calls and do not define a second authorization model.
- Choose each existential Policy Node extent deliberately: `node()` for topology-owned matching,
  `node(Class)` for a polymorphic Class family, or `node.exact(Class)` for exact identity.
- Treat the installed SDK's public exports and the current Domain source as authoritative
  for API syntax.

## Intent Router

Use this router to load only the references owned by the current task. For new Domains, also use the
phased workflow below; an existing public scaffold already satisfies its foundation phase.

- Scaffold, test, or configure TypeScript and Environments for a domain: read `references/development.md`.
- Deploy, install, publish or yank a version, roll back, rotate a deployment's secret, or decide who
  owns a development instance: read `references/release.md`.
- Author schema, vocabulary, properties, Class/Edge choices, or review a schema: read `references/schema.md` first. Always read it for schema work.
- Implement handlers, callable bindings, kernel calls, graph reads/writes, or cross-domain calls: read `references/runtime.md`.
- Wrap an external API, define an Integration/Provider, receive webhooks, or design side-effect/retry behavior: read `references/integrations.md`.
- Decide whether to reuse/import a native Astrale domain instead of modeling a capability yourself: read `references/domains.md`.
- Model sign-in users, invite/register existing people, assign Shell groups, or make someone an instance administrator: read `references/users.md`.
- Secure a Domain, Function, View, client call, public endpoint, identity, delegation, authentication mode, or Policy: read `references/policies.md`.
- Build or review browser views, mounted UI, View access, View resolution, or frontend design: read
  `references/views.md` and apply `astrale-frontend-design` for product-interface layout,
  interaction, and copy.
- Plan or qualify an installed Schema revision, data transition, or backfill; migrate a breaking
  change (a Root maintenance session by default); follow an install; repair data an install refuses;
  or uninstall a Domain with data: read `references/migration.md`.
- Optimize graph access, reduce round trips, choose indexes/queries, or review call patterns for latency: read `references/performance.md`.
- Author or update demo data — the Datasets under `tests/` the Studio draws and proves policies on:
  read `references/datasets.md`.
- Write tests, fixtures, demo flows, or smoke-test scenarios: read `references/testing.md`.
- Diagnose a failing live domain, issuer/discovery confusion, invocation routing, or runtime drift:
  read `references/debugging.md`.

## New Domain Creation Workflow

For a request to create, build, prototype, or make a POC of a Domain, follow the applicable phases in
order and load a reference only when its phase begins.

1. **Foundation:** Inspect the workspace first. When no public scaffold exists, read
   `references/development.md`; read `references/domains.md` only when deciding whether to reuse a
   native Domain. When the workspace already declares the SDK, deployment adapter, Domain definition, and
   Runtime, keep that plumbing and move directly to Schema.
2. **Schema:** Before authoring the schema, read `references/schema.md`; for sign-in users and groups,
   also read `references/users.md` before inventing identity or onboarding vocabulary.
3. **Callables:** Before implementing callables, read `references/runtime.md` and
   `references/policies.md`. If an external system is involved, also read `references/integrations.md`.
4. **Views:** When the Domain owns a browser surface, read `references/views.md` before designing or
   implementing it. Views are Schema declarations, not fields on the SDK Domain definition. Every View
   belongs to its Domain; node screens are internal routes of its frontend, not Class-bound Views.
5. **Demo data:** For a Domain with a meaningful sample graph, author a small Dataset under `tests/`,
   referenced from `astrale.config.ts`. Read `references/datasets.md` first; do not invent graph data
   for an API-only Domain or expand a focused edit into unrelated demo work.
6. **Completion:** Read `references/testing.md`; exercise the delivered public callables with
   representative success and applicable refusal inputs, then run the relevant tests, typecheck,
   lint, and build. Verify packaging when delivering a consumable package and live behavior when
   claiming deployment or integration success.

Read `references/migration.md`, `references/performance.md`, and `references/debugging.md` only when the
domain's lifecycle or current problem calls for them.

## Always-On Workflow

1. Inspect the current repo or scaffold before trusting API syntax from memory.
2. For live behavior, use `references/debugging.md` and prove the deployed/installed/runtime path before treating source edits as effective.
3. When a Schema change affects existing Datasets, keep them valid and representative in the same
   change. Read `references/datasets.md`; examples complement tests rather than exhaust every case.
4. When a problem that blocks you, costs significant time, or forces an unsatisfactory workaround
   points to Astrale rather than to this Domain, report it with `astrale issue` as the `astrale-cli`
   skill describes.

© astrale-os · Apache-2.0 · astrale-os/cli

Similar skills

All skills for Backend and APIs →

From the same set2

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor