@zibby/workflow-templates 0.9.0 → 0.9.2

package/index.js

@@ -387,7 +387,357 @@ export const TEMPLATES = {
         'Post the digest to our #leadership Lark group + #eng Slack channel',
       ],
     },
-  }
+  },
+
+  // ── pipeline-supervisor: Zibby managing Zibby (read + propose + notify) ─
+  'pipeline-supervisor': {
+    name: 'pipeline-supervisor',
+    displayName: 'Pipeline Supervisor',
+    description: 'Zibby managing Zibby — a scheduled supervisor that scans the project\'s other pipelines, flags the ones failing or running slow, and posts human-reviewable improvement proposals (add a test gate / tweak a prompt / add an approval gate / drop a redundant step) to Slack or Lark. Read + propose + notify only; it never edits another workflow.',
+    path: join(__dirname, 'pipeline-supervisor'),
+    defaultSlug: 'pipeline-supervisor',
+    deps: { zod: '^3.23.0', '@zibby/skills': '^0.1.26' },
+    features: [
+      '3-node graph: scan_pipelines → propose_improvements → notify',
+      'Reads other pipelines\' executions via the Zibby REST API (user-PAT authed)',
+      'Per-pipeline health rollup: fail-rate, median duration, worst recent run',
+      'LLM proposes ONE concrete, evidence-backed change per flagged pipeline',
+      'Posts a review card to Slack OR Lark (chat_notify OR-group)',
+      'Read + propose + notify only — never edits another workflow\'s graph (safe L3)',
+      'Cron-friendly: e.g. daily, default lookbackHours=24 / minFailRate=0.4',
+    ],
+    marketplace: {
+      slug: 'pipeline-supervisor',
+      tagline: 'Zibby watching Zibby — find your flaky pipelines and propose the fix.',
+      iconPrompt: [
+        'Hand-painted storybook illustration in a warm gouache style with soft brushwork and gentle painterly texture, featuring a friendly round robot-supervisor mascot character with two big kindly eyes and a rosy blush, wearing a tiny site-foreman hard hat in soft violet (#7553FF), standing on a little mint-green platform and holding a small glowing clipboard with a checkmark.',
+        'In front of the mascot float three small rounded pipeline-segment shapes connected left-to-right like a little assembly line: the first two glow calm green, the third glows a gentle warning amber with a tiny magnifier-free spotlight on it — reinforcing the "watch the pipelines, spot the broken one, suggest a fix" idea WITHOUT any literal magnifying glass.',
+        'Background is a soft sunrise gradient of pale peach at the top blending through buttercream into a wash of dusty lavender at the base, tying the warm scene to the violet hard hat; a few small fluffy pastel clouds float in for friendliness.',
+        'Centered composition with the robot-supervisor as the focal point, the three pipeline segments arrayed below-front; plenty of breathing room so the silhouette reads at 64×64.',
+        'Mood is warm, reassuring, helpful — a friendly watchful helper, NOT tactical or corporate or alarming.',
+        'Soft rounded square 1024×1024 canvas with a subtle paper-grain texture.',
+        'NO text, NO letters, NO photo-realism, NO sleek 3D render, NO magnifying glass, NO speech bubbles, NO dark navy or near-black backgrounds, NO literal Slack / Lark / Zibby wordmark.',
+      ].join('\n'),
+      tags: ['On-call', 'Bug Triage', 'Notifications'],
+      capabilities: [
+        'Scheduled scan of every pipeline\'s recent run history',
+        'Flags pipelines by failure rate and slow-outlier duration',
+        'LLM proposes a specific, evidence-backed improvement per problem pipeline',
+        'Posts a review card to Slack or Lark — whichever your project has connected',
+        'Proposal-only: a human reviews and applies; the supervisor changes nothing',
+      ],
+      conversationStarters: [
+        'Scan my pipelines from the last 24h and flag the ones failing 40%+ of runs',
+        'Which of my workflows is the flakiest, and what should I change?',
+        'Propose a fix for any pipeline that keeps failing on the same step',
+        'Only supervise my deploy pipelines and post proposals to #eng',
+      ],
+    },
+  },
+
+  // ── ticket-triage: tracker-neutral triage building block ──────────
+  'ticket-triage': {
+    name: 'ticket-triage',
+    displayName: 'Ticket Triage',
+    description: 'Tracker-neutral triage building block — LLM-classifies one ticket (from any tracker) into a severity (CRITICAL…NOISE), a shouldAutofix decision, and a human summary. The first block of the bug-autofix pipeline; usable on its own.',
+    path: join(__dirname, 'ticket-triage'),
+    defaultSlug: 'ticket-triage',
+    deps: { zod: '^3.23.0' },
+    features: [
+      'Single LLM node: classify → { severity, shouldAutofix, summary }',
+      'Tracker-neutral input (Jira today; GitHub / Linear are extension points)',
+      'Severity rubric adapted from sentry-triage, with auditable reasoning',
+      'Tunable SEVERITY_THRESHOLD + free-form AUTOFIX_RULES per deploy',
+      'Designed to be dispatched as a sub-graph by the bug-autofix orchestrator',
+    ],
+    marketplace: {
+      slug: 'ticket-triage',
+      tagline: 'Triage any ticket: how bad is it, and should a bot fix it?',
+      iconPrompt: [
+        'A clean, friendly flat-design app icon for "Ticket Triage" — a workflow that sorts incoming tickets by severity.',
+        'Subject: a single rounded paper ticket/tag shape (like a luggage tag) centered on the canvas, tilted slightly, with three small colored signal dots stacked along its right edge — one green, one amber, one red — reading top-to-bottom as a severity scale.',
+        'Background: a soft rounded square with a gentle teal-to-sky gradient (#2DD4BF → #38BDF8). Subtle long shadow under the ticket for depth.',
+        'Style: modern flat illustration with soft gradients, the family of Linear / Height product icons. Crisp at 64×64.',
+        'NO text, NO letters, NO photorealism, NO mascot, NO trademarked Jira/Linear logos.',
+      ].join('\n'),
+      tags: ['Bug Triage', 'child-workflow'],
+      capabilities: [
+        'Classifies one ticket into a severity bucket with auditable reasoning',
+        'Decides shouldAutofix — is this concrete enough for an agent to fix?',
+        'Tracker-agnostic input; only Jira flows end-to-end in v1',
+        'Composable: the bug-autofix orchestrator calls it as a sub-graph',
+      ],
+      conversationStarters: [
+        'Triage this bug ticket and tell me if a bot could fix it',
+        'How severe is PROJ-123, and should we auto-fix it?',
+        'Never mark auth tickets as auto-fixable',
+      ],
+    },
+  },
+
+  // ── code-fix: clone → agent fix + inline test-gate → PR ───────────
+  'code-fix': {
+    name: 'code-fix',
+    displayName: 'Code Fix (clone → fix → PR)',
+    description: 'Clones a repo into an isolated workspace, has an agent fix one ticket with an inline test-gate (run the tests, feed failures back for one retry), and opens a PR. Output: { pr_url, branch }. The "do the work" block of the bug-autofix pipeline.',
+    path: join(__dirname, 'code-fix'),
+    defaultSlug: 'code-fix',
+    deps: { zod: '^3.23.0', axios: '^1.6.0' },
+    features: [
+      '3-node graph: setup (clone) → fix_code (agent + inline test-gate) → create_pr',
+      'Agent edits in an isolated Fargate workspace; SKILLS.GIT auto-auth clone',
+      'Inline test-gate: run npm test / pytest, feed failures back for ONE retry',
+      'Opens a GitHub PR off the pushed branch → { pr_url, branch }',
+      'Stops at the PR — a human reviews + merges (no auto-merge, no in-engine approval)',
+      'Auto-detects the test command (or override via TEST_COMMAND)',
+    ],
+    marketplace: {
+      slug: 'code-fix',
+      tagline: 'Hand it a ticket + a repo; get back a tested fix PR.',
+      iconPrompt: [
+        'A bold, modern app icon for "Code Fix" — a workflow that fixes a bug and opens a pull request.',
+        'Subject: a rounded wrench crossed subtly behind a git-branch / pull-request glyph (two nodes joined by a curved line), with a small green checkmark badge in the lower-right indicating tests passed.',
+        'Background: a soft rounded square with a deep indigo-to-violet gradient (#4F46E5 → #7C3AED). Soft inner glow behind the glyph.',
+        'Style: clean flat-with-depth product illustration, glossy but not skeuomorphic; the family of GitHub / Linear product marks. Crisp at 64×64.',
+        'NO text, NO letters, NO photorealism, NO mascot, NO trademarked GitHub/GitLab logos.',
+      ].join('\n'),
+      tags: ['Bug Triage', 'Testing', 'child-workflow'],
+      capabilities: [
+        'Clones the target repo into an isolated per-run workspace',
+        'Agent makes the smallest correct change to fix the ticket',
+        'Inline test-gate runs the suite and retries once on failure',
+        'Opens a GitHub PR with the diff, test status, and ticket link',
+        'Composable: the bug-autofix orchestrator calls it as a sub-graph',
+      ],
+      conversationStarters: [
+        'Fix PROJ-123 in the web repo and open a PR',
+        'Run the tests after fixing and retry once if they fail',
+        'Use pytest -q as the test command',
+      ],
+    },
+  },
+
+  // ── tracker-writeback: transition + comment + chat notify ─────────
+  'tracker-writeback': {
+    name: 'tracker-writeback',
+    displayName: 'Tracker Writeback',
+    description: 'Closes the loop after triage/fix — transitions the tracker issue (Jira → In Review when a PR opened), comments the PR link + verdict, and posts a Slack or Lark note. The writeback block of the bug-autofix pipeline (Jira in v1; GitHub / Linear are extension points).',
+    path: join(__dirname, 'tracker-writeback'),
+    defaultSlug: 'tracker-writeback',
+    deps: { zod: '^3.23.0', '@zibby/skills': '^0.1.26' },
+    features: [
+      'Single LLM node with SKILLS.JIRA + SKILLS.CHAT_NOTIFY',
+      'Jira: transition (fuzzy status match, reused) + comment the PR link/verdict',
+      'PR link rides in a comment (no Jira remote-link tool) — documented v1 fallback',
+      'Posts a short Slack OR Lark note (chat_notify, like notify-slack)',
+      'Runs on both branches: autofixed (PR up for review) and notify-only',
+      'jiraFetch is now exported so the remote-link extension point can reuse it',
+    ],
+    marketplace: {
+      slug: 'tracker-writeback',
+      tagline: 'Update the ticket, link the PR, ping the channel — done.',
+      iconPrompt: [
+        'A clean, friendly flat-design app icon for "Tracker Writeback" — a workflow that updates a ticket and notifies a chat channel.',
+        'Subject: a rounded ticket/card shape with a small curved "return" arrow looping back into it, and a tiny speech-bubble badge in the upper-right (the chat notification).',
+        'Background: a soft rounded square with a warm coral-to-amber gradient (#FB7185 → #FBBF24). Subtle drop shadow for depth.',
+        'Style: modern flat illustration with soft gradients, the family of Linear / Slack product icons. Crisp at 64×64.',
+        'NO text, NO letters, NO photorealism, NO mascot, NO trademarked Jira/Slack/Lark logos.',
+      ].join('\n'),
+      tags: ['Notifications', 'child-workflow'],
+      capabilities: [
+        'Transitions the Jira issue to a review/triage status (fuzzy-matched)',
+        'Comments the triage summary + the PR link on the ticket',
+        'Posts a short Slack or Lark note — whichever the project has connected',
+        'Runs on both the autofixed and notify-only branches',
+        'Composable: the bug-autofix orchestrator calls it as a sub-graph',
+      ],
+      conversationStarters: [
+        'Move PROJ-123 to In Review and comment the PR link',
+        'Post to #eng when a fix PR is opened',
+        'When a ticket can\'t be auto-fixed, comment why and ping a human',
+      ],
+    },
+  },
+
+  // ── bug-autofix: the ⭐ orchestrator (poll → triage → fix → writeback) ─
+  'bug-autofix': {
+    name: 'bug-autofix',
+    displayName: 'Bug Autofix Pipeline',
+    description: 'The composable bug-autofix SDLC pipeline. Polls a tracker, then connects three reusable building blocks via sub-graph dispatch: ticket-triage → (autofixable?) → code-fix → tracker-writeback. High-severity autofixable bugs get a tested fix PR opened and the ticket moved to In Review; everything else is triaged and a human is notified. Stops at the PR — a human merges.',
+    path: join(__dirname, 'bug-autofix'),
+    defaultSlug: 'bug-autofix',
+    deps: { zod: '^3.23.0', '@zibby/skills': '^0.1.26' },
+    features: [
+      'Orchestrator: poll → ticket-triage → code-fix → tracker-writeback',
+      'Composes 3 marketplace templates via Zibby sub-graph dispatch ({ workflow: slug })',
+      'Routes on triage: severity ≥ floor AND shouldAutofix → fix; else notify-only',
+      'Cron-poll of the tracker, or per-ticket webhook (ticketKey)',
+      'Each child is a separate linked execution (parentExecutionId tree-view)',
+      'Stops at PR opened + tracker written back — human merges (no in-engine approval)',
+    ],
+    marketplace: {
+      slug: 'bug-autofix',
+      tagline: 'Poll bugs, triage, open a tested fix PR, write the ticket back — on autopilot.',
+      iconPrompt: [
+        'A premium, hi-fi app icon for "Bug Autofix" — an orchestrator that turns a bug ticket into a reviewed fix PR automatically.',
+        'Visual style: 3D-rendered hero object floating in space, in the style of Apple Vision Pro icons or a Stripe product render. Glossy, dimensional, soft rim-light.',
+        'Subject: a friendly 3D ladybug-style bug figure being lifted/healed by a glowing violet loop-arrow that circles it (the autofix cycle), with three small connected glossy nodes orbiting around — suggesting a pipeline of stages. A tiny green checkmark spark where the loop closes.',
+        'Background: a deep midnight-navy gradient (#0F172A → #1E1B4B) with a soft violet glow (#7C3AED) behind the subject and a few faint star specks. Square 1024×1024.',
+        'Composition: subject centered, subtle drop shadow. Mood: confident, premium, "it just handles it" — the flagship of the set.',
+        'NO text, NO letters, NO flat sticker style, NO trademarked logos. This one is DEEP and 3D-rendered, distinct from the three flat building-block icons.',
+      ].join('\n'),
+      tags: ['Bug Triage', 'Incidents'],
+      capabilities: [
+        'Polls your tracker for candidate bugs (JQL) or runs per-ticket via webhook',
+        'Triages each ticket, then routes autofixable ones to an agent fix',
+        'Opens a tested fix PR and moves the ticket to In Review',
+        'Notifies a human for anything it shouldn\'t auto-fix',
+        'Composes three reusable templates — swap or reuse the blocks independently',
+      ],
+      conversationStarters: [
+        'Poll my open bugs and auto-fix the autofixable ones',
+        'When a P1 bug comes in, open a fix PR and move it to In Review',
+        'Only auto-fix HIGH+ severity bugs; notify a human for the rest',
+        'Run the bug-autofix pipeline on PROJ-123',
+      ],
+    },
+  },
+
+  // ── github-ai-scout: daily AI-project discovery → Slack shortlist ─
+  'github-ai-scout': {
+    name: 'github-ai-scout',
+    displayName: 'Daily GitHub AI Scout',
+    description: 'A daily scout that searches GitHub for new/trending AI projects, scores them against YOUR configurable rubric with an LLM, and posts a Slack shortlist for a human to review. General + config-driven — the query, recency/star thresholds, and rubric are all deploy-time inputs. Proposes a shortlist; never stars, forks, or auto-adds anything.',
+    path: join(__dirname, 'github-ai-scout'),
+    defaultSlug: 'github-ai-scout',
+    deps: { zod: '^3.23.0', '@zibby/skills': '^0.1.25' },
+    features: [
+      '3-node graph: scan (GitHub search API) → score (LLM rubric) → digest (Slack)',
+      'Cron-friendly: daily schedule, default daysBack=30 / minStars=30',
+      'Configurable query + rubric — point it at any topic + taste, nothing is hard-coded',
+      'LLM ranks + filters candidates; only ever picks from the scanned repos (no invented repos)',
+      'excludeRepos allow-list dedups against projects you already track',
+      'Renders a native Slack Block-Kit card via the notify-slack sub-graph',
+      'Proposes a shortlist — a human reviews, the scout never auto-acts',
+    ],
+    marketplace: {
+      slug: 'github-ai-scout',
+      tagline: 'Scout new AI projects on GitHub every morning — scored to your taste, shortlisted in Slack.',
+      iconPrompt: [
+        'A premium, hi-fi app icon for "Daily GitHub AI Scout" — a workflow that scans GitHub for new AI projects and shortlists the best ones.',
+        'Visual style: 3D-rendered hero object floating in space, in the style of Apple Vision Pro icons or a Stripe product render. Glossy, dimensional, with subtle reflections and a soft rim-light.',
+        'Subject: a sleek 3D-rendered pair of binoculars (or a small telescope) tilted up in three-quarter perspective, its glossy violet body catching a soft rim-light, sweeping a thin glowing scan-beam across a small cluster of glossy golden five-pointed STARS — two or three stars caught bright in the beam, a few fainter ones drifting past. A single tiny AI spark — a small four-point sparkle in soft cyan — glints near the lens to signal the smart-scoring step, and one small rounded code-bracket glyph "{ }" floats subtly in the lower corner to hint at "code repositories" WITHOUT any logo.',
+        'Background: a deep midnight-navy gradient (#0F172A at the top, #1E1B4B at the bottom) with a single soft violet glow (#7553FF) behind the binoculars and a scatter of faint star-like specks across the canvas. Square format, 1024×1024.',
+        'Composition: binoculars centered and slightly raised, scan-beam angled up-right toward the brightest star, subtle drop shadow on the canvas. Mood: curious, premium, "always watching the frontier".',
+        'NO text, NO letters, NO numbers, NO flat sticker style, NO mascot face, NO magnifying glass, NO trademarked GitHub octocat / Slack / OpenAI logos — this one is DEEP and 3D-rendered.',
+      ].join('\n'),
+      tags: ['Reports', 'Notifications'],
+      capabilities: [
+        'Searches GitHub daily for newly-created, trending repositories matching your query',
+        'Filters by recency (created within N days) and a minimum star count',
+        'Scores every candidate 1-5 against your plain-English rubric with an LLM',
+        'Keeps a tight shortlist of the best finds — drops abandoned demos and trivial wrappers',
+        'Dedups against repos you already track via an excludeRepos allow-list',
+        'Posts a numbered Block-Kit shortlist to Slack — stars, language, license, one-line reason, link',
+      ],
+      conversationStarters: [
+        'Scout new AI agent frameworks on GitHub every morning',
+        'Find trending RAG and LLM repos created this month and shortlist the best 8',
+        'Only surface repos with 100+ stars and a real README; skip the ones I already track',
+        'Post a daily GitHub AI radar to our #ai-radar Slack channel',
+      ],
+    },
+  },
+
+  // ── github-code-review: review a GitHub PR → post the review back ─
+  'github-code-review': {
+    name: 'github-code-review',
+    displayName: 'GitHub Code Review',
+    description: 'Reviews a GitHub pull request with an LLM and posts the review back to the PR — a summary plus inline comments and an APPROVE / COMMENT / REQUEST_CHANGES verdict. If the PR is linked to a Jira or Linear ticket (and that integration is connected), it ALSO validates the change against the ticket\'s acceptance criteria and renders an objectives-met table, the way CodeRabbit does. GitHub required; Jira/Linear optional (ticket context only).',
+    path: join(__dirname, 'github-code-review'),
+    defaultSlug: 'github-code-review',
+    deps: { zod: '^3.23.0', '@zibby/skills': '^0.1.33' },
+    features: [
+      '3-node graph: fetch_pr (github) → fetch_ticket (optional) → review (LLM)',
+      'Posts a real PR review via github_create_review — summary body + inline comments + verdict',
+      'DYNAMIC prompt: linked ticket → objectives-met table vs ticket acceptance criteria; no ticket → standalone diff review (never mentions a ticket)',
+      'Jira/Linear are OPTIONAL — fetched via direct tool calls so they don\'t gate deploy',
+      'Webhook-triggered on a PR: { owner, repo, prNumber }',
+      'Reviews + comments only — never merges, closes, or pushes',
+    ],
+    marketplace: {
+      slug: 'github-code-review',
+      tagline: 'Auto-review every GitHub PR — inline comments, a verdict, and objectives checked against the linked ticket.',
+      iconPrompt: [
+        'A premium, hi-fi app icon for "GitHub Code Review" — a workflow that reviews a GitHub pull request and posts the review back inline.',
+        'Visual style: 3D-rendered hero object floating in space, in the style of Apple Vision Pro icons or a Stripe product render. Glossy, dimensional, with subtle reflections and a soft rim-light.',
+        'Subject: a sleek 3D-rendered DARK octocat-style cat-with-tentacles silhouette (an original friendly cephalopod-cat creature, NOT the literal trademarked GitHub Octocat logo) rendered in glossy obsidian-black with a soft violet rim-light, holding a small glowing magnifier over a floating diff card; on the diff card two short code lines glow — one soft red (a removed line), one soft green (an added line) — and a small cyan check-mark sparkle sits at the corner to signal "reviewed". The whole motif reads "dark code-review".',
+        'Background: a deep charcoal-to-midnight gradient (#0D1117 at the top — GitHub\'s dark canvas — to #161B22 at the bottom) with a single soft violet glow (#7C3AED) behind the creature and a scatter of faint specks. Square format, 1024×1024.',
+        'Composition: creature centered and slightly raised, magnifier angled toward the diff card, subtle drop shadow. Mood: focused, premium, "nothing ships unreviewed".',
+        'NO text, NO letters, NO numbers, NO flat sticker style, NO the real trademarked GitHub Octocat logo or GitHub wordmark — make it an ORIGINAL dark cephalopod-cat. This one is DEEP and 3D-rendered.',
+      ].join('\n'),
+      tags: ['Code Review'],
+      capabilities: [
+        'Reads the PR diff + changed files and reviews correctness, bugs, security, tests, design, and style',
+        'Posts the review back to the PR: a summary, inline comments on specific lines, and a verdict',
+        'When a ticket is linked, validates the change against its acceptance criteria with an objectives-met table',
+        'Optionally pulls ticket context from Jira or Linear — but neither is required to run',
+        'Webhook-driven: point a PR-opened/synchronize hook at it',
+        'Proposes feedback only — a human still decides and merges',
+      ],
+      conversationStarters: [
+        'Review pull request #412 in acme/web-app',
+        'Auto-review every new PR and post inline comments',
+        'Review this PR and check it against the linked Jira ticket\'s acceptance criteria',
+        'Block the merge if a PR introduces a security or missing-test issue',
+      ],
+    },
+  },
+
+  // ── gitlab-code-review: review a GitLab MR → post the review back ─
+  'gitlab-code-review': {
+    name: 'gitlab-code-review',
+    displayName: 'GitLab Code Review',
+    description: 'Reviews a GitLab merge request with an LLM and posts the review back to the MR — a summary note plus inline discussion comments and a clear verdict. If the MR is linked to a Jira or Linear ticket (and that integration is connected), it ALSO validates the change against the ticket\'s acceptance criteria and renders an objectives-met table, the way CodeRabbit does. GitLab required; Jira/Linear optional (ticket context only).',
+    path: join(__dirname, 'gitlab-code-review'),
+    defaultSlug: 'gitlab-code-review',
+    deps: { zod: '^3.23.0', '@zibby/skills': '^0.1.33' },
+    features: [
+      '3-node graph: fetch_mr (gitlab) → fetch_ticket (optional) → review (LLM)',
+      'Posts a real MR review via gitlab_create_mr_review — summary note + inline discussions',
+      'DYNAMIC prompt: linked ticket → objectives-met table vs ticket acceptance criteria; no ticket → standalone diff review (never mentions a ticket)',
+      'Jira/Linear are OPTIONAL — fetched via direct tool calls so they don\'t gate deploy',
+      'Webhook-triggered on an MR: { projectId, mrIid }',
+      'Works against gitlab.com and self-hosted instances',
+    ],
+    marketplace: {
+      slug: 'gitlab-code-review',
+      tagline: 'Auto-review every GitLab MR — inline discussions, a verdict, and objectives checked against the linked ticket.',
+      iconPrompt: [
+        'A premium, hi-fi app icon for "GitLab Code Review" — a workflow that reviews a GitLab merge request and posts the review back inline.',
+        'Visual style: 3D-rendered hero object floating in space, in the style of Apple Vision Pro icons or a Stripe product render. Glossy, dimensional, with subtle reflections and a soft rim-light.',
+        'Subject: a sleek 3D-rendered ORANGE FOX head (an original friendly fox character evoking GitLab\'s tanuki-fox spirit WITHOUT copying the literal trademarked GitLab logo), rendered in glossy gradient orange (#FC6D26 → #E24329) with a soft rim-light, peering over a floating merge-request card; on the card two short code lines glow — one soft red (a removed line), one soft green (an added line) — and two small branch lines MERGE into one with a glowing node at the join to signal "merge request". A tiny cyan check-mark sparkle sits at the corner for "reviewed".',
+        'Background: a deep midnight-navy gradient (#1F1B3A at the top to #2E2150 at the bottom) that makes the orange fox POP, with a soft warm-orange glow behind the fox and a scatter of faint specks. Square format, 1024×1024.',
+        'Composition: fox centered and slightly raised, peering down at the merge-request card, subtle drop shadow. Mood: clever, warm, premium — clearly ORANGE-FOX so it is instantly distinguishable from the dark GitHub review icon.',
+        'NO text, NO letters, NO numbers, NO flat sticker style, NO the real trademarked GitLab tanuki logo or wordmark — make it an ORIGINAL orange fox. This one is DEEP and 3D-rendered.',
+      ].join('\n'),
+      tags: ['Code Review'],
+      capabilities: [
+        'Reads the MR diff + changed files and reviews correctness, bugs, security, tests, design, and style',
+        'Posts the review back to the MR: a summary note, inline discussion comments on specific lines, and a verdict',
+        'When a ticket is linked, validates the change against its acceptance criteria with an objectives-met table',
+        'Optionally pulls ticket context from Jira or Linear — but neither is required to run',
+        'Works against gitlab.com and self-hosted GitLab instances',
+        'Proposes feedback only — a human still decides, approves, and merges',
+      ],
+      conversationStarters: [
+        'Review merge request !73 in acme/web-app',
+        'Auto-review every new MR and post inline discussions',
+        'Review this MR and check it against the linked Jira ticket\'s acceptance criteria',
+        'Flag any MR that introduces a security or missing-test issue',
+      ],
+    },
+  },
 };
 
 export class TemplateFactory {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zibby/workflow-templates",
-  "version": "0.9.0",
+  "version": "0.9.2",
   "description": "Built-in workflow templates for Zibby — browser-test-automation, code-analysis, generate-test-cases, notify-slack, notify-lark, notify-notion, sentry-triage.",
   "type": "module",
   "main": "index.js",
@@ -25,6 +25,8 @@
     "./sentry-triage/*": "./sentry-triage/*",
     "./ai-spend-weekly-digest": "./ai-spend-weekly-digest/graph.mjs",
     "./ai-spend-weekly-digest/*": "./ai-spend-weekly-digest/*",
+    "./pipeline-supervisor": "./pipeline-supervisor/graph.mjs",
+    "./pipeline-supervisor/*": "./pipeline-supervisor/*",
     "./package.json": "./package.json"
   },
   "scripts": {
@@ -56,6 +58,7 @@
     "notify-lark/",
     "notify-notion/",
     "sentry-triage/",
+    "pipeline-supervisor/",
     "index.js",
     "register-nodes.js",
     "global-setup.js",

package/pipeline-supervisor/README.md

@@ -0,0 +1,51 @@
+# pipeline-supervisor
+
+**Zibby managing Zibby.** A scheduled "监工 / supervisor" workflow that watches
+the project's *other* pipelines, finds the ones that are failing or slow, and
+posts a human-reviewable improvement proposal to Slack or Lark.
+
+v1 is strictly **READ → PROPOSE → NOTIFY**. It never edits another workflow's
+graph — that's the safe L3 starting point. The auto-PATCH step is a marked TODO
+in `nodes/propose-node.js`, deliberately not implemented.
+
+## Graph
+
+```
+scan_pipelines        (deterministic + Zibby REST API, PAT-authed)
+   → propose_improvements (LLM — one proposal per flagged pipeline)
+   → notify               (LLM + SKILLS.CHAT_NOTIFY — one review card)
+```
+
+If `scan_pipelines` flags nothing, the graph short-circuits straight to
+`notify` (which posts/skips without a Claude call on the proposer).
+
+## How it reads other pipelines
+
+A direct authed `GET /executions?projectId=<id>&limit=200` against the Zibby
+REST API (the same route the dashboard + remote MCP server use), carrying a
+**user personal access token** in `Authorization: Bearer`.
+
+It must be a USER PAT (`zby_pat_…`), **not** the Fargate-injected
+`PROJECT_API_TOKEN`: every cross-pipeline read route (`/executions`, `/jobs`,
+`/all`) requires a `userId` from the authorizer, and a project token carries
+none — so it 401s. See the header comment in `nodes/scan-pipelines-node.js`
+for the full rationale.
+
+## Config (ENV tab)
+
+Required:
+- `ZIBBY_PAT` — user personal access token the supervisor reads executions with.
+- `SLACK_CHANNEL` **or** `LARK_RECEIVE_ID` — where the review card goes.
+
+Optional:
+- `SUPERVISOR_PROJECT_ID` — project to supervise (defaults to the running project).
+- `SLACK_MENTIONS` / `LARK_MENTIONS` — JSON array of mentions on the card.
+
+## Input (per-run dials)
+
+| field | default | meaning |
+|---|---|---|
+| `lookbackHours` | 24 | hours of execution history to scan |
+| `minFailRate` | 0.4 | flag a pipeline failing ≥ this fraction of recent runs |
+| `targetWorkflowTypes` | — | optional name filter (case-insensitive substring) |
+| `maxPipelines` | 25 | cap on distinct pipelines analyzed per run |

package/pipeline-supervisor/graph.mjs

@@ -0,0 +1,75 @@
+/**
+ * pipeline-supervisor — Zibby's flagship "监工 / supervisor" workflow.
+ * "Zibby managing Zibby": a scheduled run that watches the project's OTHER
+ * pipelines and PROPOSES improvements. v1 is strictly READ + PROPOSE +
+ * NOTIFY — it never edits another workflow's graph (the safe L3 boundary).
+ *
+ *   scan_pipelines        (deterministic + Zibby REST) → pull recent
+ *                          executions across pipelines (PAT-authed), roll
+ *                          up per-pipeline health, flag failing/slow ones.
+ *        ↓
+ *   propose_improvements  (LLM)                         → one concrete,
+ *                          reviewable proposal per flagged pipeline
+ *                          (add test gate / tweak prompt / add approval
+ *                          gate / drop redundant step).
+ *        ↓
+ *   notify                (LLM + SKILLS.CHAT_NOTIFY)    → ONE review card
+ *                          to Slack OR Lark: "Pipeline X failed 4/5 on step
+ *                          Y. I'd suggest <change>. (review)".
+ *
+ * Short-circuit: if scan_pipelines flags nothing, skip the LLM proposer and
+ * route straight to notify (which posts a green "all healthy" no-op). The
+ * idle path is the common case — most runs find nothing wrong — so we don't
+ * spend a Claude call manufacturing proposals from an empty list.
+ */
+
+import { WorkflowAgent, WorkflowGraph } from '@zibby/core';
+
+import { scanPipelinesNode } from './nodes/scan-pipelines-node.js';
+import { proposeNode } from './nodes/propose-node.js';
+import { notifyNode } from './nodes/notify-node.js';
+
+import {
+  pipelineSupervisorInputSchema,
+  pipelineSupervisorContextSchema,
+} from './state.js';
+
+export class PipelineSupervisorAgent extends WorkflowAgent {
+  buildGraph() {
+    const graph = new WorkflowGraph();
+    graph
+      .setInputSchema(pipelineSupervisorInputSchema)
+      .setContextSchema(pipelineSupervisorContextSchema);
+
+    graph.addNode('scan_pipelines', scanPipelinesNode);
+    graph.addNode('propose_improvements', proposeNode);
+    graph.addNode('notify', notifyNode);
+
+    graph.setEntryPoint('scan_pipelines');
+
+    // No flagged pipelines → skip the proposer, go straight to notify. The
+    // notify node's no-op short-circuit posts (or skips) without a model
+    // round-trip, so an all-healthy scan costs one Claude call at most.
+    graph.addConditionalEdges('scan_pipelines', (state) => {
+      const flagged = (state?.scan_pipelines?.pipelines || []).filter((p) => p.flagged);
+      return flagged.length === 0 ? 'notify' : 'propose_improvements';
+    });
+    graph.addEdge('propose_improvements', 'notify');
+    graph.addEdge('notify', 'END');
+
+    return graph;
+  }
+
+  async onComplete(result) {
+    const pipelines = result?.state?.scan_pipelines?.pipelines || [];
+    const flagged = pipelines.filter((p) => p.flagged).length;
+    const proposals = result?.state?.propose_improvements?.proposals?.length || 0;
+    const s = result?.state?.notify?.summary || {};
+    console.log(
+      `[pipeline-supervisor] complete — pipelines=${pipelines.length}, flagged=${flagged}, ` +
+      `proposals=${proposals}, sent=${s.sent || 0}, skipped=${s.skipped || 0}, failed=${s.failed || 0}`,
+    );
+  }
+}
+
+export default PipelineSupervisorAgent;

package/pipeline-supervisor/node_modules/.vite/vitest/da39a3ee5e6b4b0d3255bfef95601890afd80709/results.json

@@ -0,0 +1 @@
+{"version":"4.1.7","results":[[":__tests__/graph.integration.test.js",{"duration":7.337875000000054,"failed":false}]]}

package/pipeline-supervisor/nodes/notify-node.js

@@ -0,0 +1,162 @@
+/**
+ * notify — LLM + SKILLS.CHAT_NOTIFY. Posts ONE human-reviewable card
+ * summarizing the improvement proposals to the configured chat destination.
+ * This is the "NOTIFY" half of READ → PROPOSE → NOTIFY: the human reads the
+ * card and acts manually. The supervisor never applies a change itself in v1.
+ *
+ * Mirrors sentry-triage's dispatch node: chatNotifySkill.resolve() picks
+ * slack or lark from which env var is set (SLACK_CHANNEL vs LARK_RECEIVE_ID),
+ * so the LLM only ever sees one provider's tools.
+ *
+ * ENV tab config — required:
+ *   SLACK_CHANNEL OR LARK_RECEIVE_ID  — provider selector + destination
+ * ENV tab config — optional:
+ *   SLACK_MENTIONS / LARK_MENTIONS    — JSON array of mentions on the card
+ */
+
+import { z, SKILLS } from '@zibby/core';
+
+const DispatchedRecordSchema = z.object({
+  status: z.enum(['sent', 'skipped', 'failed']),
+  // nullish (not optional) on purpose — the LLM emits explicit null rather
+  // than omitting keys; .optional() would reject null and fail the node.
+  recipient: z.object({
+    kind: z.enum(['channel', 'user_dm', 'usergroup']).nullish(),
+    id: z.string().nullish(),
+    label: z.string().nullish(),
+  }).nullish(),
+  proposalCount: z.number().nullish(),
+  messageTs: z.string().nullish(),   // Slack
+  messageId: z.string().nullish(),   // Lark
+  detail: z.string().nullish(),
+});
+
+const NotifyOutputSchema = z.object({
+  dispatched: z.array(DispatchedRecordSchema),
+  summary: z.object({
+    total: z.number(),
+    sent: z.number(),
+    skipped: z.number(),
+    failed: z.number(),
+  }),
+});
+
+const CHANGE_KIND_LABEL = {
+  add_test_gate: 'Add a test gate',
+  tweak_prompt: 'Tweak the prompt',
+  add_human_approval_gate: 'Add a human-approval gate',
+  drop_redundant_step: 'Drop a redundant step',
+  other: 'Other',
+};
+
+const NOTIFY_PROMPT = (state = {}) => {
+  const proposals = state?.propose_improvements?.proposals || [];
+  const scan = state?.scan_pipelines || {};
+  const lookbackHours = scan.lookbackHours || state?.lookbackHours || 24;
+
+  const slackChannel = process.env.SLACK_CHANNEL || '';
+  const larkReceiveId = process.env.LARK_RECEIVE_ID || '';
+
+  // ── No-op short-circuit ─────────────────────────────────────────
+  // Nothing flagged → keep the run green without a model round-trip or
+  // forcing channel setup. Return the empty envelope verbatim.
+  if (proposals.length === 0) {
+    return `pipeline-supervisor found no problem pipelines this run — nothing to propose.
+
+Return this exact JSON envelope and call no tools:
+
+\`\`\`json
+{ "dispatched": [{ "status": "skipped", "proposalCount": 0, "detail": "no flagged pipelines" }], "summary": { "total": 0, "sent": 0, "skipped": 1, "failed": 0 } }
+\`\`\`
+`;
+  }
+
+  // ── Provider selection ──────────────────────────────────────────
+  let provider, postTool, channelId, mentionsRaw;
+  if (slackChannel) {
+    provider = 'slack';
+    postTool = 'slack_post_message';
+    channelId = slackChannel;
+    mentionsRaw = process.env.SLACK_MENTIONS || '[]';
+  } else if (larkReceiveId) {
+    provider = 'lark';
+    postTool = 'lark_send_message';
+    channelId = larkReceiveId;
+    mentionsRaw = process.env.LARK_MENTIONS || '[]';
+  } else {
+    throw new Error(
+      'pipeline-supervisor has proposals to post but no destination configured. ' +
+      'Go to Project Settings → ENV and set ONE of:\n' +
+      '  - SLACK_CHANNEL=#your-channel    (uses connected Slack integration)\n' +
+      '  - LARK_RECEIVE_ID=oc_xxxxxxxx    (uses connected Lark integration)'
+    );
+  }
+
+  let mentions;
+  try { mentions = JSON.parse(mentionsRaw); } catch { mentions = []; }
+  if (!Array.isArray(mentions)) mentions = [];
+
+  const windowLabel = lookbackHours < 48
+    ? `the past ${lookbackHours} hours`
+    : `the past ${Math.round(lookbackHours / 24)} days`;
+
+  const writeGuide = provider === 'slack'
+    ? `# How to post it — a Slack review card
+Post ONCE with \`slack_post_message({ channel, text, blocks })\`. \`text\` = a one-line fallback. \`blocks\` = real Block Kit objects only:
+1. \`header\` — { "type": "header", "text": { "type": "plain_text", "text": "🛠️ Pipeline Supervisor — ${windowLabel}", "emoji": true } }
+2. \`context\` — one line: how many pipelines flagged, scanned over ${windowLabel}.
+3. Per proposal — a \`section\` then a small \`context\`:
+   { "type": "divider" }
+   { "type": "section", "text": { "type": "mrkdwn", "text": "*<pipeline>* — <problem>\\n*Suggestion (${'`'}<changeKind label>${'`'}):* <suggestion>" } }
+   { "type": "context", "elements": [{ "type": "mrkdwn", "text": "↳ <evidence — the concrete metric>" }] }
+4. final \`context\` — make clear these are PROPOSALS for a human to review and apply; the supervisor did NOT change anything.
+- header text is plain_text; section & context are mrkdwn.
+- Real Block Kit types only (header / section / divider / context).`
+    : `# How to write it — a Lark review note, talk like a teammate
+Post ONCE with \`lark_send_message({ receive_id, msg_type:"text", content })\`. Open with one sentence about ${windowLabel} and how many pipelines you flagged. Then, per proposal: the pipeline name, the problem, your suggested change (say which of the four moves it is), and the evidence number. End by making clear these are PROPOSALS for a human to review and apply — the supervisor changed nothing. No form blocks; sound like a person.`;
+
+  return `You are the notify node of pipeline-supervisor. Post ONE chat message with the **${postTool}** tool summarizing the improvement proposals for a human to review.
+
+# Destination
+Channel/receive_id: ${JSON.stringify(channelId)} (${provider}). Post with \`${postTool}\`.
+${mentions.length > 0 ? `Prepend these mentions: ${JSON.stringify(mentions.join(' '))}` : ''}
+
+# Framing (important)
+These are PROPOSALS. The supervisor read other pipelines' run history and is SUGGESTING changes a human will review and apply by hand. Do NOT imply anything was already changed. Each card line should read like "Pipeline X failed 4/5 runs on step Y — I'd suggest <change>. (review)".
+
+# changeKind → human label
+${Object.entries(CHANGE_KIND_LABEL).map(([k, v]) => `- ${k} → ${v}`).join('\n')}
+
+${writeGuide}
+
+# Output (outputSchema-enforced)
+Return ONE record for the message you posted (status "sent"), or "failed" with a \`detail\`. \`proposalCount\` = number of proposals in the card. \`recipient\` records where it went.
+
+\`\`\`json
+{
+  "dispatched": [
+    { "status": "sent", "recipient": { "kind": "channel", "id": ${JSON.stringify(channelId)} }, "proposalCount": ${proposals.length}${provider === 'slack' ? ',\n      "messageTs": "1716109330.555"' : ',\n      "messageId": "om_xxxxx"'} }
+  ],
+  "summary": { "total": 1, "sent": 1, "skipped": 0, "failed": 0 }
+}
+\`\`\`
+
+# Proposals to post
+
+\`\`\`json
+${JSON.stringify(proposals, null, 2)}
+\`\`\`
+
+# Rules
+- ONE message → ONE \`sent\` record.
+- Don't invent pipelines, metrics, or suggestions — only what's in the data above.
+- Keep it tight. If there are 2 proposals, a short card is the right answer.
+`;
+};
+
+export const notifyNode = {
+  name: 'notify',
+  skills: [SKILLS.CHAT_NOTIFY],
+  outputSchema: NotifyOutputSchema,
+  prompt: NOTIFY_PROMPT,
+};

package/pipeline-supervisor/nodes/propose-node.js

@@ -0,0 +1,91 @@
+/**
+ * propose_improvements — LLM. Reads the per-pipeline health summary from
+ * scan_pipelines and emits ONE concrete, reviewable improvement proposal
+ * per FLAGGED pipeline. No tools — everything it needs is inlined as JSON.
+ *
+ * This is the "propose" half of READ → PROPOSE → NOTIFY. It does NOT touch
+ * any other workflow's graph. It only describes a change a human can apply.
+ *
+ * ─────────────────────────────────────────────────────────────────────────
+ * TODO (future, DELIBERATELY NOT IMPLEMENTED in v1 — the safe L3 boundary):
+ *   Auto-PATCH the target pipeline's graph. When we promote this template
+ *   from "notify only" to "self-iterating", a new node AFTER human approval
+ *   would call the workflow-update API to actually apply an accepted
+ *   `changeKind` (e.g. insert a test-gate node, edit a prompt). That step
+ *   must be gated behind explicit human approval + snapshot/dry-run/verify/
+ *   rollback (see MEMORY: app-upgrade-strategy-agentic). v1 stops at the
+ *   proposal so a human reviews and applies the change by hand.
+ * ─────────────────────────────────────────────────────────────────────────
+ */
+
+import { z } from '@zibby/core';
+
+const ProposalSchema = z.object({
+  workflowType: z.string(),
+  problem: z.string(),
+  changeKind: z.enum([
+    'add_test_gate',
+    'tweak_prompt',
+    'add_human_approval_gate',
+    'drop_redundant_step',
+    'other',
+  ]),
+  suggestion: z.string(),
+  evidence: z.string().optional(),
+  confidence: z.number().min(0).max(1).optional(),
+});
+
+const ProposeOutputSchema = z.object({
+  proposals: z.array(ProposalSchema),
+});
+
+const GUIDE = `You are the propose_improvements node of pipeline-supervisor — a workflow that watches a Zibby project's OTHER pipelines and proposes concrete fixes. This is "Zibby managing Zibby."
+
+You are given a per-pipeline health summary as JSON below. Each entry is one pipeline (a workflow type) with its recent run stats: total / failed / succeeded / running, failRate, medianDurationMs, a worstRun example, and whether it's \`flagged\` (+ \`flagReason\`).
+
+# Your job
+For EACH pipeline where \`flagged === true\`, emit ONE proposal. Do NOT propose anything for un-flagged pipelines. If nothing is flagged, return an empty \`proposals\` array.
+
+# Pick ONE concrete change per problem — \`changeKind\` must be one of:
+- **add_test_gate** — the pipeline ships broken output / fails late. Propose inserting a validation/test step that catches the failure earlier (before the expensive/irreversible step).
+- **tweak_prompt** — an LLM node is making the same mistake repeatedly (e.g. wrong format, hallucinated tool call). Propose a specific prompt change.
+- **add_human_approval_gate** — the pipeline takes a risky/irreversible action and keeps getting it wrong. Propose a human-approval gate before that step.
+- **drop_redundant_step** — a step adds latency or failure surface with no value (e.g. an LLM round-trip that adds no judgment). Propose dropping it. Use this for clear "slow outlier" flags.
+- **other** — only when none of the above fit; explain in \`suggestion\`.
+
+# Each proposal must be:
+- **Specific**: name the pipeline, the symptom, and the exact change. Not "improve reliability" — instead "add a JSON-schema validation gate after the 'generate' node; 3 of the last 4 runs failed there with a malformed-output error."
+- **Evidence-backed**: put the concrete number / worstRun detail in \`evidence\` ("failRate 75% over 4 runs; worst run exec_abc failed on step 'deploy'"). Pull it straight from the data — never invent a metric.
+- **Reviewable, not auto-applied**: phrase \`suggestion\` as a recommendation a human will read and apply. You are NOT editing any graph.
+- **confidence** reflects how clean the signal is. A pipeline failing 4/4 on the same step → 0.9. A borderline slow outlier → 0.5.
+
+# Rules
+- ONE proposal per flagged pipeline. No duplicates.
+- Only use pipelines/numbers present in the data block. Don't invent pipelines, steps, or error messages.
+- \`problem\` is one sentence (the symptom). \`suggestion\` is one-to-three sentences (the fix).
+- Temperature 0. This is analysis, not creative writing.
+- Call NO tools — you have everything you need below.`;
+
+const PROPOSE_PROMPT = (state = {}) => {
+  const pipelines = state?.scan_pipelines?.pipelines || [];
+  const flagged = pipelines.filter((p) => p.flagged);
+  return `${GUIDE}
+
+## Context for this run
+- Scanned project: ${state?.scan_pipelines?.projectId || '(unknown)'}
+- Lookback: ${state?.scan_pipelines?.lookbackHours || '?'}h
+- Pipelines analyzed: ${pipelines.length}; flagged as problems: ${flagged.length}
+
+## Pipeline health summary (propose ONLY for flagged === true)
+
+\`\`\`json
+${JSON.stringify(pipelines, null, 2)}
+\`\`\`
+`;
+};
+
+export const proposeNode = {
+  name: 'propose_improvements',
+  outputSchema: ProposeOutputSchema,
+  prompt: PROPOSE_PROMPT,
+};

package/pipeline-supervisor/nodes/scan-pipelines-node.js

@@ -0,0 +1,316 @@
+/**
+ * scan_pipelines — DETERMINISTIC. Reads the project's recent executions
+ * across ALL pipelines via the Zibby REST API, then rolls them up per
+ * pipeline (workflow type) into a health summary the proposer reasons over.
+ *
+ * ── How the supervisor reads OTHER pipelines' results (the chosen mechanism) ──
+ *
+ * Mechanism: a DIRECT, authed HTTPS call to the Zibby REST API
+ *   GET {ZIBBY_ACCOUNT_API_URL|api-prod.zibby.app}/executions?projectId=<id>&limit=<n>
+ * (the same `listExecutions` route the dashboard + MCP server use), carrying
+ *   Authorization: Bearer <ZIBBY_PAT>
+ *
+ * Auth — why a user PAT, and NOT the injected PROJECT_API_TOKEN:
+ *   The executor injects PROJECT_API_TOKEN (a `zby_*` PROJECT token) into
+ *   every Fargate task. That token authenticates as the PROJECT
+ *   (authType:'project') and carries NO userId. But every cross-pipeline
+ *   READ route — /executions, /jobs/:projectId, /all/:projectId — pulls
+ *   `userId` out of the authorizer context and 401/403s when it's absent
+ *   (executions.js listExecutions: `if (!userId) return 401`;
+ *   workflow-logs.js: verifyProjectAccess(userId, …)). The remote MCP server
+ *   (mcp-server.js) goes further and validates a `zby_pat_*` PAT specifically.
+ *   So the project token literally cannot read these routes.
+ *
+ *   The credential that works is a USER personal access token (zby_pat_…),
+ *   supplied at deploy time as ZIBBY_PAT in the ENV tab. It resolves to a
+ *   userId via the authorizer's PAT path, and verifyProjectAccess then
+ *   confirms that user can see the supervised project. This is the same
+ *   credential class the MCP server requires, so the auth model is identical
+ *   whether you reach the data via REST (this node) or via the MCP tools
+ *   (zibby_list_executions / zibby_get_all_workflow_logs).
+ *
+ * Why REST over the MCP tools:
+ *   - No MCP client to stand up inside the workflow process; one fetch().
+ *   - The MCP `zibby_list_executions` tool is a thin proxy to THIS SAME
+ *     REST route, so we lose nothing by calling it directly.
+ *   - Deterministic + free: no LLM round-trip to drive a tool call for a
+ *     pure data pull.
+ *
+ * Per-pipeline rollup:
+ *   - "pipeline" = one workflow type/slug in the project. We group the
+ *     recent executions by `workflowType` and compute total / failed /
+ *     succeeded / running, failRate, and a median completed-run duration.
+ *   - A pipeline is `flagged` when failRate >= minFailRate (with >= 3 runs
+ *     so a single fluke doesn't trip it) OR it's a clear "slow" outlier.
+ *   - worstRun cites the single worst recent run so the proposer has a
+ *     concrete example to point at. failedStep/errorSummary are best-effort
+ *     — populated from whatever the execution row carries; absent is fine.
+ */
+
+import { z } from 'zod';
+
+const PipelineHealthSchema = z.object({
+  workflowType: z.string(),
+  workflowUuid: z.string().optional(),
+  total: z.number(),
+  failed: z.number(),
+  succeeded: z.number(),
+  running: z.number(),
+  failRate: z.number(),
+  medianDurationMs: z.number().optional(),
+  worstRun: z.object({
+    executionId: z.string().optional(),
+    status: z.string().optional(),
+    durationMs: z.number().optional(),
+    failedStep: z.string().optional(),
+    errorSummary: z.string().optional(),
+    startedAt: z.string().optional(),
+  }).optional(),
+  flagged: z.boolean(),
+  flagReason: z.string().optional(),
+});
+
+const ScanOutputSchema = z.object({
+  projectId: z.string(),
+  lookbackHours: z.number(),
+  scannedAt: z.string(),
+  totalExecutions: z.number(),
+  pipelines: z.array(PipelineHealthSchema),
+});
+
+// Statuses the executions API uses. Anything in FAILED_STATUSES counts
+// against the pipeline; SUCCEEDED is the clean path; the rest are in-flight.
+const FAILED_STATUSES = new Set(['failed', 'cancelled', 'blocked', 'insufficient_context']);
+const SUCCEEDED_STATUSES = new Set(['completed']);
+const RUNNING_STATUSES = new Set(['running', 'queued', 'starting', 'uploading']);
+
+function getAccountApiUrl() {
+  const raw = process.env.ZIBBY_ACCOUNT_API_URL;
+  if (raw) return raw.replace(/\/$/, '');
+  const env = process.env.ZIBBY_ENV || 'prod';
+  if (env === 'local') return 'http://localhost:3001';
+  return process.env.ZIBBY_PROD_ACCOUNT_API_URL || 'https://api-prod.zibby.app';
+}
+
+function median(nums) {
+  const xs = nums.filter((n) => typeof n === 'number' && isFinite(n)).sort((a, b) => a - b);
+  if (xs.length === 0) return undefined;
+  const mid = Math.floor(xs.length / 2);
+  return xs.length % 2 ? xs[mid] : Math.round((xs[mid - 1] + xs[mid]) / 2);
+}
+
+// Best-effort duration extraction. Execution rows don't carry a uniform
+// durationMs; derive it from start/end timestamps when both exist.
+function durationMsOf(exec) {
+  if (typeof exec.durationMs === 'number') return exec.durationMs;
+  const start = exec.startedAt || exec.createdAt;
+  const end = exec.completedAt || exec.finishedAt || exec.updatedAt;
+  if (start && end) {
+    const d = new Date(end).getTime() - new Date(start).getTime();
+    if (isFinite(d) && d >= 0) return d;
+  }
+  return undefined;
+}
+
+// Best-effort "what step failed / why" — execution rows vary; surface
+// whatever's there without inventing anything.
+function failureDetail(exec) {
+  return {
+    failedStep: exec.failedStep || exec.currentStep || exec.lastNode || undefined,
+    errorSummary: (exec.error || exec.errorMessage || exec.failureReason || '')
+      .toString().slice(0, 280) || undefined,
+  };
+}
+
+export const scanPipelinesNode = {
+  name: 'scan_pipelines',
+  outputSchema: ScanOutputSchema,
+  // 2 min — a single paginated /executions pull is usually <2s; headroom
+  // for a large project's history + transient API slowness.
+  timeout: 2 * 60 * 1000,
+  execute: async (context) => {
+    const state = (context?.state && typeof context.state.getAll === 'function')
+      ? context.state.getAll()
+      : context;
+
+    const lookbackHours = Number(state?.lookbackHours) || 24;
+    const minFailRate = typeof state?.minFailRate === 'number' ? state.minFailRate : 0.4;
+    const maxPipelines = Number(state?.maxPipelines) || 25;
+    const filters = Array.isArray(state?.targetWorkflowTypes)
+      ? state.targetWorkflowTypes.map((s) => String(s).toLowerCase())
+      : null;
+
+    // Supervised project: explicit override, else the running project.
+    const projectId = process.env.SUPERVISOR_PROJECT_ID || process.env.PROJECT_ID;
+    const pat = process.env.ZIBBY_PAT || process.env.ZIBBY_USER_TOKEN;
+
+    if (!projectId) {
+      throw new Error(
+        'pipeline-supervisor: no project to supervise. PROJECT_ID is injected by the ' +
+        'executor; set SUPERVISOR_PROJECT_ID in the ENV tab to point at a different project.'
+      );
+    }
+    if (!pat) {
+      throw new Error(
+        'pipeline-supervisor: ZIBBY_PAT is not set. The supervisor reads OTHER pipelines\' ' +
+        'executions via the Zibby REST API, which requires a USER personal access token ' +
+        '(zby_pat_…). The Fargate-injected PROJECT_API_TOKEN is a project token and the ' +
+        '/executions route rejects it (no userId). Create a PAT in the dashboard and set it ' +
+        'as ZIBBY_PAT in Project Settings → ENV.'
+      );
+    }
+
+    const base = getAccountApiUrl();
+    // limit=200 is the API ceiling; one page covers lookback for any realistic
+    // project. We post-filter by lookbackHours below rather than relying on a
+    // server-side time filter the route doesn't expose.
+    const url = `${base}/executions?projectId=${encodeURIComponent(projectId)}&limit=200`;
+    console.log(`Scanning executions: ${url}`);
+    console.log(`Lookback: ${lookbackHours}h · minFailRate: ${minFailRate} · maxPipelines: ${maxPipelines}`);
+
+    const res = await fetch(url, {
+      method: 'GET',
+      headers: { Authorization: `Bearer ${pat}` },
+    });
+
+    if (!res.ok) {
+      const body = await res.text().catch(() => '');
+      if (res.status === 401 || res.status === 403) {
+        throw new Error(
+          `pipeline-supervisor: ${res.status} reading /executions. ZIBBY_PAT is invalid, ` +
+          `expired, or its owner can't access project ${projectId}. ${body.slice(0, 200)}`
+        );
+      }
+      throw new Error(`pipeline-supervisor: /executions returned ${res.status}: ${body.slice(0, 300)}`);
+    }
+
+    const payload = await res.json().catch(() => ({}));
+    const all = Array.isArray(payload?.executions) ? payload.executions : [];
+
+    // Window + name filter.
+    const cutoff = Date.now() - lookbackHours * 3600 * 1000;
+    const inWindow = all.filter((e) => {
+      const t = new Date(e.createdAt || e.startedAt || 0).getTime();
+      return isFinite(t) && t >= cutoff;
+    });
+    const considered = filters
+      ? inWindow.filter((e) => {
+          const wt = String(e.workflowType || '').toLowerCase();
+          return filters.some((f) => wt.includes(f));
+        })
+      : inWindow;
+
+    console.log(
+      `Fetched ${all.length} execution(s); ${inWindow.length} in the last ${lookbackHours}h` +
+      `${filters ? `, ${considered.length} after type filter` : ''}.`
+    );
+
+    // ── Group by pipeline (workflowType) ──────────────────────────────
+    const byPipeline = new Map();
+    for (const e of considered) {
+      const wt = e.workflowType || '(unknown)';
+      if (!byPipeline.has(wt)) byPipeline.set(wt, []);
+      byPipeline.get(wt).push(e);
+    }
+
+    let pipelines = [];
+    for (const [workflowType, runs] of byPipeline.entries()) {
+      const failed = runs.filter((r) => FAILED_STATUSES.has(r.status));
+      const succeeded = runs.filter((r) => SUCCEEDED_STATUSES.has(r.status));
+      const running = runs.filter((r) => RUNNING_STATUSES.has(r.status));
+      // Fail rate over TERMINAL runs only — in-flight runs aren't a verdict yet.
+      const terminal = failed.length + succeeded.length;
+      const failRate = terminal > 0 ? failed.length / terminal : 0;
+      const durations = succeeded.map(durationMsOf).filter((d) => typeof d === 'number');
+      const medianDurationMs = median(durations);
+
+      // Worst run = a failure if any, else the slowest succeeded run.
+      let worstRun;
+      const worstFail = failed
+        .slice()
+        .sort((a, b) => new Date(b.createdAt || 0) - new Date(a.createdAt || 0))[0];
+      if (worstFail) {
+        const det = failureDetail(worstFail);
+        worstRun = {
+          executionId: worstFail.executionId,
+          status: worstFail.status,
+          durationMs: durationMsOf(worstFail),
+          startedAt: worstFail.createdAt || worstFail.startedAt,
+          ...det,
+        };
+      } else {
+        const slow = succeeded
+          .slice()
+          .sort((a, b) => (durationMsOf(b) || 0) - (durationMsOf(a) || 0))[0];
+        if (slow) {
+          worstRun = {
+            executionId: slow.executionId,
+            status: slow.status,
+            durationMs: durationMsOf(slow),
+            startedAt: slow.createdAt || slow.startedAt,
+          };
+        }
+      }
+
+      // Flag: enough terminal runs AND failRate over threshold. The >= 3
+      // guard keeps a single failed run from flagging a pipeline that's
+      // otherwise fine.
+      let flagged = false;
+      let flagReason;
+      if (terminal >= 3 && failRate >= minFailRate) {
+        flagged = true;
+        flagReason = `failRate ${(failRate * 100).toFixed(0)}% over ${terminal} terminal run(s) (≥ ${(minFailRate * 100).toFixed(0)}% threshold)`;
+      }
+
+      pipelines.push({
+        workflowType,
+        total: runs.length,
+        failed: failed.length,
+        succeeded: succeeded.length,
+        running: running.length,
+        failRate: Number(failRate.toFixed(3)),
+        medianDurationMs,
+        worstRun,
+        flagged,
+        flagReason,
+      });
+    }
+
+    // ── Slow-outlier flag (cross-pipeline) ────────────────────────────
+    // A pipeline whose median run is > 3× the median-of-medians is "slow",
+    // even if it's not failing. Only meaningful with a few pipelines that
+    // actually have durations.
+    const meds = pipelines.map((p) => p.medianDurationMs).filter((d) => typeof d === 'number');
+    const globalMed = median(meds);
+    if (globalMed && globalMed > 0) {
+      for (const p of pipelines) {
+        if (!p.flagged && typeof p.medianDurationMs === 'number' && p.medianDurationMs > globalMed * 3) {
+          p.flagged = true;
+          p.flagReason = `median run ${(p.medianDurationMs / 1000).toFixed(0)}s is >3× the project median (${(globalMed / 1000).toFixed(0)}s) — slow outlier`;
+        }
+      }
+    }
+
+    // Flagged first, then worst failRate, then most runs. Cap to maxPipelines.
+    pipelines.sort((a, b) =>
+      (Number(b.flagged) - Number(a.flagged)) ||
+      (b.failRate - a.failRate) ||
+      (b.total - a.total)
+    );
+    pipelines = pipelines.slice(0, maxPipelines);
+
+    const flaggedCount = pipelines.filter((p) => p.flagged).length;
+    console.log(`Rolled up ${pipelines.length} pipeline(s); ${flaggedCount} flagged.`);
+    for (const p of pipelines.filter((x) => x.flagged)) {
+      console.log(`  ⚠ ${p.workflowType}: ${p.flagReason}`);
+    }
+
+    return {
+      projectId,
+      lookbackHours,
+      scannedAt: new Date().toISOString(),
+      totalExecutions: considered.length,
+      pipelines,
+    };
+  },
+};

package/pipeline-supervisor/package.json

@@ -0,0 +1,19 @@
+{
+  "name": "pipeline-supervisor",
+  "version": "1.0.0",
+  "private": true,
+  "type": "module",
+  "description": "Zibby managing Zibby — a scheduled supervisor that scans the project's other pipelines, finds the failing/slow ones, and posts human-reviewable improvement proposals to Slack or Lark. Read + propose + notify only (v1 never edits other workflows).",
+  "main": "graph.mjs",
+  "scripts": {
+    "test": "vitest run"
+  },
+  "dependencies": {
+    "@zibby/core": "^0.5.1",
+    "@zibby/skills": "^0.1.26",
+    "zod": "^3.23.0"
+  },
+  "devDependencies": {
+    "vitest": "^2.1.5"
+  }
+}

package/pipeline-supervisor/state.js

@@ -0,0 +1,151 @@
+/**
+ * pipeline-supervisor — input + context schemas.
+ *
+ * "Zibby managing Zibby." A scheduled workflow that watches the project's
+ * OTHER pipelines, finds the ones that are failing / slow / repeatedly
+ * erroring, and posts a human-reviewable improvement proposal to Slack or
+ * Lark. v1 is strictly READ + PROPOSE + NOTIFY — it never edits another
+ * workflow's graph. That's the safe L3 starting point; the auto-PATCH step
+ * is a clearly-marked TODO in propose-node.js, deliberately NOT implemented.
+ *
+ * Trigger payload (inputSchema) carries the three per-run dials a human
+ * would actually want to tune at schedule time: how far back to look, how
+ * bad a pipeline has to be before we flag it, and an optional name filter.
+ * Everything else (the chat destination, the supervisor's read credential)
+ * is deploy-time ENV-tab config:
+ *
+ *   Required:
+ *     ZIBBY_PAT              Personal access token (zby_pat_…) the supervisor
+ *                            uses to READ this project's executions across
+ *                            ALL pipelines. The Fargate-injected
+ *                            PROJECT_API_TOKEN is a PROJECT token (authType
+ *                            'project', no userId) and the /executions +
+ *                            /jobs + /all read routes all require a user
+ *                            identity — so they 401 for a project token.
+ *                            A user PAT is the credential that works. See
+ *                            nodes/scan-pipelines-node.js for the full
+ *                            auth rationale.
+ *     SLACK_CHANNEL          channel id "C012345" or "#name"           ─┐ set
+ *     LARK_RECEIVE_ID        oc_… chat id, ou_… open id, or email      ─┘ ONE
+ *
+ *   Optional:
+ *     SUPERVISOR_PROJECT_ID  Project UUID to supervise. Defaults to the
+ *                            running project (PROJECT_ID env, injected by the
+ *                            executor) — i.e. the supervisor watches its own
+ *                            project's other pipelines. Set this to point it
+ *                            at a DIFFERENT project the PAT owner can access.
+ *     SLACK_MENTIONS         JSON array — appended to the proposal card.
+ *     LARK_MENTIONS          JSON array — appended to the proposal card.
+ */
+
+import { z } from 'zod';
+
+export const pipelineSupervisorInputSchema = z.object({
+  lookbackHours: z.number().int().min(1).max(720).default(24)
+    .describe('How many hours of execution history to scan across pipelines (1–720, default 24).'),
+
+  // A pipeline with >= this fraction of recent runs failing is "problem".
+  // 0.4 = flag anything failing 2 in 5 or worse. Tunable so a noisy team
+  // can raise it (only page on near-total breakage) or a strict team can
+  // lower it (catch flakiness early).
+  minFailRate: z.number().min(0).max(1).default(0.4)
+    .describe('Minimum failure rate (0–1) for a pipeline to be flagged as a problem. Default 0.4 = failing ≥40% of recent runs.'),
+
+  // Optional name filter. When set, only pipelines whose workflow type /
+  // slug matches one of these strings (case-insensitive substring) are
+  // considered — lets you supervise just "the deploy ones" without noise
+  // from every test run. Omit to consider every pipeline in the project.
+  targetWorkflowTypes: z.array(z.string().min(1)).optional()
+    .describe('Optional: only supervise pipelines whose workflow type/slug matches one of these (case-insensitive substring). Omit to scan all.'),
+
+  // Cap on how many distinct pipelines we'll fetch per-run job/log detail
+  // for. The scan lists executions cheaply; deep per-pipeline log reads are
+  // the expensive part, so we bound them. 25 covers any realistic project.
+  maxPipelines: z.number().int().min(1).max(100).default(25)
+    .describe('Max number of distinct pipelines to analyze in one run (1–100, default 25).'),
+});
+
+export const pipelineSupervisorContextSchema = z.object({
+  workspace: z.string().optional()
+    .describe('Workspace path — runner-injected; the supervisor doesn\'t need it but graph.run requires it.'),
+
+  // scan_pipelines — DETERMINISTIC. Pulls recent executions via the Zibby
+  // REST API (PAT-authed) and rolls them up per pipeline into a health
+  // summary the proposer reasons over.
+  scan_pipelines: z.object({
+    projectId: z.string().optional(),
+    lookbackHours: z.number().optional(),
+    scannedAt: z.string().optional(),
+    totalExecutions: z.number().optional(),
+    pipelines: z.array(z.object({
+      // A "pipeline" = one workflow type/slug within the project. Executions
+      // are grouped by their workflow identity.
+      workflowType: z.string(),
+      workflowUuid: z.string().optional(),
+      total: z.number(),
+      failed: z.number(),
+      succeeded: z.number(),
+      running: z.number(),
+      failRate: z.number(),
+      // Median wall-clock duration (ms) of completed runs — the "slow" signal.
+      medianDurationMs: z.number().optional(),
+      // The single worst recent run, for the proposer to cite a concrete
+      // example ("failed on step Y at 14:02").
+      worstRun: z.object({
+        executionId: z.string().optional(),
+        status: z.string().optional(),
+        durationMs: z.number().optional(),
+        failedStep: z.string().optional(),
+        errorSummary: z.string().optional(),
+        startedAt: z.string().optional(),
+      }).optional(),
+      // Whether this pipeline crossed minFailRate (or the slow threshold).
+      flagged: z.boolean(),
+      flagReason: z.string().optional(),
+    })),
+  }).optional(),
+
+  // propose_improvements — LLM. Reads the per-pipeline health summary and
+  // emits one concrete, reviewable improvement proposal per flagged pipeline.
+  propose_improvements: z.object({
+    proposals: z.array(z.object({
+      workflowType: z.string(),
+      problem: z.string(),
+      // The kind of change suggested — constrained so the UI / future
+      // auto-PATCH step can route on it. Maps to the four moves in the brief.
+      changeKind: z.enum([
+        'add_test_gate',
+        'tweak_prompt',
+        'add_human_approval_gate',
+        'drop_redundant_step',
+        'other',
+      ]),
+      suggestion: z.string(),
+      evidence: z.string().optional(),
+      confidence: z.number().min(0).max(1).optional(),
+    })),
+  }).optional(),
+
+  // notify — LLM + SKILLS.CHAT_NOTIFY. Posts ONE review card summarizing
+  // the proposals to the configured Slack or Lark destination.
+  notify: z.object({
+    dispatched: z.array(z.object({
+      status: z.enum(['sent', 'skipped', 'failed']),
+      recipient: z.object({
+        kind: z.enum(['channel', 'user_dm', 'usergroup']).nullish(),
+        id: z.string().nullish(),
+        label: z.string().nullish(),
+      }).nullish(),
+      proposalCount: z.number().nullish(),
+      messageTs: z.string().nullish(),   // Slack
+      messageId: z.string().nullish(),   // Lark
+      detail: z.string().nullish(),
+    })),
+    summary: z.object({
+      total: z.number(),
+      sent: z.number(),
+      skipped: z.number(),
+      failed: z.number(),
+    }),
+  }).optional(),
+});