Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →tobihagemann/preview
Stand up the project's live app and hand it to the user to try a change firsthand, then gate on their verdict before continuing.
Passed 5 of 15 test cases with the skill, and 5 of 15 without it.
and 2 more in the full report
5 fixed3 passed either way9 still failing5 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
Please prepare a live preview for https://github.com/example/repo/pull/89. I haven't checked out the branch locally yet. What is your first step?
| Checked | Without skill | With skill |
|---|---|---|
| Fetches pull request #89 details and inspects modified files to identify target UI areas | Missed | Passed |
The instructions your model reads when the skill loads.
Bring up the running app and let the user drive it themselves to judge the change, then act on their verdict.
Resolve what to preview using the first match:
If the resolved scope has no user-visible surface to try (a CLI-only change, a library with no entry point, backend work with no UI to look at), present this message: "Nothing to preview — ." Then call update_plan to mark this step completed and continue with the next step of the active workflow.
Check for a project-specific skill or plugin that launches the app, and use it if present. Otherwise use the fallback for the surface type:
Start backend services and frontend together — a frontend-only change still needs the backend running to be exercised. Build first if the project requires a build step.
Start long-running processes in a background shell and wait until each reports ready. Tail their logs in a background shell so backend errors and warnings surface while the user is trying the app.
If a required service cannot be stood up in this session (missing auth provider, external dependency, seed data), or a process fails to start or never reports ready, use request_user_input to surface the blocker and let the user choose how to proceed.
Output as text:
test cases passed, vs 5 / 15 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.