From rai-ast
Use when an agent needs to interact with the Rendered.ai Agent Studio platform — authentication, workspace management, creating servers, running service jobs, managing data in volumes, skills, MCP servers, and more.
How this skill is triggered — by the user, by Claude, or both
Slash command
/rai-ast:rai-astThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Agent Studio is a cloud platform for AI-assisted development. Users configure **workspaces** that bundle tools (services), data (volumes), behavior rules, and MCP integrations. From a workspace, users launch **servers** — cloud development environments with a built-in IDE and AI agent (Claude Code). Services are developed, tested, deployed and used **on** servers. Service jobs run **within** wo...
Agent Studio is a cloud platform for AI-assisted development. Users configure workspaces that bundle tools (services), data (volumes), behavior rules, and MCP integrations. From a workspace, users launch servers — cloud development environments with a built-in IDE and AI agent (Claude Code). Services are developed, tested, deployed and used on servers. Service jobs run within workspace context. Volumes mount to servers for persistent, shared storage.
Before running any command, determine which binary to use:
# 1. Already on PATH
if command -v rai-ast >/dev/null 2>&1; then
CLI="rai-ast"
# 2. Claude Code skill directory
elif [ -f "$HOME/.claude/skills/rai-ast/bin/rai-ast" ]; then
CLI="$HOME/.claude/skills/rai-ast/bin/rai-ast"
# 3. Gemini skill directory
elif [ -f "$HOME/.gemini/skills/rai-ast/bin/rai-ast" ]; then
CLI="$HOME/.gemini/skills/rai-ast/bin/rai-ast"
# 4. Codex skill directory
elif [ -f "$HOME/.codex/skills/rai-ast/bin/rai-ast" ]; then
CLI="$HOME/.codex/skills/rai-ast/bin/rai-ast"
# 5. Legacy default install location
elif [ -f "$HOME/.local/bin/rai-ast" ]; then
CLI="$HOME/.local/bin/rai-ast"
# 6. Install from GitHub
elif curl -fsSL https://raw.githubusercontent.com/renderedai/rai-agent-studio-cli/main/install.sh | bash; then
CLI="$HOME/.local/bin/rai-ast"
# 7. Offline fallback — build from source (requires git + cargo)
elif command -v cargo >/dev/null 2>&1 || [ -x "$HOME/.cargo/bin/cargo" ]; then
CARGO="${HOME}/.cargo/bin/cargo"
command -v cargo >/dev/null 2>&1 && CARGO="cargo"
git clone https://github.com/renderedai/rai-agent-studio-cli /tmp/agent-studio-cli 2>&1
cd /tmp/agent-studio-cli
$CARGO build --release 2>&1
CLI="/tmp/agent-studio-cli/target/release/rai-ast"
else
echo "ERROR: Cannot install rai-ast." >&2
echo "" >&2
echo "All install methods failed. To build from source, install the following dependencies:" >&2
echo " 1. git — https://git-scm.com/downloads" >&2
echo " 2. cargo — curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh" >&2
echo "" >&2
echo "Then re-run this script, or build manually:" >&2
echo " git clone https://github.com/renderedai/rai-agent-studio-cli /tmp/agent-studio-cli" >&2
echo " cd /tmp/agent-studio-cli && cargo build --release" >&2
echo " cp target/release/rai-ast ~/.local/bin/" >&2
exit 1
fi
Use $CLI in place of rai-ast in all commands below.
These apply to every command:
| Option | Description | Default |
|---|---|---|
--format <json|table> | Output format | json |
--env <prod|test|dev|local> | Target environment (env: RENDEREDAI_ENV) | prod |
--api-key <KEY> | API key, overrides config (env: RENDEREDAI_API_KEY) | — |
--bearer-token <TOKEN> | Bearer token, overrides API key (env: RENDEREDAI_BEARER_TOKEN) | — |
-v, --verbose | Debug logging | off |
Auth priority: --bearer-token > --api-key > config file > keychain token.
Both auth login and auth register use a two-phase OAuth pattern. This is the first step for any new user.
Phase 1: run auth login / auth register → exits immediately, prints [INSTANCE_ID] [WAIT_TOKEN]
Phase 2: start auth callback in background IMMEDIATELY → blocks on SSE until tokens arrive
Then: present the URL to the user → wait for background task completion notification
Do NOT:
Do:
auth callback in the background immediately after parsing Phase 1 outputRun synchronously (not in background) — it exits immediately:
$CLI auth login 2>&1
[AUTH_URL] https://keycloak.example.com/realms/renderedai/protocol/openid-connect/auth?client_id=...
[INSTANCE_ID] xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
[WAIT_TOKEN] yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
[ACTION] Start `auth callback --instance-id xxx --wait-token yyy` in the background, then present AUTH_URL to the user...
Start this immediately after Phase 1, in the background — before presenting the URL to the user:
$CLI auth callback \
--instance-id <INSTANCE_ID_FROM_PHASE_1> \
--wait-token <WAIT_TOKEN_FROM_PHASE_1> \
2>&1
Use run_in_background: true (Bash tool) so the agent continues while the callback waits on SSE.
If your client cannot run background processes, use auth status instead of auth callback. It makes a single GET request and returns immediately:
$CLI auth status \
--instance-id <INSTANCE_ID_FROM_PHASE_1> \
--wait-token <WAIT_TOKEN_FROM_PHASE_1> \
2>&1
[AUTH_COMPLETE] — tokens stored, user is authenticated (exit code 0)[AUTH_WAITING] — user hasn't completed browser flow yet (exit code non-zero)[AUTH_FAILED] — error occurred (exit code non-zero)Call auth status on your own schedule — retry until you get [AUTH_COMPLETE] or [AUTH_FAILED].
auth login synchronously — parse [AUTH_URL], [INSTANCE_ID], [WAIT_TOKEN]auth callback --instance-id <ID> --wait-token <TOKEN> in the background (or use auth status if background processes are unavailable)[AUTH_USER] and tell the user they're logged inIf you see Warning: Manager relay login failed, the CLI fell back to the paste-URL flow:
[AUTH_URL]http://localhost:9090/?code=... (page won't load)$CLI auth register 2>&1
[REGISTER_URL] https://deckard.example.com/register-as/?source=cli&instanceId=xxx&loginUrl=<encoded>
[INSTANCE_ID] xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
[WAIT_TOKEN] yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
auth callback (or auth status) command as loginauth register synchronously — parse [REGISTER_URL], [INSTANCE_ID], [WAIT_TOKEN]auth callback --instance-id <ID> --wait-token <TOKEN> in the background (or use auth status if background processes are unavailable)[AUTH_USER] and tell the user they're registered and logged in[REGISTER_URL] → Deckard registration formNote on email verification: The verification link in the email goes to Keycloak, not back to the Deckard verify page. The user should keep the Deckard verify tab open so they can click "Continue to Login" after verifying.
[AUTH_USER] c w ([email protected]) | MyOrg
[AUTH_COMPLETE] Tokens stored. You are authenticated.
If the output is unavailable when notified (file cleaned up), fall back to:
$CLI auth whoami 2>&1
IMPORTANT: The labeled output ([AUTH_URL], [REGISTER_URL], [INSTANCE_ID], etc.) is
for the agent to parse — never show raw labels or technical details to the user.
For login — before: show the user something like:
Please open this link to log in:
https://keycloak.example.com/realms/...
I'm waiting in the background — you'll be signed in automatically once you complete the browser flow.
For register — before: show something like:
Please open this link to create your account:
https://deckard.example.com/register-as/...
After signing up, check your email and click the verification link. I'm waiting in the background — you'll be signed in automatically once you're done.
After login/register — parse [AUTH_USER] and show:
You're logged in as c w ([email protected]) on the MyOrg organization.
Keep it simple — no instance IDs, wait tokens, phases, or JSON dumps.
| Output | Meaning |
|---|---|
RENDEREDAI_MANAGER_URL is not set | Should not occur with prod defaults — set RENDEREDAI_ENV=prod |
RENDEREDAI_DECKARD_URL is not set | Should not occur with prod defaults (register only) |
Manager relay returned error | Management server rejected the request |
Invalid wait token — access denied | Wrong wait_token — re-run Phase 1 |
Session expired or not found | Took too long — re-run Phase 1 |
Timed out waiting for authentication | User didn't complete browser flow within 15 min |
Auth failed: Token exchange with Keycloak failed | Server-side PKCE exchange failed |
KEYCLOAK_ISSUER or KEYCLOAK_CLI_REDIRECT_URI env vars.RENDEREDAI_MANAGER_URL. Check: curl -s $RENDEREDAI_MANAGER_URL/healthdeckard client's "Valid redirect URIs".export RENDEREDAI_MANAGER_URL="" && $CLI auth login 2>&1Agent Management Server Keycloak / Deckard
| | |
| Phase 1: auth login/register |
|-- POST /cli-auth -------->| |
|<-- { url, instanceId, | |
| waitToken } | |
| | |
| print [URL] [INSTANCE_ID] [WAIT_TOKEN] → exit Phase 1|
| | |
| Phase 2: auth callback (background) |
|== GET /events/:id =======>| (SSE connection held open)|
| ?token=waitToken | |
| | |
| [present URL to user] |
| | |
| [user opens url in browser] ----------------------->|
| [user completes flow] |
| |<-- GET /callback?code= ---|
| |-- POST /token (PKCE) ---->|
| |<-- { access_token } ------|
| | |
|<== SSE push: { success, | (instant delivery) |
| token, refreshToken } | |
| | |
| stores tokens, sets org | |
| background task exits 0 | |
| → agent notified → tells user they're authenticated |
After authentication, get the user into a running server as fast as possible. The server URL is the deliverable of onboarding — not the workspace ID. Do not explain all platform concepts upfront. Do not list all available features. Do not ask "what would you like to do next?" — the next step is always: open the IDE.
organizations get --format tableorganizations use --organization-id <ORG_ID>Do not skip this step. If you default to the wrong org, everything downstream is wrong.
Important: Once the organization is confirmed, use --organization-id <ORG_ID> on all subsequent commands to scope results to that org. Without it, queries return resources across ALL organizations the user belongs to.
workspaces get --organization-id <ORG_ID> --format tablehttps://deckard.rendered.ai/<organizationId>/examples/workspaces/workspaces createservers get --format tablehttps://<editorId>.tyrell-proxy.prod.rendered.ai/#/workspaceservers start --editor-id <EDITOR_ID>, then construct the URLAfter giving the URL, say something like:
Your workspace "lens-design" is ready, and a server is running for you.
Open your IDE here: https://ed-1234567890.tyrell-proxy.prod.rendered.ai/#/workspace
Once you're in, your AI assistant can help you find and use services, work with data, and more.
Do NOT:
Do:
User: Can you help me get started with Rendered.ai Agent Studio?
Agent: [resolves CLI, checks auth — already logged in]
Welcome back, Ethan! You're authenticated.
You belong to multiple organizations:
- Rendered.ai Agent Studio
- Nullspace
Which organization would you like to work in?
User: Rendered.ai Agent Studio
Agent: [switches org, checks workspaces — none found]
You don't have any workspaces yet in this org.
Would you like to create a new one, or explore an example
workspace from the marketplace?
User: Create a new one for lens design
Agent: [creates workspace, checks servers, constructs URL]
Your workspace "lens-design" is ready, and a server is
running for you.
Open your IDE here:
https://ed-1773262942743.tyrell-proxy.prod.rendered.ai/#/workspace
Once you're in, your AI assistant can help you find and use
services, work with data, and more.
Notice: no feature dump, no "what next?", no IDs shown. The user goes from zero to a running IDE in four exchanges.
Once the user is on a server, introduce concepts only when the user's current task requires it:
| User wants to... | Introduce... | How |
|---|---|---|
| Work with data or files | Volumes | Create/upload a volume, attach to workspace, show mount path |
| Use a tool or run a job | Services | Browse available services, attach one, run a job with it |
| Change how the AI behaves | Rules | Show current rules, edit workspace rules |
| Connect external tools (Slack, GitHub, etc.) | MCP Configs | Add an MCP server config to the workspace |
| Store API keys securely | Secrets | Add a workspace secret, explain it becomes an env var |
| Build a custom tool | Service development | Walk through scaffold → build → test → deploy on the server |
| Share with teammates | Members | Add members to the org or share workspace access |
| Reuse prompts or workflows | Skills | Explain skills, show how to create or attach one |
Always frame concepts in terms of the user's goal, not as abstract platform features. For example:
If the user explicitly asks to understand the platform or wants a walkthrough, suggest they start with an example workspace from the marketplace. Example workspaces come pre-configured with services, volumes, and rules — so the user can see everything working together before learning the individual pieces.
Walk them through what's already set up:
/workspace/volumes/<name>/."Learning by inspecting a working example is more effective than reading definitions.
Reference material for the agent — the concepts and URL patterns needed to help users effectively.
Organization
├── Members (roles: admin, member)
├── Organization Services (containerized tools, shared catalog)
├── Organization Volumes (shared storage across workspaces)
├── Organization Rules (company-wide agent behavior)
├── Organization MCP Configs (company-wide mcp configurations)
├── Organization Agent Skills (company-wide shared skills)
├── Organization Secrets (shared env vars)
└── Organization Workspaces (project configurations)
├── Workspace Services → agent can invoke their tools
├── Workspace Volumes → mounted to servers
│ ├── Workspace Volume (auto-created, scoped to workspace)
│ └── Organization Volumes (explicitly attached)
├── Workspace Rules (project-specific agent guidance)
├── Workspace MCP Configs + overrides
├── Workspace Secrets (project-specific env vars)
└── Workspace Servers (cloud dev environments, 1+ per workspace)
├── Configured Agent (Tyrell - browser only, Claude Code, Codex, Gemini, etc.)
│ ├── Agent Context (primed with combined rules)
│ ├── Agent MCP (ability to run service jobs, develop services, update rules, use custom MCPs, etc.)
│ └── Agent Skills (reusable prompt packages that extend agent capabilities for specific tasks)
├── Web IDE (browser, no setup needed)
├── Desktop IDE (VS Code, Cursor, Windsurf via SSH)
├── Mounted volumes at /workspace/volumes/<volume-name>/
├── Injected secrets as environment variables
└── Docker runtime for service development
organizations get to list, organizations use to switch)./workspace/volumes/<volume-name>/.| Resource | URL Pattern |
|---|---|
| Organization home | https://deckard.rendered.ai/<organizationId>/ |
| Workspace | https://deckard.rendered.ai/<organizationId>/workspaces/<workspaceId>/ |
| Volume | https://deckard.rendered.ai/<organizationId>/volumes/<volumeId>/ |
| Examples (main) | https://deckard.rendered.ai/<organizationId>/examples/ |
| Example workspaces | https://deckard.rendered.ai/<organizationId>/examples/workspaces/ |
| Resource | URL Pattern |
|---|---|
| Web IDE | https://<editorId>.tyrell-proxy.prod.rendered.ai/#/workspace |
All entity IDs (organization, workspace, volume, service, editor) use UUID format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
When a user provides a URL, parse out the relevant IDs:
| URL | Extracted IDs |
|---|---|
https://deckard.rendered.ai/abc123-…/workspaces/def456-…/ | organizationId=abc123-…, workspaceId=def456-… |
https://deckard.rendered.ai/abc123-…/volumes/ghi789-…/ | organizationId=abc123-…, volumeId=ghi789-… |
https://xyz789-….tyrell-proxy.prod.rendered.ai/#/workspace | editorId=xyz789-… |
If a user provides a URL that doesn't match the patterns above:
$CLI workspaces get --format table / $CLI servers get --format table to look up the correct IDsNever guess or fabricate IDs. Always verify with the CLI or ask the user.
# Register and authenticate
$CLI auth register # two-phase flow (see Auth section above)
$CLI auth whoami # verify identity
# Explore the platform
$CLI organizations get --format table # see your org(s)
$CLI workspaces get --format table # list workspaces
# Point user to the examples marketplace for getting started:
# https://deckard.rendered.ai/<organizationId>/examples/workspaces/
After registration, guide the user to create their first workspace or explore example workspaces in the marketplace.
$CLI auth login # two-phase flow (see Auth section above)
$CLI auth whoami # verify identity
$CLI workspaces get --format table # list workspaces
$CLI servers get --format table # check server status
If the user provides a Deckard URL, parse the IDs (see URL Patterns above) and use them directly.
# 1. Create workspace (auto-starts a server)
$CLI workspaces create \
--organization-id <ORG_ID> \
--name "My Workspace" \
--description "Description"
# 2. Attach services to the workspace
$CLI services get --format table # browse available services
$CLI services add-to-workspace \
--workspace-id <WS_ID> \
--service-ids <SERVICE_ID>
# 3. Attach volumes to the workspace
$CLI volumes get --organization-id <ORG_ID> --format table # list volumes
$CLI volumes add-to-workspace \
--workspace-id <WS_ID> \
--volume-ids <VOL_ID>
# 4. Check server status (one was auto-created with the workspace)
$CLI servers get --format table
# 5. If no running server, start one
$CLI servers start --editor-id <EDITOR_ID>
# 6. User opens the IDE:
# Browser: https://<editorId>.tyrell-proxy.prod.rendered.ai/#/workspace
# Desktop: VS Code / Cursor / Windsurf via SSH (requires SSH keys in Profile)
# 7. From within the IDE, the agent can:
# - Develop services (Docker build/test/deploy)
# - Run service jobs
# - Access volume data at /workspace/volumes/<volume-name>/
# - Use all attached services as tools
# Create an organization volume
$CLI volumes create \
--organization-id <ORG_ID> \
--name "My Data"
# Upload files
$CLI volume-data upload \
--volume-id <VOL_ID> \
--file /path/to/file.json
# Attach to workspace (makes it available on servers at /workspace/volumes/My Data/)
$CLI volumes add-to-workspace \
--workspace-id <WS_ID> \
--volume-ids <VOL_ID>
# Ensure service is attached to the workspace first
$CLI services add-to-workspace \
--workspace-id <WS_ID> \
--service-ids <SERVICE_ID>
# Submit job with payload
$CLI service-jobs create \
--workspace-id <WS_ID> \
--service-id <SERVICE_ID> \
--name "My Job" \
--payload '{"tool": "tool_name", "inputs": {"param1": "value1"}}'
# Check job status
$CLI service-jobs get --workspace-id <WS_ID> --format table
Payload format: {"tool": "<tool_name>", "inputs": {<parameters>}} — always include "inputs" even if empty.
Services are developed on servers inside the IDE:
~/.renderedai/templates or ask the agentservice.yaml (name, description, tools, inputs, outputs)entrypoint.py, Dockerfiledocker build -t my-service -f .devcontainer/Dockerfile .docker run -e payload='{"tool":"...","inputs":{...}}' -v /workspace:/workspace -u $(id -u):$(id -g) my-serviceanadeploy CLIGPU support: add --gpus all to docker run. Mount source code for rapid iteration without full rebuilds.
| Command | Required Options | Description |
|---|---|---|
auth login | — | OAuth2 PKCE login (two-phase, see above) |
auth logout | — | Clear stored credentials |
auth whoami | — | Show current user info |
auth register | — | Register new account (two-phase, see above) |
auth callback | --instance-id, --wait-token | Complete two-phase auth (run in background) |
auth status | --instance-id, --wait-token | Non-blocking auth check (single request, returns immediately) |
Options for auth login: --interactive (open browser directly).
| Command | Required Options | Optional |
|---|---|---|
organizations get | — | --organization-id, --limit (50), --cursor, --fields |
organizations edit | --organization-id, --name | — |
organizations use | — | --organization-id or --interactive (one required) |
| Command | Required Options | Optional |
|---|---|---|
workspaces get | — | --organization-id, --workspace-id, --limit (50), --cursor, --fields, --filters |
workspaces create | --organization-id, --name | --description, --tags |
workspaces edit | --workspace-id | --name, --description, --tags |
workspaces delete | --workspace-id | — |
| Command | Required Options | Optional |
|---|---|---|
members get | --organization-id | --limit (50), --cursor |
members add | --organization-id, --email, --role | — |
members remove | --organization-id, --email | — |
members edit | --organization-id, --email, --role | — |
Role values: admin, member.
| Command | Required Options | Optional |
|---|---|---|
volumes get | — | --organization-id, --workspace-id, --volume-id, --limit (50), --cursor, --fields, --filters |
volumes create | --organization-id, --name | --description, --permission (private|organization), --tags |
volumes edit | --volume-id | --name, --description, --permission, --tags |
volumes delete | --volume-id, --organization-id | — |
volumes add-to-workspace | --workspace-id | --volume-ids |
volumes remove-from-workspace | --workspace-id | --volume-ids |
| Command | Required Options | Optional |
|---|---|---|
volume-data get | --volume-id | --dir, --recursive (true|false), --limit (50), --cursor |
volume-data upload | --volume-id, --file | --key |
volume-data download | --volume-id | --keys, --output-dir |
volume-data delete | --volume-id | --keys |
| Command | Required Options | Optional |
|---|---|---|
services get | — | --organization-id, --workspace-id, --service-id, --limit (50), --cursor, --fields, --filters |
services create | --organization-id, --service-type-id, --name | --description, --instance, --tags |
services edit | --service-id | --name, --description, --instance, --tags |
services delete | --service-id | — |
services deploy | --service-id | — |
services types | — | — |
services instance-types | — | — |
services add-to-workspace | --workspace-id | --service-ids |
services remove-from-workspace | --workspace-id | --service-ids |
Service types:
| Command | Required Options | Optional |
|---|---|---|
service-jobs get | — | --workspace-id, --service-id, --limit (50), --cursor, --fields, --filters |
service-jobs create | --workspace-id, --service-id, --name | --description, --payload (JSON string), --payload-file (path) |
service-jobs delete | --workspace-id, --job-id | — |
Important: The CLI uses --editor-id (not --server-id) due to legacy naming. The UI calls these "servers" but the API still uses "editor" terminology.
| Command | Required Options | Optional |
|---|---|---|
servers get | — | --fields |
servers create | --name | --workspace-id, --instance, --storage-size (small=300GB, medium=500GB, large=1TB) |
servers delete | --editor-id | — |
servers start | --editor-id | — |
servers stop | --editor-id | — |
Server states:
Access methods:
https://<editorId>.tyrell-proxy.prod.rendered.ai/#/workspaceInstance types:
Use $CLI services instance-types to list available options with pricing.
| Command | Required Options | Optional |
|---|---|---|
api-keys get | — | --name |
api-keys create | --name, --scope (user|organization|workspace) | --organization-id, --workspace-id, --expires-at |
api-keys delete | --name | — |
MCP (Model Context Protocol) Configs connect additional MCP servers to extend agent capabilities with external tools and data sources.
| Command | Required Options | Optional |
|---|---|---|
mcp-servers get | --mode (organization|workspace|user|all|aggregated) | --organization-id, --workspace-id |
mcp-servers create | --scope-type (organization|workspace|user), --name, --config (JSON) | --organization-id, --workspace-id, --description, --enabled |
mcp-servers edit | --mcp-server-id | --name, --description, --config, --enabled |
mcp-servers delete | --mcp-server-id | — |
mcp-servers overrides | --workspace-id | — |
mcp-servers toggle-override | --workspace-id, --mcp-server-id | — |
Config example: '{"command":"npx","args":["@playwright/mcp@latest"]}'
Scope behavior:
| Command | Required Options | Optional |
|---|---|---|
skills get | — | --mode, --organization-id, --workspace-id, --scope-type, --name |
skills create | --scope-type, --name, --file (.tar.gz) | --organization-id, --workspace-id, --description, --version, --config |
skills edit | --skill-id | --name, --description, --version, --config, --enabled |
skills delete | --skill-id | — |
skills replace-package | --skill-id, --file | — |
skills overrides | --workspace-id | — |
skills toggle-override | --workspace-id, --skill-id | — |
Rules are text instructions that shape how agents work. They're compiled into the agent's context at startup.
Hierarchy (broadest → most specific, more specific overrides broader): Organization → User → Service → Workspace
| Command | Required Options |
|---|---|
rules get-platform | — |
rules get-organization | --organization-id |
rules edit-organization | --organization-id, --rules |
rules get-workspace | --workspace-id |
rules edit-workspace | --workspace-id, --rules |
rules get-service | --service-id |
rules edit-service | --service-id, --rules |
rules get-user | — |
rules edit-user | --rules |
| Command | Required Options |
|---|---|
schema types | — |
schema fields | --type-name <TYPE_NAME> |
$CLI status
No subcommands or extra options.
Provides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.
npx claudepluginhub renderedai/rai-agent-studio-cli --plugin rai-ast