@flumecode/runner 0.14.0 → 0.15.0

package/dist/cli.js

@@ -746,7 +746,9 @@ var pseudoCodeEntrySchema = z2.object({
 });
 var stepSchema = z2.object({
   title: z2.string().min(1).describe("A concise imperative title for this step."),
-  description: z2.string().min(1).describe("What changes and why \u2014 the rationale for this step. " + INLINE_CODE_HINT),
+  description: z2.array(z2.string().min(1)).min(1).describe(
+    "Bullet points that explain this step's change so a reviewer can judge whether the design is correct. Each array item is one short, self-contained bullet \u2014 not a single paragraph, and not a restatement of the pseudo code. " + INLINE_CODE_HINT
+  ),
   pseudoCode: z2.array(pseudoCodeEntrySchema).optional().describe(
     "Per-file pseudo code. Provide an entry for every non-documentation file this step touches. Each entry contains the file path and pseudo code describing the changes to that file."
   )
@@ -786,7 +788,9 @@ function renderPlan(plan) {
     lines2.push("");
     lines2.push(`### ${i + 1}. ${step.title}`);
     lines2.push("");
-    lines2.push(step.description);
+    for (const bullet of step.description) {
+      lines2.push(`- ${bullet}`);
+    }
     if (step.pseudoCode && step.pseudoCode.length > 0) {
       for (const entry of step.pseudoCode) {
         lines2.push("");

package/package.json

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

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

@@ -0,0 +1,64 @@
+---
+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/request-to-plan/SKILL.md

@@ -68,7 +68,7 @@ Field-by-field guidance:
   unanswered defaults from Phase 1).
 - **`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`** — what changes and why: the concrete change being made and the rationale for it. Use concrete file references (`path/to/file.ts`) and name the functions/symbols involved.
+  - **`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.
   - **`pseudoCode`** — an array of `{ file, pseudoCode }` entries. Provide an entry for every file the step touches **except** documentation files (SKILL.md, README.md, wiki pages, etc.). `pseudoCode` is optional in the schema but expected for all non-documentation files. Each entry names the file path and contains pseudo code that precisely describes the changes to make in that file.
 - **`acceptanceCriteria`** — **required; at least 2 items.** Each criterion must
   be a concrete, deterministically-checkable condition that a third party can verify