rome-os

release-rome-image

Release a new Rome runtime image by pushing a `vX.Y.Z` tag — pick the version, verify main is releasable, push the tag, and confirm the image published to Docker Hub. Covers the `v*` runtime-image tag only, not the desktop app (`desktop-v*`) and not npm packages (`ui-v*`, `app-runtime-v*`).

todos-to-github-project

Turn the remaining todos of the current conversation into a GitHub project of task-spec issues wired with native blocked-by dependencies.

routine-from-chat

Turn a plain-language "do this automatically" request into a routine — either event-triggered ("text me when I get an email from my landlord") or scheduled ("remind me every Friday at 9am"). For third-party events (Gmail, GitHub, Slack…) it confirms with the guardian and then subscribes to the connector trigger so the event actually fires, even one that has never fired before. Ask for any missing detail, then confirm with a card. Reach for this first whenever the guardian wants something to happen automatically; do not explore the codebase or hand-build a trigger.

app_remix

Create a new Rome app from the complete published bundle of an installed App Store app whose local app.yaml enables includeSource. Use when the user asks to remix, fork, or customize an installed app. Never edit or overwrite the source app.

import-skill

Import a Rome skill from a URL, a pasted SKILL.md, or a plain-language description — validate it against Rome's frontmatter parser, preview the final file, and install it into the user-skills carrier app after the guardian confirms.

design-workflow

Turn a guardian's plain-language automation into a runnable Rome workflow app, in one conversation. Use whenever the guardian wants to build, create, set up, or design an automation or workflow ("every morning summarize my unread emails", "when I save a link, fetch and summarize it", "for each new ticket, look up the customer and draft a reply"). You shape the idea into a short spec, get the guardian's approval, then build and install the workflow yourself — no separate planner or builder.

browser-automation

Route browser automation tasks to specialized Rome apps first, then use OpenCLI help discovery when no specialized Rome app is available.

color-audit

Audit a design system's color palette against measurable color-science disciplines — WCAG/APCA contrast of declared token pairs, perceptual (OKLCH) ramp uniformity, color-blindness safety of status/categorical sets, token architecture (primitives → semantic → components), dark-mode integrity, and hue budget — and produce evidence-cited findings with concrete fixes. Use this skill whenever the user asks to review, evaluate, or fix design-system colors, palettes, ramps/scales, themes, or dark mode; asks "are our colors accessible/consistent?", "is this palette reasonable?", or "audit our tokens"; wants to add or change a theme, accent, or status color safely; or reports contrast/readability/color-blindness concerns — even if they don't say "audit". For behavioral/semantic UX review of views (labels, states, redundancy), use ux-semantics-audit instead; this skill owns everything palette- and token-level about color.

secondary-text-audit

Audit the subordinate copy in a UI — section descriptions, field helper text, hints, card subtitles, empty-state body copy, tooltip bodies — against the secondary-text ruleset, and emit a per-string keep/rewrite/delete verdict table a coding agent can apply. Use this skill whenever the user asks to review, tighten, trim, or clean up UI copy, microcopy, descriptions, helper text, subtitles, hints, or empty states; asks "is this copy necessary?", "does this description earn its place?", "why is our UI so wordy?"; wants a settings page or dialog decluttered; or is writing new secondary text and wants it checked before it ships — even if they don't say "audit". For view-level UX behavior (labels, missing states, redundancy, one-primary-action), use ux-semantics-audit; for palette and tokens, use color-audit. This skill owns everything about whether a piece of subordinate copy should exist at all and how it should read.

Web & Frontend Featured

ux-semantics-audit

Audit an existing UI/UX design (React/JSX/TSX components, HTML, or generated app code) against a tiered ruleset of verifiable UX principles, and produce structured, evidence-cited findings that a coding agent can act on to fix the design. Use this skill whenever the user asks to review, evaluate, critique, audit, or lint a UI, screen, view, form, dialog, dashboard, or frontend codebase for UX quality, design problems, redundancy, confusing labels, missing states, or accessibility of status indicators — even if they don't say the word "audit". Also use it when a coding agent's generated UI needs a quality check before shipping, or when the user asks "is this a good design?" about code.

API & Backend Featured

validate-oauth-integration

Validate a Rome-managed OAuth integration end-to-end — prove a user can click Connect and Rome ends up holding a delegated token it can use to call the provider's API. Use when asked to "validate / test the <service> OAuth connector", "check that a user can connect <service>", or "verify the OAuth round-trip". This is the validation half of the GitHub/Slack model (brokered by Pantheon, NOT Composio). For *building* a new integration, run the add-oauth-integration skill first; this skill assumes the code already exists. NOT for Composio-managed toolkits and NOT for inbound webhook events.

composio-cli

Help users operate the published Composio CLI to find the right tool, connect accounts, inspect schemas, execute tools, subscribe to trigger events with `composio listen`, script workflows with `composio run`, and call authenticated app APIs with `composio proxy`. Use when the user asks how to do something with `composio`, wants to run a known tool slug, needs to discover a slug with `composio search`, fix a missing connection with `composio link`, inspect tool inputs with `--get-schema` or `--dry-run`, troubleshoot top-level CLI flows, or explicitly needs `composio dev` guidance.