preview

Name: preview
Author: tobihagemann

375stars29forks

How to install preview?

tobihagemann/turbo/preview

$npx -y skills add tobihagemann/turbo --skill preview

Installs into the current project.

Summary

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. Use when the user asks to \"preview the change\", \"let me try it\", \"spin up the app so I can test it\", \"set it up so I can poke at it\", or before

Files · 1

View on GitHub

SKILL.md

1	# Preview
2
3	Bring up the running app and let the user drive it themselves to judge the change, then act on their verdict.
4
5	## Step 1: Determine Scope
6
7	Resolve what to preview using the first match:
8
9	1. User-specified — the user says what to look at. Use that.
10	2. PR — a PR URL or number is provided. Fetch its details and read the changed code.
11	3. Conversation context — prior conversation contains recent work. Extract what changed, where it lives, and the expected behavior.
12	4. App-level discovery — fresh context with no prior work. Examine entry points, routes, and the README to identify the app's core user-facing flows.
13
14	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 — <one-line reason>." Then use the TaskList tool and proceed to any remaining task.
15
16	## Step 2: Determine Launch Approach
17
18	Check for a project-specific skill or MCP tool that launches the app, and use it if present. Otherwise use the fallback for the surface type:
19
20	- Web app → start the dev server; the access point is the local URL and port
21	- Desktop/native app → build and launch the app so its window is open
22
23	## Step 3: Bring Up the Stack
24
25	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.
26
27	Start long-running processes with the Bash tool (`run_in_background: true`) and wait until each reports ready. Tail their logs with the Monitor tool so backend errors and warnings surface while the user is trying the app.
28
29	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 `AskUserQuestion` to surface the blocker and let the user choose how to proceed.
30
31	## Step 4: Point the User at the Running App
32
33	Output as text:
34
35	- The access point — the local URL and port for a web app, or confirmation that the window is open for a native app
36	- What changed and where to look
37	- Any specific interaction worth checking
38
39	## Step 5: Verdict Gate
40
41	Use `AskUserQuestion` to ask the user for their verdict after they have tried the app. Three options, with keeping the app running as the default:
42
43	- Looks good, keep it running — leave every process this skill started running so the user can keep using the app.
44	- Looks good, shut it down — stop every process this skill started.
45	- Needs changes — note what the user wants different, make the change, rebuild or refresh the running app so it is live, then repeat this step's gate. When the user's response or session context surfaces further open issues, resolve every known issue — fixing and re-verifying each — before re-asking the verdict; the gate re-fires only once no known issue remains.
46
47	Then use the TaskList tool and proceed to any remaining task.

People who liked this also viewed

6 picks

Type

preview

375stars29forks

View on GitHub

How to install preview?

tobihagemann/turbo/preview

$npx -y skills add tobihagemann/turbo --skill preview

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Preview
2
3	Bring up the running app and let the user drive it themselves to judge the change, then act on their verdict.
4
5	## Step 1: Determine Scope
6
7	Resolve what to preview using the first match:
8
9	1. User-specified — the user says what to look at. Use that.
10	2. PR — a PR URL or number is provided. Fetch its details and read the changed code.
11	3. Conversation context — prior conversation contains recent work. Extract what changed, where it lives, and the expected behavior.
12	4. App-level discovery — fresh context with no prior work. Examine entry points, routes, and the README to identify the app's core user-facing flows.
13
14	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 — <one-line reason>." Then use the TaskList tool and proceed to any remaining task.
15
16	## Step 2: Determine Launch Approach
17
18	Check for a project-specific skill or MCP tool that launches the app, and use it if present. Otherwise use the fallback for the surface type:
19
20	- Web app → start the dev server; the access point is the local URL and port
21	- Desktop/native app → build and launch the app so its window is open
22
23	## Step 3: Bring Up the Stack
24
25	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.
26
27	Start long-running processes with the Bash tool (`run_in_background: true`) and wait until each reports ready. Tail their logs with the Monitor tool so backend errors and warnings surface while the user is trying the app.
28
29	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 `AskUserQuestion` to surface the blocker and let the user choose how to proceed.
30
31	## Step 4: Point the User at the Running App
32
33	Output as text:
34
35	- The access point — the local URL and port for a web app, or confirmation that the window is open for a native app
36	- What changed and where to look
37	- Any specific interaction worth checking
38
39	## Step 5: Verdict Gate
40
41	Use `AskUserQuestion` to ask the user for their verdict after they have tried the app. Three options, with keeping the app running as the default:
42
43	- Looks good, keep it running — leave every process this skill started running so the user can keep using the app.
44	- Looks good, shut it down — stop every process this skill started.
45	- Needs changes — note what the user wants different, make the change, rebuild or refresh the running app so it is live, then repeat this step's gate. When the user's response or session context surfaces further open issues, resolve every known issue — fixing and re-verifying each — before re-asking the verdict; the gate re-fires only once no known issue remains.
46
47	Then use the TaskList tool and proceed to any remaining task.

People who liked this also viewed

6 picks

Type