# Revyl MCP Dev Loop

> Optional MCP dev-first mobile loop for screenshot-observe-action execution. Not started by the Cursor plugin.

- Skill: `revylai/revyl-mcp-dev-loop` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add revylai/revyl-mcp-dev-loop`
- Raw SKILL.md: https://api.skillmd.com/api/skills/revylai/revyl-mcp-dev-loop/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: revylai (https://skillmd.com/u/revylai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/revylai/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.