Revyl

View saved version →

---
name: revyl-codex-dev-loop
description: Run, preview, debug, and verify mobile app changes on Revyl cloud devices from Codex, with screenshots and semantic validation.
---

# Revyl Codex Dev Loop

Use this skill for an authorized Revyl development loop in Codex. This plugin
has no hooks and no MCP server. Installation never changes an app's source or
`.revyl/config.yaml`; later source/configuration work is allowed only when the
task explicitly requires it and the user authorizes it.

## Launcher and setup

Resolve the launcher from this skill's own absolute directory before changing
to the app directory. On POSIX use `../../scripts/launch-revyl`; on Windows use
`../../scripts/launch-revyl.cmd`. Call that absolute launcher for **every**
Revyl command; do not use `revyl` from `PATH`, `PLUGIN_ROOT`, or another
installed CLI.

```sh
SKILL_DIR="<absolute directory containing this SKILL.md>"
LAUNCHER="$(cd "$SKILL_DIR/../../scripts" && pwd)/launch-revyl"
"$LAUNCHER" --version
"$LAUNCHER" auth status
```

```bat
REM Windows cmd.exe
set "SKILL_DIR=<absolute directory containing this SKILL.md>"
set "LAUNCHER=%SKILL_DIR%\..\..\scripts\launch-revyl.cmd"
"%LAUNCHER%" --version
"%LAUNCHER%" auth status
```

If authentication is needed, use `"$LAUNCHER" auth login`. An existing
environment-provided secret may authenticate the launcher without being copied
or named in an argument. Never run credential-provisioning or secret-bridge
commands, print credentials, or paste them into chat. Post the normal login
approval URL as a clickable link and wait for approval; do not claim that a
browser opened.

## Authorization and selection

Before any build, remote session, cloud device, or paid operation, require
authorization naming the app, environment, and paid operation. Resolve the
exact profile and platform from the repository, task, and user context without
changing them; ask only when they remain ambiguous. Run from the app directory
that owns `.revyl/config.yaml`, not the monorepo root. Let `dev` create its new
context, capture the returned context and session IDs, and clean up only those
resources when the work ends or fails.

For native or rebuild-first apps, use the detached remote loop with explicit
selection and no browser opening:

```sh
"$LAUNCHER" dev --profile <exact-profile> --platform <ios-or-android> \
  --remote --detach --json --no-open
```

Return the handshake's `viewer_url` immediately without opening it. A viewer or
`--wait-ready` only means the session is available, not that the current build
succeeded. Wait for the build to reach its terminal success state before
claiming a build result.

Use short-lived commands in separate calls. Target the returned context with
`--context` for status and rebuild, and pass it positionally to stop:

```sh
"$LAUNCHER" dev status --context <returned-context>
"$LAUNCHER" dev rebuild --context <returned-context> --wait --timeout 600 --json
"$LAUNCHER" dev stop <returned-context> --json
```

Target **every** device command with `-s <returned-session-id>`. Open each
captured screenshot before describing it. A false or missing semantic verdict
is a failed validation, but cleanup still runs for the returned context/session.
Bound status polling to the configured build timeout. If that limit expires,
report a timeout and stop the owned loop instead of polling indefinitely.

## Detailed CLI mechanics

Resolve this skill's `../../references/revyl-cli-dev-loop.md` to an absolute
path and read it for framework behavior, evidence, and troubleshooting. This
skill overrides that reference whenever they conflict:

- Do not use its browser-opening, URL-opening, foreground, persistent-shell,
  `PATH`, or installed-CLI examples. Use `--detach --json --no-open` and the
  absolute launcher above.
- Do not start a local app source/configuration change, a device, build, or
  paid action without the named authorization above.
- Do not install, enable, configure, or invoke `revyl-cli-auth-bypass`. That
  skill is not shipped with this plugin, and authentication bypass is never an
  automatic fallback.
- Use exact resolved profile and platform values, and clean up only the context
  and session created for the authorized request.

Report an unavailable authorization or ambiguous target instead of guessing.

View saved version →

---
name: revyl-codex-proof-ci
description: Verify a mobile pull request using an exact-SHA match among its app's recent CI-uploaded Revyl builds, collect device evidence, and prepare a proof summary without rebuilding.
---

# Revyl Codex Proof from CI Builds

Use this skill only for an authorized proof of a pull request whose artifact
was already uploaded by CI. It does not build, upload, or configure an app.

## Launcher and authorization

Resolve the launcher from this skill's own absolute directory before changing
to the app directory. On POSIX use `../../scripts/launch-revyl`; on Windows use
`../../scripts/launch-revyl.cmd`. Invoke that absolute launcher for **every**
Revyl command; never use `revyl` from `PATH`, `PLUGIN_ROOT`, or another
installed CLI.

```sh
SKILL_DIR="<absolute directory containing this SKILL.md>"
LAUNCHER="$(cd "$SKILL_DIR/../../scripts" && pwd)/launch-revyl"
"$LAUNCHER" --version
"$LAUNCHER" auth status
```

```bat
REM Windows cmd.exe
set "SKILL_DIR=<absolute directory containing this SKILL.md>"
set "LAUNCHER=%SKILL_DIR%\..\..\scripts\launch-revyl.cmd"
"%LAUNCHER%" --version
"%LAUNCHER%" auth status
```

Use normal `"$LAUNCHER" auth login` only when authentication is needed. An
existing environment secret may be used without placing its value in a command,
chat, or artifact. Do not run credential-provisioning or secret-bridge
commands. Post the normal login approval URL as a clickable link and wait for
approval; do not claim that a browser opened.

Before starting a device or another paid action, require authorization naming
the app, environment, and paid operation. Resolve the pull request's **full**
head SHA and platform from read-only PR, repository, and user context; ask only
when ambiguous. Do not treat a short SHA, branch name, or version label as a
match. Run from the app directory that owns `.revyl/config.yaml` so the
project's existing launch configuration applies.

## Proof loop

1. Find a CI-uploaded build whose `metadata.scm_head_sha` exactly equals the
   full PR SHA. For example:

   ```sh
   "$LAUNCHER" build list --app <app-id> --json
   ```

   This pinned CLI lists only the newest 20 versions and does not expose
   pagination. A match in this window is usable; no match does not establish
   that the artifact is absent. While the named CI upload is pending, make at
   most three retries, ten seconds apart. If no exact match arrives, stop and
   report **proof not run: recent-build lookup incomplete**. Explain the
   20-version limit, without claiming a full-history search. Do not invent
   pagination flags, bypass CLI authentication, rebuild, re-upload, or use an
   unrelated artifact as a fallback.
2. With explicit authorization, start a device on the matching build and save
   its exact session ID:

   ```sh
   "$LAUNCHER" device start --build-version-id <matching-build-id> --json
   ```

   Return the viewer URL immediately as a clickable link when one is present.
   Exercise only the changed behavior. Target every device command with
   `-s <session-id>`, save concise screenshots, and open each screenshot before
   describing it. A false or missing semantic verdict is a failed proof, but
   still stop that exact session with `"$LAUNCHER" device stop -s <session-id>`.
   Never use global cleanup.
3. Obtain a report with `"$LAUNCHER" device report -s <session-id> --json` and
   report success only when a matching device session produced the evidence. A
   missing device session is never a passed proof.

## Reporting and publication

When an authorized PR-comment surface is available, use that surface to add or
update the proof. Otherwise return a ready-to-post draft headed
`## Revyl device proof` with the full SHA, matching build ID, device result,
and only the evidence actually collected.

Session sharing and screenshot/report publication are separate external
actions. Run `session share` or `session publish` only after the user explicitly
approves publication and its audience; otherwise keep the evidence local and
return the draft without public links. Never include credentials, launch-var
values, or signed URLs.