@desplega.ai/agent-swarm 1.145.0 → 1.147.0

package/dist/{index-53zyht4z.js → index-tce1rss4.js}

@@ -1,10 +1,13 @@
+import {
+  buildSkillContent
+} from "./cli-ep19k3mb.js";
 import {
   agentFsProvisionSeeder,
   extractArgsJsonSchema,
   extractScriptSignature,
   typecheckScript
-} from "./cli-ygbjp3z8.js";
-import"./cli-gzky0gkr.js";
+} from "./cli-54wwve05.js";
+import"./cli-de14znh8.js";
 import {
   require_dist
 } from "./cli-qgm2pfpq.js";
@@ -13,15 +16,16 @@ import {
   upsertScriptByName,
   validateDefinition,
   validateScriptImports
-} from "./cli-rs6ec3b9.js";
+} from "./cli-3tgwnf43.js";
 import"./cli-epan13p1.js";
-import"./cli-a0g1gbt5.js";
-import"./cli-s2f20r5w.js";
+import"./cli-hbv0kq6w.js";
+import"./cli-1th1728g.js";
 import"./cli-y89t4nca.js";
 import"./cli-f14fvzag.js";
-import"./cli-fs1kkqgr.js";
-import"./cli-wvp6bvy4.js";
+import"./cli-m9sxbkhm.js";
+import"./cli-zhjmqxzh.js";
 import"./cli-aehm1rbq.js";
+import"./cli-9d8ntetj.js";
 import {
   computeContentHash,
   createScheduledTask,
@@ -38,15 +42,15 @@ import {
   updateSkill,
   updateWorkflow,
   upsertSkillFiles
-} from "./cli-f567d5c1.js";
-import"./cli-kpev657q.js";
-import"./cli-7fnkj1hj.js";
+} from "./cli-ftht3zzj.js";
+import"./cli-y6b6fb76.js";
+import"./cli-kpv03zhj.js";
 import"./cli-e29gmdmw.js";
 import"./cli-c2mk1kgf.js";
 import"./cli-ej6gbxfb.js";
 import"./cli-sd0mxa3c.js";
 import"./cli-w5e1d1vv.js";
-import"./cli-dc9k2ba9.js";
+import"./cli-w9kb3bk1.js";
 import"./cli-xqcq9y5e.js";
 import"./cli-zf8jjwex.js";
 import {
@@ -3933,7 +3937,7 @@ const CONTRADICTORY_RE =
   /\\b(do not|don't|never)\\b[\\s\\S]{0,240}\\b(always|must|required)\\b|\\b(always|must|required)\\b[\\s\\S]{0,240}\\b(do not|don't|never)\\b/i;
 
 const CODE_REGISTRY_EVENTS =
-  "agentmail.email.followup agentmail.email.mapped_lead agentmail.email.mapped_worker agentmail.email.no_agent agentmail.email.unmapped common.command_suggestions.github_comment_issue common.command_suggestions.github_comment_pr common.command_suggestions.github_issue common.command_suggestions.github_pr common.command_suggestions.gitlab_issue common.command_suggestions.gitlab_mr common.delegation_instruction common.delegation_instruction.gitlab github.check_run.failed github.check_suite.failed github.comment.mentioned github.issue.assigned github.issue.labeled github.issue.mentioned github.pull_request.assigned github.pull_request.closed github.pull_request.labeled github.pull_request.mentioned github.pull_request.review_requested github.pull_request.review_submitted github.pull_request.synchronize github.workflow_run.failed gitlab.comment.mentioned gitlab.issue.assigned gitlab.merge_request.opened gitlab.pipeline.failed heartbeat.boot-triage heartbeat.checklist jira.issue.assigned jira.issue.commented jira.issue.followup kapso.message.received linear.issue.assigned linear.issue.followup linear.issue.reassigned slack.assistant.greeting slack.assistant.offline slack.assistant.suggested_prompts slack.message.thread_context system.agent.communication system.agent.lead system.agent.memory system.agent.memory.remote system.agent.outputs system.agent.outputs.no_agent_fs system.agent.repository system.agent.role system.agent.secrets system.agent.slack system.agent.tools_skills system.agent.worker system.agent.worker.remote system.agent.workspace system.agent.workspace.remote system.session.lead system.session.lead.managed system.session.worker system.session.worker.managed system.session.worker.remote task.budget.refused task.requester.profile task.worker.completed task.worker.failed".split(
+  "agentmail.email.followup agentmail.email.mapped_lead agentmail.email.mapped_worker agentmail.email.no_agent agentmail.email.unmapped common.command_suggestions.github_comment_issue common.command_suggestions.github_comment_pr common.command_suggestions.github_issue common.command_suggestions.github_pr common.command_suggestions.gitlab_issue common.command_suggestions.gitlab_mr common.delegation_instruction common.delegation_instruction.gitlab github.check_run.failed github.check_suite.failed github.comment.mentioned github.issue.assigned github.issue.labeled github.issue.mentioned github.pull_request.assigned github.pull_request.closed github.pull_request.labeled github.pull_request.mentioned github.pull_request.review_requested github.pull_request.review_submitted github.pull_request.synchronize github.workflow_run.failed gitlab.comment.mentioned gitlab.issue.assigned gitlab.merge_request.opened gitlab.pipeline.failed heartbeat.boot-triage heartbeat.checklist jira.issue.assigned jira.issue.commented jira.issue.followup kapso.message.received linear.issue.assigned linear.issue.followup linear.issue.reassigned slack.assistant.greeting slack.assistant.offline slack.assistant.suggested_prompts slack.message.attachment_failed slack.message.thread_context system.agent.communication system.agent.lead system.agent.memory system.agent.memory.remote system.agent.outputs system.agent.outputs.no_agent_fs system.agent.repository system.agent.role system.agent.secrets system.agent.slack system.agent.tools_skills system.agent.worker system.agent.worker.remote system.agent.workspace system.agent.workspace.remote system.session.lead system.session.lead.managed system.session.worker system.session.worker.managed system.session.worker.remote task.budget.refused task.requester.profile task.worker.completed task.worker.failed".split(
     " ",
   );
 
@@ -4725,6 +4729,232 @@ export default async function smartRecall(args: any, ctx: any) {
 }
 `;
 
+// src/be/seed-scripts/catalog/star-history-refresh.ts
+var star_history_refresh_default = `import type { ScriptContext } from "swarm-sdk";
+import * as z from "zod";
+import { renderChart } from "./star-history-renderer";
+
+export const argsSchema = z.object({
+  dryRun: z.boolean().default(false),
+  authenticated: z.boolean().default(true),
+});
+
+const repository = "desplega-ai/agent-swarm";
+const namespace = "star-history:desplega-ai/agent-swarm";
+const cacheSchema = z.object({
+  fetchedAt: z.string(),
+  pages: z.array(z.object({ etag: z.string().nullable(), timestamps: z.array(z.number().finite()) })),
+});
+type Cache = z.infer<typeof cacheSchema>;
+
+/** Refresh the light and dark star-history images, retaining the last-known series on GitHub failure. */
+export default async function main(args: z.input<typeof argsSchema>, ctx: ScriptContext) {
+  const options = argsSchema.parse(args ?? {});
+  const entry = await ctx.swarm.kv_getOrNull({ namespace, key: "series" });
+  const parsed = cacheSchema.safeParse(entry?.value);
+  const cached = parsed.success ? parsed.data : undefined;
+  let series: Cache;
+  let stale = false;
+  let fetchError: string | undefined;
+  let requests = 0;
+  let notModified = 0;
+  try {
+    const pages: Cache["pages"] = [];
+    const deadline = Date.now() + 12000;
+    // Bound the job so a pagination error cannot consume the entire API budget.
+    for (let page = 1; page <= 50; page++) {
+      if (Date.now() > deadline) throw new Error("GitHub refresh budget exhausted");
+      const previous = cached?.pages[page - 1];
+      const headers: Record<string, string> = {
+        Accept: "application/vnd.github.star+json",
+        "User-Agent": "agent-swarm-star-history-generator",
+        "X-GitHub-Api-Version": "2022-11-28",
+      };
+      if (options.authenticated) headers.Authorization = "Bearer [REDACTED:GITHUB_TOKEN]";
+      if (previous?.etag) headers["If-None-Match"] = previous.etag;
+      requests++;
+      const response = await ctx.stdlib.fetch(
+        \`https://api.github.com/repos/\${repository}/stargazers?per_page=100&page=\${page}\`,
+        { headers, signal: AbortSignal.timeout(1500) },
+      );
+      let current: Cache["pages"][number];
+      if (response.status === 304 && previous) {
+        current = previous;
+        notModified++;
+      } else {
+        if (!response.ok) throw new Error(\`GitHub stargazers HTTP \${response.status}\`);
+        const rows = z.array(z.object({ starred_at: z.string() })).parse(await response.json());
+        const timestamps = rows.map((row) => Date.parse(row.starred_at));
+        if (timestamps.some((timestamp) => !Number.isFinite(timestamp))) {
+          throw new Error("GitHub returned invalid star timestamps");
+        }
+        current = { etag: response.headers.get("etag"), timestamps };
+      }
+      pages.push(current);
+      if (current.timestamps.length < 100) break;
+      if (page === 50) throw new Error("Stargazer pagination exceeded 50 pages");
+    }
+    if (!pages.some((page) => page.timestamps.length)) throw new Error("No stargazers returned");
+    series = { fetchedAt: new Date().toISOString(), pages };
+    await ctx.swarm.kv_set({ namespace, key: "series", value: series });
+  } catch (error) {
+    if (!cached?.pages.some((page) => page.timestamps.length)) {
+      throw new Error("GitHub fetch failed and no cached series exists; no pages published");
+    }
+    series = cached;
+    stale = true;
+    // Avoid transporting fetch exception text, which may include request details.
+    fetchError = error instanceof Error && error.message.startsWith("GitHub stargazers HTTP")
+      ? error.message : "GitHub refresh failed; using last-known series";
+  }
+
+  const timestamps = series.pages.flatMap((page) => page.timestamps).sort((a, b) => a - b);
+  const pages = [];
+  for (const theme of ["light", "dark"] as const) {
+    const body = renderChart(repository, timestamps, theme);
+    const slug = \`star-history-\${theme}\`;
+    if (options.dryRun) {
+      pages.push({ slug, bytes: new TextEncoder().encode(body).length });
+      continue;
+    }
+    const response = await ctx.swarm.page_create({
+      slug, title: \`Star history (\${theme})\`, body,
+      description: \`GitHub stars for \${repository}; fetched \${series.fetchedAt}\`,
+      contentType: "image/svg+xml", authMode: "public",
+    }) as { data?: { id?: string; api_url?: string }; id?: string; api_url?: string };
+    const page = response.data ?? response;
+    if (!page.id || !page.api_url) throw new Error(\`Failed to publish \${slug}\`);
+    pages.push({ slug, id: page.id, apiUrl: page.api_url });
+  }
+  return {
+    repository, stars: timestamps.length, fetchedAt: series.fetchedAt, stale, fetchError,
+    authenticated: options.authenticated, requests, notModified, dryRun: options.dryRun, pages,
+  };
+}
+`;
+
+// src/be/seed-scripts/catalog/star-history-renderer.ts
+var star_history_renderer_default = `const themes = {
+  light: {
+    background: "#ffffff",
+    border: "#e5e7eb",
+    grid: "#e5e7eb",
+    text: "#111827",
+    muted: "#6b7280",
+    accent: "#f59e0b",
+  },
+  dark: {
+    background: "#0d1117",
+    border: "#30363d",
+    grid: "#21262d",
+    text: "#f0f6fc",
+    muted: "#8b949e",
+    accent: "#f59e0b",
+  },
+};
+
+function escapeXml(value: string) {
+  return value.replaceAll("&", "&amp;").replaceAll("<", "&lt;").replaceAll(">", "&gt;");
+}
+
+function niceStep(maximum: number, targetTickCount = 6) {
+  const roughStep = maximum / targetTickCount;
+  const power = 10 ** Math.floor(Math.log10(roughStep));
+  const normalized = roughStep / power;
+  const multiplier = normalized <= 1 ? 1 : normalized <= 2 ? 2 : normalized <= 5 ? 5 : 10;
+  return multiplier * power;
+}
+
+export function renderChart(repository: string, timestamps: number[], themeName: keyof typeof themes) {
+  const theme = themes[themeName];
+  const width = 960;
+  const height = 520;
+  const margin = { top: 96, right: 34, bottom: 62, left: 76 };
+  const plotWidth = width - margin.left - margin.right;
+  const plotHeight = height - margin.top - margin.bottom;
+  const firstStar = timestamps[0]!;
+  const lastStar = timestamps.at(-1)!;
+  const timeRange = Math.max(lastStar - firstStar, 1);
+  const yStep = niceStep(timestamps.length);
+  const yMaximum = Math.ceil(timestamps.length / yStep) * yStep;
+  const plotBottom = margin.top + plotHeight;
+
+  const x = (timestamp: number) => margin.left + ((timestamp - firstStar) / timeRange) * plotWidth;
+  const y = (stars: number) => margin.top + plotHeight - (stars / yMaximum) * plotHeight;
+
+  const points = timestamps.map((timestamp, index) => ({
+    x: x(timestamp),
+    y: y(index + 1),
+  }));
+  const linePath = points
+    .map((point, index) => \`\${index === 0 ? "M" : "L"} \${point.x.toFixed(1)} \${point.y.toFixed(1)}\`)
+    .join(" ");
+  const areaPath = \`M \${points[0]!.x.toFixed(1)} \${plotBottom.toFixed(1)} \${linePath.replace(/^M/, "L")} L \${points.at(-1)!.x.toFixed(1)} \${plotBottom.toFixed(1)} Z\`;
+
+  const yTicks = [];
+  for (let stars = 0; stars <= yMaximum; stars += yStep) {
+    const tickY = y(stars);
+    yTicks.push(\`
+      <line x1="\${margin.left}" y1="\${tickY.toFixed(1)}" x2="\${width - margin.right}" y2="\${tickY.toFixed(1)}" stroke="\${theme.grid}" />
+      <text x="\${margin.left - 14}" y="\${(tickY + 5).toFixed(1)}" text-anchor="end" fill="\${theme.muted}" font-size="13">\${stars}</text>\`);
+  }
+
+  const dateFormatter = new Intl.DateTimeFormat("en-US", {
+    month: "short",
+    year: "numeric",
+    timeZone: "UTC",
+  });
+  const updatedFormatter = new Intl.DateTimeFormat("en-US", {
+    day: "numeric",
+    month: "short",
+    year: "numeric",
+    timeZone: "UTC",
+  });
+  const xTicks = Array.from({ length: 7 }, (_, index) => {
+    const fraction = index / 6;
+    const timestamp = firstStar + timeRange * fraction;
+    const tickX = margin.left + plotWidth * fraction;
+    return \`
+      <line x1="\${tickX.toFixed(1)}" y1="\${margin.top}" x2="\${tickX.toFixed(1)}" y2="\${plotBottom}" stroke="\${theme.grid}" />
+      <text x="\${tickX.toFixed(1)}" y="\${plotBottom + 30}" text-anchor="middle" fill="\${theme.muted}" font-size="13">\${dateFormatter.format(timestamp)}</text>\`;
+  });
+
+  const escapedRepository = escapeXml(repository);
+  const lastPoint = points.at(-1)!;
+
+  return \`<svg xmlns="http://www.w3.org/2000/svg" width="960" height="520" viewBox="0 0 960 520" role="img" aria-labelledby="title description">
+  <title id="title">Star history for \${escapedRepository}</title>
+  <desc id="description">\${timestamps.length} cumulative GitHub stars from \${updatedFormatter.format(firstStar)} through \${updatedFormatter.format(lastStar)}.</desc>
+  <defs>
+    <linearGradient id="star-area" x1="0" y1="0" x2="0" y2="1">
+      <stop offset="0%" stop-color="\${theme.accent}" stop-opacity="0.24" />
+      <stop offset="100%" stop-color="\${theme.accent}" stop-opacity="0.02" />
+    </linearGradient>
+    <filter id="point-shadow" x="-100%" y="-100%" width="300%" height="300%">
+      <feDropShadow dx="0" dy="1" stdDeviation="2" flood-color="\${theme.accent}" flood-opacity="0.35" />
+    </filter>
+  </defs>
+  <rect x="0.5" y="0.5" width="959" height="519" rx="12" fill="\${theme.background}" stroke="\${theme.border}" />
+  <g font-family="-apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif">
+    <text x="\${margin.left}" y="43" fill="\${theme.text}" font-size="21" font-weight="600">\${escapedRepository}</text>
+    <text x="\${margin.left}" y="69" fill="\${theme.muted}" font-size="13">Cumulative GitHub stars · updated \${updatedFormatter.format(lastStar)}</text>
+    <g transform="translate(\${width - margin.right - 118}, 34)">
+      <text x="0" y="17" fill="\${theme.accent}" font-size="19">★</text>
+      <text x="27" y="17" fill="\${theme.text}" font-size="16" font-weight="600">\${timestamps.length} stars</text>
+    </g>
+    \${yTicks.join("").trim()}
+    \${xTicks.join("").trim()}
+    <path d="\${areaPath}" fill="url(#star-area)" />
+    <path d="\${linePath}" fill="none" stroke="\${theme.accent}" stroke-width="3" stroke-linecap="round" stroke-linejoin="round" />
+    <circle cx="\${lastPoint.x.toFixed(1)}" cy="\${lastPoint.y.toFixed(1)}" r="5" fill="\${theme.background}" stroke="\${theme.accent}" stroke-width="3" filter="url(#point-shadow)" />
+    <text x="20" y="\${margin.top + plotHeight / 2}" transform="rotate(-90 20 \${margin.top + plotHeight / 2})" text-anchor="middle" fill="\${theme.muted}" font-size="13">GitHub stars</text>
+  </g>
+</svg>
+\`;
+}
+
+`;
+
 // src/be/seed-scripts/catalog/swarm-overview.ts
 var swarm_overview_default = `import { z } from "zod";
 
@@ -5196,6 +5426,13 @@ function bundleCatalogReport(source) {
 ${source.replace(CATALOG_REPORT_IMPORT_RE, "")}`;
 }
 var SEED_SCRIPTS = [
+  {
+    name: "star-history-refresh",
+    description: "Refresh stable public light/dark SVG star-history pages from GitHub with ETags and a last-known KV series.",
+    intent: "Run hourly under the same page-owning agent identity; dryRun validates rendering before SVG page support deploys.",
+    source: asText(star_history_renderer_default) + `
+` + asText(star_history_refresh_default).replace('import { renderChart } from "./star-history-renderer";', "")
+  },
   {
     name: "gh-pr-snapshot",
     description: "One-call GitHub pull request snapshot: title, state, draft, mergeable, CI check tallies (passed/failed/pending) and review tallies (approved/changes-requested/pending).",
@@ -6111,7 +6348,7 @@ var config_default8 = `{
 `;
 
 // templates/skills/code-quality/content.md
-var content_default8 = "# Code quality\n\nThis skill covers the moment code leaves your machine: a push, a pull request, a merge, a review.\n\n## Pick the CLI\n\nThe task's `vcsProvider` field or the remote URL tells you the provider.\n\n| Operation | GitHub (`gh`) | GitLab (`glab`) |\n|---|---|---|\n| Clone | `gh repo clone` | `glab repo clone` |\n| Create PR or MR | `gh pr create` | `glab mr create` |\n| View | `gh pr view` | `glab mr view` |\n| CI status | `gh pr checks` | `glab mr view --json pipelines` |\n| Review | `gh pr review` | `glab mr approve`, `glab mr note` |\n| Comment on an issue | `gh issue comment` | `glab issue note` |\n\n## Before you push\n\n1. Run every command in the Repository Guidelines section \"PR Checks\" of your system prompt, one after the other. When no guidelines exist, run the checklist in the repo's CLAUDE.md. When neither exists, ask the lead before you push.\n2. A failing check: fix the cause and run the check again. Push only when every check passes.\n3. Git hooks stay on. `--no-verify` and any other bypass flag are out.\n4. `main` and `master` are never force-pushed.\n5. One logical change per PR. Conventional commit titles when the repo uses them.\n\n## After you open a PR\n\n1. Wait about 30 seconds, then read CI: `gh pr checks <number>` or `glab mr view --json pipelines`.\n2. Red CI: read the failing job, fix, push, read CI again. Repeat until green.\n3. Put the PR URL and the CI status in your task output.\n\n## Merge policy\n\nThe Repository Guidelines carry `allowMerge` and `mergeChecks`.\n\n- `allowMerge` false (the default): review and approve. Do not merge.\n- `allowMerge` true: run every `mergeChecks` entry first, then merge.\n\n## Review a PR\n\n1. CI status first. Failing CI is a REQUEST_CHANGES. Name the failing checks in the review.\n2. Tests second. A code change without new or updated tests is a REQUEST_CHANGES. Name the tests you expect. Exceptions: documentation-only, configuration-only, and dependency-bump PRs.\n3. Apply the \"Review Guidance\" entries from the Repository Guidelines.\n4. Read the diff for security (injection, secrets in code), logic (null handling, off-by-one, edge cases), performance (N+1, leaks), and code shape (naming, duplication, error handling). Run the test suite and the type check locally when you can.\n5. Post the review with the verdict first. One finding per comment, with file and line, and what to change.\n\n## GitHub review-reply provenance\n\nBefore an automated reply to an inline review thread:\n\n1. `gh api user --jq .login` must equal `${GITHUB_BOT_NAME:-agent-swarm-bot}`.\n2. Post through the `GITHUB_TOKEN`-backed `gh api` path.\n3. Append `<!-- agent-swarm:review-ack -->` to the reply body.\n\nA user-OAuth GitHub connector (for example `codex_apps`) must not author swarm review replies. When the login does not match, do not post. Report the mismatch in your task output.\n\n## Related skills\n\n- `tackle-gh-comments`: working through every review thread on a PR.\n- `engineering-standards`: the code-shape bar a reviewer holds the diff to.\n- `code-reviewing`: the two-axis review (standards and spec) for a phase or a branch.\n";
+var content_default8 = "# Code quality\n\nThis skill covers the moment code leaves your machine: a push, a pull request, a merge, a review.\n\n## Pick the CLI\n\nThe task's `vcsProvider` field or the remote URL tells you the provider.\n\n| Operation | GitHub (`gh`) | GitLab (`glab`) |\n|---|---|---|\n| Clone | `gh repo clone` | `glab repo clone` |\n| Create PR or MR | `gh pr create` | `glab mr create` |\n| View | `gh pr view` | `glab mr view` |\n| CI status | `gh pr checks` | `glab mr view --json pipelines` |\n| Review | `gh pr review` | `glab mr approve`, `glab mr note` |\n| Comment on an issue | `gh issue comment` | `glab issue note` |\n\n## Before you push\n\n1. Run every command in the Repository Guidelines section \"PR Checks\" of your system prompt, one after the other. When no guidelines exist, run the checklist in the repo's CLAUDE.md. When neither exists, ask the lead before you push.\n2. A failing check: fix the cause and run the check again. Push only when every check passes.\n3. Git hooks stay on. `--no-verify` and any other bypass flag are out.\n4. `main` and `master` are never force-pushed.\n5. One logical change per PR. Conventional commit titles when the repo uses them.\n\n## After you open a PR\n\n1. Wait about 30 seconds, then read CI: `gh pr checks <number>` or `glab mr view --json pipelines`.\n2. Red CI: read the failing job, fix, push, read CI again. Repeat until green.\n3. Put the PR URL and the CI status in your task output.\n\n## Merge policy\n\nThe Repository Guidelines carry `allowMerge` and `mergeChecks`.\n\n- `allowMerge` false (the default): review and approve. Do not merge.\n- `allowMerge` true: run every `mergeChecks` entry first, then merge.\n\n## Review a PR\n\n1. CI status first, including the fork checks below before treating CI as evidence. Failing CI is a REQUEST_CHANGES. Name the failing checks in the review.\n2. Detect a GitHub fork PR with `gh pr view <number> --json isCrossRepository --jq .isCrossRepository`.\n3. For a GitHub fork PR, inspect held runs with `SHA=$(gh pr view <number> --json headRefOid --jq .headRefOid); gh api --paginate \"repos/<owner>/<repo>/actions/runs?head_sha=$SHA\" --jq '.workflow_runs[] | \"\\(.conclusion // .status)|\\(.name)\"'`; `gh pr checks` and `statusCheckRollup` can omit them.\n4. Treat any `action_required` run or no substantive run executed on that SHA as a CI blocker. Keep run handling read-only: REQUEST_CHANGES naming the held or unexecuted run, and report the blocker so an explicitly authorized maintainer or the application-controlled GitHub integration can approve the run after validating the workflow and its trust boundary. Do not APPROVE on omitted runs.\n5. Tests second. A code change without new or updated tests is a REQUEST_CHANGES. Name the tests you expect. Exceptions: documentation-only, configuration-only, and dependency-bump PRs.\n6. Apply the \"Review Guidance\" entries from the Repository Guidelines.\n7. Read the diff for security (injection, secrets in code), logic (null handling, off-by-one, edge cases), performance (N+1, leaks), and code shape (naming, duplication, error handling). Run the test suite and the type check locally when you can.\n8. Post the review with the verdict first. One finding per comment, with file and line, and what to change.\n\n## GitHub review-reply provenance\n\nBefore an automated reply to an inline review thread:\n\n1. `gh api user --jq .login` must equal `${GITHUB_BOT_NAME:-agent-swarm-bot}`.\n2. Post through the `GITHUB_TOKEN`-backed `gh api` path.\n3. Append `<!-- agent-swarm:review-ack -->` to the reply body.\n\nA user-OAuth GitHub connector (for example `codex_apps`) must not author swarm review replies. When the login does not match, do not post. Report the mismatch in your task output.\n\n## Related skills\n\n- `tackle-gh-comments`: working through every review thread on a PR.\n- `engineering-standards`: the code-shape bar a reviewer holds the diff to.\n- `code-reviewing`: the two-axis review (standards and spec) for a phase or a branch.\n";
 
 // templates/skills/code-reviewing/config.json
 var config_default9 = `{
@@ -6702,7 +6939,7 @@ var config_default17 = `{
 `;
 
 // templates/skills/download-task-attachment/content.md
-var content_default17 = '# Download a Task Attachment\n\nTask attachments (files uploaded via the UI or API onto a task) are served\nthrough a single **provider-agnostic** REST route — regardless of whether the\nbacking storage is `local-fs` or `agent-fs`. You do not need to know or care\nwhich provider is active, and you do not need `agent-fs org`/`agent-fs drive`\ndiscovery.\n\n## The one-call recipe\n\n```bash\ncurl "$MCP_BASE_URL/api/fs/tasks/$AGENT_SWARM_TASK_ID/files/<attachmentId>/raw" \\\n  -H "X-Agent-ID: $AGENT_ID" \\\n  -H "Authorization: Bearer ${AGENT_SWARM_API_KEY:-$API_KEY}" \\\n  -o /tmp/<name>\n```\n\n- `$MCP_BASE_URL`, `$AGENT_ID`, `$AGENT_SWARM_TASK_ID` (or `$AGENT_SWARM_AGENT_ID`/`TASK_FILE`-derived taskId), and `$AGENT_SWARM_API_KEY`/`$API_KEY` are already present in every worker container\'s env — no new plumbing needed.\n- `<attachmentId>` and `<name>`/`mimeType` come from the task\'s attachment list (see below).\n- The route resolves the active file-storage provider (`local-fs` in dev, `agent-fs` in prod) server-side and streams the raw bytes back with the correct `Content-Type` — you get one call no matter which provider is behind it.\n\n## Finding the attachment ID\n\nIf the dispatch prompt already injected an `## Attachments` section with the\ncurl command pre-filled, just run it — that\'s the fast path (see\n`buildAttachmentsSection()` in `src/commands/runner.ts`).\n\nOtherwise, pull it from the task:\n\n```\nget-task-details taskId=<your task id>\n```\n\nThe response includes an `attachments` array: `{id, name, mimeType, sizeBytes}`.\nUse `id` as `<attachmentId>` in the curl above.\n\n## Why not the `agent-fs` CLI directly?\n\n`agent-fs` is a general-purpose CLI for the swarm\'s own agent-fs filesystem —\nit requires you to already know the org/drive a file lives in, and task\nattachments don\'t always carry that (older rows, or attachments stored via\n`local-fs` in dev have no org/drive at all). Reaching for `agent-fs cat` /\n`agent-fs download` on a task attachment means guessing subcommand names,\ndiscovering the right org via `agent-fs org list`, and re-trying — several\ntool calls where one `curl` suffices. This was root-caused from a real\nsession that burned 7 tool calls (~64s) doing exactly that detour before\nsucceeding; see `runbooks/harness-providers.md` and PR that added\n`buildAttachmentsSection()` for the full trace.\n\n## Gotchas\n\n- The route requires `X-Agent-ID` + bearer auth like any other swarm API call — same headers you\'d use for any MCP-adjacent REST call.\n- `mimeType` on the attachment record reflects the real upload `Content-Type` (not a filename-extension guess) — trust it when deciding how to handle the downloaded bytes (image vs PDF vs text).\n- If you get a 404, double-check you\'re using the **attachment ID** (from `attachments[].id`), not the display `name`.\n';
+var content_default17 = '# Download a Task Attachment\n\nTask attachments (files uploaded via the UI or API onto a task) are served\nthrough a single **provider-agnostic** REST route — regardless of whether the\nbacking storage is `local-fs` or `agent-fs`. You do not need to know or care\nwhich provider is active, and you do not need `agent-fs org`/`agent-fs drive`\ndiscovery.\n\n## The one-call recipe\n\n```bash\ncurl "$MCP_BASE_URL/api/fs/tasks/$AGENT_SWARM_TASK_ID/files/<attachmentId>/raw" \\\n  -H "X-Agent-ID: $AGENT_ID" \\\n  -H "Authorization: Bearer ${AGENT_SWARM_API_KEY:-$API_KEY}" \\\n  --create-dirs -o "/tmp/attachments/<attachmentId>/<name>"\n```\n\n- `$MCP_BASE_URL`, `$AGENT_ID`, `$AGENT_SWARM_TASK_ID` (or `$AGENT_SWARM_AGENT_ID`/`TASK_FILE`-derived taskId), and `$AGENT_SWARM_API_KEY`/`$API_KEY` are already present in every worker container\'s env — no new plumbing needed.\n- `<attachmentId>` and `<name>`/`mimeType` come from the task\'s attachment list (see below).\n- One directory per attachment: two attachments can share a name (every pasted screenshot is `image.png`), and `/tmp/<name>` would let one overwrite the other.\n- The route resolves the active file-storage provider (`local-fs` in dev, `agent-fs` in prod) server-side and streams the raw bytes back with the correct `Content-Type` — you get one call no matter which provider is behind it.\n\n## Finding the attachment ID\n\nIf the dispatch prompt already injected an `## Attachments` section with the\ncurl command pre-filled, just run it — that\'s the fast path (see\n`buildAttachmentsSection()` in `src/commands/runner.ts`).\n\nOtherwise, pull it from the task:\n\n```\nget-task-details taskId=<your task id>\n```\n\nThe response includes an `attachments` array: `{id, name, mimeType, sizeBytes}`.\nUse `id` as `<attachmentId>` in the curl above.\n\n## Why not the `agent-fs` CLI directly?\n\n`agent-fs` is a general-purpose CLI for the swarm\'s own agent-fs filesystem —\nit requires you to already know the org/drive a file lives in, and task\nattachments don\'t always carry that (older rows, or attachments stored via\n`local-fs` in dev have no org/drive at all). Reaching for `agent-fs cat` /\n`agent-fs download` on a task attachment means guessing subcommand names,\ndiscovering the right org via `agent-fs org list`, and re-trying — several\ntool calls where one `curl` suffices. This was root-caused from a real\nsession that burned 7 tool calls (~64s) doing exactly that detour before\nsucceeding; see `runbooks/harness-providers.md` and PR that added\n`buildAttachmentsSection()` for the full trace.\n\n## Gotchas\n\n- The route requires `X-Agent-ID` + bearer auth like any other swarm API call — same headers you\'d use for any MCP-adjacent REST call.\n- `mimeType` on the attachment record reflects the real upload `Content-Type` (not a filename-extension guess) — trust it when deciding how to handle the downloaded bytes (image vs PDF vs text).\n- If you get a 404, double-check you\'re using the **attachment ID** (from `attachments[].id`), not the display `name`.\n';
 
 // templates/skills/engineering-standards/config.json
 var config_default18 = `{
@@ -9681,8 +9918,28 @@ File-review is on by default (unless Autopilot):
 - **REMEMBER**: Document what IS, not what SHOULD BE
 `;
 
-// templates/skills/reviewing/config.json
+// templates/skills/review-offered-task/config.json
 var config_default32 = `{
+  "kind": "skill",
+  "name": "review-offered-task",
+  "displayName": "Review Offered Task",
+  "slug": "review-offered-task",
+  "title": "Review Offered Task",
+  "description": "Turn prompt for an offered swarm task: read the offer, accept with task-action and start work-on-task, or reject with a reason.",
+  "version": "1.0.0",
+  "category": "skills",
+  "placeholders": [],
+  "runAllSeedersCandidate": true,
+  "systemDefault": true,
+  "tags": ["tasks", "turn-prompt", "worker"]
+}
+`;
+
+// templates/skills/review-offered-task/content.md
+var content_default32 = '# Review Offered Task\n\nYou have been offered a task. Your job is to review it and decide whether to accept or reject it based on your capabilities and current workload.\n\n## Workflow\n\n1. **Get task details**: Call the `get-task-details` tool with the provided `taskId` to understand what the task involves.\n\n2. **Evaluate the task**: Consider:\n   - Does this task match your capabilities?\n   - Do you have the necessary context or access to complete it?\n   - Is the task description clear enough to proceed?\n\n3. **Make a decision**:\n   - **Accept**: If you can complete this task, call `task-action` with `action: "accept"` and `taskId: "<taskId>"`. Then immediately use the `work-on-task` skill with the taskId to start working on it.\n   - **Reject**: If you cannot complete this task, call `task-action` with `action: "reject"`, `taskId: "<taskId>"`, and provide a `reason` explaining why you\'re rejecting it (e.g., "Task requires Python expertise which I don\'t have", "Task description is too vague").\n\n## Example Accept Flow\n\n```\n1. get-task-details taskId="abc-123"\n2. [Review the task details]\n3. task-action action="accept" taskId="abc-123"\n4. /work-on-task abc-123\n```\n\n## Example Reject Flow\n\n```\n1. get-task-details taskId="abc-123"\n2. [Review the task details]\n3. task-action action="reject" taskId="abc-123" reason="Task requires access to production database which I don\'t have"\n4. Stop\n```\n\n## Important Notes\n\n- Always provide a clear reason when rejecting a task - this helps the lead agent reassign it appropriately\n- If you accept, you must immediately start working on the task using the `work-on-task` skill\n- If you reject, the task returns to the unassigned pool for reassignment\n';
+
+// templates/skills/reviewing/config.json
+var config_default33 = `{
   "category": "skills",
   "description": "Structured critique of research, plan, and brainstorm documents for completeness, gaps, and quality.",
   "displayName": "Reviewing",
@@ -9703,7 +9960,7 @@ var config_default32 = `{
 `;
 
 // templates/skills/reviewing/content.md
-var content_default32 = `# Reviewing
+var content_default33 = `# Reviewing
 
 You are performing a structured critique of a document (research, plan, or brainstorm) to identify gaps, weaknesses, and quality issues. (For reviewing a code diff, use \`desplega:code-reviewing\` instead — this skill reviews documents.)
 
@@ -9955,7 +10212,7 @@ File-review is on by default (unless Autopilot):
 `;
 
 // templates/skills/scheduled-task-resilience/config.json
-var config_default33 = `{
+var config_default34 = `{
   "kind": "skill",
   "name": "scheduled-task-resilience",
   "displayName": "Scheduled Task Resilience",
@@ -9972,7 +10229,7 @@ var config_default33 = `{
 `;
 
 // templates/skills/scheduled-task-resilience/content.md
-var content_default33 = `# Scheduled Task Resilience
+var content_default34 = `# Scheduled Task Resilience
 
 Use these rules whenever a scheduled or regular task polls or waits on a long-running operation. They prevent heartbeat collisions, lost work, duplicate delivery, and sessions that fail after holding an external job open too long.
 
@@ -10072,7 +10329,7 @@ When historical incident detail is useful, search the deployment's memory regist
 `;
 
 // templates/skills/scheduling/config.json
-var config_default34 = `{
+var config_default35 = `{
   "kind": "skill",
   "name": "scheduling",
   "displayName": "Scheduling",
@@ -10089,10 +10346,10 @@ var config_default34 = `{
 `;
 
 // templates/skills/scheduling/content.md
-var content_default34 = '# Scheduling\n\nUse a schedule when work repeats on a clock, or when it must run once at a later time. On each tick the schedule creates one run. The run is a workflow, a catalog script, or an agent task.\n\n## Tools\n\n`list-schedules`, `create-schedule`, `update-schedule`, `patch-schedule`, `delete-schedule`, `run-schedule-now`. They are deferred. Load them with your harness tool search before the first call.\n\n## Pick the target type\n\n| The tick should | `targetType` | Required fields |\n|---|---|---|\n| Start a workflow | `workflow` | `workflowId` |\n| Run a catalog script | `script` | `scriptName`, optional `scriptArgs` |\n| Put a reasoning agent in the loop | `agent-task` (default) | `taskTemplate` |\n\nChoose `agent-task` only when the run needs judgment, open-ended work, or tool orchestration that no workflow or script covers. An `agent-task` whose template says "trigger workflow X" or "run script Y" is wrong: use the direct target instead.\n\nThe agent-task fields `targetAgentId`, `model`, `modelTier`, `taskTemplate`, `priority`, and `tags` do not apply to workflow or script targets. Workflow cooldowns still gate workflow targets.\n\n## Pick the timing\n\n| Shape | Fields |\n|---|---|\n| Recurring on a cron | `scheduleType: "recurring"`, `cronExpression` (for example `0 9 * * 1-5`), `timezone` (default `UTC`) |\n| Recurring on an interval | `scheduleType: "recurring"`, `intervalMs` (for example `3600000` for hourly) |\n| Once, at a time | `scheduleType: "one_time"`, `runAt` (ISO datetime) |\n| Once, after a delay | `scheduleType: "one_time"`, `delayMs` |\n\nGive the schedule a unique `name` and a one-line `description` that says what a human gets from it.\n\n## Write the task template (agent-task target)\n\nThe template is the whole task the agent receives. It must state:\n\n- the goal and the inputs (IDs, repo, channel),\n- where the result goes (a page, agent-fs, a Slack thread, a task output),\n- what done looks like.\n\n`targetAgentId` pins the task to one agent. Omit it to use the pool. `modelTier` (`smol`, `regular`, `smart`, `ultra`) is the portable way to pick a model. `model` is a provider-specific override.\n\nTasks created by a schedule are automatic tasks. Their completed output is not stored as memory unless the agent calls `store-progress` with `persistMemory: true`.\n\n## Secrets\n\nA `taskTemplate` and `scriptArgs` are stored as plain text and replayed on every run. They must not contain a token, password, or key. Call the external API from a script through a registered connection or a credential binding instead. See the `swarm-scripts` skill, section Secrets.\n\n## Verify before you leave\n\n1. `run-schedule-now` once and read the run result.\n2. `list-schedules` with `name` to confirm `nextRunAt` and `enabled`.\n3. For a script target, the script must exist at global scope: `script-search` by name.\n\n## Repair a failing schedule\n\n`list-schedules` with `lastRunStatus: "failed"` or `consecutiveErrorsMin: 3` lists the failing ones. Fix the cause, then `run-schedule-now` to confirm. A schedule you cannot fix now: `patch-schedule` with `enabled: false` and say so in your task output. A second schedule next to a broken one is not a fix.\n\n## Related skills\n\n- `scheduled-task-resilience`: waiting on CI, builds, deploys, or other slow jobs inside a scheduled task.\n- `swarm-scripts`: writing the script a `script` target runs.\n- `workflow-iterate`: building and testing the workflow a `workflow` target starts.\n';
+var content_default35 = '# Scheduling\n\nUse a schedule when work repeats on a clock, or when it must run once at a later time. On each tick the schedule creates one run. The run is a workflow, a catalog script, or an agent task.\n\n## Tools\n\n`list-schedules`, `create-schedule`, `update-schedule`, `patch-schedule`, `delete-schedule`, `run-schedule-now`. They are deferred. Load them with your harness tool search before the first call.\n\n## Pick the target type\n\n| The tick should | `targetType` | Required fields |\n|---|---|---|\n| Start a workflow | `workflow` | `workflowId` |\n| Run a catalog script | `script` | `scriptName`, optional `scriptArgs` |\n| Put a reasoning agent in the loop | `agent-task` (default) | `taskTemplate` |\n\nChoose `agent-task` only when the run needs judgment, open-ended work, or tool orchestration that no workflow or script covers. An `agent-task` whose template says "trigger workflow X" or "run script Y" is wrong: use the direct target instead.\n\nThe agent-task fields `targetAgentId`, `model`, `modelTier`, `taskTemplate`, `priority`, and `tags` do not apply to workflow or script targets. Workflow cooldowns still gate workflow targets.\n\n## Pick the timing\n\n| Shape | Fields |\n|---|---|\n| Recurring on a cron | `scheduleType: "recurring"`, `cronExpression` (for example `0 9 * * 1-5`), `timezone` (default `UTC`) |\n| Recurring on an interval | `scheduleType: "recurring"`, `intervalMs` (for example `3600000` for hourly) |\n| Once, at a time | `scheduleType: "one_time"`, `runAt` (ISO datetime) |\n| Once, after a delay | `scheduleType: "one_time"`, `delayMs` |\n\nGive the schedule a unique `name` and a one-line `description` that says what a human gets from it.\n\n## Write the task template (agent-task target)\n\nThe template is the whole task the agent receives. It must state:\n\n- the goal and the inputs (IDs, repo, channel),\n- where the result goes (a page, agent-fs, a Slack thread, a task output),\n- what done looks like.\n\n`targetAgentId` pins the task to one agent. Omit it to use the pool. `modelTier` (`smol`, `regular`, `smart`, `ultra`) is the portable way to pick a model. `model` is a provider-specific override.\n\nTasks created by a schedule are automatic tasks. Their completed output is not stored as memory unless the agent calls `store-progress` with `persistMemory: true`.\n\n## Check back later\n\nA task whose answer needs time (a build, a deploy, a reply) calls `defer-task` with `delayMs` or `runAt`, a `summary` of what you did so far, and a `note` that says what is pending. The tool completes the task and creates the one-off schedule for you. The task reaches its final state (`completed`) on this call, and the `summary` becomes its output. The wake-up task carries the deferred task as its parent, so you receive that task\'s context. Add `checks` to list what to verify on wake-up. Do not hand-roll this with `create-schedule`.\n\n## Secrets\n\nA `taskTemplate` and `scriptArgs` are stored as plain text and replayed on every run. They must not contain a token, password, or key. Call the external API from a script through a registered connection or a credential binding instead. See the `swarm-scripts` skill, section Secrets.\n\n## Verify before you leave\n\n1. `run-schedule-now` once and read the run result.\n2. `list-schedules` with `name` to confirm `nextRunAt` and `enabled`.\n3. For a script target, the script must exist at global scope: `script-search` by name.\n\n## Repair a failing schedule\n\n`list-schedules` with `lastRunStatus: "failed"` or `consecutiveErrorsMin: 3` lists the failing ones. Fix the cause, then `run-schedule-now` to confirm. A schedule you cannot fix now: `patch-schedule` with `enabled: false` and say so in your task output. A second schedule next to a broken one is not a fix.\n\n## Related skills\n\n- `scheduled-task-resilience`: waiting on CI, builds, deploys, or other slow jobs inside a scheduled task.\n- `swarm-scripts`: writing the script a `script` target runs.\n- `workflow-iterate`: building and testing the workflow a `workflow` target starts.\n';
 
 // templates/skills/script-builder/config.json
-var config_default35 = `{
+var config_default36 = `{
   "category": "skills",
   "description": "Generate durable, re-runnable scripts from session intent — validation scripts (PASS/FAIL contract) AND gather/bulk scripts (many API/tool calls in code, one derived summary out). Supports TypeScript, Python, Bash with auto-detection, enforces context-optimal output, and auto-documents scripts in CLAUDE.md. Triggers on \\"turn this into a script\\", \\"I want to test/validate X end-to-end\\", \\"wrap this in a re-runnable script\\" — and, critically, whenever you are about to make (or just made) ~10+ similar tool/API calls or any bulk fan-out over a list: that mechanical middle belongs in a script, not in context.",
   "displayName": "Script Builder",
@@ -10113,10 +10370,10 @@ var config_default35 = `{
 `;
 
 // templates/skills/script-builder/content.md
-var content_default35 = "# script-builder\n\nYou are converting session intent into a durable, re-runnable script committed to the target project's `scripts/` directory. Two script classes share one principle — **only the derived answer re-enters context; raw payloads never do**:\n\n- **Validation scripts** (`check-*`, `e2e-*`, `smoke-*`, …): a single PASS/FAIL line + `/tmp` log path on success, full verbose output redirected to a timestamped log file.\n- **Gather/bulk scripts** (`gather-*`, `bulk-*`): replace N similar tool/API calls with one script that loops, filters, and aggregates *in code* — stdout is one compact summary block (JSON or table), raw responses go to the `/tmp` log. Rubric (from production code-mode data): past ~10 items or any fan-out over a list, a script beats individual tool calls by ~100x on context and roughly halves end-to-end cost. Offer the script *before* the fan-out happens when you can see it coming, not just retrospectively.\n\nBoth classes get an `<important if>` block in `CLAUDE.md`/`AGENTS.md` so future agents discover the script when the intent recurs — durable scripts are reusable agent memory: import, don't re-derive.\n\n**Schema discovery happens in code, too**: when scripting against an unfamiliar API, grep/filter its OpenAPI spec or typed client programmatically to find the few relevant endpoints — never paste the full schema into context.\n\n## Working Agreement\n\nThese instructions establish a working agreement between you and the user. The key principles are:\n\n1. **AskUserQuestion is your primary communication tool** - Whenever you need to ask the user anything (clarifications, preferences, decisions, confirmations), use the **AskUserQuestion tool**. Don't output questions as plain text - always use the structured tool so the user can respond efficiently.\n\n2. **Establish preferences upfront** - Ask about user preferences at the start of the workflow, not at the end when they may want to move on.\n\n3. **Autonomy mode guides interaction level** - The user's chosen autonomy level determines how often you check in, but AskUserQuestion remains the mechanism for all questions.\n\n## When to Use\n\nThis skill activates when:\n- User invokes `/script-builder` command\n- Another skill references `**OPTIONAL SUB-SKILL:** desplega:script-builder`\n- A `planning`, `qa`, or `verifying` flow needs a re-runnable validation script that doesn't yet exist\n- The user expresses intent to \"turn X into a script\", \"wrap this validation into something reusable\", or \"I want to test X end-to-end\" with no existing script\n\n## Autonomy Mode\n\nAdapt your behavior based on the autonomy mode:\n\n| Mode | Behavior |\n|------|----------|\n| **Autopilot** | Detect mode, draft, syntax-check, document, and (if escalation tier) run + iterate without intermediate confirmations. Pause only at hard blockers or destructive side-effects. |\n| **Critical** (Default) | Confirm at each tier boundary (after draft, before doc edit, before run). Use AskUserQuestion for fix application during iterate loop. |\n| **Verbose** | Confirm before each step. Show every diff. Walk through detection reasoning out loud. |\n\nThe autonomy mode is passed by the invoking command. If not specified, default to **Critical**.\n\n## Process Steps\n\n### Step 1: Detect Mode (Retrospective vs Forward-Declared)\n\nDecide silently — **do not** ask the user \"which mode?\". Use the following heuristics:\n\n1. **Scan recent session tool-use history** (the last ~20 tool calls in the current conversation) for test/validation-shaped activity: `curl`/`fetch` calls, `bun run`/`python`/`pytest`, database queries, `agent-browser` actions, repeated `grep`/log inspection of a single endpoint or table. If ≥2 such actions targeting the same area exist → **retrospective mode**. Separately, if the history (or the task ahead) shows the *same call shape repeated ~10+ times or a fan-out over a list* → **gather-script mode**: propose replacing the repetition with one `gather-*` script before continuing.\n2. **Parse the user's invocation message** for cues:\n   - Narrative cues → retrospective: *\"we just figured out\"*, *\"turn this into a script\"*, *\"wrap that in\"*, *\"that thing we just did\"*.\n   - Intent cues → forward-declared: *\"I want to test\"*, *\"validate that\"*, *\"smoke check\"*, *\"check before deploy\"*.\n3. **Fallback**: when ambiguous, default to **forward-declared**.\n\n**Retrospective first action**: summarize the observed activity back to the user as plain text (≤6 lines: what was probed, against what, with what success signal), then go to Step 3 with a confirmation prompt instead of Q&A.\n\n**Forward first action**: skip directly to Step 3's Q&A.\n\n### Step 2: Scan Existing Scripts for Overlap\n\n**Resolve the scripts directory** in this order:\n1. Check `CLAUDE.md` for a `<!-- script-builder:dir=<path> -->` marker. If present, use that path.\n2. If `scripts/` exists at the repo root, use it.\n3. Use **AskUserQuestion** with options: `scripts/ (Recommended) | custom path | skip dir persistence for this run`.\n\n**Edge case — directory absent**: if the resolved path doesn't exist, skip the dedup scan, print a one-line note (`No existing scripts directory at <path> — proceeding to intent gathering`), and remember to optionally offer to create the directory before Step 5.\n\n**When the directory exists**:\n1. List files in the scripts directory (top-level only for v1).\n2. For each file, read the top of the file (header comment) and capture the file-name tokens.\n3. Read `CLAUDE.md`/`AGENTS.md` for `<important if=\"...\">` blocks that point at scripts in this directory and capture the trigger phrases.\n4. Fuzzy-match the current intent string against (file-name tokens ∪ header keywords ∪ trigger phrases). A \"plausible match\" is shared keyword + same area noun (e.g., `auth`, `health`, `webhook`).\n5. If ≥1 plausible match → use **AskUserQuestion** with options: `Reuse <name> as-is | Extend <name> | Generate new anyway`.\n\nNever silently skip dedup on borderline matches — surface and let the user decide. The **Extend** branch appends a sub-command/flag to the existing script (do not create a new file); document the new flag in the script's header comment and the existing `<important if>` block.\n\n### Step 3: Gather Intent\n\nBoth modes converge on the same internal intent structure: `{ what, success_signal, failure_signal, inputs, env, side_effects }`.\n\n**Forward mode** — use **AskUserQuestion** (one or two questions, not five):\n\n| Question | Options |\n|----------|---------|\n| \"What are we validating, and what's the success signal?\" | [Free text — collect what + success signal in one answer] |\n| \"Any required env vars, inputs, or side-effects to flag (e.g., writes to prod, costs money)?\" | [Free text — optional; skip if forward intent already specified them] |\n\n**Retrospective mode** — present the summary from Step 1 and use **AskUserQuestion** with: `That's the flow | Close but fix X | Start over`. On *Close but fix X*, ask for the correction inline; on *Start over*, fall through to forward-mode Q&A.\n\nPersist the resolved intent in working memory (do not write to disk yet).\n\n### Step 4: Detect Language\n\nPriority order — first match wins, with override paths:\n\n1. **TypeScript** — `package.json` + `tsconfig.json` exist.\n   - **Bun** if `bun.lock` or `bunfig.toml` is present.\n   - else **tsx** if `tsx` appears in `package.json` devDependencies.\n   - else **compiled Node** (note in script header: requires `tsc` build).\n2. **Python** — `pyproject.toml` or `uv.lock` or `requirements.txt` exists.\n   - **uv** if `uv.lock` exists or `pyproject.toml` has `[tool.uv]` configured (sets `{{UV_METADATA}}`).\n   - else **vanilla python3** (`{{UV_METADATA}}` substituted with empty string).\n3. **Both TS and Python detected** — count source files in `src/`/top-level and ask **AskUserQuestion** tiebreaker with the dominant one Recommended.\n4. `Cargo.toml` / `go.mod` only → fall back to **bash** (note: TS/Python/Bash only in v1).\n5. Nothing matched → **bash**.\n\n**Task-driven override**: if the gathered intent is clearly shell-y (\"verify three docker containers respond\", \"tail this log file for an error\"), propose **bash** even in a TS/Python project.\n\nConfirm via **AskUserQuestion** with the detected language as the first option (Recommended). Skip in Autopilot.\n\n### Step 5: Draft the Script\n\n1. **Pick the template**: `templates/{typescript.ts.tmpl|python.py.tmpl|bash.sh.tmpl}`.\n2. **Resolve substitution markers** from gathered intent:\n   - `{{SCRIPT_NAME}}` ← proposed file-name stem (see naming table).\n   - `{{WHAT}}` / `{{WHEN}}` / `{{ENV}}` / `{{EXAMPLE}}` ← intent fields.\n   - `{{UV_METADATA}}` ← per Step 4.\n3. **Generate `{{TEST_BODY}}`** from the intent. Keep it minimal: a single concrete probe + assertion, not a battery. Re-read the templates' README (`templates/README.md`) for the contract — the body must respect the PASS/FAIL surface. Throw/raise/`exit 1` on failure; let the template's outer try/trap convert it into the FAIL line.\n   **Gather-class bodies** adapt the same template: the loop/aggregation replaces the probe, raw per-item responses go to the log only, and the final `console.log`/`print` emits one compact summary (JSON or aligned table) instead of the PASS line — exit non-zero only on operational failure (auth, network), not on \"found problems\" (problems ARE the output).\n4. **Propose a file name** matching the intent shape — see the prefix table below. Use **AskUserQuestion** with the proposed name first (Recommended) and `custom name` as the alternative.\n\n**Naming conventions** (advisory — skill proposes, user overrides):\n\n| Prefix | When | Example |\n|--------|------|---------|\n| `e2e-*` | End-to-end flows across multiple components | `e2e-auth-flow.ts` |\n| `check-*` | Idempotent single-probe verifications | `check-db-boundary.sh` |\n| `smoke-*` | Minimal-viability post-deploy checks | `smoke-prod-api.ts` |\n| `measure-*` | Performance / size / token measurements | `measure-tool-tokens.ts` |\n| `seed-*` / `generate-*` | Data seeding or artifact generation (rare for validation) | `seed-api-keys.sh` |\n| `gather-*` / `bulk-*` | Bulk data-gathering or bulk mutation replacing N tool calls; stdout = one summary block, not PASS/FAIL | `gather-workflow-health.ts` |\n\nIf the intent doesn't match any prefix cleanly, propose a free-form name like `validate-<area>.<ext>`.\n\n5. **Write the file** to the resolved scripts directory. Make it executable (`chmod +x`).\n\n### Step 6: Syntax/Type-Check\n\nRun the appropriate checker:\n\n| Language | Checker (in priority order) |\n|----------|-----------------------------|\n| TypeScript | `bunx tsc --noEmit <file>` if Bun present, else `npx tsc --noEmit <file>` |\n| Python | `python3 -m py_compile <file>` (always) + `ruff check <file>` if `ruff` is on PATH |\n| Bash | `shellcheck <file>` if available, else `bash -n <file>` |\n\n**On success**: log a single line (`syntax check OK`) and proceed to Step 7.\n\n**On failure**:\n1. Print the error (≤10 lines, not the full output).\n2. Propose a concrete one-edit fix (the exact `Edit` you'd apply).\n3. Use **AskUserQuestion** with `Apply fix | Investigate | Stop`.\n   - **Apply fix** → edit the script and re-run the checker (loop, no hardcoded cap).\n   - **Investigate** → drop into discussion with the user; do not auto-apply anything.\n   - **Stop** → leave script in place at its path; print the path; do not delete.\n\n### Step 7: Document the Script\n\nAuto-edit the target project's `CLAUDE.md` and/or `AGENTS.md` so future agents discover this script when the matching intent recurs.\n\n**Block template** (the literal markdown the skill emits):\n\n```markdown\n<important if=\"[TRIGGER: e.g., you are testing the auth flow]\">\n\n## [Area] validation\n\nRun `scripts/<name>` to [one-liner]. Requires [env/deps]. Example: `<cmd>`. Full log at `/tmp/<name>-*.log`.\n\nGenerated/maintained via `/script-builder`.\n\n</important>\n```\n\n**Behavior**:\n\n1. **Target file selection**: edit `CLAUDE.md` and `AGENTS.md` if both exist; edit only what exists. **Never** create either file from scratch — if neither exists, print a one-line note (`No CLAUDE.md or AGENTS.md found — script generated but not documented`) and skip this step.\n2. **Placement heuristic**: search the file for the first heading matching `Test|Testing|Validation|Scripts` (case-insensitive). If found, append the new block within/after that section. Otherwise, append a new `## Scripts for testing & validation` section near the end of the file but **before** any heading matching `License|Acknowledg|Maintain|Contributors`.\n3. **Idempotency**: if a block referencing `scripts/<name>` already exists (i.e., a prior `/script-builder` run for the same script name), update it in place — replace the entire `<important if=...>...</important>` block, do not append a duplicate.\n4. **Scripts-dir marker**: if Step 2 resolved the scripts directory by user choice (not from an existing marker), insert `<!-- script-builder:dir=<path> -->` near the top of `CLAUDE.md` (after the title) so subsequent runs are silent. Skip if the marker already exists.\n5. **Scale gate — `scripts/index.md`**: if the scripts directory holds **>10 documented scripts**, per-script `<important if>` blocks become their own context bloat. Generate/maintain a `scripts/index.md` hub instead (one line + link per script, mirroring the `runbooks/` convention from `desplega:engineering-standards`), collapse the CLAUDE.md/AGENTS.md blocks into ONE pointer block referencing the hub, and add new scripts to the hub only.\n6. **Show the diff**: run the equivalent of `git diff CLAUDE.md AGENTS.md` and print a 5-line summary of what changed. **Never auto-stage** — the user commits.\n\n### Step 8: Offer Escalation\n\nAfter the doc edit, decide whether to proceed to the run-and-iterate tier.\n\n| Autonomy | Behavior |\n|----------|----------|\n| **Autopilot** | Auto-escalate to Step 9 unless the intent flagged side-effects (writes to prod, sends real money, mutates a shared resource). On flagged side-effects, fall through to Critical behavior. |\n| **Critical** (Default) | Use **AskUserQuestion**: `Run it now to confirm it works | I'll run it myself later | Just generate, don't run`. |\n| **Verbose** | Same as Critical, plus offer the proposed run command for review before executing. |\n\nIf the user picks \"I'll run it myself later\" or \"Just generate, don't run\" → skip directly to Step 10.\n\n### Step 9: Iterate on Failures (Escalated Tier Only)\n\nA bounded-by-the-human loop. **Never auto-apply a fix** outside Autopilot.\n\n1. **Run the script** with the proposed example invocation (no `--verbose`, no `--json`). Capture exit code and `tail -n 40` of the `/tmp` log.\n2. **If exit code 0** → report PASS (echo the script's PASS line) and proceed to Step 10.\n3. **If exit code non-zero**:\n   - Summarize the failure in **1–3 lines**: error class (timeout / 4xx / 5xx / assertion / dependency-missing / etc.) + likely cause (grep the log for known signatures: `ECONNREFUSED`, `Traceback`, `non-zero exit`, `command not found`, etc.).\n   - **Propose a concrete diff** — the exact `Edit` you would apply to the script. Show old → new.\n   - Use **AskUserQuestion**: `Apply fix | Investigate differently | Stop`.\n     - **Apply fix** → edit the script, log the change, loop back to (1).\n     - **Investigate differently** → drop into discussion; do not auto-apply.\n     - **Stop** → leave the script in place, print its path; do not revert.\n\n**No hardcoded retry cap** — the human is the implicit bound.\n\n**Side-effect flag**: if the intent declared side-effects (Step 3) and Autopilot is active, surface a one-line `WARNING: this script <does X> against <target>` before the first run and require explicit confirmation via **AskUserQuestion** even in Autopilot mode.\n\n### Step 10: Handoff\n\nHow the skill exits depends on how it was invoked:\n\n**Invoked as a sub-skill** (from `planning`, `qa`, `verifying`):\nReturn control to the parent skill with a structured summary: `{ script_path, status: \"pass\"|\"fail\"|\"unrun\", log_path?, doc_files_edited: [...] }`.\n\n**Invoked directly** (`/script-builder`):\nUse **AskUserQuestion**: `Run it with /qa | Run /verify-plan | Commit the script and doc changes | Done`.\n- **Run with /qa** → invoke `desplega:qa` with the script path as the source.\n- **Run /verify-plan** → invoke `desplega:verifying` if a plan path is in current context.\n- **Commit** → propose a commit message (`feat(scripts): add scripts/<name> for <area> validation`) and stage only the generated script + the CLAUDE.md/AGENTS.md edits. Do not auto-commit; show the proposed `git add` and `git commit` commands and require user confirmation.\n- **Done** → print the script path + log path (if escalation ran) and exit.\n\n**Abort path** (Stop selected at any earlier gate): leave the generated script in place, leave any CLAUDE.md/AGENTS.md edit in place if Step 7 ran, and print a one-liner: `Aborted. Script: <path>. Doc edits: <files or \"none\">. Re-run /script-builder or git checkout to discard.` Do not `git restore` on the user's behalf.\n\n## Learning Capture\n\n**OPTIONAL SUB-SKILL:** If significant insights, patterns, gotchas, or decisions emerged during this workflow, consider using `desplega:learning` to capture them via `/learning capture`. Focus on learnings that would help someone else in a future session.\n";
+var content_default36 = "# script-builder\n\nYou are converting session intent into a durable, re-runnable script committed to the target project's `scripts/` directory. Two script classes share one principle — **only the derived answer re-enters context; raw payloads never do**:\n\n- **Validation scripts** (`check-*`, `e2e-*`, `smoke-*`, …): a single PASS/FAIL line + `/tmp` log path on success, full verbose output redirected to a timestamped log file.\n- **Gather/bulk scripts** (`gather-*`, `bulk-*`): replace N similar tool/API calls with one script that loops, filters, and aggregates *in code* — stdout is one compact summary block (JSON or table), raw responses go to the `/tmp` log. Rubric (from production code-mode data): past ~10 items or any fan-out over a list, a script beats individual tool calls by ~100x on context and roughly halves end-to-end cost. Offer the script *before* the fan-out happens when you can see it coming, not just retrospectively.\n\nBoth classes get an `<important if>` block in `CLAUDE.md`/`AGENTS.md` so future agents discover the script when the intent recurs — durable scripts are reusable agent memory: import, don't re-derive.\n\n**Schema discovery happens in code, too**: when scripting against an unfamiliar API, grep/filter its OpenAPI spec or typed client programmatically to find the few relevant endpoints — never paste the full schema into context.\n\n## Working Agreement\n\nThese instructions establish a working agreement between you and the user. The key principles are:\n\n1. **AskUserQuestion is your primary communication tool** - Whenever you need to ask the user anything (clarifications, preferences, decisions, confirmations), use the **AskUserQuestion tool**. Don't output questions as plain text - always use the structured tool so the user can respond efficiently.\n\n2. **Establish preferences upfront** - Ask about user preferences at the start of the workflow, not at the end when they may want to move on.\n\n3. **Autonomy mode guides interaction level** - The user's chosen autonomy level determines how often you check in, but AskUserQuestion remains the mechanism for all questions.\n\n## When to Use\n\nThis skill activates when:\n- User invokes `/script-builder` command\n- Another skill references `**OPTIONAL SUB-SKILL:** desplega:script-builder`\n- A `planning`, `qa`, or `verifying` flow needs a re-runnable validation script that doesn't yet exist\n- The user expresses intent to \"turn X into a script\", \"wrap this validation into something reusable\", or \"I want to test X end-to-end\" with no existing script\n\n## Autonomy Mode\n\nAdapt your behavior based on the autonomy mode:\n\n| Mode | Behavior |\n|------|----------|\n| **Autopilot** | Detect mode, draft, syntax-check, document, and (if escalation tier) run + iterate without intermediate confirmations. Pause only at hard blockers or destructive side-effects. |\n| **Critical** (Default) | Confirm at each tier boundary (after draft, before doc edit, before run). Use AskUserQuestion for fix application during iterate loop. |\n| **Verbose** | Confirm before each step. Show every diff. Walk through detection reasoning out loud. |\n\nThe autonomy mode is passed by the invoking command. If not specified, default to **Critical**.\n\n## Process Steps\n\n### Step 1: Detect Mode (Retrospective vs Forward-Declared)\n\nDecide silently — **do not** ask the user \"which mode?\". Use the following heuristics:\n\n1. **Scan recent session tool-use history** (the last ~20 tool calls in the current conversation) for test/validation-shaped activity: `curl`/`fetch` calls, `bun run`/`python`/`pytest`, database queries, `agent-browser` actions, repeated `grep`/log inspection of a single endpoint or table. If ≥2 such actions targeting the same area exist → **retrospective mode**. Separately, if the history (or the task ahead) shows the *same call shape repeated ~10+ times or a fan-out over a list* → **gather-script mode**: propose replacing the repetition with one `gather-*` script before continuing.\n2. **Parse the user's invocation message** for cues:\n   - Narrative cues → retrospective: *\"we just figured out\"*, *\"turn this into a script\"*, *\"wrap that in\"*, *\"that thing we just did\"*.\n   - Intent cues → forward-declared: *\"I want to test\"*, *\"validate that\"*, *\"smoke check\"*, *\"check before deploy\"*.\n3. **Fallback**: when ambiguous, default to **forward-declared**.\n\n**Retrospective first action**: summarize the observed activity back to the user as plain text (≤6 lines: what was probed, against what, with what success signal), then go to Step 3 with a confirmation prompt instead of Q&A.\n\n**Forward first action**: skip directly to Step 3's Q&A.\n\n### Step 2: Scan Existing Scripts for Overlap\n\n**Resolve the scripts directory** in this order:\n1. Check `CLAUDE.md` for a `<!-- script-builder:dir=<path> -->` marker. If present, use that path.\n2. If `scripts/` exists at the repo root, use it.\n3. Use **AskUserQuestion** with options: `scripts/ (Recommended) | custom path | skip dir persistence for this run`.\n\n**Edge case — directory absent**: if the resolved path doesn't exist, skip the dedup scan, print a one-line note (`No existing scripts directory at <path> — proceeding to intent gathering`), and remember to optionally offer to create the directory before Step 5.\n\n**When the directory exists**:\n1. List files in the scripts directory (top-level only for v1).\n2. For each file, read the top of the file (header comment) and capture the file-name tokens.\n3. Read `CLAUDE.md`/`AGENTS.md` for `<important if=\"...\">` blocks that point at scripts in this directory and capture the trigger phrases.\n4. Fuzzy-match the current intent string against (file-name tokens ∪ header keywords ∪ trigger phrases). A \"plausible match\" is shared keyword + same area noun (e.g., `auth`, `health`, `webhook`).\n5. If ≥1 plausible match → use **AskUserQuestion** with options: `Reuse <name> as-is | Extend <name> | Generate new anyway`.\n\nNever silently skip dedup on borderline matches — surface and let the user decide. The **Extend** branch appends a sub-command/flag to the existing script (do not create a new file); document the new flag in the script's header comment and the existing `<important if>` block.\n\n### Step 3: Gather Intent\n\nBoth modes converge on the same internal intent structure: `{ what, success_signal, failure_signal, inputs, env, side_effects }`.\n\n**Forward mode** — use **AskUserQuestion** (one or two questions, not five):\n\n| Question | Options |\n|----------|---------|\n| \"What are we validating, and what's the success signal?\" | [Free text — collect what + success signal in one answer] |\n| \"Any required env vars, inputs, or side-effects to flag (e.g., writes to prod, costs money)?\" | [Free text — optional; skip if forward intent already specified them] |\n\n**Retrospective mode** — present the summary from Step 1 and use **AskUserQuestion** with: `That's the flow | Close but fix X | Start over`. On *Close but fix X*, ask for the correction inline; on *Start over*, fall through to forward-mode Q&A.\n\nPersist the resolved intent in working memory (do not write to disk yet).\n\n### Step 4: Detect Language\n\nPriority order — first match wins, with override paths:\n\n1. **TypeScript** — `package.json` + `tsconfig.json` exist.\n   - **Bun** if `bun.lock` or `bunfig.toml` is present.\n   - else **tsx** if `tsx` appears in `package.json` devDependencies.\n   - else **compiled Node** (note in script header: requires `tsc` build).\n2. **Python** — `pyproject.toml` or `uv.lock` or `requirements.txt` exists.\n   - **uv** if `uv.lock` exists or `pyproject.toml` has `[tool.uv]` configured (sets `{{UV_METADATA}}`).\n   - else **vanilla python3** (`{{UV_METADATA}}` substituted with empty string).\n3. **Both TS and Python detected** — count source files in `src/`/top-level and ask **AskUserQuestion** tiebreaker with the dominant one Recommended.\n4. `Cargo.toml` / `go.mod` only → fall back to **bash** (note: TS/Python/Bash only in v1).\n5. Nothing matched → **bash**.\n\n**Task-driven override**: if the gathered intent is clearly shell-y (\"verify three docker containers respond\", \"tail this log file for an error\"), propose **bash** even in a TS/Python project.\n\nConfirm via **AskUserQuestion** with the detected language as the first option (Recommended). Skip in Autopilot.\n\n### Step 5: Draft the Script\n\n1. **Pick the template**: `templates/{typescript.ts.tmpl|python.py.tmpl|bash.sh.tmpl}`.\n2. **Resolve substitution markers** from gathered intent:\n   - `{{SCRIPT_NAME}}` ← proposed file-name stem (see naming table).\n   - `{{WHAT}}` / `{{WHEN}}` / `{{ENV}}` / `{{EXAMPLE}}` ← intent fields.\n   - `{{UV_METADATA}}` ← per Step 4.\n3. **Generate `{{TEST_BODY}}`** from the intent. Keep it minimal: a single concrete probe + assertion, not a battery. Re-read the templates' README (`templates/README.md`) for the contract — the body must respect the PASS/FAIL surface. Throw/raise/`exit 1` on failure; let the template's outer try/trap convert it into the FAIL line.\n   **Gather-class bodies** adapt the same template: the loop/aggregation replaces the probe, raw per-item responses go to the log only, and the final `console.log`/`print` emits one compact summary (JSON or aligned table) instead of the PASS line — exit non-zero only on operational failure (auth, network), not on \"found problems\" (problems ARE the output).\n4. **Propose a file name** matching the intent shape — see the prefix table below. Use **AskUserQuestion** with the proposed name first (Recommended) and `custom name` as the alternative.\n\n**Naming conventions** (advisory — skill proposes, user overrides):\n\n| Prefix | When | Example |\n|--------|------|---------|\n| `e2e-*` | End-to-end flows across multiple components | `e2e-auth-flow.ts` |\n| `check-*` | Idempotent single-probe verifications | `check-db-boundary.sh` |\n| `smoke-*` | Minimal-viability post-deploy checks | `smoke-prod-api.ts` |\n| `measure-*` | Performance / size / token measurements | `measure-tool-tokens.ts` |\n| `seed-*` / `generate-*` | Data seeding or artifact generation (rare for validation) | `seed-api-keys.sh` |\n| `gather-*` / `bulk-*` | Bulk data-gathering or bulk mutation replacing N tool calls; stdout = one summary block, not PASS/FAIL | `gather-workflow-health.ts` |\n\nIf the intent doesn't match any prefix cleanly, propose a free-form name like `validate-<area>.<ext>`.\n\n5. **Write the file** to the resolved scripts directory. Make it executable (`chmod +x`).\n\n### Step 6: Syntax/Type-Check\n\nRun the appropriate checker:\n\n| Language | Checker (in priority order) |\n|----------|-----------------------------|\n| TypeScript | `bunx tsc --noEmit <file>` if Bun present, else `npx tsc --noEmit <file>` |\n| Python | `python3 -m py_compile <file>` (always) + `ruff check <file>` if `ruff` is on PATH |\n| Bash | `shellcheck <file>` if available, else `bash -n <file>` |\n\n**On success**: log a single line (`syntax check OK`) and proceed to Step 7.\n\n**On failure**:\n1. Print the error (≤10 lines, not the full output).\n2. Propose a concrete one-edit fix (the exact `Edit` you'd apply).\n3. Use **AskUserQuestion** with `Apply fix | Investigate | Stop`.\n   - **Apply fix** → edit the script and re-run the checker (loop, no hardcoded cap).\n   - **Investigate** → drop into discussion with the user; do not auto-apply anything.\n   - **Stop** → leave script in place at its path; print the path; do not delete.\n\n### Step 7: Document the Script\n\nAuto-edit the target project's `CLAUDE.md` and/or `AGENTS.md` so future agents discover this script when the matching intent recurs.\n\n**Block template** (the literal markdown the skill emits):\n\n```markdown\n<important if=\"[TRIGGER: e.g., you are testing the auth flow]\">\n\n## [Area] validation\n\nRun `scripts/<name>` to [one-liner]. Requires [env/deps]. Example: `<cmd>`. Full log at `/tmp/<name>-*.log`.\n\nGenerated/maintained via `/script-builder`.\n\n</important>\n```\n\n**Behavior**:\n\n1. **Target file selection**: edit `CLAUDE.md` and `AGENTS.md` if both exist; edit only what exists. **Never** create either file from scratch — if neither exists, print a one-line note (`No CLAUDE.md or AGENTS.md found — script generated but not documented`) and skip this step.\n2. **Placement heuristic**: search the file for the first heading matching `Test|Testing|Validation|Scripts` (case-insensitive). If found, append the new block within/after that section. Otherwise, append a new `## Scripts for testing & validation` section near the end of the file but **before** any heading matching `License|Acknowledg|Maintain|Contributors`.\n3. **Idempotency**: if a block referencing `scripts/<name>` already exists (i.e., a prior `/script-builder` run for the same script name), update it in place — replace the entire `<important if=...>...</important>` block, do not append a duplicate.\n4. **Scripts-dir marker**: if Step 2 resolved the scripts directory by user choice (not from an existing marker), insert `<!-- script-builder:dir=<path> -->` near the top of `CLAUDE.md` (after the title) so subsequent runs are silent. Skip if the marker already exists.\n5. **Scale gate — `scripts/index.md`**: if the scripts directory holds **>10 documented scripts**, per-script `<important if>` blocks become their own context bloat. Generate/maintain a `scripts/index.md` hub instead (one line + link per script, mirroring the `runbooks/` convention from `desplega:engineering-standards`), collapse the CLAUDE.md/AGENTS.md blocks into ONE pointer block referencing the hub, and add new scripts to the hub only.\n6. **Show the diff**: run the equivalent of `git diff CLAUDE.md AGENTS.md` and print a 5-line summary of what changed. **Never auto-stage** — the user commits.\n\n### Step 8: Offer Escalation\n\nAfter the doc edit, decide whether to proceed to the run-and-iterate tier.\n\n| Autonomy | Behavior |\n|----------|----------|\n| **Autopilot** | Auto-escalate to Step 9 unless the intent flagged side-effects (writes to prod, sends real money, mutates a shared resource). On flagged side-effects, fall through to Critical behavior. |\n| **Critical** (Default) | Use **AskUserQuestion**: `Run it now to confirm it works | I'll run it myself later | Just generate, don't run`. |\n| **Verbose** | Same as Critical, plus offer the proposed run command for review before executing. |\n\nIf the user picks \"I'll run it myself later\" or \"Just generate, don't run\" → skip directly to Step 10.\n\n### Step 9: Iterate on Failures (Escalated Tier Only)\n\nA bounded-by-the-human loop. **Never auto-apply a fix** outside Autopilot.\n\n1. **Run the script** with the proposed example invocation (no `--verbose`, no `--json`). Capture exit code and `tail -n 40` of the `/tmp` log.\n2. **If exit code 0** → report PASS (echo the script's PASS line) and proceed to Step 10.\n3. **If exit code non-zero**:\n   - Summarize the failure in **1–3 lines**: error class (timeout / 4xx / 5xx / assertion / dependency-missing / etc.) + likely cause (grep the log for known signatures: `ECONNREFUSED`, `Traceback`, `non-zero exit`, `command not found`, etc.).\n   - **Propose a concrete diff** — the exact `Edit` you would apply to the script. Show old → new.\n   - Use **AskUserQuestion**: `Apply fix | Investigate differently | Stop`.\n     - **Apply fix** → edit the script, log the change, loop back to (1).\n     - **Investigate differently** → drop into discussion; do not auto-apply.\n     - **Stop** → leave the script in place, print its path; do not revert.\n\n**No hardcoded retry cap** — the human is the implicit bound.\n\n**Side-effect flag**: if the intent declared side-effects (Step 3) and Autopilot is active, surface a one-line `WARNING: this script <does X> against <target>` before the first run and require explicit confirmation via **AskUserQuestion** even in Autopilot mode.\n\n### Step 10: Handoff\n\nHow the skill exits depends on how it was invoked:\n\n**Invoked as a sub-skill** (from `planning`, `qa`, `verifying`):\nReturn control to the parent skill with a structured summary: `{ script_path, status: \"pass\"|\"fail\"|\"unrun\", log_path?, doc_files_edited: [...] }`.\n\n**Invoked directly** (`/script-builder`):\nUse **AskUserQuestion**: `Run it with /qa | Run /verify-plan | Commit the script and doc changes | Done`.\n- **Run with /qa** → invoke `desplega:qa` with the script path as the source.\n- **Run /verify-plan** → invoke `desplega:verifying` if a plan path is in current context.\n- **Commit** → propose a commit message (`feat(scripts): add scripts/<name> for <area> validation`) and stage only the generated script + the CLAUDE.md/AGENTS.md edits. Do not auto-commit; show the proposed `git add` and `git commit` commands and require user confirmation.\n- **Done** → print the script path + log path (if escalation ran) and exit.\n\n**Abort path** (Stop selected at any earlier gate): leave the generated script in place, leave any CLAUDE.md/AGENTS.md edit in place if Step 7 ran, and print a one-liner: `Aborted. Script: <path>. Doc edits: <files or \"none\">. Re-run /script-builder or git checkout to discard.` Do not `git restore` on the user's behalf.\n\n## Learning Capture\n\n**OPTIONAL SUB-SKILL:** If significant insights, patterns, gotchas, or decisions emerged during this workflow, consider using `desplega:learning` to capture them via `/learning capture`. Focus on learnings that would help someone else in a future session.\n";
 
 // templates/skills/script-workflows/config.json
-var config_default36 = `{
+var config_default37 = `{
   "kind": "skill",
   "name": "script-workflows",
   "displayName": "Script Workflows",
@@ -10133,16 +10390,16 @@ var config_default36 = `{
 `;
 
 // templates/skills/script-workflows/content.md
-var content_default36 = "Use this skill when a user asks to launch, monitor, inspect, or debug a durable script workflow run. This is for the Script Workflows v1 runtime: one-off TypeScript workflow source with journaled `swarm-script`, `raw-llm`, and `agent-task` steps.\n\n## Tool Flow\n\nLoad the script workflow tools with ToolSearch when they are not already visible:\n\n```text\nlaunch-script-run\nget-script-run\nlist-script-runs\n```\n\nUse `launch-script-run` to start a one-off run. It calls the same `/api/script-runs` API as the dashboard, preserves the invoking agent identity, and starts the run in the background.\n\nUse `get-script-run` to read terminal status and journal entries. Poll it when needed, but keep polling bounded and report progress for long runs.\n\nUse `list-script-runs` to find recent runs or filter by `status` / `agentId`.\n\nDo not hand-roll raw HTTP for this flow unless the tool itself is broken and you are explicitly debugging the API. The tool handles auth and `X-Agent-ID` like the existing inline `script-run` tool family.\n\n## Source Shape\n\nAuthor TypeScript workflow source as a default export. The runtime provides `args` and `ctx`.\n\n```ts\nexport default async function main(args, ctx) {\n  const lookup = await ctx.step.swarmScript(\"lookup-data\", {\n    scriptName: \"fetch-readable\",\n    args: { url: args.url },\n  });\n\n  const summary = await ctx.step.rawLlm(\"summarize\", {\n    prompt: `Summarize this for an operator:\\n${JSON.stringify(lookup)}`,\n  });\n\n  const task = await ctx.step.agentTask(\"operator-review\", {\n    task: `Review this summary and flag risks:\\n${JSON.stringify(summary)}`,\n    tags: [\"script-run\"],\n    priority: 50,\n  });\n\n  return { lookup, summary, task };\n}\n```\n\n`ctx.step.agentTask` blocks until the dispatched task reaches a terminal status (default `waitForCompletion: true`, default `timeoutMs` 2h) and journals its real output — a sequential `plan → implement → review` chain will not fan out. Pass `waitForCompletion: false` for the legacy fire-and-poll-yourself shape, or `failOnTaskFailure: false` to receive `{taskId, status: \"failed\", error}` instead of a throw when the task fails/is cancelled.\n\n## Label Rules\n\nStep labels are durability keys. They must be stable and unique for each logical step. Do not reuse the same literal label inside a loop; launch will fail with `label_lint_violation`.\n\nFor looped work, include an item identifier in the label:\n\n```ts\nfor (const item of args.items) {\n  await ctx.step.agentTask(`review-${item.id}`, { task: item.prompt });\n}\n```\n\n## Statuses\n\nTerminal statuses to surface clearly:\n\n- `completed` — run finished and `output` may be present.\n- `failed` — run ended with `error`.\n- `cancelled` — run was cancelled before completion.\n- `aborted_limit` — runtime guardrail stopped the run, usually step count, agent-task count, or wall-clock cap.\n- `label_lint_violation` — launch-time rejection, not a persisted run status.\n\nWhen a run is not terminal, report the current status, journal count, and latest heartbeat if present.\n";
+var content_default37 = "Use this skill when a user asks to launch, monitor, inspect, or debug a durable script workflow run. This is for the Script Workflows v1 runtime: one-off TypeScript workflow source with journaled `swarm-script`, `raw-llm`, and `agent-task` steps.\n\n## Tool Flow\n\nLoad the script workflow tools with ToolSearch when they are not already visible:\n\n```text\nlaunch-script-run\nget-script-run\nlist-script-runs\n```\n\nUse `launch-script-run` to start a one-off run. It calls the same `/api/script-runs` API as the dashboard, preserves the invoking agent identity, and starts the run in the background.\n\nUse `get-script-run` to read terminal status and journal entries. Poll it when needed, but keep polling bounded and report progress for long runs.\n\nUse `list-script-runs` to find recent runs or filter by `status` / `agentId`.\n\nDo not hand-roll raw HTTP for this flow unless the tool itself is broken and you are explicitly debugging the API. The tool handles auth and `X-Agent-ID` like the existing inline `script-run` tool family.\n\n## Source Shape\n\nAuthor TypeScript workflow source as a default export. The runtime provides `args` and `ctx`.\n\n```ts\nexport default async function main(args, ctx) {\n  const lookup = await ctx.step.swarmScript(\"lookup-data\", {\n    scriptName: \"fetch-readable\",\n    args: { url: args.url },\n  });\n\n  const summary = await ctx.step.rawLlm(\"summarize\", {\n    prompt: `Summarize this for an operator:\\n${JSON.stringify(lookup)}`,\n  });\n\n  const task = await ctx.step.agentTask(\"operator-review\", {\n    task: `Review this summary and flag risks:\\n${JSON.stringify(summary)}`,\n    tags: [\"script-run\"],\n    priority: 50,\n  });\n\n  return { lookup, summary, task };\n}\n```\n\n`ctx.step.agentTask` blocks until the dispatched task reaches a terminal status (default `waitForCompletion: true`, default `timeoutMs` 2h) and journals its real output — a sequential `plan → implement → review` chain will not fan out. Pass `waitForCompletion: false` for the legacy fire-and-poll-yourself shape, or `failOnTaskFailure: false` to receive `{taskId, status: \"failed\", error}` instead of a throw when the task fails/is cancelled.\n\n## Label Rules\n\nStep labels are durability keys. They must be stable and unique for each logical step. Do not reuse the same literal label inside a loop; launch will fail with `label_lint_violation`.\n\nFor looped work, include an item identifier in the label:\n\n```ts\nfor (const item of args.items) {\n  await ctx.step.agentTask(`review-${item.id}`, { task: item.prompt });\n}\n```\n\n## Statuses\n\nTerminal statuses to surface clearly:\n\n- `completed` — run finished and `output` may be present.\n- `failed` — run ended with `error`.\n- `cancelled` — run was cancelled before completion.\n- `aborted_limit` — runtime guardrail stopped the run, usually step count, agent-task count, or wall-clock cap.\n- `label_lint_violation` — launch-time rejection, not a persisted run status.\n\nWhen a run is not terminal, report the current status, journal count, and latest heartbeat if present.\n";
 
 // templates/skills/slack-interaction/config.json
-var config_default37 = '{\n  "kind": "skill",\n  "name": "slack-interaction",\n  "displayName": "Slack Interaction",\n  "slug": "slack-interaction",\n  "title": "Slack Interaction",\n  "description": "Slack: reply, post, read, upload, and the thread rules. What the engine already posts, the one-message rule, `slack-reply`, `slack-post`, `slack-start-thread`, `slack-read`, `slack-upload-file`, `slack-download-file`, `slack-list-channels`, `slack-update`, `slack-delete`, unknown-user registration with `manage-user`, and Slack standing orders. Use before any Slack message.",\n  "version": "1.0.0",\n  "category": "skills",\n  "placeholders": [],\n  "runAllSeedersCandidate": true,\n  "systemDefault": true,\n  "tags": ["slack", "communication"]\n}\n';
+var config_default38 = '{\n  "kind": "skill",\n  "name": "slack-interaction",\n  "displayName": "Slack Interaction",\n  "slug": "slack-interaction",\n  "title": "Slack Interaction",\n  "description": "Slack: reply, post, read, upload, and the thread rules. What the engine already posts, the one-message rule, `slack-reply`, `slack-post`, `slack-start-thread`, `slack-read`, `slack-upload-file`, `slack-download-file`, `slack-list-channels`, `slack-update`, `slack-delete`, unknown-user registration with `manage-user`, and Slack standing orders. Use before any Slack message.",\n  "version": "1.0.0",\n  "category": "skills",\n  "placeholders": [],\n  "runAllSeedersCandidate": true,\n  "systemDefault": true,\n  "tags": ["slack", "communication"]\n}\n';
 
 // templates/skills/slack-interaction/content.md
-var content_default37 = '# Slack interaction\n\n## What the engine posts\n\nFor every task that came from Slack, the engine owns the thread tree and the top-level outcome card. It posts the start, the completion, and the failure. You do not.\n\n## Your one message\n\n- At most one message per task, and only when the outcome card will not carry it: a question, a decision the requester must make, a link to a page or file with one line of context.\n- Progress, receipts, acknowledgments, and relayed worker output stay out of Slack.\n- Concrete content. The length matches what the requester asked for.\n- The "How you write" rules of your system prompt apply. Slack renders mrkdwn: `*bold*`, `_italic_`, `` `code` ``, `<url|text>` for links. Markdown headings and tables do not render.\n\n## Where to post\n\nThe task carries `slackChannelId` and `slackThreadTs` in its metadata. A follow-up task with `parentTaskId` inherits them.\n\n- Reply in the task\'s thread: `slack-reply` with `taskId` and `message`.\n- Reply to an inbox message: `slack-reply` with `inboxMessageId`.\n- New top-level message in a channel (lead): `slack-start-thread` with `channelId`, then `slack-post` with the returned `ts` as `threadTs` for replies under it.\n- Fix your own message: `slack-update` (text) or `slack-delete` (lead). Both work only on messages this bot authored.\n\n## Tools\n\n| Tool | Use |\n|---|---|\n| `slack-reply` | reply in a thread by `taskId` or `inboxMessageId` |\n| `slack-post` | post to a channel, optional `threadTs` (lead) |\n| `slack-start-thread` | post a top-level message and get its `ts` (lead) |\n| `slack-read` | read a thread by `taskId` or `inboxMessageId`, or a channel by `channelId` (lead) |\n| `slack-list-channels` | channels the bot is a member of |\n| `slack-upload-file` | upload a file to a thread or channel, up to 1 GB |\n| `slack-download-file` | download a Slack file by ID or URL |\n| `slack-update` | edit your own message |\n| `slack-delete` | delete your own message (lead) |\n| `slack-create-channel`, `slack-invite-to-channel`, `slack-archive-channel` | channel lifecycle (lead) |\n\nFiles attached to your task already come with download commands in the task message. Use those before `slack-download-file`.\n\n## Unknown user\n\nA task without `requestedByUserId` came from a Slack user the swarm does not know. Register them with `manage-user`, using the Slack user ID and display name from the task metadata, then continue. When you learn a requester\'s stable preferences (language, tone, verbosity), the lead stores them in the user\'s `comms` field with `manage-user`.\n\n## Lead standing orders\n\nWhen your heartbeat runbook says so, check for unaddressed requests older than one hour: `slack-list-channels`, then `slack-read` per channel, then create a task for each open request.\n\n## Scripts-only mode\n\nThe named Slack tools are not registered. Use `script-run` with inline source: `ctx.swarm.slack_reply({ taskId, message })`. The task ID carries the thread context.\n';
+var content_default38 = '# Slack interaction\n\n## What the engine posts\n\nFor every task that came from Slack, the engine owns the thread tree and the top-level outcome card. It posts the start, the completion, and the failure. You do not.\n\n## Your one message\n\n- At most one message per task, and only when the outcome card will not carry it: a question, a decision the requester must make, a link to a page or file with one line of context.\n- Progress, receipts, acknowledgments, and relayed worker output stay out of Slack.\n- Concrete content. The length matches what the requester asked for.\n- The "How you write" rules of your system prompt apply. Slack renders mrkdwn: `*bold*`, `_italic_`, `` `code` ``, `<url|text>` for links. Markdown headings and tables do not render.\n\n## Where to post\n\nThe task carries `slackChannelId` and `slackThreadTs` in its metadata. A follow-up task with `parentTaskId` inherits them.\n\n- Reply in the task\'s thread: `slack-reply` with `taskId` and `message`.\n- Reply to an inbox message: `slack-reply` with `inboxMessageId`.\n- New top-level message in a channel (lead): `slack-start-thread` with `channelId`, then `slack-post` with the returned `ts` as `threadTs` for replies under it.\n- Fix your own message: `slack-update` (text) or `slack-delete` (lead). Both work only on messages this bot authored.\n\n## Tools\n\n| Tool | Use |\n|---|---|\n| `slack-reply` | reply in a thread by `taskId` or `inboxMessageId` |\n| `slack-post` | post to a channel, optional `threadTs` (lead) |\n| `slack-start-thread` | post a top-level message and get its `ts` (lead) |\n| `slack-read` | read a thread by `taskId` or `inboxMessageId`, or a channel by `channelId` (lead) |\n| `slack-list-channels` | channels the bot is a member of |\n| `slack-upload-file` | upload a file to a thread or channel, up to 1 GB |\n| `slack-download-file` | attach a Slack file (by ID or URL) to your task; run the `fetchCommand` it returns to get the bytes |\n| `slack-update` | edit your own message |\n| `slack-delete` | delete your own message (lead) |\n| `slack-create-channel`, `slack-invite-to-channel`, `slack-archive-channel` | channel lifecycle (lead) |\n\nFiles attached to your task already come with download commands in the task message. Use those before `slack-download-file`. `slack-read` on your task also attaches the files in the thread and gives each one a `fetchCommand`. Don\'t look for Slack files under `/app/shared` or `/workspace/shared/downloads`: those paths are the API server\'s disk.\n\n## Unknown user\n\nA task without `requestedByUserId` came from a Slack user the swarm does not know. Register them with `manage-user`, using the Slack user ID and display name from the task metadata, then continue. When you learn a requester\'s stable preferences (language, tone, verbosity), the lead stores them in the user\'s `comms` field with `manage-user`.\n\n## Lead standing orders\n\nWhen your heartbeat runbook says so, check for unaddressed requests older than one hour: `slack-list-channels`, then `slack-read` per channel, then create a task for each open request.\n\n## Scripts-only mode\n\nThe named Slack tools are not registered. Use `script-run` with inline source: `ctx.swarm.slack_reply({ taskId, message })`. The task ID carries the thread context.\n';
 
 // templates/skills/step-running/config.json
-var config_default38 = `{
+var config_default39 = `{
   "category": "skills",
   "description": "Execute a single DAG step as an autonomous background sub-agent. Sibling of phase-running for DAG plans produced by v-planning. Reads a step-<n>.md file directly, atomically claims it via frontmatter status, runs the three-bucket Success Criteria, and reports back. Spawned by v-implementing or by /run-step.",
   "displayName": "Step Running",
@@ -10163,10 +10420,10 @@ var config_default38 = `{
 `;
 
 // templates/skills/step-running/content.md
-var content_default38 = "# Step Running\n\nYou execute a single step of a DAG plan as an atomic background sub-agent. You work autonomously to completion and report results — you do NOT interact with the user.\n\nThis is the DAG sibling of `phase-running`. The execution model and atomicity contract are identical; the differences are:\n- You receive a **step file path** (`step-<n>.md`), not a plan path + phase number.\n- You **claim the step atomically** via the step's frontmatter `status` field before doing work, and release it on completion / failure. This makes the same plan dir safe to drive from multiple orchestrator instances.\n\n## Execution Model\n\nThis skill runs inside a background `Agent` (sub-agent). v-implementing (or a user invoking `/run-step`) spawns it via the Agent tool with `run_in_background: true`.\n\nThe step agent receives:\n- **Step path**: full path to `step-<n>.md`\n- **Plan dir**: full path to the parent plan directory (read `root.md` from here for plan-level context)\n- **Agent ID**: unique identifier for this sub-agent (e.g. orchestrator session ID + step ID + timestamp). Used for atomic claim + stale-claim detection.\n- **Relevant context**: any extra context from the caller\n\n## Concurrency: Atomic Claim\n\nBefore doing any work, claim the step:\n\n1. Read the step file's frontmatter.\n2. **If `status: done`** — report `Status: skipped` and exit. The step is already finished.\n3. **If `status: claimed`** and `assignee` differs from your agent ID:\n   - Fresh claim (`claimed_at` within last hour): report `Status: blocked` (reason: `claimed by <other-id>`) and exit.\n   - Stale claim (>1h): proceed and overwrite — the previous worker likely died.\n4. **Otherwise** (`status: ready`, or stale `claimed`): rewrite the frontmatter block in a single `Edit` so the write is atomic-enough for filesystem-based coordination. Set:\n   - `status: claimed`\n   - `assignee: <your-agent-id>`\n   - `claimed_at: <ISO timestamp UTC>`\n5. Re-read the file. If `assignee` is not yours, another worker raced you — report `Status: blocked` (reason: `lost claim race`) and exit.\n\nOn terminal transitions, set frontmatter:\n- **Completed**: `status: done`, clear `assignee` and `claimed_at`.\n- **Blocked or failed (retry-able)**: `status: ready`, clear `assignee` and `claimed_at`. The orchestrator (or another worker) can retry.\n- **Failed (non-retry-able)**: leave `status: claimed` so the orchestrator can investigate; include the reason in the report.\n\nFor true cross-machine atomicity (NFS, etc.), the caller is responsible for rendezvous (e.g. a shared lock service). The single-Edit pattern is good-enough for local filesystem and well-behaved network filesystems.\n\n## Autonomy\n\nStep agents always run as **Autopilot** within the sub-agent. The calling context controls outer autonomy and human checkpoints.\n\n**CRITICAL**: Step agents do NOT use AskUserQuestion. If something is ambiguous, report `Status: blocked` with details. The caller handles all user interaction.\n\n## Process Steps\n\n### Step 1: Load Context\n\n1. **Claim the step** (see \"Concurrency: Atomic Claim\"). Stop here on any non-claim outcome.\n2. Read the full step file.\n3. Read `root.md` from the plan dir for plan-level context: Overview, Current State, Desired End State, Implementation Approach, Global Verification.\n4. Read all files mentioned in the step's \"Changes Required\" section.\n\n### Step 2: Pre-flight Check\n\n| Check | Action if failed |\n|-------|-----------------|\n| All `depends_on` steps have `status: done` | Scheduler bug — release claim, report `blocked` |\n| No merge conflicts in target files | Release claim, report `blocked` |\n| Files/dirs from depended-on steps exist | Release claim, report `blocked` |\n\n### Step 3: Execute Step\n\nImplement the changes described in the step's \"Changes Required\" section. Adapt to minor mismatches; report `blocked` for significant ones.\n\n### Step 4: Run Verification\n\nSame three-bucket pattern as `phase-running`:\n1. **Automated Verification** (runnable commands): run each, record pass/fail. On failure, attempt one fix-and-retry.\n2. **Automated QA** (agent-driven scenarios — browser-use, screenshot diff, CLI walkthrough): execute, record pass/fail per item.\n3. **Manual Verification**: leave unchecked. Caller handles with the user.\n4. **QA Spec (linked doc)**: if present, report `QA Doc: <path>`. Do not execute scenarios inline.\n\n### Step 5: Update Step File\n\n- Check off (`- [x]`) Automated Verification + Automated QA items that passed.\n- Do NOT check off Manual Verification items.\n- Update frontmatter `status` per \"Concurrency: Atomic Claim\" terminal-transition rules.\n- Update `last_updated` / `last_updated_by` frontmatter fields if present.\n\n### Step 6: Report Results\n\n**Completed:**\n```\nStatus: completed\nStep: step-N - <Name>\nFinal frontmatter status: done\nFiles changed: [list]\nAutomated Verification: N/M passed\n- [x] [Check 1] — passed\nAutomated QA: N/M passed\n- [x] [Scenario 1] — passed\nQA Doc: <path> | n/a\nManual verification needed:\n- [ ] [Manual check 1]\n```\n\n**Blocked / failed:** mirror `phase-running`'s shape, plus a `Final frontmatter status:` line so the orchestrator knows whether the step is released for retry (`ready`) or held for investigation (`claimed`).\n\n## Atomicity Contract\n\n- No interactive questions.\n- No partial states left unexplained.\n- Frontmatter `status` always reflects the final state at exit.\n- Report includes enough detail for the caller to decide next steps.\n\n## Context Handoff Pattern\n\n| Direction | Data |\n|-----------|------|\n| **Caller → Step Agent** | Step path + plan dir + agent ID + autonomy mode |\n| **Step Agent reads** | Step file + root.md + files in Changes Required |\n| **Step Agent writes** | Frontmatter status transitions + checkboxes + code changes |\n| **Step Agent → Caller** | Status + changed files + verification results + final frontmatter status |\n| **Caller handles** | Manual verification, cross-step coordination, QA doc execution, human checkpoints |\n";
+var content_default39 = "# Step Running\n\nYou execute a single step of a DAG plan as an atomic background sub-agent. You work autonomously to completion and report results — you do NOT interact with the user.\n\nThis is the DAG sibling of `phase-running`. The execution model and atomicity contract are identical; the differences are:\n- You receive a **step file path** (`step-<n>.md`), not a plan path + phase number.\n- You **claim the step atomically** via the step's frontmatter `status` field before doing work, and release it on completion / failure. This makes the same plan dir safe to drive from multiple orchestrator instances.\n\n## Execution Model\n\nThis skill runs inside a background `Agent` (sub-agent). v-implementing (or a user invoking `/run-step`) spawns it via the Agent tool with `run_in_background: true`.\n\nThe step agent receives:\n- **Step path**: full path to `step-<n>.md`\n- **Plan dir**: full path to the parent plan directory (read `root.md` from here for plan-level context)\n- **Agent ID**: unique identifier for this sub-agent (e.g. orchestrator session ID + step ID + timestamp). Used for atomic claim + stale-claim detection.\n- **Relevant context**: any extra context from the caller\n\n## Concurrency: Atomic Claim\n\nBefore doing any work, claim the step:\n\n1. Read the step file's frontmatter.\n2. **If `status: done`** — report `Status: skipped` and exit. The step is already finished.\n3. **If `status: claimed`** and `assignee` differs from your agent ID:\n   - Fresh claim (`claimed_at` within last hour): report `Status: blocked` (reason: `claimed by <other-id>`) and exit.\n   - Stale claim (>1h): proceed and overwrite — the previous worker likely died.\n4. **Otherwise** (`status: ready`, or stale `claimed`): rewrite the frontmatter block in a single `Edit` so the write is atomic-enough for filesystem-based coordination. Set:\n   - `status: claimed`\n   - `assignee: <your-agent-id>`\n   - `claimed_at: <ISO timestamp UTC>`\n5. Re-read the file. If `assignee` is not yours, another worker raced you — report `Status: blocked` (reason: `lost claim race`) and exit.\n\nOn terminal transitions, set frontmatter:\n- **Completed**: `status: done`, clear `assignee` and `claimed_at`.\n- **Blocked or failed (retry-able)**: `status: ready`, clear `assignee` and `claimed_at`. The orchestrator (or another worker) can retry.\n- **Failed (non-retry-able)**: leave `status: claimed` so the orchestrator can investigate; include the reason in the report.\n\nFor true cross-machine atomicity (NFS, etc.), the caller is responsible for rendezvous (e.g. a shared lock service). The single-Edit pattern is good-enough for local filesystem and well-behaved network filesystems.\n\n## Autonomy\n\nStep agents always run as **Autopilot** within the sub-agent. The calling context controls outer autonomy and human checkpoints.\n\n**CRITICAL**: Step agents do NOT use AskUserQuestion. If something is ambiguous, report `Status: blocked` with details. The caller handles all user interaction.\n\n## Process Steps\n\n### Step 1: Load Context\n\n1. **Claim the step** (see \"Concurrency: Atomic Claim\"). Stop here on any non-claim outcome.\n2. Read the full step file.\n3. Read `root.md` from the plan dir for plan-level context: Overview, Current State, Desired End State, Implementation Approach, Global Verification.\n4. Read all files mentioned in the step's \"Changes Required\" section.\n\n### Step 2: Pre-flight Check\n\n| Check | Action if failed |\n|-------|-----------------|\n| All `depends_on` steps have `status: done` | Scheduler bug — release claim, report `blocked` |\n| No merge conflicts in target files | Release claim, report `blocked` |\n| Files/dirs from depended-on steps exist | Release claim, report `blocked` |\n\n### Step 3: Execute Step\n\nImplement the changes described in the step's \"Changes Required\" section. Adapt to minor mismatches; report `blocked` for significant ones.\n\n### Step 4: Run Verification\n\nSame three-bucket pattern as `phase-running`:\n1. **Automated Verification** (runnable commands): run each, record pass/fail. On failure, attempt one fix-and-retry.\n2. **Automated QA** (agent-driven scenarios — browser-use, screenshot diff, CLI walkthrough): execute, record pass/fail per item.\n3. **Manual Verification**: leave unchecked. Caller handles with the user.\n4. **QA Spec (linked doc)**: if present, report `QA Doc: <path>`. Do not execute scenarios inline.\n\n### Step 5: Update Step File\n\n- Check off (`- [x]`) Automated Verification + Automated QA items that passed.\n- Do NOT check off Manual Verification items.\n- Update frontmatter `status` per \"Concurrency: Atomic Claim\" terminal-transition rules.\n- Update `last_updated` / `last_updated_by` frontmatter fields if present.\n\n### Step 6: Report Results\n\n**Completed:**\n```\nStatus: completed\nStep: step-N - <Name>\nFinal frontmatter status: done\nFiles changed: [list]\nAutomated Verification: N/M passed\n- [x] [Check 1] — passed\nAutomated QA: N/M passed\n- [x] [Scenario 1] — passed\nQA Doc: <path> | n/a\nManual verification needed:\n- [ ] [Manual check 1]\n```\n\n**Blocked / failed:** mirror `phase-running`'s shape, plus a `Final frontmatter status:` line so the orchestrator knows whether the step is released for retry (`ready`) or held for investigation (`claimed`).\n\n## Atomicity Contract\n\n- No interactive questions.\n- No partial states left unexplained.\n- Frontmatter `status` always reflects the final state at exit.\n- Report includes enough detail for the caller to decide next steps.\n\n## Context Handoff Pattern\n\n| Direction | Data |\n|-----------|------|\n| **Caller → Step Agent** | Step path + plan dir + agent ID + autonomy mode |\n| **Step Agent reads** | Step file + root.md + files in Changes Required |\n| **Step Agent writes** | Frontmatter status transitions + checkboxes + code changes |\n| **Step Agent → Caller** | Status + changed files + verification results + final frontmatter status |\n| **Caller handles** | Manual verification, cross-step coordination, QA doc execution, human checkpoints |\n";
 
 // templates/skills/swarm-scripts/config.json
-var config_default39 = `{
+var config_default40 = `{
   "kind": "skill",
   "name": "swarm-scripts",
   "displayName": "Swarm Scripts",
@@ -10183,7 +10440,7 @@ var config_default39 = `{
 `;
 
 // templates/skills/swarm-scripts/content.md
-var content_default39 = `# Swarm Scripts
+var content_default40 = `# Swarm Scripts
 
 A swarm script is TypeScript that runs out of process with a typed Swarm SDK. Only its return value enters your context. Use one when direct tool calls would repeat, flood your context, or need deterministic processing over many records.
 
@@ -10338,7 +10595,7 @@ A named script can serve \`POST /api/x/script/<id>\` for callers outside the swa
 `;
 
 // templates/skills/tackle-gh-comments/config.json
-var config_default40 = `{
+var config_default41 = `{
   "category": "skills",
   "description": "Work through every review comment on a GitHub PR — fetch the threads, verify each claim against the code, fix what is real, then reply and mark each thread resolved before pushing. Use when the user says \\"tackle the PR comments\\", \\"address the review\\", \\"handle the bot comments\\", \\"check the comments on the PR\\", \\"resolve the review threads\\", or invokes /tackle-gh-comments. Project-agnostic; works in any repo with a GitHub remote.",
   "displayName": "Tackle GH Comments",
@@ -10359,7 +10616,7 @@ var config_default40 = `{
 `;
 
 // templates/skills/tackle-gh-comments/content.md
-var content_default40 = `# Tackle GitHub PR comments
+var content_default41 = `# Tackle GitHub PR comments
 
 Review threads and their resolved state live **only in GraphQL**. The REST API
 cannot read \`isResolved\` and cannot resolve a thread, and \`gh pr view --comments\`
@@ -10478,7 +10735,7 @@ committed, and the branch is pushed.
 `;
 
 // templates/skills/taste-minimalist-skill/config.json
-var config_default41 = `{
+var config_default42 = `{
   "kind": "skill",
   "name": "taste-minimalist-skill",
   "displayName": "Taste Minimalist Skill",
@@ -10500,7 +10757,7 @@ var config_default41 = `{
 `;
 
 // templates/skills/taste-minimalist-skill/content.md
-var content_default41 = `> Vendored from [taste-skill](https://github.com/Leonxlnx/taste-skill) / [tasteskill.dev](https://www.tasteskill.dev/) at commit 06d6028b5c623016c59ce8536f578e5a1127b499.
+var content_default42 = `> Vendored from [taste-skill](https://github.com/Leonxlnx/taste-skill) / [tasteskill.dev](https://www.tasteskill.dev/) at commit 06d6028b5c623016c59ce8536f578e5a1127b499.
 > Upstream license: MIT, Copyright (c) 2026 Leonxlnx. See ../TASTE-SKILL-LICENSE.
 
 # Protocol: Premium Utilitarian Minimalism UI Architect
@@ -10586,7 +10843,7 @@ When tasked with writing frontend code (HTML, React, Tailwind, Vue) or designing
 `;
 
 // templates/skills/tdd-planning/config.json
-var config_default42 = `{
+var config_default43 = `{
   "category": "skills",
   "description": "TDD-focused implementation planning. Creates plans with strict Red-Green-Commit/Rollback cycles for each step.",
   "displayName": "TDD Planning",
@@ -10607,7 +10864,7 @@ var config_default42 = `{
 `;
 
 // templates/skills/tdd-planning/content.md
-var content_default42 = `# TDD Planning
+var content_default43 = `# TDD Planning
 
 You are creating implementation plans that follow a strict Test-Driven Development approach. Every implementation step follows the TDD cycle: **RED → GREEN → COMMIT/ROLLBACK**.
 
@@ -10869,7 +11126,7 @@ Before finalizing any TDD plan, verify:
 `;
 
 // templates/skills/v-implementing/config.json
-var config_default43 = `{
+var config_default44 = `{
   "category": "skills",
   "description": "Parallel DAG-plan implementation skill. Reads a v-planning plan directory (root.md + step-<n>.md files), topologically schedules ready steps, and fans them out as parallel sub-agents. Use whenever the user invokes /v-implement, points at a plan directory produced by /v-plan, or asks to \\"run the parallel plan\\", \\"implement the DAG\\", or \\"fan out the steps\\" — even without those exact words. For linear plans (single .md file), use \`implementing\` instead.",
   "displayName": "V-Implementing",
@@ -10890,10 +11147,10 @@ var config_default43 = `{
 `;
 
 // templates/skills/v-implementing/content.md
-var content_default43 = "# v-implementing\n\nYou are implementing an approved DAG-structured plan produced by `v-planning`. The plan is a directory with `root.md` + one `step-<n>.md` per node. Your job is to act as a **topological scheduler**: at each tick, find steps whose dependencies are all done, fan them out as parallel sub-agents (one per ready step), wait, repeat — until the DAG is drained. Then run Global Verification.\n\nThis is the parallel sibling of `implementing`. The orchestration model is the same (sub-agents do the work, main session coordinates), only the scheduler is different.\n\n## Working Agreement\n\n**All user-facing questions go through `AskUserQuestion`** — see `desplega:ask-user` for conventions. Never ask in chat as plain bullets.\n\n**All read/research/validation work goes through sub-agents** — keep raw tool output out of the main session. Default to `run_in_background: true`. The fan-out scheduler below is built on this.\n\nThe autonomy mode (below) controls how often you check in. AskUserQuestion is always the mechanism.\n\nFile-review is on by default — when significant changes land in a step (or wave), invoke `/file-review:file-review <path>` for inline feedback (skip only if Autopilot).\n\n## Autonomy Mode\n\n| Mode | Behavior |\n|------|----------|\n| **Autopilot** | Drain the DAG without pausing. Only stop on blocker / failed step. |\n| **Critical** (Default) | Pause when each *wave* of parallel steps completes; wait for manual verification before unlocking the next wave. |\n| **Verbose** | Pause after each individual step (even within a wave). |\n\n## Initial Setup Questions\n\nAfter understanding the plan and before the scheduler loop starts, gather implementation-specific details (skip in Autopilot):\n\n### 1. Branch / Worktree Setup\n\nCheck the current branch: `git branch --show-current`. Then check if the `wts` plugin is installed (look for `wts:wts` in available skills).\n\n**If wts is installed**, use **AskUserQuestion**:\n\n| Question | Options |\n|----------|---------|\n| \"You're on `<current-branch>`. Where would you like to implement?\" | 1. Continue on current branch, 2. Create a new branch, 3. Create a wts worktree |\n\n**If wts is not installed**, drop the worktree option.\n\n### 2. Commit Strategy\n\nUse **AskUserQuestion**:\n\n| Question | Options |\n|----------|---------|\n| \"How would you like to handle commits during parallel implementation?\" | 1. Commit after each step completes (Recommended), 2. Commit at the end (single commit), 3. Let me decide as I go |\n\nIf \"Commit after each step\" is selected, after a step's manual verification passes, create a commit: `[step-N] <step name>`.\n\n### 3. Orchestration Mode (only if the `Workflow` tool is available)\n\n| Question | Options |\n|----------|---------|\n| \"Run the DAG waves as Workflow scripts? (deterministic scheduling, parallel steps as agent() calls)\" | 1. Yes — Workflow waves, 2. No — Agent fan-out (Default) |\n\nA \"yes\" is the explicit opt-in the Workflow tool requires. If opted in, each wave of the scheduler loop below runs as one Workflow script — a `parallel()` of `agent()` calls, one per ready step, with `model`/`effort` per `desplega:delegate-work`. Everything else is unchanged: step agents still follow the `step-running` contract (atomic frontmatter claim, three-bucket verification), and autonomy-mode pause points sit **between** Workflow invocations, never inside one. In Autopilot these questions are skipped, so there is no opt-in — use Agent fan-out unless the user pre-authorized workflows.\n\n### 4. Code Review Mode\n\n| Question | Options |\n|----------|---------|\n| \"Run an automatic code review after each wave?\" | 1. Automatic two-axis review per wave (Recommended), 2. Only at the end (single review after the DAG drains), 3. Off — I'll review myself |\n\nIn **Autopilot**, skip the question and default to automatic per-wave review.\n\n## Getting Started\n\nGiven a plan directory path:\n\n1. **Read `root.md` fully** (no `limit`/`offset`). Capture: Overview, Current State, Desired End State, Implementation Approach, Global Verification.\n2. **Read every `step-<n>.md`'s frontmatter** to build the dependency graph (`id`, `depends_on`). You don't need to read step bodies up front — the sub-agents will do that.\n3. **Validate the DAG:**\n   - No cycles\n   - Every `depends_on` ID exists as a step file\n   - At least one step has `depends_on: []` (otherwise nothing can start)\n4. **Set `root.md` frontmatter `status: in-progress`.**\n5. **Build a TodoWrite list** with one entry per step, marked `pending`.\n6. **Resume support:** if any step's body has `- [x]` boxes already (or its frontmatter says `status: completed` if the user added it), trust them and treat that step as `done`.\n\nIf no path given, ask via AskUserQuestion.\n\n## The Scheduler Loop\n\nThe scheduler reads each step's frontmatter `status` (`ready` | `claimed` | `done`) and `depends_on`. The frontmatter `status` field is the **single source of truth** — multiple orchestrator instances on the same plan dir coordinate through it (each `desplega:step-running` sub-agent atomically claims its step before doing work).\n\n```\nwhile any step has status != done:\n    ready = [step for step in steps\n             if step.status == \"ready\"\n             and all(dep.status == \"done\" for dep in step.depends_on)]\n    if not ready:\n        # DAG drained, OR every remaining undone step is claimed by another worker\n        if any step has status == claimed: wait for in-flight claims to resolve\n        else: report stuck (likely cycle or unrecoverable failure)\n        continue\n    fan out each step in `ready` as a parallel `desplega:step-running` sub-agent\n    wait for the wave to complete\n    review reports; step-running has already updated frontmatter\n        (status: done on success, status: ready on retry-able failure, status: claimed if held for investigation)\n    if Critical mode: pause for manual verification of newly-completed steps\n    if any failed: stop and ask user how to proceed\n```\n\n### Spawning a Step Sub-agent\n\nUse the `Agent` tool with `run_in_background: true`, invoking `desplega:step-running`. Pass:\n\n- **Step path**: full path to `step-<n>.md`\n- **Plan dir**: full path to the parent plan directory\n- **Agent ID**: unique ID for this sub-agent (e.g. orchestrator session ID + step ID + timestamp). step-running uses this for atomic claim + stale-claim detection.\n- **Plan-level context** (optional): a quick brief from `root.md`. step-running re-reads `root.md` itself, so this is just to reduce round-trips.\n\n`step-running` owns:\n- Atomic claim (rewrite frontmatter `status: ready` → `status: claimed, assignee: <agent-id>, claimed_at: <ts>`)\n- Three-bucket verification (Automated Verification, Automated QA, QA Doc identification)\n- Terminal status transition (`status: done` on success, `status: ready` on retry-able failure)\n- Reporting back\n\nThe orchestrator does NOT do step work itself — it delegates. See `desplega:step-running` for the full sub-agent contract.\n\n**Executor routing**: if the `desplega:delegate-work` skill is available, pick each step's executor per its routing matrix instead of defaulting to a `step-running` sub-agent — a step may route to a Codex variant (one worktree per parallel slice) or a specific Claude model tier. Only the executor choice changes; the scheduler, frontmatter claim protocol, and all other semantics here stay unchanged. When a step routes to Codex, the orchestrator owns the frontmatter bookkeeping that `step-running` would normally do (Codex must not edit plan files).\n\n### Wave Completion\n\nWhen a wave finishes:\n1. **Review each agent's report.** Mark steps `done` only if `completed` was reported.\n2. **Run the wave code review** (unless review mode is Off) — invoke `desplega:code-reviewing` on the wave's combined diff: Standards + Spec axes as parallel background sub-agents (routed per `desplega:delegate-work`), spec source = the completed steps' bodies and Success Criteria. Critical findings block those steps' commits — fix and re-verify first. If \"Only at the end\" was selected, run one review over the full diff after the DAG drains instead.\n3. **Handle `QA Doc: <path>`** — for each step that reported a QA doc, invoke `desplega:qa` against that path. The Automated QA bucket inside the step is already handled by the sub-agent; only the linked doc needs separate orchestration here. (`QA: n/a` → proceed normally.)\n4. **Manual verification (if not Autopilot)** — present manual verification items from each completed step's body. Wait for user confirmation. Don't tick manual boxes until confirmed.\n5. **Commits (if commit-per-step was selected)** — after a step's manual verification passes, create a commit: `[step-N] <step name>`.\n6. **Loop** — recompute `ready` and start the next wave.\n\n## Handling Failures and Mismatches\n\nIf a sub-agent reports `failed` or `blocked`, or you spot a mismatch between plan and reality:\n\n| Question | Options |\n|----------|---------|\n| \"[step-N] [issue]. How should I proceed?\" | 1. Adapt step (edit step-N.md and retry), 2. Retry as-is, 3. Skip and continue (mark step blocked), 4. Stop the run |\n\nIn Autopilot mode, use best judgment, document the decision in the step file, and continue if non-fatal.\n\n## After the DAG Drains\n\nWhen every step is `done`:\n\n1. Run **Global Verification** from `root.md`. Tick automated checks; surface manual checks to the user.\n2. Set `root.md` frontmatter `status: completed`.\n3. Offer post-implementation auditing: \"Would you like me to run `/verify-plan` and `/review` on the plan directory?\"\n4. If commit-per-step was off, offer to create a single bundled commit now.\n5. If the work ships as a GitHub PR: once review comments land, address them with `desplega:tackle-gh-comments` (fetch threads, verify each claim, fix, reply, resolve — push last).\n\n## Important Guidelines\n\n1. **One step = one sub-agent.** Don't bundle steps into a single agent even if they're in the same wave — fan-out is the whole point.\n2. **Plan-level context goes to every sub-agent.** Sibling step bodies do not.\n3. **The DAG is canonical via step frontmatter** — if `root.md`'s table is out of sync, trust the frontmatter.\n4. **Resume works step-granular.** If the user re-runs `/v-implement` mid-DAG, completed steps stay completed; only undone ones rerun.\n5. **Don't tick manual checkboxes** until the user confirms — automated boxes can be ticked by the sub-agent or the orchestrator.\n\n## Review Integration\n\nIf `file-review` is available and the user opted in:\n- After each step's significant code changes, invoke `/file-review:file-review <changed-file>`.\n- Process feedback with `file-review:process-review` before treating the step as done.\n- Skip in Autopilot.\n";
+var content_default44 = "# v-implementing\n\nYou are implementing an approved DAG-structured plan produced by `v-planning`. The plan is a directory with `root.md` + one `step-<n>.md` per node. Your job is to act as a **topological scheduler**: at each tick, find steps whose dependencies are all done, fan them out as parallel sub-agents (one per ready step), wait, repeat — until the DAG is drained. Then run Global Verification.\n\nThis is the parallel sibling of `implementing`. The orchestration model is the same (sub-agents do the work, main session coordinates), only the scheduler is different.\n\n## Working Agreement\n\n**All user-facing questions go through `AskUserQuestion`** — see `desplega:ask-user` for conventions. Never ask in chat as plain bullets.\n\n**All read/research/validation work goes through sub-agents** — keep raw tool output out of the main session. Default to `run_in_background: true`. The fan-out scheduler below is built on this.\n\nThe autonomy mode (below) controls how often you check in. AskUserQuestion is always the mechanism.\n\nFile-review is on by default — when significant changes land in a step (or wave), invoke `/file-review:file-review <path>` for inline feedback (skip only if Autopilot).\n\n## Autonomy Mode\n\n| Mode | Behavior |\n|------|----------|\n| **Autopilot** | Drain the DAG without pausing. Only stop on blocker / failed step. |\n| **Critical** (Default) | Pause when each *wave* of parallel steps completes; wait for manual verification before unlocking the next wave. |\n| **Verbose** | Pause after each individual step (even within a wave). |\n\n## Initial Setup Questions\n\nAfter understanding the plan and before the scheduler loop starts, gather implementation-specific details (skip in Autopilot):\n\n### 1. Branch / Worktree Setup\n\nCheck the current branch: `git branch --show-current`. Then check if the `wts` plugin is installed (look for `wts:wts` in available skills).\n\n**If wts is installed**, use **AskUserQuestion**:\n\n| Question | Options |\n|----------|---------|\n| \"You're on `<current-branch>`. Where would you like to implement?\" | 1. Continue on current branch, 2. Create a new branch, 3. Create a wts worktree |\n\n**If wts is not installed**, drop the worktree option.\n\n### 2. Commit Strategy\n\nUse **AskUserQuestion**:\n\n| Question | Options |\n|----------|---------|\n| \"How would you like to handle commits during parallel implementation?\" | 1. Commit after each step completes (Recommended), 2. Commit at the end (single commit), 3. Let me decide as I go |\n\nIf \"Commit after each step\" is selected, after a step's manual verification passes, create a commit: `[step-N] <step name>`.\n\n### 3. Orchestration Mode (only if the `Workflow` tool is available)\n\n| Question | Options |\n|----------|---------|\n| \"Run the DAG waves as Workflow scripts? (deterministic scheduling, parallel steps as agent() calls)\" | 1. Yes — Workflow waves, 2. No — Agent fan-out (Default) |\n\nA \"yes\" is the explicit opt-in the Workflow tool requires. If opted in, each wave of the scheduler loop below runs as one Workflow script — a `parallel()` of `agent()` calls, one per ready step, with `model`/`effort` per `desplega:delegate-work`. Everything else is unchanged: step agents still follow the `step-running` contract (atomic frontmatter claim, three-bucket verification), and autonomy-mode pause points sit **between** Workflow invocations, never inside one. In Autopilot these questions are skipped, so there is no opt-in — use Agent fan-out unless the user pre-authorized workflows.\n\n### 4. Code Review Mode\n\n| Question | Options |\n|----------|---------|\n| \"Run an automatic code review after each wave?\" | 1. Automatic two-axis review per wave (Recommended), 2. Only at the end (single review after the DAG drains), 3. Off — I'll review myself |\n\nIn **Autopilot**, skip the question and default to automatic per-wave review.\n\n## Getting Started\n\nGiven a plan directory path:\n\n1. **Read `root.md` fully** (no `limit`/`offset`). Capture: Overview, Current State, Desired End State, Implementation Approach, Global Verification.\n2. **Read every `step-<n>.md`'s frontmatter** to build the dependency graph (`id`, `depends_on`). You don't need to read step bodies up front — the sub-agents will do that.\n3. **Validate the DAG:**\n   - No cycles\n   - Every `depends_on` ID exists as a step file\n   - At least one step has `depends_on: []` (otherwise nothing can start)\n4. **Set `root.md` frontmatter `status: in-progress`.**\n5. **Build a TodoWrite list** with one entry per step, marked `pending`.\n6. **Resume support:** if any step's body has `- [x]` boxes already (or its frontmatter says `status: completed` if the user added it), trust them and treat that step as `done`.\n\nIf no path given, ask via AskUserQuestion.\n\n## The Scheduler Loop\n\nThe scheduler reads each step's frontmatter `status` (`ready` | `claimed` | `done`) and `depends_on`. The frontmatter `status` field is the **single source of truth** — multiple orchestrator instances on the same plan dir coordinate through it (each `desplega:step-running` sub-agent atomically claims its step before doing work).\n\n```\nwhile any step has status != done:\n    ready = [step for step in steps\n             if step.status == \"ready\"\n             and all(dep.status == \"done\" for dep in step.depends_on)]\n    if not ready:\n        # DAG drained, OR every remaining undone step is claimed by another worker\n        if any step has status == claimed: wait for in-flight claims to resolve\n        else: report stuck (likely cycle or unrecoverable failure)\n        continue\n    fan out each step in `ready` as a parallel `desplega:step-running` sub-agent\n    wait for the wave to complete\n    review reports; step-running has already updated frontmatter\n        (status: done on success, status: ready on retry-able failure, status: claimed if held for investigation)\n    if Critical mode: pause for manual verification of newly-completed steps\n    if any failed: stop and ask user how to proceed\n```\n\n### Spawning a Step Sub-agent\n\nUse the `Agent` tool with `run_in_background: true`, invoking `desplega:step-running`. Pass:\n\n- **Step path**: full path to `step-<n>.md`\n- **Plan dir**: full path to the parent plan directory\n- **Agent ID**: unique ID for this sub-agent (e.g. orchestrator session ID + step ID + timestamp). step-running uses this for atomic claim + stale-claim detection.\n- **Plan-level context** (optional): a quick brief from `root.md`. step-running re-reads `root.md` itself, so this is just to reduce round-trips.\n\n`step-running` owns:\n- Atomic claim (rewrite frontmatter `status: ready` → `status: claimed, assignee: <agent-id>, claimed_at: <ts>`)\n- Three-bucket verification (Automated Verification, Automated QA, QA Doc identification)\n- Terminal status transition (`status: done` on success, `status: ready` on retry-able failure)\n- Reporting back\n\nThe orchestrator does NOT do step work itself — it delegates. See `desplega:step-running` for the full sub-agent contract.\n\n**Executor routing**: if the `desplega:delegate-work` skill is available, pick each step's executor per its routing matrix instead of defaulting to a `step-running` sub-agent — a step may route to a Codex variant (one worktree per parallel slice) or a specific Claude model tier. Only the executor choice changes; the scheduler, frontmatter claim protocol, and all other semantics here stay unchanged. When a step routes to Codex, the orchestrator owns the frontmatter bookkeeping that `step-running` would normally do (Codex must not edit plan files).\n\n### Wave Completion\n\nWhen a wave finishes:\n1. **Review each agent's report.** Mark steps `done` only if `completed` was reported.\n2. **Run the wave code review** (unless review mode is Off) — invoke `desplega:code-reviewing` on the wave's combined diff: Standards + Spec axes as parallel background sub-agents (routed per `desplega:delegate-work`), spec source = the completed steps' bodies and Success Criteria. Critical findings block those steps' commits — fix and re-verify first. If \"Only at the end\" was selected, run one review over the full diff after the DAG drains instead.\n3. **Handle `QA Doc: <path>`** — for each step that reported a QA doc, invoke `desplega:qa` against that path. The Automated QA bucket inside the step is already handled by the sub-agent; only the linked doc needs separate orchestration here. (`QA: n/a` → proceed normally.)\n4. **Manual verification (if not Autopilot)** — present manual verification items from each completed step's body. Wait for user confirmation. Don't tick manual boxes until confirmed.\n5. **Commits (if commit-per-step was selected)** — after a step's manual verification passes, create a commit: `[step-N] <step name>`.\n6. **Loop** — recompute `ready` and start the next wave.\n\n## Handling Failures and Mismatches\n\nIf a sub-agent reports `failed` or `blocked`, or you spot a mismatch between plan and reality:\n\n| Question | Options |\n|----------|---------|\n| \"[step-N] [issue]. How should I proceed?\" | 1. Adapt step (edit step-N.md and retry), 2. Retry as-is, 3. Skip and continue (mark step blocked), 4. Stop the run |\n\nIn Autopilot mode, use best judgment, document the decision in the step file, and continue if non-fatal.\n\n## After the DAG Drains\n\nWhen every step is `done`:\n\n1. Run **Global Verification** from `root.md`. Tick automated checks; surface manual checks to the user.\n2. Set `root.md` frontmatter `status: completed`.\n3. Offer post-implementation auditing: \"Would you like me to run `/verify-plan` and `/review` on the plan directory?\"\n4. If commit-per-step was off, offer to create a single bundled commit now.\n5. If the work ships as a GitHub PR: once review comments land, address them with `desplega:tackle-gh-comments` (fetch threads, verify each claim, fix, reply, resolve — push last).\n\n## Important Guidelines\n\n1. **One step = one sub-agent.** Don't bundle steps into a single agent even if they're in the same wave — fan-out is the whole point.\n2. **Plan-level context goes to every sub-agent.** Sibling step bodies do not.\n3. **The DAG is canonical via step frontmatter** — if `root.md`'s table is out of sync, trust the frontmatter.\n4. **Resume works step-granular.** If the user re-runs `/v-implement` mid-DAG, completed steps stay completed; only undone ones rerun.\n5. **Don't tick manual checkboxes** until the user confirms — automated boxes can be ticked by the sub-agent or the orchestrator.\n\n## Review Integration\n\nIf `file-review` is available and the user opted in:\n- After each step's significant code changes, invoke `/file-review:file-review <changed-file>`.\n- Process feedback with `file-review:process-review` before treating the step as done.\n- Skip in Autopilot.\n";
 
 // templates/skills/v-planning/config.json
-var config_default44 = `{
+var config_default45 = `{
   "category": "skills",
   "description": "Vertical / parallel implementation planning skill. Creates DAG-structured plan directories where each step is an independent, QA-able vertical slice that sub-agents can pick up and implement in parallel. Use whenever the user wants a plan that fans out (multiple independent features), invokes /v-plan, or asks for a \\"parallel plan\\", \\"DAG plan\\", \\"vertical plan\\", or \\"plan that can be parallelized\\" — even if they don't say those exact words. Prefer the linear \`planning\` skill for strictly sequential work.",
   "displayName": "V-Planning",
@@ -10914,7 +11171,7 @@ var config_default44 = `{
 `;
 
 // templates/skills/v-planning/content.md
-var content_default44 = `# v-planning
+var content_default45 = `# v-planning
 
 You create implementation plans as a **DAG of vertical steps** — each step a complete, QA-able slice of value (DB + API + UI + tests for one feature). The DAG captures feature-level dependencies, so independent steps can be implemented in parallel by sub-agents.
 
@@ -11005,7 +11262,7 @@ Structure validation runs automatically (rule 9, Haiku sub-agent).
 `;
 
 // templates/skills/verifying/config.json
-var config_default45 = `{
+var config_default46 = `{
   "category": "skills",
   "description": "Post-implementation plan verification. Cross-references plans against actual changes for completeness and accuracy.",
   "displayName": "Verifying",
@@ -11026,7 +11283,7 @@ var config_default45 = `{
 `;
 
 // templates/skills/verifying/content.md
-var content_default45 = `# Verifying
+var content_default46 = `# Verifying
 
 You are performing a post-implementation audit of a plan, cross-referencing it against actual changes to ensure nothing was missed, nothing is stale, and the implementation matches what was planned.
 
@@ -11173,8 +11430,28 @@ File-review is on by default (unless Autopilot):
 - Process feedback with the \`file-review:process-review\` skill
 `;
 
+// templates/skills/work-on-task/config.json
+var config_default47 = `{
+  "kind": "skill",
+  "name": "work-on-task",
+  "displayName": "Work On Task",
+  "slug": "work-on-task",
+  "title": "Work On Task",
+  "description": "Turn prompt for an assigned swarm task: find the task, gather context when the message lacks it, use the skill the task names, finish with one of the four endings.",
+  "version": "1.0.0",
+  "category": "skills",
+  "placeholders": [],
+  "runAllSeedersCandidate": true,
+  "systemDefault": true,
+  "tags": ["tasks", "turn-prompt", "worker"]
+}
+`;
+
+// templates/skills/work-on-task/content.md
+var content_default47 = "# Working on a task\n\nThe taskId follows the command. Without one, call `get-tasks` with `mineOnly: true` and take your `pending` or `in_progress` task. If there is none, say so and stop.\n\nThis message carries the task text, its attachments, its output format, and memories from past sessions. If it does not (you invoked this command yourself, or the context was compacted), run the `task-context-gathering` script with the taskId.\n\nWhen the task names a skill (`researching`, `planning`, `implementing`), use it. Otherwise work directly.\n\nFinish the task with one of the four endings in your operating contract: `completed`, `defer-task`, `request-human-input`, or `failed`. Then stop.\n\nIf the user interrupts, follow their instructions. To resume, call `/work-on-task <taskId>` again.\n";
+
 // templates/skills/workflow-iterate/config.json
-var config_default46 = `{
+var config_default48 = `{
   "kind": "skill",
   "name": "workflow-iterate",
   "displayName": "Workflow Iteration",
@@ -11196,7 +11473,7 @@ var config_default46 = `{
 `;
 
 // templates/skills/workflow-iterate/content.md
-var content_default46 = `# Workflow Iteration
+var content_default48 = `# Workflow Iteration
 
 Use this skill when you need to change an existing workflow without breaking live runs. The goal is to make small, verified revisions: inspect the current workflow, diagnose the failing step, patch only the required node or edge, trigger a realistic run, and keep iterating until the run reaches the intended terminal state.
 
@@ -11338,7 +11615,7 @@ Use these shapes as a starting point, then confirm them against the current exec
 `;
 
 // templates/skills/workflow-structured-output/config.json
-var config_default47 = `{
+var config_default49 = `{
   "kind": "skill",
   "name": "workflow-structured-output",
   "displayName": "Workflow Structured Output",
@@ -11355,10 +11632,10 @@ var config_default47 = `{
 `;
 
 // templates/skills/workflow-structured-output/content.md
-var content_default47 = '# Workflow Structured Output\n\n> **Companion skill — `workflow-iterate` (author-side).** This skill is for *workers* assigned a task spawned by an `agent-task` workflow node with an `outputSchema`. The author-side counterpart `workflow-iterate` covers how the workflow defines that schema, why gates downstream depend on it, and how to debug failed runs. If you ever need to understand *why* a particular schema is shaped the way it is — or you\'re switching from worker to author mode — read `workflow-iterate`.\n\n## Failure reason → fix (read this first)\n\nIf you see this failure reason on a task, the fix is always the same:\n\n| failureReason contains | What it means | Fix |\n|---|---|---|\n| `Task has an outputSchema but no output was provided` | You called `store-progress` without an `output` when the task required a JSON object matching `outputSchema` | Re-call `store-progress` with `status: "completed"` and `output` = a **stringified JSON** matching the schema exactly |\n| `Task output must be valid JSON` / `Task output does not match the outputSchema` | You passed invalid JSON, omitted required fields, or used the wrong types | Re-read the schema, include every `required` field with the exact key names, re-call `store-progress` |\n\n**You can re-call `store-progress` even after a rejection.** Your prior progress updates do not count as the final output. Fix the JSON and try again.\n\n## Pre-flight checklist (run through before calling store-progress)\n\n1. **Do the task details contain an actual `outputSchema`?** If yes, runtime\n   enforcement is active: continue with that exact schema.\n2. **If there is no `outputSchema`, does the user provide an explicit JSON Output\n   Format or interface?** Honor it as the requested output contract even though\n   the runner is not enforcing an `outputSchema`.\n3. **Are workflow origin or tags such as `deterministic`, `litmus`, `validation`,\n   or `context` the only signals?** They are heuristics only. Re-read the task\n   details for an actual schema or explicit format. If neither exists, do not\n   invent one; plain-text output is allowed.\n4. **Can I quote the exact required shape from the task details?** Use its exact\n   keys and types, with every required field and no guessed renames.\n5. **Is my `output` a string (stringified JSON), not an object?** For a structured\n   contract, `store-progress.output` should be a JSON string.\n6. **Only after the applicable contract is clear:** call `store-progress` with\n   `status: "completed"` and the stringified JSON, or use plain text when no\n   structured contract exists.\n\nIf the required shape is unclear, re-read the task details. Never synthesize a\nschema from tags or workflow origin.\n\n## Why this exists\n\nWhen a task has an actual `outputSchema`, the runner validates\n`store-progress.output` against it and rejects missing output, invalid JSON, or\nschema mismatches with one of the current messages listed above. A JSON Output\nFormat or interface without `task.outputSchema` remains a user instruction, but\nit is not the same runtime enforcement mechanism. Missing the distinction can\nturn completed work into a rejected terminal update, so check the task contract\nbefore reporting completion.\n\n## How to spot a structured-output task\n\nTreat these signals differently:\n\n- An actual `task.outputSchema` means JSON is runtime-enforced.\n- An explicit "Output Format", "Return a JSON object", or TypeScript/JSON\n  interface is a user contract to return that shape, even without runtime\n  enforcement.\n- Tags such as `deterministic`, `litmus`, `validation`, `releases`, or `context`,\n  and `source = workflow`, only tell you to inspect the task details carefully.\n  They do not prove a schema exists.\n\nWhen in doubt, re-read the task details and its `outputSchema`. Do not invent a\nschema or required fields.\n\n## How to complete correctly\n\n1. **Build the JSON object** that matches the actual `outputSchema` or explicit\n   user-provided JSON format. Include every required field and use the exact key\n   names from that contract.\n2. **Stringify it** — `store-progress.output` must be a string, not an object. Use `JSON.stringify(obj)` in your head.\n3. **Call store-progress** with `status: "completed"` and that JSON string as `output`.\n\n### Example — skip case\n\nTask has schema `{skip: bool, reason?: str, contextPath?: str, ...}` and you\'re skipping because the release already exists:\n\n```\nstore-progress(\n  taskId,\n  status="completed",\n  output=\'{"skip":true,"reason":"Release already exists for this week"}\'\n)\n```\n\n### Example — full run\n\n```\nstore-progress(\n  taskId,\n  status="completed",\n  output=\'{"skip":false,"contextPath":"release-runs/2026-04-20/context.json","commitCount":42,"repos":["example-repo"],"repoPatternsSource":"cache","dateRange":"2026-04-13 to 2026-04-20"}\'\n)\n```\n\n### Example — litmus / validation verdict\n\n```\nstore-progress(\n  taskId,\n  status="completed",\n  output=\'{"verdict":"publish","reason":"5 user-facing changes; threshold met"}\'\n)\n```\n\n## Anti-patterns for an `outputSchema` task\n\n- `output: "Done. Context written to agent-fs at release-runs/2026-04-20/context.json"`\n- `output: "Published release notes for week of 2026-04-20"`\n- `output: "Verdict: publish"`\n- Calling `store-progress` with `status: "completed"` and no `output` at all\n- JSON that\'s missing any `required` field from the schema\n- JSON with extra keys instead of the schema\'s exact keys\n\n## Recovery if you realize mid-task\n\nIf you\'ve done all the work but forgot the JSON contract, just call `store-progress` again with the correct JSON string in `output`. Your prior progress updates don\'t count as the final output.\n\n## Verify before completing\n\nRead your task description once more. Find the schema. Build the JSON. Then complete. Takes 30 seconds. Saves a workflow re-run.\n\n## See also\n\n- **`workflow-iterate`** — the author-side counterpart of this skill. Read it if you\'re editing the workflow that produced this task, or want to understand why this particular schema is shaped the way it is (which gates downstream depend on it, etc.).\n';
+var content_default49 = '# Workflow Structured Output\n\n> **Companion skill — `workflow-iterate` (author-side).** This skill is for *workers* assigned a task spawned by an `agent-task` workflow node with an `outputSchema`. The author-side counterpart `workflow-iterate` covers how the workflow defines that schema, why gates downstream depend on it, and how to debug failed runs. If you ever need to understand *why* a particular schema is shaped the way it is — or you\'re switching from worker to author mode — read `workflow-iterate`.\n\n## Failure reason → fix (read this first)\n\nIf you see this failure reason on a task, the fix is always the same:\n\n| failureReason contains | What it means | Fix |\n|---|---|---|\n| `Task has an outputSchema but no output was provided` | You called `store-progress` without an `output` when the task required a JSON object matching `outputSchema` | Re-call `store-progress` with `status: "completed"` and `output` = a **stringified JSON** matching the schema exactly |\n| `Task output must be valid JSON` / `Task output does not match the outputSchema` | You passed invalid JSON, omitted required fields, or used the wrong types | Re-read the schema, include every `required` field with the exact key names, re-call `store-progress` |\n\n**You can re-call `store-progress` even after a rejection.** Your prior progress updates do not count as the final output. Fix the JSON and try again.\n\n## Pre-flight checklist (run through before calling store-progress)\n\n1. **Do the task details contain an actual `outputSchema`?** If yes, runtime\n   enforcement is active: continue with that exact schema.\n2. **If there is no `outputSchema`, does the user provide an explicit JSON Output\n   Format or interface?** Honor it as the requested output contract even though\n   the runner is not enforcing an `outputSchema`.\n3. **Are workflow origin or tags such as `deterministic`, `litmus`, `validation`,\n   or `context` the only signals?** They are heuristics only. Re-read the task\n   details for an actual schema or explicit format. If neither exists, do not\n   invent one; plain-text output is allowed.\n4. **Can I quote the exact required shape from the task details?** Use its exact\n   keys and types, with every required field and no guessed renames.\n5. **Is my `output` a string (stringified JSON), not an object?** For a structured\n   contract, `store-progress.output` should be a JSON string.\n6. **Only after the applicable contract is clear:** call `store-progress` with\n   `status: "completed"` and the stringified JSON, or use plain text when no\n   structured contract exists.\n\nIf the required shape is unclear, re-read the task details. Never synthesize a\nschema from tags or workflow origin.\n\n## Why this exists\n\nWhen a task has an actual `outputSchema`, the runner validates\n`store-progress.output` against it and rejects missing output, invalid JSON, or\nschema mismatches with one of the current messages listed above. A JSON Output\nFormat or interface without `task.outputSchema` remains a user instruction, but\nit is not the same runtime enforcement mechanism. Missing the distinction can\nturn completed work into a rejected terminal update, so check the task contract\nbefore reporting completion.\n\n## How to spot a structured-output task\n\nTreat these signals differently:\n\n- An actual `task.outputSchema` means JSON is runtime-enforced.\n- An explicit "Output Format", "Return a JSON object", or TypeScript/JSON\n  interface is a user contract to return that shape, even without runtime\n  enforcement.\n- Tags such as `deterministic`, `litmus`, `validation`, `releases`, or `context`,\n  and `source = workflow`, only tell you to inspect the task details carefully.\n  They do not prove a schema exists.\n\nWhen in doubt, re-read the task details and its `outputSchema`. Do not invent a\nschema or required fields.\n\n## How to complete correctly\n\n1. **Build the JSON object** that matches the actual `outputSchema` or explicit\n   user-provided JSON format. Include every required field and use the exact key\n   names from that contract.\n2. **Stringify it** — `store-progress.output` must be a string, not an object. Use `JSON.stringify(obj)` in your head.\n3. **Call store-progress** with `status: "completed"` and that JSON string as `output`.\n\n### Example — skip case\n\nTask has schema `{skip: bool, reason?: str, contextPath?: str, ...}` and you\'re skipping because the release already exists:\n\n```\nstore-progress(\n  taskId,\n  status="completed",\n  output=\'{"skip":true,"reason":"Release already exists for this week"}\'\n)\n```\n\n### Example — full run\n\n```\nstore-progress(\n  taskId,\n  status="completed",\n  output=\'{"skip":false,"contextPath":"release-runs/2026-04-20/context.json","commitCount":42,"repos":["example-repo"],"repoPatternsSource":"cache","dateRange":"2026-04-13 to 2026-04-20"}\'\n)\n```\n\n### Example — litmus / validation verdict\n\n```\nstore-progress(\n  taskId,\n  status="completed",\n  output=\'{"verdict":"publish","reason":"5 user-facing changes; threshold met"}\'\n)\n```\n\n## Anti-patterns for an `outputSchema` task\n\n- `output: "Done. Context written to agent-fs at release-runs/2026-04-20/context.json"`\n- `output: "Published release notes for week of 2026-04-20"`\n- `output: "Verdict: publish"`\n- Calling `store-progress` with `status: "completed"` and no `output` at all\n- JSON that\'s missing any `required` field from the schema\n- JSON with extra keys instead of the schema\'s exact keys\n\n## Recovery if you realize mid-task\n\nIf you\'ve done all the work but forgot the JSON contract, just call `store-progress` again with the correct JSON string in `output`. Your prior progress updates don\'t count as the final output.\n\n## Verify before completing\n\nRead your task description once more. Find the schema. Build the JSON. Then complete. Takes 30 seconds. Saves a workflow re-run.\n\n## See also\n\n- **`workflow-iterate`** — the author-side counterpart of this skill. Read it if you\'re editing the workflow that produced this task, or want to understand why this particular schema is shaped the way it is (which gates downstream depend on it, etc.).\n';
 
 // templates/skills/wts-expert/config.json
-var config_default48 = `{
+var config_default50 = `{
   "category": "skills",
   "description": "Git worktree management expert for @desplega.ai/wts. Use when the user asks about git worktrees, wts commands, worktree workflows, or wants help managing multiple branches simultaneously.",
   "displayName": "WTS Expert",
@@ -11379,7 +11656,7 @@ var config_default48 = `{
 `;
 
 // templates/skills/wts-expert/content.md
-var content_default48 = `# WTS Expert
+var content_default50 = `# WTS Expert
 
 You are an expert on \`@desplega.ai/wts\`, a CLI tool for managing Git worktrees with tmux integration, Claude Code launcher support, and GitHub PR creation.
 
@@ -13947,24 +14224,6 @@ wts cleanup --unmerged      # Include unmerged worktrees
   ]
 };
 
-// src/be/seed-skills/render.ts
-var YAML_IMPLICIT_NON_STRING = /^(?:~|null|true|false|yes|no|on|off|[-+]?(?:0b[01_]+|0o[0-7_]+|0x[0-9a-f_]+|[0-9][0-9_]*(?:\.[0-9_]*)?(?:e[-+]?[0-9]+)?|\.[0-9][0-9_]*(?:e[-+]?[0-9]+)?)|[-+]?\.(?:inf|nan)|[0-9]{4}-[0-9]{1,2}-[0-9]{1,2}(?:[t ].*)?)$/i;
-function yamlScalar(value) {
-  const unsafe = value === "" || /(: )|(:$)|( #)|[\n\t]|^[\s\-?:,[\]{}#&*!|>'"%@`]|\s$/.test(value) || YAML_IMPLICIT_NON_STRING.test(value);
-  return unsafe ? JSON.stringify(value) : value;
-}
-function buildSkillContent(config, body) {
-  const userInvocable = config.userInvocable === false ? `
-user-invocable: false` : "";
-  return `---
-name: ${config.name}
-description: ${yamlScalar(config.description)}${userInvocable}
----
-
-${body.trim()}
-`;
-}
-
 // src/be/seed-skills/index.ts
 var BUILT_IN_SKILL_FILES = bundled_files_generated_default;
 var BUILT_IN_SKILL_SOURCES = [
@@ -14015,7 +14274,9 @@ var BUILT_IN_SKILL_SOURCES = [
   { config: config_default45, body: content_default45 },
   { config: config_default46, body: content_default46 },
   { config: config_default47, body: content_default47 },
-  { config: config_default48, body: content_default48 }
+  { config: config_default48, body: content_default48 },
+  { config: config_default49, body: content_default49 },
+  { config: config_default50, body: content_default50 }
 ];
 function canonicalFiles(files) {
   return [...files].sort((a, b) => a.path.localeCompare(b.path)).map((file) => `${file.path}
@@ -14233,7 +14494,7 @@ async function runSeeders(seeders, opts) {
 var import_cron_parser = __toESM(require_dist(), 1);
 
 // templates/schedules/daily-blocker-digest/config.json
-var config_default49 = `{
+var config_default51 = `{
   "kind": "schedule",
   "name": "daily-blocker-digest",
   "displayName": "Daily Blocker Digest",
@@ -14250,7 +14511,7 @@ var config_default49 = `{
 `;
 
 // templates/schedules/daily-blocker-digest/content.md
-var content_default49 = `# Daily Blocker Digest
+var content_default51 = `# Daily Blocker Digest
 
 Delivery uses configured admin channels with an in-app fallback.
 
@@ -14420,7 +14681,7 @@ Call \`store-progress\` with status \`completed\` and an output paragraph coveri
 `;
 
 // templates/schedules/daily-compounding-reflection/config.json
-var config_default50 = `{
+var config_default52 = `{
   "kind": "schedule",
   "name": "daily-compounding-reflection",
   "displayName": "Daily Evolution",
@@ -14442,7 +14703,7 @@ var config_default50 = `{
 `;
 
 // templates/schedules/daily-compounding-reflection/content.md
-var content_default50 = `# Daily Compounding Reflection
+var content_default52 = `# Daily Compounding Reflection
 
 Delivery uses configured admin channels with an in-app fallback.
 
@@ -14667,7 +14928,7 @@ If you have zero changes across all three folds and zero deferred items, somethi
 `;
 
 // templates/schedules/daily-status-report/config.json
-var config_default51 = `{
+var config_default53 = `{
   "kind": "schedule",
   "name": "daily-status-report",
   "displayName": "Daily Status Report",
@@ -14684,7 +14945,7 @@ var config_default51 = `{
 `;
 
 // templates/schedules/daily-status-report/content.md
-var content_default51 = `# Daily Status Report
+var content_default53 = `# Daily Status Report
 
 Give the operator one daily read on whether the swarm is healthy: what's running, what's failed, what's waiting on them.
 
@@ -14767,7 +15028,7 @@ Integration setup: [missing credentials from /status], or all verified.
 `;
 
 // templates/schedules/daily-workflow-health-audit/config.json
-var config_default52 = `{
+var config_default54 = `{
   "kind": "schedule",
   "name": "daily-workflow-health-audit",
   "displayName": "Daily Workflow Health Audit",
@@ -14784,7 +15045,7 @@ var config_default52 = `{
 `;
 
 // templates/schedules/daily-workflow-health-audit/content.md
-var content_default52 = `# Daily Workflow Health Audit
+var content_default54 = `# Daily Workflow Health Audit
 
 Delivery uses configured admin channels with an in-app fallback.
 
@@ -14978,7 +15239,7 @@ Omit any section whose count is 0. Cap message at 4000 chars (Slack limit) — i
 `;
 
 // templates/schedules/gtm-weekly-review/config.json
-var config_default53 = `{
+var config_default55 = `{
   "kind": "schedule",
   "name": "gtm-weekly-review",
   "displayName": "Weekly GTM Metrics Review",
@@ -14995,7 +15256,7 @@ var config_default53 = `{
 `;
 
 // templates/schedules/gtm-weekly-review/content.md
-var content_default53 = `Template parameters: {{REPO_URL}}, {{GSC_PROPERTY}}
+var content_default55 = `Template parameters: {{REPO_URL}}, {{GSC_PROPERTY}}
 
 # Weekly GTM Metrics Review
 
@@ -15076,7 +15337,7 @@ This is part of your team's GTM goal; update the goal statement before enabling
 `;
 
 // templates/schedules/weekly-code-health-reports/config.json
-var config_default54 = `{
+var config_default56 = `{
   "kind": "schedule",
   "name": "weekly-code-health-reports",
   "displayName": "Weekly Code Health Reports",
@@ -15093,7 +15354,7 @@ var config_default54 = `{
 `;
 
 // templates/schedules/weekly-code-health-reports/content.md
-var content_default54 = `# Weekly Code Health Reports
+var content_default56 = `# Weekly Code Health Reports
 
 Template parameters: {{REPO_URL}}, {{BRANCH}}, {{SCOPE_PATH}}, {{REPORT_NAME}}, {{PAGE_ID}}
 
@@ -15158,7 +15419,7 @@ Call \`store-progress\` with status \`completed\` and an output summary that inc
 `;
 
 // templates/schedules/weekly-dependabot-triage/config.json
-var config_default55 = `{
+var config_default57 = `{
   "kind": "schedule",
   "name": "weekly-dependabot-triage",
   "displayName": "Weekly Dependency Triage",
@@ -15175,7 +15436,7 @@ var config_default55 = `{
 `;
 
 // templates/schedules/weekly-dependabot-triage/content.md
-var content_default55 = `# Weekly Dependency Triage
+var content_default57 = `# Weekly Dependency Triage
 
 Template parameters: {{SLACK_CHANNEL_ID}}, {{REPO_URL}}, {{TIMEZONE}}
 
@@ -15229,7 +15490,7 @@ Call \`store-progress\` with status \`completed\` and an output summary listing
 `;
 
 // templates/schedules/weekly-dora-metrics/config.json
-var config_default56 = `{
+var config_default58 = `{
   "kind": "schedule",
   "name": "weekly-dora-metrics",
   "displayName": "Weekly DORA Metrics",
@@ -15246,7 +15507,7 @@ var config_default56 = `{
 `;
 
 // templates/schedules/weekly-dora-metrics/content.md
-var content_default56 = `# Weekly DORA Metrics
+var content_default58 = `# Weekly DORA Metrics
 
 Template parameters: {{REPO_URL}}, {{BRANCH}}, {{TAG_PATTERN}}, {{REPORT_NAME}}, {{PAGE_ID}}
 
@@ -15315,7 +15576,7 @@ Call \`store-progress\` with status \`completed\` and an output summary that inc
 init_db();
 
 // templates/workflows/alerts-triage/config.json
-var config_default57 = `{
+var config_default59 = `{
   "kind": "workflow",
   "name": "alerts-triage",
   "displayName": "Alerts Triage",
@@ -15332,7 +15593,7 @@ var config_default57 = `{
 `;
 
 // templates/workflows/alerts-triage/content.md
-var content_default57 = `# Alerts Triage
+var content_default59 = `# Alerts Triage
 
 The Slack handler emits \`slack.message\`; this workflow keeps the event-driven path and deduplicates work after the channel filter.
 
@@ -15352,7 +15613,7 @@ The Slack handler emits \`slack.message\`; this workflow keeps the event-driven
 `;
 
 // templates/workflows/autopilot/config.json
-var config_default58 = `{
+var config_default60 = `{
   "kind": "workflow",
   "name": "autopilot",
   "displayName": "Autopilot Feature Pipeline",
@@ -15369,7 +15630,7 @@ var config_default58 = `{
 `;
 
 // templates/workflows/autopilot/content.md
-var content_default58 = `# Autopilot Feature Pipeline
+var content_default60 = `# Autopilot Feature Pipeline
 
 Template parameter: {{REPO_URL}}
 
@@ -15381,7 +15642,7 @@ Use this workflow as a canonical feature delivery pipeline. Customize roles and
 `;
 
 // templates/workflows/competitor-radar/config.json
-var config_default59 = `{
+var config_default61 = `{
   "kind": "workflow",
   "name": "competitor-radar",
   "displayName": "Competitor Radar",
@@ -15398,7 +15659,7 @@ var config_default59 = `{
 `;
 
 // templates/workflows/competitor-radar/content.md
-var content_default59 = `# Competitor Radar
+var content_default61 = `# Competitor Radar
 
 This self-hosted port retains the scheduled, fixture, extraction, gap-analysis, litmus, cooldown, and bounded-report behavior. Its pinned GSC helper is embedded in the workflow, so it does not fetch executable code from Desplega infrastructure.
 
@@ -15408,7 +15669,7 @@ This self-hosted port retains the scheduled, fixture, extraction, gap-analysis,
 `;
 
 // templates/workflows/docs-site-releases/config.json
-var config_default60 = `{
+var config_default62 = `{
   "kind": "workflow",
   "name": "docs-site-releases",
   "displayName": "Documentation Release Notes",
@@ -15425,7 +15686,7 @@ var config_default60 = `{
 `;
 
 // templates/workflows/docs-site-releases/content.md
-var content_default60 = `# Documentation Release Notes
+var content_default62 = `# Documentation Release Notes
 
 This topology-preserving self-hosted port removes installation-specific identities, endpoints, and credentials while retaining the live workflow's nodes, edges, input mappings, guards, retries, cooldown, and triggers. Configure the declared template parameters and integrations before enabling it.
 
@@ -15440,7 +15701,7 @@ This topology-preserving self-hosted port removes installation-specific identiti
 `;
 
 // templates/workflows/linear-drain-loop/config.json
-var config_default61 = `{
+var config_default63 = `{
   "kind": "workflow",
   "name": "linear-drain-loop",
   "displayName": "Linear Drain Loop",
@@ -15462,7 +15723,7 @@ var config_default61 = `{
 `;
 
 // templates/workflows/linear-drain-loop/content.md
-var content_default61 = `# Linear Drain Loop
+var content_default63 = `# Linear Drain Loop
 
 Template parameter: {{LINEAR_PROJECT_ID}}
 
@@ -15507,7 +15768,7 @@ Blocked and ambiguous items are explicitly left alone — the dispatch node surf
 `;
 
 // templates/workflows/llm-safe-release-context/config.json
-var config_default62 = `{
+var config_default64 = `{
   "kind": "workflow",
   "name": "llm-safe-release-context",
   "displayName": "LLM-Safe Release Context",
@@ -15524,7 +15785,7 @@ var config_default62 = `{
 `;
 
 // templates/workflows/llm-safe-release-context/content.md
-var content_default62 = `# LLM-Safe Release Context
+var content_default64 = `# LLM-Safe Release Context
 
 Template parameters: {{ORG_ID}}, {{REPO_URL}}
 
@@ -15598,7 +15859,7 @@ This avoids the common failure mode where a large \`context.json\` fills the mod
 `;
 
 // templates/workflows/pr-review-status-sweep/config.json
-var config_default63 = `{
+var config_default65 = `{
   "kind": "workflow",
   "name": "pr-review-status-sweep",
   "displayName": "PR Review Status Sweep",
@@ -15615,7 +15876,7 @@ var config_default63 = `{
 `;
 
 // templates/workflows/pr-review-status-sweep/content.md
-var content_default63 = `# PR Review Status Sweep
+var content_default65 = `# PR Review Status Sweep
 
 This topology-preserving self-hosted port removes installation-specific identities, endpoints, and credentials while retaining the live workflow's nodes, edges, input mappings, guards, retries, cooldown, and triggers. Configure the declared template parameters and integrations before enabling it.
 
@@ -15628,7 +15889,7 @@ This topology-preserving self-hosted port removes installation-specific identiti
 `;
 
 // templates/workflows/ralph-loop/config.json
-var config_default64 = `{
+var config_default66 = `{
   "kind": "workflow",
   "name": "ralph-loop",
   "displayName": "Iterative Review Loop",
@@ -15645,7 +15906,7 @@ var config_default64 = `{
 `;
 
 // templates/workflows/ralph-loop/content.md
-var content_default64 = `# Iterative Review Loop
+var content_default66 = `# Iterative Review Loop
 
 Template parameter: {{REPO_URL}}
 
@@ -15696,14 +15957,14 @@ The \`maxIterations\` parameter is declarative: the reviewer signals PASS when d
 init_db();
 var asText2 = (value) => value;
 var BUILT_IN_WORKFLOW_SOURCES = [
-  { config: asText2(config_default57), content: asText2(content_default57) },
-  { config: asText2(config_default58), content: asText2(content_default58) },
   { config: asText2(config_default59), content: asText2(content_default59) },
   { config: asText2(config_default60), content: asText2(content_default60) },
   { config: asText2(config_default61), content: asText2(content_default61) },
   { config: asText2(config_default62), content: asText2(content_default62) },
   { config: asText2(config_default63), content: asText2(content_default63) },
-  { config: asText2(config_default64), content: asText2(content_default64) }
+  { config: asText2(config_default64), content: asText2(content_default64) },
+  { config: asText2(config_default65), content: asText2(content_default65) },
+  { config: asText2(config_default66), content: asText2(content_default66) }
 ];
 function sortJson(value) {
   if (Array.isArray(value))
@@ -15812,11 +16073,6 @@ var workflowsSeeder = createWorkflowsSeeder();
 // src/be/seed/schedules-seeder.ts
 var asText3 = (value) => value;
 var BUILT_IN_SCHEDULE_SOURCES = [
-  { config: asText3(config_default49), content: asText3(content_default49) },
-  {
-    config: asText3(config_default50),
-    content: asText3(content_default50)
-  },
   { config: asText3(config_default51), content: asText3(content_default51) },
   {
     config: asText3(config_default52),
@@ -15827,11 +16083,16 @@ var BUILT_IN_SCHEDULE_SOURCES = [
     config: asText3(config_default54),
     content: asText3(content_default54)
   },
+  { config: asText3(config_default55), content: asText3(content_default55) },
+  {
+    config: asText3(config_default56),
+    content: asText3(content_default56)
+  },
   {
-    config: asText3(config_default55),
-    content: asText3(content_default55)
+    config: asText3(config_default57),
+    content: asText3(content_default57)
   },
-  { config: asText3(config_default56), content: asText3(content_default56) }
+  { config: asText3(config_default58), content: asText3(content_default58) }
 ];
 function parseScheduleSource(source) {
   const config = JSON.parse(source.config);