--- name: rock8cloud-prototype description: Starts a new app from a Rock8Cloud blueprint (a ready-made stack that forks a template repo and wires up services and databases) and hands the feature work to a cloud coding agent that returns a pull request with a live preview. Use when the user wants to build or prototype something from scratch, needs a starter stack such as Vue, TanStack Start, Next.js, Go or an Elysia dashboard, or wants to delegate coding to a Rock8Cloud agent and iterate on its pull request. --- # Prototype from a blueprint, build with a cloud agent A blueprint forks a template repository into the user's GitHub account, creates the project and services, provisions any database or bucket, wires environment variables and starts the first deploy. A cloud agent then works on the code in an isolated sandbox and opens a pull request. Needs the rock8cloud MCP server connected (skill `rock8cloud-setup`) and the GitHub App installed. ## 1. Pick and deploy a blueprint 1. `list_organizations` for `organizationId`. 2. `list_blueprints` with `organizationId`. Each entry has `slug`, `name`, `shortDescription`, `technologies`, `choices` and `inputs`. Match the user's goal to a stack. Not every blueprint has a database. 3. `list_github_owners` with `organizationId`. Pick a `login` to fork into. An empty list means the Rock8Cloud GitHub App is not installed, so use `check_github_connection` and its `installUrl` (skill `rock8cloud-setup`). 4. Ask the user to confirm blueprint, project name (max 50 characters) and GitHub owner. This forks real repositories and creates billed services. 5. For each `choices` entry, propose the `default` option first and offer others only if needed. Ask only for the `inputs` that apply to the chosen option. Secret inputs are credentials, so ask the user and never invent them. 6. `deploy_blueprint` with `organizationId`, `slug`, `projectName`, `githubOwner`, and optional `choices` and `inputs`, both keyed by id. The result has `projectId`, `services` (each with `slotId`, `serviceId`, `kind` of `code`, `database` or `s3`, and `githubRepo` for code services), `notes` and `bootstrapFailures`. The first deploy starts on its own, so do not call `deploy_service`. A service listed in `bootstrapFailures` was created but did not start, so call `deploy_service` for it. Show the user `notes`. If the call fails halfway, the error lists repositories it already forked. Tell the user to delete them before retrying. ## 2. Wait for the first deploy `deploy_blueprint` returns service ids but no deployment id. For each service call `get_latest_build` with `serviceId` to get the `deploymentId`, then poll `get_deployment_status` every 15 to 30 seconds until `live`, `failed` or `cancelled`. On failure use skill `rock8cloud-logs`. When it is live, give the user the `url` from `get_deployment_status`. ## 3. Hand the feature to a cloud agent Use the `code` service as `serviceId`. The agent needs a repository, not a running app. `task_agent` with: - `organizationId`, `serviceId` - `agentType`: `code-autonomous` works alone, pushes a branch and opens a pull request. `code-collab` interviews the user first (through you) and then does the same. `analyze` is read-only and reports back. - `prompt`: self-contained. The agent sees only this session, not your conversation. State the goal, the screens, endpoints or data involved, constraints and what done looks like. - `modelId` (optional): from `list_agent_models`. Omit it for the platform default. It returns `sessionId` and `runId` at once. Runs take minutes. ## 4. Poll and iterate 1. `get_agent_run` with `organizationId`, `sessionId`, `runId` every 15 to 30 seconds until `done` is `true`. `status` is `waiting`, `running`, `successful`, `error` or `cancelled`. 2. On `successful` read `reply`, `filesChanged`, `commitSha` and `pullRequestUrl`. If `published` is `false`, `gitState` or `conflictedFiles` explain what is stuck. 3. A non-null `pendingQuestion` means the agent is waiting. Relay it to the user, then answer with `continue_agent_session`. 4. For changes, call `continue_agent_session` with `sessionId` and a new `prompt`. Runs in one session are serialized. A suspended session resumes with full context. Continuing a closed session starts a new one and returns a new `sessionId`, so use the returned id from then on. 5. `get_agent_session` returns the conversation and the latest handoff brief, which is the agent's own summary and the best view of where it stands. `list_agent_sessions` finds earlier work, so prefer continuing a session over starting a new one for the same task. A run that ends in `error` can mean the AI budget is used up, so read the `error` text. The user can check what is left, or top up, under Settings > AI in the dashboard. ## 5. Preview and ship When the pull request is open, the Preview Deployments workflow builds a preview environment if the branch matches its pattern (default `feat/*`). Call `list_environments` with `serviceId` and give the user the `previewUrl` of the entry whose `pullRequestNumber` matches. If there is none, the user can comment `@ preview ` on the PR. Each push the agent makes updates the preview. If AI code review is enabled, `get_code_reviews` with the agent's branch returns findings (skill `rock8cloud-code-review`). Merging is the user's decision. After a merge, Deploy on Push puts the change on the stable URL. Call `close_agent_session` only when the work is finished. It is permanent. Idle sessions park themselves for free. ## Cost Agent runs spend the organization's AI budget and the sandbox time counts toward usage. Heavier models cost more. Do not start parallel sessions for work one session can do. ## Docs - https://docs.rock8.cloud/docs/blueprint.md - https://docs.rock8.cloud/docs/guides/agents.md - https://docs.rock8.cloud/docs/guides/preview-deployments.md - https://docs.rock8.cloud/docs/guides/mcp-integration.md