$npx -y skills add vercel/next.js --skill next-dev-loopnext-dev-loop is an agent skill published from vercel/next.js, installable through the skills CLI.
| 1 | # next-dev-loop |
| 2 | |
| 3 | The edit/verify rhythm during `next dev` — make a change, then |
| 4 | confirm it actually works at runtime, not only that the types or |
| 5 | the build are happy. |
| 6 | |
| 7 | You verify through two views of the same running app: |
| 8 | |
| 9 | - **`/_next/mcp`** — an HTTP endpoint Next.js exposes about itself. |
| 10 | Knows framework-specific things: routes, segments, RSC, server |
| 11 | actions, server logs, and errors as Next.js saw them. Call |
| 12 | `tools/list` for the current surface. |
| 13 | - **`agent-browser`** — a CLI that drives a real Chrome. Knows |
| 14 | framework-agnostic browser things: DOM, console, network, React |
| 15 | fiber, vitals. Before driving it, run `agent-browser skills get core` |
| 16 | once for the version-matched usage guide — don't guess subcommands |
| 17 | from memory. |
| 18 | |
| 19 | The two views cross-check each other. |
| 20 | |
| 21 | ## requires |
| 22 | |
| 23 | - Next.js **16.3+** with **Turbopack** — `/_next/mcp` plus the |
| 24 | proactive compile check via `get_compilation_issues`. |
| 25 | - `agent-browser` **>= 0.31.1** — React introspection, worktree-scoped |
| 26 | `session id`, idempotent `--restore`, and launch flag reconciliation. |
| 27 | |
| 28 | These are hard floors, not soft preferences. If anything is missing, |
| 29 | tell the user how to upgrade and stop. Don't fall back to grepping |
| 30 | source or to a weaker probe — this skill assumes both views are live |
| 31 | at the versions above. |
| 32 | |
| 33 | - Upgrade Next.js: `pnpm next upgrade` (or `npx next upgrade`). |
| 34 | Docs: https://nextjs.org/docs/app/getting-started/upgrading |
| 35 | (version-16 guide: |
| 36 | https://nextjs.org/docs/app/guides/upgrading/version-16) |
| 37 | - Install or upgrade `agent-browser`: `npm i -g agent-browser@latest`. |
| 38 | If the CLI isn't on `PATH`, install it before continuing — preflight |
| 39 | expects to invoke it directly. |
| 40 | |
| 41 | ## preflight |
| 42 | |
| 43 | Once per session, confirm both views are live. |
| 44 | |
| 45 | 1. **Open `agent-browser` at the target URL, restoring saved |
| 46 | login state when present.** First derive one stable session id for |
| 47 | this checkout and use it for every `agent-browser` command: |
| 48 | |
| 49 | ```bash |
| 50 | SESSION="$(agent-browser session id --scope worktree --prefix next-dev-loop)" |
| 51 | export AGENT_BROWSER_SESSION="$SESSION" |
| 52 | export AGENT_BROWSER_RESTORE="$SESSION" |
| 53 | ``` |
| 54 | |
| 55 | Then open the target URL: |
| 56 | |
| 57 | ```bash |
| 58 | agent-browser --session "$SESSION" --restore --headed --enable react-devtools open <url> |
| 59 | ``` |
| 60 | |
| 61 | `--scope worktree` keeps parallel worktrees and copied checkouts |
| 62 | from colliding. Bare `--restore` uses the session id as the |
| 63 | persistence key, loads saved cookies/localStorage before navigation |
| 64 | when present, and auto-saves state on close. Always pass the desired |
| 65 | launch flags on `open`; agent-browser will reuse, relaunch, or restart |
| 66 | its scoped background state as needed. |
| 67 | |
| 68 | The browser is the user's. If state was not restored (first run, |
| 69 | expired session) and the page is gated, the user drives the login — |
| 70 | pause until they confirm. After login, continue using the same session |
| 71 | and restore context; `agent-browser close` saves the cookie state so |
| 72 | the next `open` restores it. |
| 73 | |
| 74 | 2. Probe `/_next/mcp` (`tools/list`) — confirm it's reachable and |
| 75 | lists `get_compilation_issues`: |
| 76 | - Unreachable → either `next dev` isn't running, or Next.js is |
| 77 | below 16.3. Check `package.json` to disambiguate, then refuse. |
| 78 | - `get_compilation_issues` not in the list → Next.js below 16.3. |
| 79 | Refuse and tell the user to upgrade. |
| 80 | 3. `get_compilation_issues` doubles as a Turbopack probe. An error |
| 81 | response of `"Turbopack project is not available..."` means the |
| 82 | user is on webpack. Refuse — Turbopack is required. |
| 83 | 4. `get_routes` → your route map for the rest of the session. |
| 84 | |
| 85 | ## loop |
| 86 | |
| 87 | ### before the edit — narrow the scope |
| 88 | |
| 89 | Ask the running app, not the codebase. `/_next/mcp` knows which |
| 90 | files rendered the current route; use those as your search scope. |
| 91 | Runtime introspection stays cheap as the codebase grows; agentic |
| 92 | search doesn't. |
| 93 | |
| 94 | ### after the edit — verify |
| 95 | |
| 96 | Four failure modes. Check each: |
| 97 | |
| 98 | - **Compiles** — `get_compilation_issues`. |
| 99 | - **Runs without errors** — `/_next/mcp` (server and bubbled-up |
| 100 | browser errors both surface here). |
| 101 | - **Behaves as intended** — `agent-browser` drives the page; assert |
| 102 | what the user actually sees. |
| 103 | - **React-level behavior** — `agent-browser` with react-devtools |
| 104 | enabled exposes the component tree, props, state, and render |
| 105 | counts. Anchor framework-level checks here (extra renders, |
| 106 | server/client boundary shifts, suspense fallbacks) — DOM asserts |
| 107 | alone miss them. |
| 108 | |
| 109 | Pick the specific tool from `tools/list` or the agent-browser |
| 110 | manual rather than from memory. |
| 111 | |
| 112 | ## gotchas |
| 113 | |
| 114 | - **Every `agent-browser` command must know your session and restore |
| 115 | key, or it may use an empty default browser or fail to save login |
| 116 | state.** Easiest: export |