preview

# Preview Bring up the running app and let the user drive it themselves to judge the change, then act on their verdict. ## Step 1: Determine Scope Resolve what to preview using the first match: 1. **User-specified** — the user says what to look at. Use that. 2. **PR** — a PR URL or number is provided. Fetch its details and read the changed code. 3. **Conversation context** — prior conversation contains recent work. Extract what changed, where it lives, and the expected behavior. 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. 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. ## Step 2: Determine Launch Approach 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: - **Web app** → start the dev server; the access point is the local URL and port - **Desktop/native app** → build and launch the app so its window is open ## Step 3: Bring Up the Stack Start backend services and frontend together — a frontend-only change still needs the backend running to be exercised. When a service runs at an address other than its default, find the settings elsewhere in the stack...