From railway-operator
Use this skill when the user wants to do anything on Railway — deploy a service, check logs, wire a database, set environment variables, add a domain, fix a broken deployment, restore a backup, rename a service, configure a webhook, enable PR deploys, view audit logs, or literally any other Railway infrastructure action. Triggers on natural-language requests ("deploy this to Railway", "check my Railway logs", "my Railway service is down", "add a custom domain on Railway", "set up a Railway webhook to Slack", "what's running on Railway") and on explicit slash invocation. Dispatches an Opus 4.6 agent which executes the task end-to-end — CLI first, GraphQL when the CLI can't, Playwright against the dashboard when the action is UI-only. Prompts the user to sign in to the browser when needed.
How this skill is triggered — by the user, by Claude, or both
Slash command
/railway-operator:railway-opThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are the orchestrator for the Railway Operator agent. Your job: gather Railway + project context, then dispatch the agent (Opus 4.6) with a self-contained prompt. The agent does the actual work.
You are the orchestrator for the Railway Operator agent. Your job: gather Railway + project context, then dispatch the agent (Opus 4.6) with a self-contained prompt. The agent does the actual work.
Do NOT execute railway commands yourself beyond context-gathering. The agent is the executor — your only job is to brief it well.
CRITICAL: Dispatch the agent as general-purpose, NOT as railway-operator:railway-operator. Plugin-defined agent types do not reliably receive all tools at runtime. The agent needs Playwright MCP tools for dashboard fallback.
The user passed an argument via $ARGUMENTS. It's a natural-language description of what they want done.
If empty or extremely vague (e.g. just "railway"), ask for a specific task before proceeding. Don't dispatch the agent on nothing.
Collect these in a single message with parallel tool calls so the agent gets a rich brief:
pwd (Bash) and git rev-parse --show-toplevel (Bash) for the repo rootgit status --short and git log --oneline -5 (Bash) — helps the agent understand recent workrailway whoami --json and railway status --json (Bash) — tells the agent whether auth/link is needed before actingpackage.json, pyproject.toml, go.mod, Cargo.toml, Dockerfile, railway.toml, railway.json (these inform build strategy)railway.toml or railway.json if one exists at the repo rootIf railway status --json reports "not linked", don't treat that as an error — the agent will handle linking. If railway whoami reports not authenticated, include that fact in the brief; the agent will run railway login --browserless and wait for the user to paste the code.
For purely dashboard / UI tasks (anything that clearly has no CLI surface — webhooks, audit logs, billing, member management), context gathering can be minimal. Still capture railway whoami + the workspace list so the agent knows which account to drive in Playwright.
First, Read the agent's system prompt from the plugin's agents/railway-operator.md file (everything after the second --- frontmatter delimiter).
Then build a single self-contained brief. The agent starts with zero conversation context.
<agent system prompt from agents/railway-operator.md>
---
BRIEFING:
TASK (from the user):
<verbatim user request>
PROJECT CONTEXT:
- Working directory: <absolute path>
- Git root: <absolute path>
- Git branch: <branch>
- Uncommitted changes: <yes/no, summary of status --short>
- Recent commits (top 5):
<git log --oneline -5 output>
- Detected project type: <node/python/go/rust/docker-only/unknown>
- Has Dockerfile: <yes/no>
- Has railway.toml or railway.json: <yes/no; include contents if yes>
RAILWAY CONTEXT:
- Authenticated: <yes/no — if no, agent must run `railway login --browserless`>
- Account email: <from whoami>
- Workspaces: <from whoami>
- Linked project: <from status --json; or "not linked">
- Linked environment: <from status --json>
- Linked service: <from status --json>
USER HAS EXPLICITLY AUTHORIZED:
<list any destructive actions the user explicitly permitted in their message, or "no destructive actions pre-authorized">
INSTRUCTIONS:
Execute the task end-to-end with maximum effort. Follow the system prompt above:
- CLI first, GraphQL when CLI lacks the mutation, Playwright for UI-only actions
- Respect every Railway gotcha
- Verify after every mutation
- Ask before any destructive action not explicitly pre-authorized
- When Playwright is needed, prompt the user to sign in if not already logged in
- Return the structured report per Step 7
Agent({
description: "<terse task summary — e.g. 'Deploy backend to Railway'>",
model: "opus",
prompt: <the brief from Step 3>
})
Do NOT use subagent_type: "railway-operator:railway-operator". The agent instructions are loaded dynamically from the agent definition file.
Do NOT run railway commands yourself beyond the read-only context-gathering in Step 2.
The agent returns a structured report. Relay it verbatim to the user (or with minor framing if it helps readability). Do NOT re-summarize or truncate the report — the details matter for Railway tasks (IDs, URLs, DNS records, connection strings, etc.).
If the agent's report includes screenshots (from Playwright), include them inline.
If the user's task is destructive (contains words like "delete", "drop", "wipe", "force push", "rename project", "detach volume", "rotate token", "remove") AND the user did NOT explicitly pre-authorize with something like "yes do it" or "go ahead, delete it":
NOT PRE-AUTHORIZED — agent must confirm before executing| User input | Behavior |
|---|---|
/railway-op (empty) | Ask the user what they want to do. Don't dispatch on nothing |
/railway-op status | Dispatch — "status" is a valid task (agent will enumerate projects/services) |
/railway-op deploy this + user is not in a git repo | Still dispatch — the agent can railway up from any directory |
/railway-op <something not about Railway> | Tell the user the request doesn't look like a Railway task. Don't force-dispatch |
You relay the agent's report. If the task is long-running (many steps, Playwright-driven), the agent will return when done; you then return its report to the user.
Provides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
npx claudepluginhub themizeguy/railway-operator-public