@flumecode/runner 0.1.0 → 0.2.0

package/dist/cli.js

@@ -175,6 +175,9 @@ var stepSchema = z2.object({
   files: z2.array(z2.string()).optional().describe("Affected file paths.")
 });
 var planInputSchema = {
+  title: z2.string().min(1).max(120).describe(
+    "A concise, descriptive name for THIS plan. Must be distinct from the request title and from any sibling plans on the same request. Keep it under 120 characters."
+  ),
   scope: z2.enum(["feat", "fix", "chore", "docs", "test", "refactor"]).describe("The primary intent of the change."),
   goal: z2.string().min(1).describe("One or two sentences stating the outcome."),
   assumptions: z2.array(z2.string()).describe("Anything decided during planning, including unanswered defaults."),
@@ -188,6 +191,8 @@ var planInputSchema = {
 var planSchema = z2.object(planInputSchema);
 function renderPlan(plan) {
   const lines = [];
+  lines.push(`# ${plan.title}`);
+  lines.push("");
   lines.push(`**Scope** \u2014 \`${plan.scope}\``);
   lines.push("");
   lines.push(`**Goal** \u2014 ${plan.goal}`);
@@ -235,7 +240,7 @@ function createPlanTooling() {
   let renderedPlan = null;
   const submitPlan = tool2(
     SUBMIT_PLAN,
-    "Submit the finished plan. Call this \u2014 and only this \u2014 when the plan is complete and ready to post. The runner renders your structured fields into the canonical plan markdown and posts it as your comment. acceptanceCriteria is required and must contain at least 2 observable, verifiable conditions (behaviors, tests, or states you could check) that together define 'done'. After calling this, end your turn.",
+    "Submit the finished plan. Call this \u2014 and only this \u2014 when the plan is complete and ready to post. The runner renders your structured fields into the canonical plan markdown and posts it as your comment. acceptanceCriteria is required and must contain at least 2 observable, verifiable conditions (behaviors, tests, or states you could check) that together define 'done'. After calling this, end your turn. The `title` field names this specific plan \u2014 make it concise and distinct from the request title.",
     planInputSchema,
     async (args) => {
       renderedPlan = renderPlan(planSchema.parse(args));

package/package.json

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

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

@@ -57,6 +57,8 @@ it as your comment — do **not** write the plan as your reply text.
 
 Field-by-field guidance:
 
+- **`title`** — a concise, descriptive name for this specific plan. Must be distinct from the
+  request title and from any sibling plans on the same request. Keep it under 120 characters.
 - **`scope`** — exactly one of `feat`, `fix`, `chore`, `docs`, `test`,
   `refactor`. Pick the one that best matches the primary intent of the request.
 - **`goal`** — one or two sentences stating the outcome, phrased so it directly
@@ -85,9 +87,10 @@ plan without re-deriving it.
 A single request can yield **several** plans — one thread can be accepted into
 many. If the work naturally splits into independent pieces, or the user asks for
 more than one plan, call `submit_plan` once for each finished plan so each can
-be accepted into its own GitHub issue. After a plan is accepted the user may
-keep commenting to refine it; treat a later turn as a fresh **Plan** phase and
-call `submit_plan` again with the revised fields.
+be accepted into its own GitHub issue. Give each plan its own distinct `title`
+so sibling plans don't collide. After a plan is accepted the user may keep
+commenting to refine it; treat a later turn as a fresh **Plan** phase and call
+`submit_plan` again with the revised fields.
 
 ## Always