@flumecode/runner 0.16.0 → 0.18.0

package/package.json

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

package/skills-plugin/rules/technical-writing.md

@@ -1,8 +1,9 @@
 ---
 name: technical-writing
 description: >-
-  Inline-code conventions for agent-authored plan and report prose: wrap code
-  identifiers in backticks so they render as inline code.
+  Inline-code and output-language conventions for agent-authored plan and report
+  prose: wrap code identifiers in backticks, and write prose in the same natural
+  language as the user's request.
 ---
 
 # Technical Writing
@@ -12,3 +13,12 @@ description: >-
 Wrap code identifiers — function names, variable names, type names, file names, commands, and flags — in inline backticks so they render as inline code. For example: `getCodingSessionsForRequest`, not getCodingSessionsForRequest.
 
 This convention applies to all free-text fields in plans and reports: goals, step descriptions, acceptance criteria, summaries, code-quality notes, and caveats.
+
+## Output language
+
+Write all free-text prose in the same natural language as the user's request
+(Korean in → Korean out, English in → English out). This applies to every
+free-text field you author — plan goals/steps/risks, report summaries,
+clarifying questions, and push-backs. Keep code identifiers, file paths,
+commands, and quoted code/diffs verbatim; only the surrounding prose follows
+the request language.

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/document/SKILL.md

@@ -88,11 +88,26 @@ contain, in this order:
 
 ### Every page: front-load an "At a glance" block
 
+Before the "At a glance" block on **every** page (component pages, README,
+architecture, glossary), place a TL;DR blockquote immediately after the H1:
+
+```
+> **TL;DR** — one plain-language sentence on what this page covers.
+```
+
+Then a blank line, then the existing `> **Purpose**` / "At a glance" block
+(where applicable). For `README.md`, place the TL;DR after the
+`<!-- wiki-synced-to -->` marker and H1. The blank line between the TL;DR and
+the next blockquote is required — without it, markdown merges the two
+blockquotes into one. This rule applies in both Bootstrap and Update modes.
+
 So an agent can grab context in seconds, begin each component page with:
 
 ```
 # <component>
 
+> **TL;DR** — one plain-language sentence on what this page covers.
+
 > **Purpose** — one or two sentences.
 > **Key files** — `path/a.ts`, `path/b.ts` (the entry points worth opening).
 > **Depends on** — what it relies on. **Used by** — what relies on it.

package/skills-plugin/skills/implement-plan/SKILL.md

@@ -138,7 +138,11 @@ the next step.
 7. **Report** — Task, `model: "opus"`, read-only. Give the subagent the AC
    verdicts (with criterion text, from step 4), the Verify results (from step 3),
    and the quality findings, and tell it to run `git --no-pager diff` itself as
-   the **single source of truth** for the report. Do not pass the full plan — the
+   the **single source of truth** for the report. Pass the Verify results as the
+   `cicd` field — one entry per check with `command`, `status` (`passed`/`failed`),
+   and (on failure) a short `output` excerpt. Omit `cicd` when no verification
+   setup exists. A failing check does NOT block the report — include the failing
+   entry and continue. Do not pass the full plan — the
    AC verdicts carry each criterion verbatim, and the live `git --no-pager diff`
    is the authoritative source for evidence; re-inlining the full plan is
    redundant. Keep each subagent prompt to the minimal self-contained slice it
@@ -181,6 +185,7 @@ The report subagent calls `submit_report` with these fields:
     verbatim from the live `git --no-pager diff`, including each hunk's `@@ -a,b +c,d @@` header line(s) (do not strip them — the report renders file line numbers from them), and proves the verdict (`note`
     optionally explains it). Never include a hunk that isn't in the actual diff. Cite
     the supporting hunk(s) for a met criterion; may be empty for not_met / unclear.
+- **`cicd`** (optional) — array of Verify-phase check results. Each entry: `command` (exact command run), `status` (`"passed"` / `"failed"`), `output` (short failing-output excerpt, on failure only). Omit when the repo has no verification setup. Rendered under `## CI/CD`. A failing check does not block the report.
 
 ## Always
 

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/resolve-merge-conflict/SKILL.md

@@ -104,5 +104,6 @@ Call **`submit_report`** with the structured report. Fields:
   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.
+- `cicd` (optional): array of Verify-phase check results from Step 3, each with `command`, `status` (`"passed"`/`"failed"`), and `output` on failure. Omit when no build/test setup exists.
 
 The runner renders the report and appends the pull-request link — do not add one yourself.

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

@@ -84,6 +84,8 @@ user:
   `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`).
+  Include `cicd` from the Verify results (one entry per check, same shape as
+  `implement-plan`; omit when no verification setup).
   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.

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.