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.
npx skills add astrale-os/cli --skill astrale-domain -a claude-codeWhat 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-code2Manually: put the files in place
~/.claude/skills/astrale-domain/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/astrale-domain/
1Skills CLI (Vercel)
npx skills add astrale-os/cli --skill astrale-domain -a codex2Manually: put the files in place
.agents/skills/astrale-domain/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add astrale-os/cli --skill astrale-domain -a cursor2Manually: put the files in place
.cursor/skills/astrale-domain/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install astrale-os/cli astrale-domain2Manually: put the files in place
.github/skills/astrale-domain/SKILL.md1Skills CLI (Vercel)
npx skills add astrale-os/cli --skill astrale-domain -a gemini-cli2Platform CLI
gemini skills install https://github.com/astrale-os/cli --path skills/astrale-domainManually: put the files in place
.devin/skills/astrale-domain/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add astrale-os/cli --skill astrale-domain -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
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