revyl-mcp-dev-loop

# Revyl MCP Dev Loop Skill This skill is for users who **opt into** custom MCP. The Cursor plugin does not start an MCP server. Add a personal MCP entry with a literal command such as `revyl` or `/usr/local/bin/revyl`, never `${...}`. Use this skill for the full flow: 1. Start dev loop equivalent. 2. Execute screenshot-observe-action cycles. ## Default Operating Mode Always prefer dev-loop flow before plain device-only flows: 1. Call `start_dev_loop`. Pass `profile` and `platform` when repository evidence determines the named recipe; never invent an active/default value. 2. On success, share `viewer_url` as a clickable link and confirm the session is active. When the inline Revyl app exposes **Open live device**, the user may use it to hand the URL to the host browser; the link remains the portable fallback. 3. On a setup failure, follow the single structured `remediation` action and retry `start_dev_loop` once. 4. Call `screenshot()` and begin interaction. Fallback to plain device session only when dev loop is unavailable. ## Execution Guardrails 1. First tool call must be `start_dev_loop`. 2. Do not call listing tools unless the user explicitly asks. 3. Treat `next_steps` as advisory only. 4. Re-anchor with `screenshot()` before state-dependent actions. 5. Express device actions through the current natural-language schema, for example `interact(task="Tap the Sign In button")`. Do not calculate or supply coordinates. 6. Use `setup_status` only when the user explicitly asks for setup diagnostics. Its `remediation` object is the read-only view of the same recovery plan: follow `check_command` before `apply_command` when both are present. 7. Never claim that a Cloud Agent opened the viewer on the user's local computer. Cloud tools run on the remote VM; the inline open control and clickable URL are client-side handoffs. ## Setup Recovery Handle setup outcomes as bounded recovery steps: - `auth_required` / `auth_expired` / `auth_invalid`: run `remediation.command` once, then retry `start_dev_loop`. If the command cannot complete, post `outcome.authorization_url` as a clickable markdown link and stop until the user approves; that URL is a live approval request Revyl already registered, and it works from any browser. - `cloud_secret_required`: run `remediation.command` once to bridge the hosted agent's injected `remediation.env_name`, then retry `start_dev_loop`. If that command reports no key in the environment, post `outcome.authorization_url` as a clickable link and tell the user that adding `remediation.env_name` as a Runtime Secret plus a new Cloud session is the durable fix. - `project_not_initialized`: use `remediation.command` to pull an existing UI-created or server-managed project, or `remediation.alternative_command` to initialize a genuinely new project. Use repository and user context to choose; ask when unclear. Run only the selected exact command with `remediation.working_directory`, then retry `start_dev_loop` once. The executable may be the plugin-pinned runtime rather than `revyl` on `PATH`; do not rewrite either command or add `--force`. - `project_legacy_config`: run the exact JSON `remediation.check_command` first and review its canonical proposal and complete omission ledger. Then run the exact `remediation.apply_command` once to create the backup and apply that proposal. If the ledger is lossy, reconcile the migrated file against the reported backup before retrying `start_dev_loop`; otherwise retry directly. Do not rewrite either command, skip the check, or hide reported omissions or ambiguities. - `project_outside_git`: select a project directory inside an active Git worktree from repository context and retry `start_dev_loop` with that exact path as `project_dir`. Treat `remediation.env_name` as the durable runtime configuration hint, not as permission to invent a path. If no intended Git worktree is evident, ask the user to choose one. - `project_ambiguous`: inspect `remediation.candidate_roots`, select the intended project from repository context, and retry with that exact root as `project_dir`. If the intended project is unclear, ask the user to choose. Do not initialize another project or retry without an explicit `project_dir`. - `project_invalid`: report `remediation.config_path` and wait for it to be repaired before retrying. After one remediation and one retry, stop and report any remaining failure. Do not enter a setup loop. If `start_dev_loop` fails with a profile/platform selection error instead of a setup remediation, inspect its valid choices and retry once with exact `profile` and `platform` values. Do not guess. If a deprecated `platform_key` input returns `dev_loop_platform_key_removed`, replace it with `profile` and `platform`. ## Interaction Loop For each iteration: 1. `screenshot()` 2. State visible UI in one short line. 3. Take one best action with `interact(task="...")`. 4. `screenshot()` to verify. 5. Repeat. Short deterministic burst allowance: - Up to two actions before verification for obvious two-step entry flows.