@flumecode/runner 0.17.0 → 0.18.0

package/dist/cli.js

@@ -266,6 +266,28 @@ function widgetPosted(kind) {
 import { createSdkMcpServer as createSdkMcpServer2, tool as tool2 } from "@anthropic-ai/claude-agent-sdk";
 import { z as z2 } from "zod";
 
+// src/code-lang.ts
+var EXT_TO_LANG = {
+  ts: "typescript",
+  tsx: "tsx",
+  js: "javascript",
+  jsx: "jsx",
+  json: "json",
+  css: "css",
+  md: "markdown",
+  sh: "bash",
+  py: "python",
+  yaml: "yaml",
+  yml: "yaml",
+  html: "markup",
+  xml: "markup",
+  sql: "sql"
+};
+function langFromPath(path) {
+  const ext = path.split(".").pop()?.toLowerCase();
+  return ext ? EXT_TO_LANG[ext] : void 0;
+}
+
 // src/schema-hints.ts
 var INLINE_CODE_HINT = "Wrap code identifiers (function, variable, type, and file names, commands, and flags) in inline backticks, e.g. `getCodingSessionsForRequest`.";
 
@@ -357,7 +379,8 @@ function renderPlan(plan) {
         lines2.push("");
         lines2.push(`\`${entry.file}\``);
         lines2.push("");
-        lines2.push("```");
+        const lang = langFromPath(entry.file);
+        lines2.push(lang ? "```" + lang : "```");
         lines2.push(entry.pseudoCode);
         lines2.push("```");
       }
@@ -446,6 +469,15 @@ var STATUS_ICON = {
   not_met: "\u274C",
   unclear: "\u26A0\uFE0F"
 };
+var CICD_STATUS_ICON = {
+  passed: "\u2705",
+  failed: "\u274C"
+};
+var cicdCheckSchema = z3.object({
+  command: z3.string().min(1).describe("The exact verification command run, e.g. `pnpm typecheck`."),
+  status: z3.enum(["passed", "failed"]).describe("Whether the command passed or failed."),
+  output: z3.string().optional().describe("Short excerpt of failing output; include on failure.")
+});
 var evidenceSchema = z3.object({
   file: z3.string().min(1).describe("Repo-relative path the hunk comes from."),
   hunk: z3.string().min(1).describe(
@@ -477,6 +509,9 @@ var reportInputSchema = {
   ),
   conflictResolution: z3.string().optional().describe(
     "Markdown: present ONLY when a merge conflict was actually resolved. Explain, per conflicted file, how ours/theirs were integrated. Rendered under '## Conflict resolution'. Omit entirely when no conflict occurred."
+  ),
+  cicd: z3.array(cicdCheckSchema).optional().describe(
+    "Verify-phase build/typecheck/lint/test results. Omit when the repo has no verification setup. Rendered under '## CI/CD'."
   )
 };
 var reportSchema = z3.object(reportInputSchema);
@@ -504,6 +539,15 @@ function renderReport(report) {
   if (report.conflictResolution?.trim()) {
     lines2.push("", "## Conflict resolution", "", report.conflictResolution.trim());
   }
+  if (report.cicd && report.cicd.length > 0) {
+    lines2.push("", "## CI/CD");
+    for (const check of report.cicd) {
+      lines2.push("", `- ${CICD_STATUS_ICON[check.status]} \`${check.command}\``);
+      if (check.status === "failed" && check.output?.trim()) {
+        lines2.push("", "```", check.output.trim(), "```");
+      }
+    }
+  }
   lines2.push("", "## Code quality", "", report.codeQuality.trim());
   lines2.push("", "## Caveats / follow-ups", "", report.caveats.trim());
   return lines2.join("\n");
@@ -512,7 +556,7 @@ function createReportTooling() {
   let submittedReport = null;
   const submitReport = tool3(
     SUBMIT_REPORT,
-    "Submit the final implementation report as structured data. Call this exactly once, at the end of the run. `acceptanceCriteria` must contain one entry per plan criterion, each with a met / not_met / unclear verdict and the diff hunk(s) that prove it. `summary`, `filesChanged`, `codeQuality`, and `caveats` are the four named markdown sections. Do NOT include a PR link \u2014 the runner appends it.",
+    "Submit the final implementation report as structured data. Call this exactly once, at the end of the run. `acceptanceCriteria` must contain one entry per plan criterion, each with a met / not_met / unclear verdict and the diff hunk(s) that prove it. `summary`, `filesChanged`, `codeQuality`, and `caveats` are the four named markdown sections. `cicd` (optional) holds Verify-phase check results (one entry per command with `command`, `status` `passed`/`failed`, and `output` on failure); omit when no verification setup exists. Do NOT include a PR link \u2014 the runner appends it.",
     reportInputSchema,
     async (args) => {
       submittedReport = reportSchema.parse(args);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@flumecode/runner",
-  "version": "0.17.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/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/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.