@flumecode/runner 0.21.0-beta.1 → 0.23.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@flumecode/runner",
-  "version": "0.21.0-beta.1",
+  "version": "0.23.0",
   "type": "module",
   "description": "FlumeCode local runner — claims jobs and drives your local Claude Code against a real checkout.",
   "bin": {
@@ -28,11 +28,17 @@
   "dependencies": {
     "@anthropic-ai/claude-agent-sdk": "^0.3.0",
     "@modelcontextprotocol/sdk": "^1",
+    "ink": "^5.2.1",
+    "ink-text-input": "^6.0.0",
+    "playwright": "^1.52.0",
+    "react": "^18.3.1",
     "zod": "4.4.3"
   },
   "devDependencies": {
     "@types/node": "^22.10.5",
+    "@types/react": "^19.0.0",
     "esbuild": "^0.24.2",
+    "ink-testing-library": "^4.0.0",
     "tsx": "^4.19.2",
     "typescript": "^5.7.3"
   }

package/skills-plugin/skills/create-release/SKILL.md

@@ -1,10 +1,10 @@
 ---
 name: create-release
 description: >-
-  Draft release notes and version suggestions for a release, then (after the
-  user confirms) open a bump PR that updates package.json version(s) and
-  CHANGELOG.md. Two-turn flow: first turn asks the user to confirm versions via
-  widgets; second turn (answers in thread) writes the bumps and opens the PR.
+  Draft release notes and version suggestions for a release. Two-turn flow:
+  first turn asks the user to confirm versions via widgets; second turn (answers
+  in thread) emits the structured report with confirmed versions and notes. Does
+  NOT edit package.json or CHANGELOG.md, and does NOT commit, push, or open a PR.
 ---
 
 # create-release
@@ -17,7 +17,7 @@ which one applies before acting.
 Check the thread (`# Conversation so far` in the prompt). If **no widget answers**
 appear in any prior agent turn, this is **Phase 1** — propose versions and ask.
 If a prior turn contains widget-answer selections (the user picked a version), this
-is **Phase 2** — apply the bumps and report.
+is **Phase 2** — emit the final report.
 
 ---
 
@@ -99,11 +99,11 @@ can read them inside the question widget:
 - `options`: `Yes, use these notes`, `I'll edit them in the PR`
   (You may still summarise in the reply text, but the notes MUST be in the widget `body`.)
 
-**After calling widgets, end your turn.** Do NOT open a PR in Phase 1.
+**After calling widgets, end your turn.** Do NOT edit any files in Phase 1.
 
 ---
 
-## Phase 2 — Apply the bumps and report
+## Phase 2 — Emit the final report
 
 ### 1. Read the widget answers
 
@@ -111,52 +111,19 @@ The user's confirmed version selections appear in the `# Conversation so far`
 thread as agent messages (the widget-answer turn). Extract the chosen version for
 each package from those selections.
 
-### 2. Update package.json files
+### 2. Emit the structured report
 
-For each package whose version changed, edit the `"version"` field in:
-
-- `apps/web/package.json` — for `@flumecode/web`
-- `apps/runner/package.json` — for `@flumecode/runner`
-
-Change only the `"version"` line; do not reformat the file.
-
-### 3. Update CHANGELOG.md
-
-Edit (or create) `CHANGELOG.md` at the repo root. Insert a new section at the
-top, below any existing `# Changelog` title line:
+Your final message must match this shape (adjust versions and notes to match what
+was confirmed):
 
 ```
-## [X.Y.Z / runner-X.Y.Z] - YYYY-MM-DD
+**Confirmed versions:**
+- `@flumecode/web`: `0.9.0`
+- `@flumecode/runner`: `0.5.0`
 
+**Release notes:**
 - Bullet point from release notes
 - Another bullet point
-```
-
-Use the ISO date format (`YYYY-MM-DD`). Preserve all existing entries — do not
-delete or rewrite prior sections.
-
-If both packages are bumped, list both versions in the heading (e.g.
-`## [0.9.0 / runner-0.5.0] - 2026-06-06`). If only one package is bumped, list
-only that version in the heading.
-
-### 4. Stop — do not commit or push
-
-Leave the edited files in the working tree. The runner commits them and opens the
-pull request.
-
-### 5. End with this exact report format
-
-Your final message must match this shape (adjust versions and files to match what
-actually changed):
-
-```
-**Bumped versions:**
-- `@flumecode/web`: `0.8.0` → `0.9.0`
-- `@flumecode/runner`: `0.4.0` → `0.5.0`
-
-**CHANGELOG updated** with release notes.
-
-**Files changed:** `apps/web/package.json`, `apps/runner/package.json`, `CHANGELOG.md`
 
 <!-- flumecode:versions {"@flumecode/web":"0.9.0","@flumecode/runner":"0.5.0"} -->
 ```
@@ -167,21 +134,20 @@ reads it to persist the confirmed versions on the release entity. Use the exact
 JSON key names `@flumecode/web` and `@flumecode/runner`; omit a package if its
 version did not change.
 
+**Do NOT edit package.json, CHANGELOG.md, or any other file. Do NOT commit,
+push, or open a pull request.** The GitHub Release is cut directly from the
+frozen commit by the web interface.
+
 ---
 
 ## Notes
 
-- **Runner-only bump:** if only `apps/runner/` has commits, bump only
-  `apps/runner/package.json`. Leave `apps/web/package.json` unchanged.
+- **Runner-only bump:** if only `apps/runner/` has commits, include only
+  `apps/runner/package.json`'s version in the `flumecode:versions` comment.
 - **Clear Phase 1 text:** be explicit about what changed since the last tag so the
   user can confidently confirm or override your suggestions.
-- **Edit only version files — with one exception.** Normally edit only
-  `apps/web/package.json`, `apps/runner/package.json`, and `CHANGELOG.md`. The sole
-  exception: when the prompt includes a **`# Pre-release check status`** section
-  reporting failing checks, you must also fix the failing code (any file needed) so
-  the tree is green — see "Pre-release checks" below. Never weaken or skip checks to
-  silence them.
-- **Never commit, push, or open a PR** — the runner does that.
+- **Read-only:** do not edit any files at any point. This skill is purely
+  analytical — it reads the repo, proposes versions, and emits a report.
 
 ## Pre-release
 
@@ -202,27 +168,6 @@ pre-release version strings instead of stable ones:
   `0.9.0-beta.1`) in the version-confirmation widgets instead of the stable
   version.
 
-- **Phase 2 (apply):** write the pre-release version string (e.g.
-  `0.9.0-beta.1`) to `package.json`, `CHANGELOG.md`, and the
-  `<!-- flumecode:versions {...} -->` comment — exactly as you would for a
-  stable release, just with the pre-release suffix included.
-
----
-
-## Pre-release checks
-
-We cannot release code with failing checks. Before this turn, the runner ran the
-repository's own pre-commit hook (lint / typecheck / tests). If the prompt contains
-a **`# Pre-release check status`** section, the base branch is currently broken
-_independently of the version bump_:
-
-- **Phase 1:** state plainly in your reply that the base currently fails these
-  checks and that the release will fix them as part of the bump, then ask the
-  version questions as usual.
-- **Phase 2:** fix the failing code at its root **first** (so the checks pass),
-  **then** apply the version bumps and CHANGELOG. The fixes ship in the same bump
-  PR. Do not delete or skip tests, weaken assertions, or disable checks. Still do
-  not commit or push — the runner commits everything together.
-
-If there is no `# Pre-release check status` section, the base is clean (or the check
-was skipped); proceed normally and edit only the version files.
+- **Phase 2 (emit):** include the pre-release version string (e.g.
+  `0.9.0-beta.1`) in the `<!-- flumecode:versions {...} -->` comment — exactly
+  as you would for a stable release, just with the pre-release suffix included.

package/skills-plugin/skills/preview-ui/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: preview-ui
+description: >-
+  Author an ephemeral fake-data showcase page for changed UI components so the
+  runner can screenshot them in a headless browser. Use after a UI-touching
+  implementation, when the runner provides a tmpRoute directory. Writes the
+  showcase files there and records the URL path in a sentinel file. Never
+  commits, pushes, or modifies application code outside the tmpRoute directory.
+---
+
+# preview-ui
+
+You author a **temporary showcase page** that imports the recently-changed UI
+components and fills them with realistic fake data, so the runner can start the
+repo's dev server and take headless screenshots.
+
+You write only inside the `<tmpRoute>` directory the runner hands you. You never
+modify production code, commit, or push.
+
+## What you receive
+
+The runner injects these into your prompt:
+
+- **`<tmpRoute>`** — an absolute path to an empty temp directory inside the repo
+  (already git-excluded). Write your showcase files here.
+- **Committed UI files** — the list of files changed by the implementation, so
+  you know which components to showcase.
+
+## Step 1 — Detect the framework
+
+Read the repo's `package.json` (and `package.json` files in workspaces, if any)
+to determine the framework:
+
+| Framework     | Key `dependencies` / `devDependencies`  |
+| ------------- | --------------------------------------- |
+| Next.js       | `next`                                  |
+| Vite + React  | `vite` + `react`                        |
+| Vite + Vue    | `vite` + `vue`                          |
+| Vite + Svelte | `vite` + `svelte` (no SvelteKit)        |
+| SvelteKit     | `@sveltejs/kit`                         |
+| Nuxt          | `nuxt`                                  |
+| Astro         | `astro`                                 |
+| CRA           | `react-scripts`                         |
+| Remix         | `@remix-run/react` or `@remix-run/node` |
+
+If the framework is not recognisable or the file list contains no importable
+components, write a single plain `<tmpRoute>/index.html` file with a message
+like "No supported framework detected" and write `/__flumecode_preview` to
+`<tmpRoute>/.showcase-path`. Then stop — do not create a route file.
+
+## Step 2 — Determine the entry path
+
+Choose a URL path unlikely to collide with real routes: `/__flumecode_preview`.
+Write that string (exactly, no trailing newline) to `<tmpRoute>/.showcase-path`.
+
+## Step 3 — Author the showcase entry file
+
+Create a single route/page file at the correct location under `<tmpRoute>` for
+the detected framework:
+
+| Framework              | File to create                                        |
+| ---------------------- | ----------------------------------------------------- |
+| Next.js (App Router)   | `<tmpRoute>/page.tsx` (if the project uses `app/`)    |
+| Next.js (Pages Router) | `<tmpRoute>/index.tsx` (if the project uses `pages/`) |
+| Vite + React           | `<tmpRoute>/App.tsx` (or `.jsx`)                      |
+| Vite + Vue             | `<tmpRoute>/App.vue`                                  |
+| Vite + Svelte          | `<tmpRoute>/App.svelte`                               |
+| SvelteKit              | `<tmpRoute>/+page.svelte`                             |
+| Nuxt                   | `<tmpRoute>/index.vue`                                |
+| Astro                  | `<tmpRoute>/index.astro`                              |
+| CRA                    | `<tmpRoute>/index.tsx`                                |
+| Remix                  | `<tmpRoute>/route.tsx`                                |
+
+**Next.js App Router note:** The runner mounts the showcase at
+`app/__flumecode_preview/page.tsx` by symlinking or copying `<tmpRoute>` to
+`app/__flumecode_preview/`. You only need to produce `<tmpRoute>/page.tsx` — the
+runner handles the mount.
+
+### Content rules
+
+- Import the changed components using their real relative paths (calculate the
+  path from `<tmpRoute>` to the component's source location).
+- Fill every prop with **realistic fake data** — use hardcoded literals, not
+  calls to external APIs or databases.
+- If a component requires a provider (React context, Vuex store, Pinia, etc.),
+  wrap it with a minimal in-file stub provider — do not import the real app
+  store or data layer.
+- If a component calls a route handler or fetch endpoint, stub the relevant
+  function or hook at the top of the file with a mock that returns realistic
+  hard-coded data. Do NOT import MSW or any test library; keep stubs as plain
+  module-level overrides.
+- Export the showcase page as the default export (except Astro/SvelteKit, which
+  don't require a default export).
+- Keep the file short: one `export default` function that renders all changed
+  components in a flex column, with a small amount of padding.
+
+### What NOT to do
+
+- Do not call `fetch`, `axios`, `prisma`, `supabase`, or any I/O in the
+  showcase.
+- Do not import from test utilities, MSW, Storybook, or Cypress.
+- Do not add new npm dependencies.
+- Do not edit any file outside `<tmpRoute>`.
+- Do not commit or push.
+
+## Step 4 — Verify your output
+
+Before finishing, confirm:
+
+1. `<tmpRoute>/.showcase-path` exists and contains the URL path string.
+2. The showcase entry file exists at the expected path under `<tmpRoute>`.
+3. The file imports only modules that already exist in the repo (no invented
+   paths).
+
+If you cannot produce a valid showcase (e.g. the components have complex
+dependencies you cannot stub), write only `<tmpRoute>/.showcase-path` with the
+URL string and leave the entry file absent — the runner will detect the missing
+file and skip the screenshot step gracefully.
+
+## Always
+
+- Write the URL path to `<tmpRoute>/.showcase-path` first, before any other
+  file — the runner reads it even if something else fails.
+- These files are ephemeral and git-excluded. They will be deleted by the runner
+  after screenshots are taken. Never commit or push them.
+- Your final reply should be one short sentence confirming what you created (e.g.
+  "Wrote `<tmpRoute>/page.tsx` showcasing `Button` and `Card` with fake data.").