@flumecode/runner 0.16.0 → 0.17.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@flumecode/runner",
-  "version": "0.16.0",
+  "version": "0.17.0",
   "type": "module",
   "description": "FlumeCode local runner — claims jobs and drives your local Claude Code against a real checkout.",
   "bin": {

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

@@ -90,10 +90,14 @@ For **each package that has commits** (skip unchanged ones), call
   if patch suggested: also offer minor and major), plus the current version as
   "No change (keep X.Y.Z)".
 
-Also present the drafted release notes in your reply text so the user can read
-them, then call `mcp__flume_widgets__single_select` for a confirmatory question:
-`Do the release notes look correct?` with options `Yes, use these notes` and
-`I'll edit them in the PR`.
+Also call `mcp__flume_widgets__single_select` for the notes confirmation, passing
+the drafted release notes (the 3–10 bullet markdown) as its `body` so the user
+can read them inside the question widget:
+
+- `body`: the drafted release-notes markdown
+- `question`: `Do the release notes look correct?`
+- `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.
 

package/skills-plugin/skills/request-to-plan/SKILL.md

@@ -31,6 +31,7 @@ and determine which phase you are in:**
 
 1. Investigate the repo enough to ask _informed_ questions — locate the relevant
    files, existing patterns, and constraints. Never ask what the code answers.
+   If the request is a bug fix, investigate deeply enough to identify the **root cause** (the specific code or condition producing the incorrect behavior) before proceeding to Plan — you will need it for the `rootCause` field.
 2. Identify genuine ambiguity only: scope, intended behavior, edge cases,
    competing approaches, acceptance criteria. Skip anything you can reasonably
    decide yourself.
@@ -64,6 +65,7 @@ Field-by-field guidance:
 - **`goal`** — one or two sentences stating the outcome, phrased so it directly
   answers the request's title and body. Must be achievable by the steps below
   and nothing more.
+- **`rootCause`** — required when `scope` is `fix`; omit for all other scopes. Identify the underlying cause of the bug — the specific code, logic, or condition that produces the incorrect behavior, **not** the symptom. To fill this accurately, you must investigate the codebase deeply enough to find the root cause before writing the plan.
 - **`assumptions`** — anything you decided during investigation (including
   unanswered defaults from Phase 1).
 - **`requirements`** — **required; at least 1 item.** Plain-language statements of what this change must accomplish and why, written so a non-technical reader can follow them. Distinct from `acceptanceCriteria`: requirements explain intent and rationale; acceptance criteria are the machine-checkable proof. At least 1 item required.

package/skills-plugin/skills/format-code-plugin-generator/SKILL.md

@@ -1,64 +0,0 @@
----
-name: format-code-plugin-generator
-description: >-
-  Generate a concrete plan to install the FlumeCode Format plugin for THIS repo —
-  a .flumecode/plugins/format-code/ manifest wired to the pre-commit socket that
-  auto-formats code (prettier --write) so changes ride into the commit.
----
-
-# format-code-plugin-generator
-
-You generate a concrete, repo-specific plan to install the FlumeCode Format
-plugin. You work **read-only**: inspect the repo and produce a plan via
-`submit_plan`; never edit files.
-
-## Orient yourself first
-
-Before producing the plan, inspect:
-
-1. `.flumecode/wiki/README.md` and `components/plugins.md` (if present) for context.
-2. `package.json` `scripts` — look for `format`, `format:write`, `prettier` references.
-3. `.prettierrc*` — confirm Prettier is configured.
-4. `.husky/pre-commit` — find the existing formatting step this plugin replaces.
-
-From this, determine the **exact shell command** the `run` script should execute
-(e.g. `pnpm format`). Do not hard-code — derive from the repo.
-
-## Produce the plan
-
-Call `submit_plan` **once**, passing a `plans` array with one entry whose steps
-instruct the implementer to create:
-
-### Artifact — `.flumecode/plugins/format-code/plugin.json`
-
-```json
-{
-  "key": "format-code",
-  "socket": "pre-commit",
-  "run": "<detected format write command>"
-}
-```
-
-Derive `run` from the repo's detected commands (e.g. `pnpm format`). Do not hard-code — include the actual commands discovered in the Orient step.
-
-### Manifest shape
-
-The manifest `plugin.json` must have exactly these fields:
-
-```
-{ key, socket, run }
-```
-
-This is the shape the FlumeCode plugin loader expects.
-
-### Acceptance criteria the plan must include
-
-- `.flumecode/plugins/format-code/plugin.json` exists with `key: "format-code"`, `socket: "pre-commit"`, and `run` set to the detected write-format command.
-- The `run` command reformats files in place and exits 0; reformatted files are staged and included in the commit.
-
-## Always
-
-- Stay read-only. Produce the plan via `submit_plan`; never edit files.
-- The plan must be specific enough for an `implement-plan` run to execute
-  without re-deriving the commands — include the actual detected commands in
-  the step descriptions and artifact content.

package/skills-plugin/skills/lint-plugin-generator/SKILL.md

@@ -1,66 +0,0 @@
----
-name: lint-plugin-generator
-description: >-
-  Generate a concrete plan to install the FlumeCode Lint plugin for THIS repo —
-  a .flumecode/plugins/lint/ manifest wired to the pre-commit socket that runs
-  the repo's lint/format checks.
----
-
-# lint-plugin-generator
-
-You generate a concrete, repo-specific plan to install the FlumeCode Lint
-plugin. You work **read-only**: inspect the repo and produce a plan via
-`submit_plan`; never edit files.
-
-## Orient yourself first
-
-Before producing the plan, inspect:
-
-1. `.flumecode/wiki/README.md` and `components/skills-plugin.md` (if present) for context.
-2. `package.json` `scripts` — look for `lint`, `format`, `format:check`, `typecheck`, `test`.
-3. `.lintstagedrc.json` / `.lintstagedrc.js` — staged-file formatters.
-4. `.husky/pre-commit` — the exact commands the pre-commit hook already runs.
-5. ESLint config (`eslint.config.*`, `.eslintrc.*`) and Prettier config (`.prettierrc.*`) to confirm tools are present.
-
-From this, determine the **exact shell commands** the run script should execute
-(e.g. `pnpm exec lint-staged && pnpm lint && pnpm typecheck`). Do not
-hard-code — derive from the repo.
-
-## Produce the plan
-
-Call `submit_plan` **once**, passing a `plans` array with one entry whose steps
-instruct the implementer to create:
-
-### Artifact 1 — `.flumecode/plugins/lint/plugin.json`
-
-```json
-{
-  "key": "lint",
-  "socket": "pre-commit",
-  "run": "<detected lint/format/typecheck command chain>"
-}
-```
-
-Derive `run` from the repo's detected commands (e.g. `pnpm exec lint-staged && pnpm lint && pnpm typecheck && pnpm test`). Do not hard-code — include the actual commands discovered in the Orient step.
-
-### Manifest shape
-
-The manifest `plugin.json` must have exactly these fields:
-
-```
-{ key, socket, run }
-```
-
-This is the shape the FlumeCode plugin loader expects.
-
-### Acceptance criteria the plan must include
-
-- `.flumecode/plugins/lint/plugin.json` exists with `key: "lint"`, `socket: "pre-commit"`, and `run` set to the detected command chain.
-- The `run` command exits non-zero on any lint/format/typecheck failure.
-
-## Always
-
-- Stay read-only. Produce the plan via `submit_plan`; never edit files.
-- The plan must be specific enough for an `implement-plan` run to execute
-  without re-deriving the commands — include the actual detected commands in
-  the step descriptions and artifact content.

package/skills-plugin/skills/unit-test-plugin-generator/SKILL.md

@@ -1,74 +0,0 @@
----
-name: unit-test-plugin-generator
-description: >-
-  Generate a concrete plan to install the FlumeCode Unit Test plugin for THIS repo —
-  a .flumecode/plugins/unit-test/ manifest wired to the pre-commit socket that runs
-  the repo's unit tests and emits a JSON report the runner parses into pass/fail counts.
----
-
-# unit-test-plugin-generator
-
-You generate a concrete, repo-specific plan to install the FlumeCode Unit Test
-plugin. You work **read-only**: inspect the repo and produce a plan via
-`submit_plan`; never edit files.
-
-## Orient yourself first
-
-Before producing the plan, inspect:
-
-1. `.flumecode/wiki/README.md` and `components/plugins.md` (if present) for context.
-2. `package.json` `scripts` — look for `test`, `test:unit`, or similar test commands.
-3. `vitest.config.*` — to detect Vitest as the test runner.
-4. `jest.config.*` — to detect Jest as the test runner.
-
-From this, determine:
-
-- Which test runner is in use (Vitest or Jest).
-- The **exact shell command** that runs the tests and writes a JSON report file (e.g. `pnpm vitest run --reporter=json --outputFile=.flumecode/tmp/unit-test-report.json`). Do not hard-code — derive from the repo.
-
-## Produce the plan
-
-Call `submit_plan` **once**, passing a `plans` array with one entry whose steps
-instruct the implementer to:
-
-### Artifact 1 — `.flumecode/plugins/unit-test/plugin.json`
-
-```json
-{
-  "key": "unit-test",
-  "socket": "pre-commit",
-  "run": "<detected command, e.g. pnpm vitest run --reporter=json --outputFile=.flumecode/tmp/unit-test-report.json>",
-  "report": { "file": ".flumecode/tmp/unit-test-report.json", "format": "jest" }
-}
-```
-
-Derive `run` from the repo's detected test runner and scripts. Do not hard-code —
-include the actual commands discovered in the Orient step.
-
-### Artifact 2 — `.gitignore` update
-
-Add `.flumecode/tmp/` to `.gitignore` so the transient JSON report file is never committed.
-
-### Manifest shape
-
-The manifest `plugin.json` must have exactly these fields:
-
-```
-{ key, socket, run, report }
-```
-
-where `report.file` points to the JSON report output path (repo-relative) and
-`report.format` is `"jest"` (Vitest's JSON reporter uses the same schema).
-
-### Acceptance criteria the plan must include
-
-- `.flumecode/plugins/unit-test/plugin.json` exists with `key: "unit-test"`, `socket: "pre-commit"`, `run` set to the detected test command that writes a JSON report, and `report` set to `{ "file": ".flumecode/tmp/unit-test-report.json", "format": "jest" }`.
-- The `run` command exits non-zero on any test failure and writes the JSON report file.
-- `.flumecode/tmp/` is present in `.gitignore`.
-
-## Always
-
-- Stay read-only. Produce the plan via `submit_plan`; never edit files.
-- The plan must be specific enough for an `implement-plan` run to execute
-  without re-deriving the commands — include the actual detected commands in
-  the step descriptions and artifact content.