--- name: rolino description: Use Rolino to upload local social media, turn folders of content into drafts, check publishing readiness, schedule or publish approved posts, inspect the social calendar, and configure Rolino CLI or MCP access. Trigger when the user asks an agent to use Rolino, schedule content from files or a folder, prepare or publish social content through Rolino, inspect Rolino projects or posts, or connect Rolino to an AI coding agent. --- # Rolino Agent Workflow Rolino is an agent-ready social scheduling service. Use its CLI in agent mode for structured output. Keep the user's control over account creation, authorization, connected social accounts, scheduling, and publishing. ## Command prefix Prefer an installed CLI: ~~~bash rolino --agent ~~~ If it is not installed, use the current public package without modifying the project: ~~~bash npx -y @rolino/cli@latest --agent ~~~ For self-hosted Rolino, preserve the user's configured ROLINO_URL or pass --base-url. Never guess a deployment URL or copy a credential into source code, logs, prompts, or a final response. ## Start with prerequisites 1. Check authentication with `rolino --agent auth status`. 2. If authentication is missing, explain that the user needs a Rolino account and browser approval. Run `rolino auth login` only when the user wants to continue, then wait for them to sign up or sign in and approve the requested workspace permissions in the browser. 3. After approval, rerun `rolino --agent auth status`, then `rolino --agent projects list`. 4. Resolve the project by an exact ID, a clearly matching name, or its website. Never silently choose between plausible projects. 5. If no project exists, ask before creating one. Use `rolino --agent projects create --name "NAME" --type PRODUCT --yes`; add a real website only when known. Project creation does not connect accounts, create posts, schedule, or publish. 6. Before preparing a destination, run `rolino --agent integrations health --project PROJECT_ID`. If the required social account is disconnected, tell the user to connect it at `https://getrolino.com/projects/PROJECT_ID/connections`, then rerun the health check. ## Interpret common requests - “Show my Rolino calendar” → resolve the project, then run `rolino --agent calendar list --project PROJECT_ID`. - “Create/prepare/draft a post” → create a draft only. Do not schedule or publish unless the user separately asks. - “Schedule this folder” → inspect supported local media without modifying it, build a file-to-caption/destination/time manifest, show ambiguities and blockers, and obtain approval for that exact batch before uploading and scheduling it. - “Schedule this post” → create or resolve the draft, check readiness, preview the exact schedule, show the user the time, timezone, destinations, and blockers, then execute only after the user has clearly approved that exact result. - “Publish this now” → create or resolve the draft, check readiness, preview the exact destinations, explain that execution queues delivery to external networks, then execute only after clear approval. - “Connect Rolino to my agent” → authenticate first, then use `rolino setup mcp --client codex` or `rolino setup mcp --client claude-code`. Preview configuration before allowing a write. ## Draft workflow Inspect the project before creating anything: ~~~bash rolino --agent projects show PROJECT_ID rolino --agent integrations health --project PROJECT_ID ~~~ Create a draft only after the user has supplied or approved the caption and destinations: ~~~bash rolino --agent posts create --project PROJECT_ID --caption "TEXT" --platform INSTAGRAM --yes ~~~ Repeat `--platform` and `--media` for additional destinations and existing Rolino media asset IDs. Instagram and video-first destinations can require media. Discover reusable assets with `rolino --agent media list --project PROJECT_ID`. Upload an approved local file with `rolino --agent media upload PATH --project PROJECT_ID --yes`, then use the returned asset ID. Never invent an asset ID. ### Draft captions by destination Resolve and preview the final caption for every selected destination before creating or updating a draft. - Use the shared caption when it fits every destination and matches the user's intent. Do not create nearly identical overrides only to make each destination different. - Create destination-specific overrides when platform limits, tone, formatting, or content type require different text. The CLI accepts `--instagram-caption`, `--tiktok-caption`, `--youtube-caption`, and `--bluesky-caption`. - Count each resolved caption using the destination's actual measurement rule and show `used / allowed` in the approval plan. Use a scalable `Caption usage` field rather than adding one table column per platform. - Never create or update a draft with text that exceeds Rolino's validated destination limit. If text is too long, prepare a compliant revision before continuing. If shortening could materially change the message, show the revision to the user for approval. - Treat preferred or “sweet spot” lengths as writing guidance, not hard limits, unless the user or their brand instructions make them requirements. Current Rolino limits are Instagram 2,200 characters; TikTok video captions 2,200 UTF-16 code units; YouTube descriptions 5,000 UTF-8 bytes; and Bluesky posts 300 graphemes. Rolino's server validation is the source of truth if provider requirements change. Use `rolino --agent posts show POST_ID --project PROJECT_ID` to obtain the current version before updating, scheduling, or publishing. Updates require `--expected-version` so web or teammate changes cannot be overwritten silently. ## Local folder workflow When the user supplies a folder of content: 1. Enumerate only that folder and identify supported JPEG, PNG, WebP, MP4, and MOV files. Ignore hidden, temporary, and unsupported files; do not rename, move, edit, or delete source files. 2. Determine the intended caption, destination, date, time, timezone, and ordering from explicit user instructions or an included manifest. Treat filenames as hints, not authoritative publishing instructions. 3. List existing project media and match obvious duplicates by exact file name and size when possible. Never substitute a merely similar asset. 4. Present one compact batch plan containing every source file, resolved destination caption, caption usage, destination, and exact scheduled time. Surface missing or over-limit captions, collisions, unsupported formats, provider constraints, and disconnected channels. 5. After the user approves that exact plan, upload only the approved files. Reuse returned asset IDs to create drafts, then run readiness on every draft. 6. Preview every exact schedule. If the previews match the approved batch with no new blockers or changes, the earlier explicit batch approval may cover execution. Otherwise show the changed result and ask again. 7. Execute each confirmed schedule with a stable, unique idempotency key, then verify the affected calendar window and report per-post results. A partial failure must not cause successful items to be duplicated. Example upload and draft preparation: ~~~bash rolino --agent media list --project PROJECT_ID --query "launch" rolino --agent media upload "/exact/path/launch-01.mp4" --project PROJECT_ID --yes rolino --agent posts create --project PROJECT_ID --caption "APPROVED TEXT" --platform TIKTOK --media ASSET_ID --yes ~~~ ## Schedule workflow Scheduling is always two-step and exact: ~~~bash rolino --agent posts readiness POST_ID --project PROJECT_ID rolino --agent posts schedule preview POST_ID --project PROJECT_ID --expected-version VERSION --at ISO_DATE --timezone IANA_TIMEZONE ~~~ The preview returns a five-minute confirmation token. After the user approves the exact preview, pass the token through ROLINO_CONFIRMATION_TOKEN and repeat the same post version, time, and timezone with a stable idempotency key: ~~~bash rolino --agent posts schedule execute POST_ID --project PROJECT_ID --expected-version VERSION --at ISO_DATE --timezone IANA_TIMEZONE --idempotency-key STABLE_KEY ~~~ Never treat a preview as a completed schedule. Never change the time, timezone, post version, or destinations between preview and execution. ## Immediate publish workflow Immediate publishing is also two-step: ~~~bash rolino --agent posts readiness POST_ID --project PROJECT_ID rolino --agent posts publish preview POST_ID --project PROJECT_ID --expected-version VERSION --platform INSTAGRAM ~~~ After the user approves the exact destinations and consequence, pass the returned token through ROLINO_CONFIRMATION_TOKEN and execute with the same version and destinations: ~~~bash rolino --agent posts publish execute POST_ID --project PROJECT_ID --expected-version VERSION --platform INSTAGRAM --idempotency-key STABLE_KEY ~~~ A successful execute queues delivery; it is not proof that every provider has published. Inspect the post afterward and report provider states accurately. ## Recovery rules - `AUTH_REQUIRED`: ask the user to create or sign into a Rolino account and approve `rolino auth login` in the browser. - `FORBIDDEN` or `SCOPE_REQUIRED`: explain which requested action lacks permission. The user must revoke or log out and authorize a new connection with that capability; never work around the scope. - `BILLING_REQUIRED` or `LIMIT_REACHED`: report the plan restriction and direct the user to `https://getrolino.com/settings/billing`. - `CONNECTION_REQUIRED` or a blocking integration-health result: direct the user to the project's Connections page. OAuth and platform approval are user actions. - `VALIDATION_ERROR`: preserve the server message, inspect the current post and readiness, and ask only for the missing decision or content. - `CONFLICT`: fetch the latest resource before retrying. Never blind-retry with changed input under the same idempotency key. - `RATE_LIMITED`: respect retryAfterSeconds. - Network timeout or unknown provider result: inspect current state before retrying. Never assume a publish failed and send a duplicate. ## Safety - Reading, listing, health checks, readiness checks, and previews are safe to run without extra confirmation. - Project and draft creation are writes; use Rolino's explicit consent flow and report what was created. - Local file upload is a write and transfers a copy to the configured Rolino media store. Read and upload only files covered by the user's approved folder plan; never alter the originals. - Scheduling and publishing affect external accounts. Require exact preview approval and never bypass Rolino's server confirmation. - Do not expose bearer credentials or confirmation tokens in source code, command arguments when an environment variable is available, logs, or final responses. - Do not claim success from intent. Verify the returned post, schedule, calendar event, or provider status and report blockers plainly.