@flumecode/runner 0.15.0 → 0.17.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@flumecode/runner",
-  "version": "0.15.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,8 +65,10 @@ 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.
 - **`steps`** — an ordered list. For each step provide:
   - **`title`** — a concise imperative phrase naming the step (e.g. "Add submit_plan schema to plan.ts").
   - **`description`** — an array of bullet points that help the reviewer understand the upcoming `pseudoCode` and decide whether the plan and design are correct. Each item is a distinct, self-contained point about what is changing and why — not a single paragraph, and not a line-by-line restatement of the pseudo code. Use concrete file references (`path/to/file.ts`) and name the functions/symbols involved. Apply inline-code formatting to all identifiers.

package/skills-plugin/skills/resolve-merge-conflict/SKILL.md

@@ -93,8 +93,16 @@ before you finish. (You don't need to `git add`; the runner stages and commits f
 
 ## Your final reply
 
-Your last message **is** the report posted to the session thread. Write it for the
-user: list which files conflicted and, briefly, how you resolved each, plus how you
-verified (build/tests). Wrap conflicted file names and code identifiers in inline
-backticks per the `# Technical Writing` section. The runner appends the pull-request
-link, so don't add one.
+Call **`submit_report`** with the structured report. Fields:
+
+- `summary`: one or two sentences on what the resolve run did.
+- `filesChanged`: markdown list of files changed (from `git --no-pager diff --stat`).
+- `codeQuality`: markdown: whether build/tests passed, any quality observations.
+- `caveats`: markdown: anything deferred, risky, or worth the user's attention. Write `None.` if nothing.
+- `acceptanceCriteria`: **leave this empty (`[]`)** — there is no plan to verify for a resolve run.
+- `conflictResolution`: **required** — a markdown section, one paragraph or bullet per conflicted
+  file, explaining which side you kept and why (or how you merged both intents). Wrap file names
+  and code identifiers in inline backticks. This is what the user reads to understand how each
+  conflict was integrated.
+
+The runner renders the report and appends the pull-request link — do not add one yourself.

package/skills-plugin/skills/revise-implementation/SKILL.md

@@ -41,7 +41,7 @@ actual code. Pick exactly one:
 - **Re-plan** — the request meaningfully changes scope or direction, enough that a
   fresh plan should be agreed before building. Call **`submit_plan`** with a `plans[]` array
   containing the revised structured fields (same per-plan shape as the request-to-plan skill:
-  `scope`, `goal`, `assumptions`, `steps`, `acceptanceCriteria` — at least 2 —, `risks`,
+  `scope`, `goal`, `assumptions`, `requirements` — at least 1 —, `steps`, `acceptanceCriteria` — at least 2 —, `risks`,
   `outOfScope`). Include only one entry for a revise turn. The runner posts it as a revision
   the user can accept; make no code changes this turn.
 - **Implement** — the request is clear and reasonable. Make the change (via
@@ -80,13 +80,13 @@ essentials:
 Your last message **is** the comment posted to the plan thread — write it for the
 user:
 
-- **Implemented:** a short report — what you changed and why, which files, and the
-  verification results: list each build/test command that was run and its final
-  pass/fail result (or note that no build/test setup was found). Base "what changed"
-  and "which files" on the actual `git --no-pager diff` (`--stat` for the file
-  list), not on what a subagent claimed; if the diff is empty, say nothing was
-  changed rather than describing edits that aren't there. The runner appends the
-  pull-request link, so don't add one.
+- **Implemented:** call **`submit_report`** with the structured report, exactly as
+  `implement-plan` does. Include one `acceptanceCriteria` entry per plan AC (with a
+  met / not_met / unclear verdict and the diff hunk(s) that prove it), plus the four
+  required markdown sections (`summary`, `filesChanged`, `codeQuality`, `caveats`).
+  Base `filesChanged` and evidence on the actual `git --no-pager diff`, not on what
+  a subagent claimed; if the diff is empty, say nothing was changed. The runner
+  renders the report and appends the pull-request link — do not add one yourself.
 - **Clarify / push back:** your question or reasoning, as prose (plus any widget).
 - **Re-plan:** you called `submit_plan`; the rendered plan is posted automatically,
   so keep any extra reply text minimal.

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.