@zibby/workflow-templates 0.4.2 → 0.7.0

package/index.js

@@ -53,8 +53,7 @@ export const TEMPLATES = {
         'Composition: character centered, slight forward lean, dynamic motion lines. Mood: cheerful, playful, fast.',
         'NO text, NO browser UI screenshots, NO outline wireframes.',
       ].join('\n'),
-      category: 'Testing',
-      tags: ['testing', 'playwright', 'e2e', 'browser'],
+      tags: ['Testing'],
       capabilities: [
         'Preflight LLM extracts assertions from a plain-English spec',
         'Live Playwright execution with screenshots + DOM at every step',
@@ -106,8 +105,7 @@ export const TEMPLATES = {
         'Composition: brackets centered, subtle drop shadow on the canvas. Mood: high-end, technical, confident — like the cover of a developer tool launch.',
         'NO text, NO outline wireframes, NO flat sticker style — this one is DEEP and 3D-rendered.',
       ].join('\n'),
-      category: 'Engineering',
-      tags: ['code-analysis', 'jira', 'github', 'test-generation'],
+      tags: ['Code Review', 'Testing'],
       capabilities: [
         'Clone repos + snapshot git baseline so changes are diff-able',
         'LLM gate: skip code-gen when ticket can\'t be implemented as-is',
@@ -150,8 +148,7 @@ export const TEMPLATES = {
         'Mood: friendly, approachable, slightly handmade. Like a children\'s book illustration applied to a developer tool.',
         'NO text, NO photo-realism, NO sleek 3D render — this one is hand-drawn and warm.',
       ].join('\n'),
-      category: 'Testing',
-      tags: ['testing', 'test-generation', 'pull-request', 'review'],
+      tags: ['Code Review', 'Testing'],
       capabilities: [
         'Skips ticket analysis — feed it the diff directly',
         'LLM explores the codebase to ground test steps in real components',
@@ -195,8 +192,7 @@ export const TEMPLATES = {
         'Mood: focused, energetic, signal-not-noise — the canonical Slack-flavored notification worker.',
         'NO text, NO letters, NO photo-realism, NO sleek 3D render, NO literal Slack wordmark — the colored pinwheel shape is allowed as the brand reference.',
       ].join('\n'),
-      category: 'Notifications',
-      tags: ['slack', 'notification', 'alert', 'child-workflow'],
+      tags: ['Notifications', 'child-workflow'],
       capabilities: [
         'Severity-coded Block Kit message (low/medium/high/critical)',
         'Code snippet + action button + caller mentions',
@@ -239,8 +235,7 @@ export const TEMPLATES = {
         'Mood: focused, professional, signal-not-noise.',
         'NO Lark / Feishu logo trademark, NO text, NO photo-realism.',
       ].join('\n'),
-      category: 'Notifications',
-      tags: ['lark', 'feishu', 'notification', 'alert', 'child-workflow'],
+      tags: ['Notifications', 'child-workflow'],
       capabilities: [
         'Severity-coded Lark Interactive Card',
         'Auto-detects receive_id_type from id prefix (chat_id / open_id / email)',
@@ -279,16 +274,14 @@ export const TEMPLATES = {
       slug: 'notify-notion',
       tagline: 'Reusable Notion archiver — durable record for any workflow.',
       iconPrompt: [
-        'Hand-painted gouache illustration with soft brushwork and gentle painterly texture, in the same family as the sentry-triage and generate-test-cases marketplace icons but with its own distinct character.',
-        'Subject: a friendly anthropomorphic notebook-document mascot — a small rounded notebook character with two big smiling eyes and a rosy blush, its open pages showing three painted horizontal ink-lines and a tiny checkmark in the corner. A soft halo of two or three little pastel page-flutter sparkles dance around it, suggesting a freshly-written entry being archived.',
-        'Background: a pale neutral Notion-flavored off-white gradient — warm cream at the top blending into a soft dove-grey at the base (#F7F3EC → #E8E4DA), with a single faint paper-grain texture and a couple of small floating pastel ink-spot dots for friendliness.',
-        'Centered composition with the notebook character as the focal point in the lower-center, sparkles arcing across the upper third; plenty of breathing room so the silhouette reads at 64×64 in the marketplace grid.',
-        'Mood is calm, archival, gently studious — the friendly notebook companion that keeps a tidy record, NOT corporate productivity or wall-of-text database.',
-        'Soft rounded square 1024×1024 canvas with a subtle paper-grain texture.',
-        'NO text, NO logo or trademarked marks, NO photo-realism, NO sleek 3D render, NO literal Notion trademark.',
+        'A premium, hi-fi app icon for "Notify Notion" — a workflow node that publishes reports to a Notion database. The real Notion brand mark will be composited on top in a post-process step; this prompt generates the BACKGROUND ONLY, with a clear empty area for the overlay.',
+        'Visual style: 3D-rendered hero object floating in space, in the style of Apple Vision Pro icons, Linear\'s changelog hero illustrations, or a Stripe product render. Glossy, dimensional, with subtle reflections and a soft rim-light. Same family as the code-analysis marketplace icon.',
+        'Subject: a single 3D-rendered page-document hero object made of glossy frosted glass / brushed silver metal, captured in head-on or near-head-on perspective (NOT three-quarter — keep the page face flat to the camera so the logo overlay sits cleanly). The page surface is COMPLETELY EMPTY — no lines, no text, no icons, no markings of any kind. The right edge curls slightly forward like a fresh page being filed, but the front face stays clean. A tiny cyan-teal glow accent sits in the upper-right corner of the page as a "freshly archived" signal.',
+        'Background: a deep midnight-navy gradient (#0F172A at the top, #1E1B4B at the bottom), with a single soft cyan glow behind the page and a few faint star-like specks scattered across the canvas. Square format, 1024×1024.',
+        'Composition: page centered, page face takes ~60-70% of the canvas and is empty/blank so a logo overlay can sit naturally on its surface. Subtle drop shadow. Mood: high-end, durable, archival — premium devtool aesthetic.',
+        'CRITICAL: the page front face must be COMPLETELY CLEAN AND EMPTY. NO N, NO letters, NO horizontal text lines, NO checkmark, NO icons, NO embossing, NO etching, NO decoration on the page surface. Just blank glossy material. NO Notion logo, NO Notion wordmark, NO trademarked marks. NO text anywhere. NO outline wireframes, NO flat sticker style, NO mascot, NO smiling face, NO cartoon. The page surface MUST be empty so a real logo PNG can be composited on it.',
       ].join('\n'),
-      category: 'Operations',
-      tags: ['notion', 'docs', 'reporting', 'knowledge-base', 'archive'],
+      tags: ['Notifications', 'Docs', 'Reports'],
       capabilities: [
         'Create a new page in a Notion database (POST /v1/pages)',
         'Append blocks to an existing page (PATCH /v1/blocks/{pageId}/children)',
@@ -306,49 +299,45 @@ export const TEMPLATES = {
     },
   },
 
-  // ── sentry-triage: parent workflow that uses notify-slack/-lark ──
+  // ── sentry-triage: hourly LLM triage → Slack OR Lark ─────────────
   'sentry-triage': {
     name: 'sentry-triage',
     displayName: 'Sentry Triage Bot',
-    description: 'Hourly Sentry triage — pulls new issues, drops obvious noise with a regex pre-filter, classifies survivors with LLM (CRITICAL/HIGH/MEDIUM/LOW/NOISE), and fans out alerts to a notify-slack OR notify-lark child workflow.',
+    description: 'Hourly Sentry triage that classifies new issues with an LLM rubric (CRITICAL/HIGH/MEDIUM/LOW/NOISE) and posts above-threshold alerts to your Slack or Lark — whichever you have connected.',
     path: join(__dirname, 'sentry-triage'),
     defaultSlug: 'sentry-triage',
-    deps: { zod: '^3.23.0' },
+    deps: { zod: '^3.23.0', '@zibby/skills': '^0.1.25' },
     features: [
-      '4-node graph: fetch → filter_noise → classify → dispatch_alerts',
-      'Regex noise filter before LLM cuts ~80% of classification cost',
-      'LLM severity classifier with explicit rubric (rules 1-5)',
-      'Sub-graph fan-out to notify-slack OR notify-lark (choose at deploy)',
-      'Per-issue failure isolation — one Slack hiccup doesn\'t stall the run',
-      'Configurable severityThreshold (don\'t notify on LOW noise)',
+      '3-node LLM graph: fetch_issues → classify → dispatch_alerts',
+      'Severity rubric with auditable reasoning per issue',
+      'Posts to Slack OR Lark (whichever the project has connected — chat_notify OR-group)',
+      'LLM dispatcher batches related issues into one message, dedupes near-duplicates',
+      'CRITICAL alerts get optional @-mentions; lower severities don\'t',
       'Cron-friendly: hourly schedule, default sinceMinutes=60',
     ],
     marketplace: {
       slug: 'sentry-triage',
-      tagline: 'Filter noise, classify severity, ping the right channel — every hour.',
+      tagline: 'Triage Sentry, ping your team — hourly.',
       iconPrompt: [
-        'Hand-painted storybook illustration in a warm gouache style with soft brushwork and gentle painterly texture, featuring the friendly round lighthouse mascot character with two big smiling eyes and a rosy blush on its white-and-coral-striped tower body, perched on a tiny mint-green island and clutching a small glowing purple SHIELD BADGE in front of its body — the badge is a rounded geometric emblem in Sentry\'s signature deep violet (#362D59 / #7553FF) with a stylized white "S"-mark inside it formed from overlapping rounded parallelogram shapes, painted with the same soft gouache brushstrokes as the rest of the scene so it feels integrated rather than corporate.',
+        'Hand-painted storybook illustration in a warm gouache style with soft brushwork and gentle painterly texture, featuring the friendly round lighthouse mascot character with two big smiling eyes and a rosy blush on its white-and-coral-striped tower body, perched on a tiny mint-green island and clutching a small glowing purple SHIELD BADGE in front of its body — the badge is a rounded geometric emblem in Sentry\'s signature deep violet (#362D59 / #7553FF) with a stylized white "S"-mark inside it formed from overlapping rounded parallelogram shapes.',
         'The lighthouse lantern emits a soft golden beam that catches one glowing amber alert orb while three faded grey noise specks drift harmlessly past, reinforcing the "filter the signal, calm the noise" idea.',
         'Background is a soft sunrise gradient of pale peach at the top blending through buttercream into a gentle wash of dusty lavender at the base, tying the warm scene to the violet of the badge; a few small fluffy pastel clouds float in for friendliness.',
-        'Centered composition with the purple shield badge as the immediate focal point in the lower-center, the lighthouse rising behind and slightly above it, beam angled diagonally; plenty of breathing room so the silhouette reads at 64×64 with the violet badge clearly visible at a glance.',
-        'Mood is warm, reassuring, optimistic — the friendly Sentry-flavored night-watch character, NOT tactical or corporate or alarming.',
+        'Centered composition with the purple shield badge as the immediate focal point in the lower-center, the lighthouse rising behind and slightly above it, beam angled diagonally; plenty of breathing room so the silhouette reads at 64×64.',
+        'Mood is warm, reassuring, optimistic — friendly night-watch character, 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 bug or insect imagery, NO literal Sentry wordmark.',
+        '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 bug or insect imagery, NO literal Sentry / Slack / Lark wordmark.',
       ].join('\n'),
-      category: 'Operations',
-      tags: ['sentry', 'observability', 'on-call', 'triage', 'alerting'],
+      tags: ['On-call', 'Bug Triage', 'Notifications'],
       capabilities: [
         'Hourly scheduled triage of new Sentry issues',
-        'Deterministic regex filter drops Script error / ResizeObserver / extension noise',
         'LLM severity classifier with auditable rubric',
-        'Dispatches to notify-slack or notify-lark (sub-graph, ~5ms in-process)',
-        'CRITICAL alerts get caller-supplied @-mentions; lower severities don\'t',
+        'Posts to Slack or Lark — whichever your project has connected',
+        'Batches related issues; CRITICAL-only @-mentions for on-call',
         'Configurable severity threshold per deploy',
       ],
       conversationStarters: [
         'Triage all new Sentry issues from the last hour',
-        'Notify #sentry-alerts when severity is HIGH or above',
-        'Run hourly and post a summary to our team Slack',
+        'Notify the on-call channel when severity is HIGH or above',
         'Page on-call when a CRITICAL error appears in checkout',
       ],
     },
@@ -375,16 +364,14 @@ export const TEMPLATES = {
       slug: 'ai-spend-weekly-digest',
       tagline: 'Track and explain your OpenAI / Anthropic / Cursor spending — every Monday morning, in Lark or Slack.',
       iconPrompt: [
-        'Hand-painted gouache illustration with soft brushwork and gentle painterly texture, featuring a friendly chubby pastel-pink piggy-bank character with two big smiling eyes and rosy blush, its body marked with a soft glowing dollar-sign sigil; the piggy is gently cradling a small stack of three coloured coins floating just above its back — a sky-blue coin for OpenAI-ish, a warm violet coin for Anthropic-ish, and a soft mint-green coin for Cursor-ish — each coin painted in the same loose gouache style with no logos or text on them, just abstract round chips.',
-        'A thin painterly trend-line ribbon arcs gently upward behind the piggy from lower-left to upper-right, suggesting "money over time", rendered as a soft watercolor ribbon in dusty rose with a tiny gentle peak near the top right.',
-        'Background is a calm sunrise gradient of pale buttercream at the top blending through soft peach into a gentle wash of pale mint at the base, with a few small pastel clouds for friendliness.',
-        'Centered composition with the piggy as the immediate focal point in the lower-center, the floating coins arcing across the upper third, the trend ribbon as background scaffolding; plenty of breathing room so the silhouette reads at 64×64.',
-        'Mood is warm, optimistic, gently informative — feels like a thoughtful finance friend, NOT corporate spreadsheet, NOT alarmist red.',
-        'Soft rounded square 1024×1024 canvas with a subtle paper-grain texture.',
-        'NO text, NO letters, NO numbers, NO photo-realism, NO sleek 3D render, NO chart axes or grid lines, NO dark navy or near-black backgrounds, NO literal OpenAI / Anthropic / Cursor logos or wordmarks, NO bar charts.',
+        'A premium, hi-fi app icon for "AI Spend Weekly Digest" — a workflow that reports cross-vendor LLM spend to engineering leaders.',
+        'Visual style: 3D-rendered hero object floating in space, in the style of Apple Vision Pro icons, Linear\'s changelog hero illustrations, or a Stripe product render. Glossy, dimensional, with subtle reflections and a soft rim-light.',
+        'Subject: a 3D-rendered stack of three glossy disc-shaped layered chips — like a tiny ascending bar-chart-of-coins — slightly rotated in three-quarter perspective. Each disc is a different premium accent color: top disc warm gold, middle disc cool platinum-silver, bottom disc deep iridescent purple. A single thin trending-up glowing line traces from lower-left to upper-right behind the stack, rendered as a soft neon ribbon (#7553FF violet glow), suggesting cost-over-time at a glance without literal axes.',
+        'Background: a deep midnight-navy gradient (#0F172A at the top, #1E1B4B at the bottom), with a single soft violet glow behind the stack and a few faint star-like specks scattered across the canvas. Square format, 1024×1024.',
+        'Composition: stack centered, subtle drop shadow on the canvas. Mood: high-end, executive, confident — like the cover image of a finance-ops product launch.',
+        'NO text, NO numbers, NO axes or grid lines, NO outline wireframes, NO flat sticker style, NO mascot, NO piggy bank, NO cartoon faces, NO trademarked OpenAI / Anthropic / Cursor logos — this one is DEEP and 3D-rendered.',
       ].join('\n'),
-      category: 'Operations',
-      tags: ['cost', 'finance', 'reporting', 'openai', 'anthropic', 'cursor', 'digest', 'weekly'],
+      tags: ['AI Spend', 'Cost Tracking', 'Reports'],
       capabilities: [
         'Pulls org-wide cost+usage from OpenAI, Anthropic, and Cursor admin APIs in parallel',
         'Joins customer attribution from provider-native project / workspace / member metadata',

package/notify-notion/brand/notion-logo.svg

@@ -0,0 +1,4 @@
+<svg width="100" height="100" viewBox="0 0 100 100" fill="none" xmlns="http://www.w3.org/2000/svg">
+  <path d="M6.017 4.313l55.333 -4.087c6.797 -0.583 8.543 -0.19 12.817 2.917l17.663 12.443c2.913 2.14 3.883 2.723 3.883 5.053v68.243c0 4.277 -1.553 6.807 -6.99 7.193L24.467 99.967c-4.08 0.193 -6.023 -0.39 -8.16 -3.113L3.3 79.94c-2.333 -3.113 -3.3 -5.443 -3.3 -8.167V11.113c0 -3.497 1.553 -6.413 6.017 -6.8z" fill="#fff"/>
+  <path fill-rule="evenodd" clip-rule="evenodd" d="M61.35 0.227l-55.333 4.087C1.553 4.7 0 7.617 0 11.113v60.66c0 2.723 0.967 5.053 3.3 8.167l13.007 16.913c2.137 2.723 4.08 3.307 8.16 3.113l64.257 -3.89c5.433 -0.387 6.99 -2.917 6.99 -7.193V20.64c0 -2.21 -0.873 -2.847 -3.443 -4.733L74.167 3.143c-4.273 -3.107 -6.02 -3.5 -12.817 -2.917zM25.92 19.523c-5.247 0.353 -6.437 0.433 -9.417 -1.99L8.927 11.507c-0.77 -0.78 -0.383 -1.753 1.557 -1.947l53.193 -3.887c4.467 -0.39 6.793 1.167 8.54 2.527l9.123 6.61c0.39 0.197 1.36 1.36 0.193 1.36l-54.933 3.307 -0.68 0.047zM19.803 88.3V30.367c0 -2.53 0.777 -3.697 3.103 -3.893L86 22.78c2.14 -0.193 3.107 1.167 3.107 3.693v57.547c0 2.53 -0.39 4.67 -3.883 4.863l-60.377 3.5c-3.493 0.193 -5.043 -0.97 -5.043 -4.083zm59.6 -54.827c0.387 1.75 0 3.5 -1.75 3.7l-2.91 0.577v42.773c-2.527 1.36 -4.853 2.137 -6.797 2.137 -3.107 0 -3.883 -0.973 -6.21 -3.887l-19.03 -29.94v28.967l6.02 1.363s0 3.5 -4.857 3.5l-13.39 0.777c-0.39 -0.78 0 -2.723 1.357 -3.11l3.497 -0.97v-38.3L30.48 40.667c-0.39 -1.75 0.58 -4.277 3.3 -4.473l14.367 -0.967 19.8 30.327v-26.83l-5.047 -0.58c-0.39 -2.143 1.163 -3.7 3.103 -3.89l13.4 -0.78z" fill="#000"/>
+</svg>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zibby/workflow-templates",
-  "version": "0.4.2",
+  "version": "0.7.0",
   "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",
@@ -72,6 +72,7 @@
   "dependencies": {
     "@anthropic-ai/sdk": "^0.88.0",
     "@zibby/agent-workflow": "^0.4.2",
+    "@zibby/skills": "^0.1.25",
     "axios": "^1.15.0",
     "handlebars": "^4.7.9",
     "zod": "^3.23.0 || ^4.0.0"

package/sentry-triage/graph.mjs

@@ -1,51 +1,41 @@
 /**
- * sentry-triage — parent workflow.
+ * sentry-triage — parent workflow. Hourly Sentry issue triage.
  *
- * Pipeline:
+ * Pipeline (3 LLM nodes, end-to-end agent-driven):
  *
- *   fetch_issues   (LLM + SKILLS.SENTRY)
+ *   fetch_issues    (LLM + SKILLS.SENTRY)        → list recent unresolved issues
  *        ↓
- *   filter_noise   (pure JS regex pre-filter — kills ~80% of LLM cost)
+ *   classify        (LLM, no tools)              → label NOISE/LOW/MEDIUM/HIGH/CRITICAL
  *        ↓
- *   classify       (LLM — assigns CRITICAL/HIGH/MEDIUM/LOW/NOISE per issue)
- *        ↓
- *   dispatch_alerts (custom execute — sub-graphs to notify-slack OR notify-lark
- *                    per issue at or above severityThreshold)
+ *   dispatch_alerts (LLM + SKILLS.CHAT_NOTIFY)   → batch + post to Slack OR Lark for
+ *                                                   issues ≥ SEVERITY_THRESHOLD
  *
- * Sub-graph dispatch: each "real" alert fans out to ONE notify-* child
- * workflow (configurable per deploy via state.notifyWorker). Failures
- * on individual alerts don't kill the triage run — failed entries are
- * reported in dispatch_alerts.summary.failed and surfaced in
- * onComplete logging.
+ * Why all three nodes are LLM (not deterministic for-loops):
+ *   - At hourly cadence with ≤20 issues/run, LLM cost is $1.50–$32/mo
+ *     depending on model. Trivial relative to Sentry / Slack subscriptions.
+ *   - LLM dispatch can BATCH related issues (5 errors in /checkout/ →
+ *     1 consolidated message) and DE-DUP near-duplicates. A
+ *     deterministic for-loop can't.
+ *   - outputSchema enforcement guarantees every above-threshold issue
+ *     either gets a "sent" record or an explicit "failed/skipped" —
+ *     no silent drops.
  *
- * In-process sub-graph execution (when both parent + child are bundled
- * in the same Fargate task) means each fan-out adds ~5ms overhead vs
- * an HTTP /trigger round-trip's 80s cold-start. For 20 issues that's
- * 100ms vs 1600s — the architecture is what makes this template
- * cheap enough to run hourly.
+ * Customize prompts: each node's prompt lives in its own module under
+ * nodes/. Override per-deploy by editing the file or by passing a
+ * custom prompt string via inputSchema (planned).
  */
 
-import { readFileSync, existsSync } from 'fs';
-import { join, dirname } from 'path';
-import { fileURLToPath } from 'url';
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';
 
 import { fetchIssuesNode } from './nodes/fetch-issues-node.js';
-import { filterNoiseNode } from './nodes/filter-noise-node.js';
 import { classifyNode } from './nodes/classify-node.js';
-import { dispatchAlertsNode } from './nodes/dispatch-alerts-node.js';
+import { dispatchNode } from './nodes/dispatch-node.js';
 
 import {
   sentryTriageInputSchema,
   sentryTriageContextSchema,
 } from './state.js';
 
-const __dirname = dirname(fileURLToPath(import.meta.url));
-function loadPrompt(filename) {
-  const path = join(__dirname, 'prompts', filename);
-  return existsSync(path) ? readFileSync(path, 'utf-8') : '';
-}
-
 export class SentryTriageAgent extends WorkflowAgent {
   buildGraph() {
     const graph = new WorkflowGraph();
@@ -53,14 +43,12 @@ export class SentryTriageAgent extends WorkflowAgent {
       .setInputSchema(sentryTriageInputSchema)
       .setContextSchema(sentryTriageContextSchema);
 
-    graph.addNode('fetch_issues', fetchIssuesNode, { prompt: loadPrompt('fetch-issues.md') });
-    graph.addNode('filter_noise', filterNoiseNode);
-    graph.addNode('classify',     classifyNode,    { prompt: loadPrompt('classify.md') });
-    graph.addNode('dispatch_alerts', dispatchAlertsNode);
+    graph.addNode('fetch_issues',    fetchIssuesNode);
+    graph.addNode('classify',        classifyNode);
+    graph.addNode('dispatch_alerts', dispatchNode);
 
     graph.setEntryPoint('fetch_issues');
-    graph.addEdge('fetch_issues',    'filter_noise');
-    graph.addEdge('filter_noise',    'classify');
+    graph.addEdge('fetch_issues',    'classify');
     graph.addEdge('classify',        'dispatch_alerts');
     graph.addEdge('dispatch_alerts', 'END');
 
@@ -69,10 +57,11 @@ export class SentryTriageAgent extends WorkflowAgent {
 
   async onComplete(result) {
     const s = result?.state?.dispatch_alerts?.summary || {};
-    const dropped = result?.state?.filter_noise?.dropped?.length || 0;
+    const classifications = result?.state?.classify?.classifications || [];
+    const noise = classifications.filter((c) => c.severity === 'NOISE').length;
     const fetched = result?.state?.fetch_issues?.issues?.length || 0;
     console.log(
-      `[sentry-triage] complete — fetched=${fetched}, noise=${dropped}, ` +
+      `[sentry-triage] complete — fetched=${fetched}, noise=${noise}, ` +
       `sent=${s.sent || 0}, skipped=${s.skipped || 0}, failed=${s.failed || 0}`,
     );
   }

package/sentry-triage/nodes/classify-node.js

@@ -1,14 +1,13 @@
 /**
  * classify node — LLM-driven severity classification.
  *
- * No tools — pure prompt + structured output. The prompt
- * (prompts/classify.md) carries the rubric (CRITICAL/HIGH/MEDIUM/LOW/
- * NOISE) and the LLM emits one classification record per kept issue.
+ * No tools — the LLM sees the rubric AND the concrete issues array
+ * (inlined as JSON at render time) and emits one classification record
+ * per issue. NOISE detection is part of the rubric itself; no separate
+ * pre-filter step.
  *
- * Temperature should be 0 (set by the runner via `model: 'auto'`'s
- * defaults for classification-style nodes). Schema enforcement
- * guarantees the emitted shape; bad models get a retry with the
- * outputSchema in the prompt.
+ * Severity threshold (skip-floor) lives on dispatch, NOT here — this
+ * node always classifies every issue. dispatch decides whether to send.
  */
 
 import { z } from '@zibby/core';
@@ -27,12 +26,98 @@ const ClassifyOutputSchema = z.object({
   classifications: z.array(ClassificationShape),
 });
 
+const RUBRIC = `You are the classify node of a Sentry triage workflow. Classify each Sentry issue into a severity bucket and explain WHY.
+
+The list of issues is appended below as a JSON array. Treat it as authoritative — do NOT call any tool, you have everything you need.
+
+# Severity rubric (apply IN ORDER, stop at first match)
+
+1. **NOISE** — these never warrant a human ping. Match if ANY:
+   - Title is "Script error." (cross-origin opaque error, no stack, useless)
+   - Title contains "Non-Error promise rejection captured"
+   - Title contains "ResizeObserver loop limit exceeded" or "ResizeObserver loop completed"
+   - culprit or metadata.filename URL starts with chrome-extension://, safari-extension://, moz-extension://, webkit-masked-url:// (user's extension crashed, not your code)
+   - Title or culprit mentions analytics SDKs: gtag, fbq, _paq, dataLayer, googletagmanager, piwik
+   - Title is "AbortError", contains "cancelled", or "Load failed" AND userCount < 3 (user navigated away)
+   - Title says "Test ", "Demo ", "[STAGING]" (wrong environment leakage)
+   - Stack trace has zero inApp:true frames (3rd-party only — not your code)
+   - User-agent in tags indicates a bot (Googlebot, AhrefsBot, etc.)
+
+2. **CRITICAL** if ANY of:
+   - userCount >= 20 (≥ 20 users affected — real prod impact)
+   - culprit or metadata.filename matches /payment|billing|checkout|auth|login|signup|session/i (security/revenue path)
+   - level === "fatal" and count >= 10
+   - count >= 100 AND firstSeen-to-lastSeen window is < 30 min (active spike)
+
+3. **HIGH** if ANY of:
+   - userCount >= 5 AND count >= 50
+   - level === "fatal" (any count)
+   - level === "error" AND userCount >= 3 AND count >= 20
+   - Errors in non-critical-but-important paths: settings, profile, search, dashboard, admin
+
+4. **MEDIUM** if ANY of:
+   - count >= 20 AND userCount >= 2
+   - count >= 50 regardless of userCount
+   - level === "error" AND count >= 10
+
+5. **LOW** — anything else (count < 20 AND userCount < 5, or level === "warning" | "info")
+
+# Recommended action per severity
+
+- CRITICAL → page_oncall (always notify, always mention rotation)
+- HIGH → notify_channel (notify, no @ unless deploy author known)
+- MEDIUM → notify_channel
+- LOW → digest_only (rolled into a daily summary, not real-time)
+- NOISE → ignore
+
+# Output shape
+
+For EACH issue in the JSON array below, emit ONE record:
+
+\`\`\`json
+{
+  "classifications": [
+    {
+      "issueId": "1234567890",
+      "severity": "CRITICAL",
+      "confidence": 0.95,
+      "reasoning": "12 users affected, culprit handleCheckout (payment path). Likely regression after recent deploy.",
+      "suggestedAction": "page_oncall",
+      "ruleMatched": "rule 2 (culprit matches /checkout/)"
+    }
+  ]
+}
+\`\`\`
+
+# Rules
+
+- confidence reflects how cleanly the issue matched. CRITICAL in /payment/ with userCount=50 → 0.95. Borderline → 0.6.
+- reasoning is ONE sentence written for an on-call engineer. Lead with the impact metric.
+- ruleMatched is which numbered rule fired. Helps operators tune the rubric over time.
+- Be consistent: same issue twice should always get the same severity.
+- Temperature 0. Classification, not creative writing.
+
+# Do NOT
+
+- Classify more issues than appear in the array below.
+- Skip issues — every issue in the array must appear in the output (NOISE included).
+- Use any severity outside NOISE|LOW|MEDIUM|HIGH|CRITICAL.
+- Call any tools.`;
+
+const CLASSIFY_PROMPT = (state = {}) => {
+  const issues = state?.fetch_issues?.issues || [];
+  return `${RUBRIC}
+
+## Issues to classify
+
+\`\`\`json
+${JSON.stringify(issues, null, 2)}
+\`\`\`
+`;
+};
+
 export const classifyNode = {
   name: 'classify',
-  // NO skills — this is a pure reasoning step; the LLM has all data
-  // it needs in state.filter_noise.kept. Adding skills would let the
-  // LLM call Sentry tools for "more context", which we don't want
-  // (rubric is supposed to be deterministic).
   outputSchema: ClassifyOutputSchema,
-  timeout: 90 * 1000,
+  prompt: CLASSIFY_PROMPT,
 };

package/sentry-triage/nodes/dispatch-node.js

@@ -0,0 +1,143 @@
+/**
+ * dispatch_alerts node — LLM-driven dispatcher.
+ *
+ * The agent sees ALL classified issues + their full data and makes
+ * judgment calls before calling the chat tool:
+ *   - Bulk related issues into ONE message (5 errors in /checkout/ →
+ *     "⚠️ Checkout spike: 5 errors, top: ...").
+ *   - De-dupe near-duplicates ("seen 3 times, same culprit").
+ *   - Honor SEVERITY_THRESHOLD (skip anything below).
+ *   - Attach mentions only on CRITICAL.
+ *
+ * Provider routing: chatNotifySkill.resolve() picks the slack OR lark
+ * MCP server based on which ENV var is set, so the LLM only ever sees
+ * ONE provider's tools (slack_* or lark_*) — it can't accidentally
+ * call the wrong one.
+ *
+ * Reliability: outputSchema enforces a `dispatched` record per
+ * group + summary counts. A malformed LLM response triggers a retry
+ * with the schema embedded.
+ *
+ * ENV tab config:
+ *   SLACK_CHANNEL OR LARK_RECEIVE_ID  — required, pick one
+ *   SEVERITY_THRESHOLD                — NOISE|LOW|MEDIUM|HIGH|CRITICAL (default MEDIUM)
+ *   SLACK_MENTIONS OR LARK_MENTIONS   — JSON array, optional, CRITICAL only
+ */
+
+import { z, SKILLS } from '@zibby/core';
+import { SEVERITY_LEVELS } from '../state.js';
+
+const DispatchAlertsOutputSchema = z.object({
+  dispatched: z.array(z.object({
+    issueIds: z.array(z.string()).describe('IDs grouped into this message; usually 1, more when batched.'),
+    severity: z.enum(SEVERITY_LEVELS),
+    status: z.enum(['sent', 'skipped', 'failed']),
+    messageTs: z.string().optional(),  // Slack
+    messageId: z.string().optional(),  // Lark
+    detail: z.string().optional(),
+  })),
+  summary: z.object({
+    total: z.number().describe('Number of messages POSTED (not issues — batched groups count as 1).'),
+    sent: z.number(),
+    skipped: z.number(),
+    failed: z.number(),
+  }),
+});
+
+const DISPATCH_PROMPT = (state = {}) => {
+  const issues = state?.fetch_issues?.issues || [];
+  const classifications = state?.classify?.classifications || [];
+
+  const threshold     = process.env.SEVERITY_THRESHOLD || 'MEDIUM';
+  const slackChannel  = process.env.SLACK_CHANNEL      || '';
+  const larkReceiveId = process.env.LARK_RECEIVE_ID    || '';
+
+  let provider, toolName, recipientLine, mentionsRaw;
+  if (slackChannel) {
+    provider = 'slack';
+    toolName = 'slack_post_message';
+    recipientLine = `Post every message to Slack channel: ${JSON.stringify(slackChannel)}\nCall: slack_post_message({ channel: "${slackChannel}", text: "…" })`;
+    mentionsRaw = process.env.SLACK_MENTIONS || '[]';
+  } else if (larkReceiveId) {
+    provider = 'lark';
+    toolName = 'lark_send_message';
+    recipientLine = `Post every message to Lark receive_id: ${JSON.stringify(larkReceiveId)}\nCall: lark_send_message({ receive_id: "${larkReceiveId}", text: "…" })`;
+    mentionsRaw = process.env.LARK_MENTIONS || '[]';
+  } else {
+    throw new Error('sentry-triage: configure SLACK_CHANNEL (for Slack) or LARK_RECEIVE_ID (for Lark) in the ENV tab.');
+  }
+
+  let mentions;
+  try { mentions = JSON.parse(mentionsRaw); } catch { mentions = []; }
+  if (!Array.isArray(mentions)) mentions = [];
+
+  return `You are the dispatch_alerts node of a Sentry triage workflow. Post chat alerts using the **${toolName}** tool.
+
+# Recipient
+${recipientLine}
+
+# Severity threshold
+Skip any issue below: ${threshold}
+(Severity order, low → high: ${SEVERITY_LEVELS.join(' < ')})
+
+# Mentions
+CRITICAL messages only — prepend: ${JSON.stringify(mentions.join(' '))}
+HIGH/MEDIUM/LOW — no mentions.
+
+# Your judgment
+- Batch issues with the same culprit / metadata.filename into ONE message.
+- De-dupe near-duplicates (e.g. same error text in different paths). Mention "seen N times".
+- Keep each message short. Lead with severity in *[BRACKETS]*. Include the Sentry permalink so the on-call can click through.
+
+# Message format (template, adapt as needed)
+\`\`\`
+*[CRITICAL]* TypeError: Cannot read 'id' of undefined
+12 users hit /checkout — likely regression on r1234.
+📍 handleCheckout(checkout.ts) · 47 events
+https://sentry.io/.../1234/
+\`\`\`
+
+# Output (outputSchema-enforced)
+
+Return ONE record per ${toolName} call you actually made (or skipped/failed).
+\`issueIds\` is an array — for batched messages it carries every issue in the group.
+\`severity\` is the highest severity in the group.
+
+\`\`\`json
+{
+  "dispatched": [
+    { "issueIds": ["1", "5", "7"], "severity": "CRITICAL", "status": "sent"${provider === 'slack' ? ', "messageTs": "1716109330.555"' : ', "messageId": "om_xxxxx"'} }
+  ],
+  "summary": { "total": 1, "sent": 1, "skipped": 0, "failed": 0 }
+}
+\`\`\`
+
+# Issues + classifications
+
+Each entry below has the Sentry issue plus the classifier's verdict + reasoning. Use both.
+
+\`\`\`json
+${JSON.stringify(
+    issues.map((issue) => {
+      const c = classifications.find((x) => String(x.issueId) === String(issue.id));
+      return { ...issue, classification: c || { severity: 'LOW' } };
+    }),
+    null,
+    2,
+  )}
+\`\`\`
+
+# Rules
+- Skip below-threshold issues silently (just include them in dispatched with status="skipped"; no chat call).
+- DON'T invent severities or issue IDs. Use what's given.
+- DON'T post more messages than necessary. If 5 issues are clearly one bug, post 1 message.
+- DO post if in doubt — under-paging is worse than over-paging for triage.
+`;
+};
+
+export const dispatchNode = {
+  name: 'dispatch_alerts',
+  skills: [SKILLS.CHAT_NOTIFY],
+  outputSchema: DispatchAlertsOutputSchema,
+  prompt: DISPATCH_PROMPT,
+};

package/sentry-triage/nodes/fetch-issues-node.js

@@ -1,21 +1,32 @@
 /**
- * fetch_issues node — LLM-driven, uses SKILLS.SENTRY.
+ * fetch_issues — DETERMINISTIC. Calls Sentry's REST API directly via
+ * the @zibby/skills client. No LLM, no MCP tool round-trip.
  *
- * The LLM is given the sentry_list_issues tool and asked to fetch the
- * recent unresolved/unassigned issue list. The prompt (prompts/fetch-issues.md)
- * tells it the exact query string to use; the agent shouldn't deviate.
+ * Why deterministic: the previous LLM-driven version hard-coded the
+ * query string and explicitly forbade filtering or follow-up calls.
+ * The LLM added zero judgment — just one round-trip of latency and
+ * ~$0.01-0.05 of token cost per run. At hourly cadence across many
+ * customers, that compounds; deterministic also removes the "LLM
+ * hallucinated query string" failure mode.
  *
- * Why an LLM node here (not a custom-execute Sentry API call): the
- * Sentry skill's tool surface is the canonical way to interact with
- * Sentry from a workflow, and consistent across all sentry-* templates
- * we'll add (autofix, incident). Bypassing it for fetch-only would
- * duplicate auth/rate-limit handling code in every template.
+ * Why still declare `skills: [SKILLS.SENTRY]`: the backend bundler
+ * reads this to build `workflow.requiredIntegrations`, which the
+ * marketplace deploy modal uses to gate install until Sentry is
+ * connected. Without it, users could install with no Sentry token
+ * wired up and the first run would 401. The skill's runtime tool
+ * injection is a no-op here (no prompt for an LLM to call them), but
+ * the integration-requirement signal still matters — same pattern as
+ * ai-spend-weekly-digest's fetch-spending-node.
  *
- * Output validation is enforced by outputSchema — if the LLM emits a
- * malformed payload, the runtime retries with the schema embedded.
+ * Auth: sentryListIssues uses resolveIntegrationToken('sentry') which
+ * hits the backend's project-scoped resolver via PROJECT_API_TOKEN +
+ * PROGRESS_API_URL env vars (set on every Fargate task by
+ * workflow-executor.js).
  */
 
-import { z, SKILLS } from '@zibby/core';
+import { z } from 'zod';
+import { SKILLS } from '@zibby/core';
+import { sentryListIssues } from '@zibby/skills/sentry';
 
 const IssueShape = z.object({
   id: z.string(),
@@ -38,15 +49,37 @@ const IssueShape = z.object({
 
 const FetchIssuesOutputSchema = z.object({
   issues: z.array(IssueShape),
-  fetchedAt: z.string().optional(),
+  fetchedAt: z.string(),
 });
 
 export const fetchIssuesNode = {
   name: 'fetch_issues',
   skills: [SKILLS.SENTRY],
   outputSchema: FetchIssuesOutputSchema,
-  // 60s — Sentry API is usually fast but the LLM round-trip + tool
-  // call sequence (often 2-3 turns for the agent to settle) needs
-  // breathing room.
-  timeout: 60 * 1000,
+  execute: async (context) => {
+    // State access pattern mirrors fetch-spending-node — the framework
+    // passes a context whose `.state.getAll()` returns the flat state,
+    // but tests sometimes pass the state object directly as context.
+    const state = (context?.state && typeof context.state.getAll === 'function')
+      ? context.state.getAll()
+      : context;
+
+    const sinceMinutes = Number(state?.sinceMinutes) || 60;
+
+    const issues = await sentryListIssues({
+      query: `is:unresolved is:unassigned firstSeen:-${sinceMinutes}m`,
+      sort: 'created',
+      // 100 issues is the practical ceiling for a triage notification.
+      // Beyond that, classify+dispatch lose signal — a "deluge" digest
+      // tells the user nothing actionable. If a customer regularly
+      // exceeds 100/hour they need to tighten the Sentry filters
+      // upstream, not raise this cap.
+      limit: 100,
+    });
+
+    return {
+      issues,
+      fetchedAt: new Date().toISOString(),
+    };
+  },
 };

package/sentry-triage/package.json

@@ -3,13 +3,14 @@
   "version": "1.0.0",
   "private": true,
   "type": "module",
-  "description": "Hourly Sentry issue triage bot — filters noise, classifies severity with LLM, dispatches notifications to Slack/Lark via sub-graph.",
+  "description": "Hourly Sentry issue triage bot — LLM-classifies new issues by severity and pings Slack OR Lark for anything ≥ threshold.",
   "main": "graph.mjs",
   "scripts": {
     "test": "vitest run"
   },
   "dependencies": {
     "@zibby/core": "^0.5.1",
+    "@zibby/skills": "^0.1.25",
     "zod": "^3.23.0"
   },
   "devDependencies": {

package/sentry-triage/state.js

@@ -1,76 +1,40 @@
 /**
- * sentry-triage — three-schema state model.
+ * sentry-triage — input + context schemas.
  *
- * Triage flow:
- *   1. fetch_issues   (LLM + sentry skill)  — pull recent unresolved
- *      issues from Sentry
- *   2. filter_noise   (custom execute)       — drop known-noise patterns
- *      (browser-extension URLs, ResizeObserver loops, etc.) WITHOUT
- *      paying an LLM call per issue
- *   3. classify       (LLM)                  — classify the survivors as
- *      NOISE / LOW / MEDIUM / HIGH / CRITICAL with reasoning
- *   4. dispatch_alerts (custom execute)      — sub-graph dispatch to
- *      notify-slack OR notify-lark for issues above severityThreshold
+ * Trigger payload (inputSchema) is intentionally tiny: just sinceMinutes,
+ * the one per-run dial. Everything else is deploy-time ENV-tab config:
  *
- * Why sub-graph dispatch (not built-in notify here):
- *   - notify-slack / notify-lark are reusable across MANY parent
- *     workflows (sentry-autofix, sentry-incident, cron-summary, etc.).
- *   - Adding a new channel (Discord, Teams) means adding a new child
- *     workflow — sentry-triage code never changes.
- *   - In-process sub-graph dispatch is ~5ms overhead in cloud, so the
- *     architectural cleanliness costs nothing.
+ *   Required (set ONE — at least one chat target):
+ *     SLACK_CHANNEL          channel id "C012345" or "#name"
+ *     LARK_RECEIVE_ID        oc_… chat id, ou_… open id, or email
+ *
+ *   Optional:
+ *     SEVERITY_THRESHOLD     NOISE|LOW|MEDIUM|HIGH|CRITICAL (default MEDIUM)
+ *     SLACK_MENTIONS         JSON array — appended to CRITICAL Slack alerts only
+ *     LARK_MENTIONS          JSON array — appended to CRITICAL Lark alerts only
  */
 
 import { z } from 'zod';
 
+// Ordered low → high. Index doubles as severity rank.
 export const SEVERITY_LEVELS = /** @type {const} */ (['NOISE', 'LOW', 'MEDIUM', 'HIGH', 'CRITICAL']);
 
+/** True iff severity is at or above threshold per SEVERITY_LEVELS order. */
+export function meetsSeverityThreshold(severity, threshold) {
+  const s = SEVERITY_LEVELS.indexOf(severity);
+  const t = SEVERITY_LEVELS.indexOf(threshold);
+  return (s === -1 ? 0 : s) >= (t === -1 ? SEVERITY_LEVELS.indexOf('MEDIUM') : t);
+}
+
 export const sentryTriageInputSchema = z.object({
-  // ── Sentry source ────────────────────────────────────────────────
-  organizationSlug: z.string().min(1)
-    .describe('Sentry organization slug (the URL segment after sentry.io/organizations/).'),
-  projectSlug: z.string().min(1)
-    .describe('Sentry project slug — limits triage to a single project.'),
-  environment: z.string().default('production')
-    .describe('Sentry environment tag to filter by (defaults to production).'),
   sinceMinutes: z.number().int().min(5).max(1440).default(60)
-    .describe('Look back this many minutes for newly-firstSeen issues. Hourly cron → 60.'),
-
-  // ── Triage thresholds ────────────────────────────────────────────
-  severityThreshold: z.enum(SEVERITY_LEVELS).default('MEDIUM')
-    .describe('Only dispatch alerts for issues at or above this severity. Drop the rest.'),
-  maxIssues: z.number().int().min(1).max(100).default(20)
-    .describe('Cap issues processed per run. Protects against an unexpected error storm.'),
-
-  // ── Where to send alerts ────────────────────────────────────────
-  notifyWorker: z.enum(['notify-slack', 'notify-lark']).default('notify-slack')
-    .describe(
-      'Which child workflow to dispatch alerts to. Both must be deployed in the same project ' +
-      'as this triage workflow. Pick whichever messaging platform your team uses.',
-    ),
-
-  // For notify-slack
-  slackChannel: z.string().min(1).max(120).optional()
-    .describe('Slack channel id (C012345) or #name. Required when notifyWorker=notify-slack.'),
-  slackMentions: z.array(z.string().max(60)).max(10).optional()
-    .describe('Mentions to append on CRITICAL alerts only, e.g. ["<!subteam^S0ONCALL>"].'),
-
-  // For notify-lark
-  larkReceiveId: z.string().min(1).max(120).optional()
-    .describe('Lark chat id (oc_…), open id (ou_…), or email. Required when notifyWorker=notify-lark.'),
-  larkMentions: z.array(z.string().max(200)).max(10).optional()
-    .describe('Lark @-mention strings for CRITICAL alerts.'),
-
-  model: z.string().default('auto')
-    .describe('LLM model override for classify_issues. Default auto-selects.'),
+    .describe('Lookback minutes (5–1440)'),
 });
 
 export const sentryTriageContextSchema = z.object({
-  // Runner-injected
   workspace: z.string().optional()
-    .describe('Workspace path — set by runner. Triage doesn\'t need it but graph.run requires it.'),
+    .describe('Workspace path — runner-injected; triage doesn\'t need it but graph.run requires it.'),
 
-  // Node outputs (mid-graph, keyed by node name)
   fetch_issues: z.object({
     issues: z.array(z.object({
       id: z.string(),
@@ -93,14 +57,6 @@ export const sentryTriageContextSchema = z.object({
     fetchedAt: z.string().optional(),
   }).optional(),
 
-  filter_noise: z.object({
-    kept: z.array(z.any()),
-    dropped: z.array(z.object({
-      id: z.string(),
-      reason: z.string(),
-    })),
-  }).optional(),
-
   classify: z.object({
     classifications: z.array(z.object({
       issueId: z.string(),
@@ -114,7 +70,11 @@ export const sentryTriageContextSchema = z.object({
 
   dispatch_alerts: z.object({
     dispatched: z.array(z.object({
-      issueId: z.string(),
+      // Deterministic dispatcher emits issueId; LLM batcher emits issueIds[].
+      // messageTs (Slack) and messageId (Lark) are both optional — only the
+      // variant that ran will populate one of them.
+      issueId: z.string().optional(),
+      issueIds: z.array(z.string()).optional(),
       severity: z.enum(SEVERITY_LEVELS),
       status: z.enum(['sent', 'skipped', 'failed']),
       detail: z.string().optional(),
@@ -129,6 +89,3 @@ export const sentryTriageContextSchema = z.object({
     }),
   }).optional(),
 });
-
-export const sentryTriageStateSchema =
-  sentryTriageInputSchema.merge(sentryTriageContextSchema);

package/sentry-triage/nodes/dispatch-alerts-node.js

@@ -1,191 +0,0 @@
-/**
- * dispatch-alerts node — sub-graph fan-out to notify-slack/notify-lark.
- *
- * For each classified issue at or above severityThreshold:
- *   - Build a provider-neutral notification payload (severity, title,
- *     body, sentryLink, etc.) from the merged issue + classification
- *     records.
- *   - Add caller-supplied per-provider config (channel for Slack,
- *     receiveId for Lark, severity-conditional mentions).
- *   - dispatchSubgraph(state.notifyWorker, { input }) — SYNC mode so we
- *     get back the messageTs/messageId for the summary.
- *   - Continue on per-issue failure (notify failure shouldn't kill the
- *     whole triage run; we report `status: 'failed'` and move on).
- *
- * Sub-graph dispatch goes via in-process executor when the child is
- * bundled in the same Fargate task. The runtime threshold for severity
- * is enforced HERE, not in the LLM classifier, so an operator can
- * raise/lower the bar at deploy time without redeploying.
- */
-
-import { z } from 'zod';
-import { dispatchSubgraph } from '@zibby/agent-workflow';
-import { SEVERITY_LEVELS } from '../state.js';
-
-const DispatchAlertsOutputSchema = z.object({
-  dispatched: z.array(z.object({
-    issueId: z.string(),
-    severity: z.enum(SEVERITY_LEVELS),
-    status: z.enum(['sent', 'skipped', 'failed']),
-    detail: z.string().optional(),
-    messageTs: z.string().optional(),
-    messageId: z.string().optional(),
-  })),
-  summary: z.object({
-    total: z.number(),
-    sent: z.number(),
-    skipped: z.number(),
-    failed: z.number(),
-  }),
-});
-
-const SEVERITY_RANK = Object.freeze({
-  NOISE: 0, LOW: 1, MEDIUM: 2, HIGH: 3, CRITICAL: 4,
-});
-
-/**
- * Build the provider-neutral notification payload from issue + classification.
- * Pure function — exposed for tests so we can pin the wire shape.
- */
-export function buildNotifyPayload({ issue, classification, state }) {
-  const severityRaw = classification?.severity || 'LOW';
-  // notify-* workflows want lowercase severity (their inputSchema enum).
-  const severity = severityRaw.toLowerCase();
-  const reason = classification?.reasoning || '';
-  const userCount = typeof issue.userCount === 'number' ? issue.userCount : undefined;
-  const events = typeof issue.count === 'number' ? issue.count
-                : (typeof issue.count === 'string' && /^\d+$/.test(issue.count)) ? Number(issue.count)
-                : undefined;
-  const release = issue?.metadata?.release
-                || (issue.tags || []).find?.((t) => t.key === 'release')?.value
-                || undefined;
-  const firstSeen = issue.firstSeen || undefined;
-
-  const culpritLine = issue.culprit ? `\n📍 ${issue.culprit}` : '';
-  const reasonLine = reason ? `\n${reason}` : '';
-  const body = `${classification?.suggestedAction ? `*Action:* ${classification.suggestedAction}\n` : ''}` +
-               `${reasonLine}${culpritLine}`.trim();
-
-  // Code snippet: when fetch_issues populated metadata.filename, use it
-  // as a one-line hint. v2 will pull the actual context lines.
-  const codeSnippet = issue?.metadata?.filename
-    ? `${issue.metadata.filename}\n// ${issue.metadata.value || issue.title}`
-    : undefined;
-
-  // Mentions: only attach on CRITICAL. Lower severities get no @-blast.
-  const isCritical = severityRaw === 'CRITICAL';
-  const slackMentions = isCritical && Array.isArray(state.slackMentions) ? state.slackMentions : undefined;
-  const larkMentions  = isCritical && Array.isArray(state.larkMentions)  ? state.larkMentions  : undefined;
-
-  // Common fields both providers accept.
-  const common = {
-    severity,
-    title: issue.title || issue.shortId || `Sentry ${issue.id}`,
-    body: body || undefined,
-    sentryLink: issue.permalink || undefined,
-    affectedUsers: userCount,
-    events,
-    release,
-    firstSeen,
-    codeSnippet,
-  };
-
-  if (state.notifyWorker === 'notify-lark') {
-    return {
-      ...common,
-      receiveId: state.larkReceiveId,
-      ...(larkMentions ? { mentions: larkMentions } : {}),
-    };
-  }
-  // default → notify-slack
-  return {
-    ...common,
-    channel: state.slackChannel,
-    ...(slackMentions ? { mentions: slackMentions } : {}),
-  };
-}
-
-/**
- * Convenience for unit tests + the node body. Decides whether a given
- * classification meets the threshold.
- */
-export function meetsSeverityThreshold(severity, threshold) {
-  const s = SEVERITY_RANK[severity] ?? 0;
-  const t = SEVERITY_RANK[threshold] ?? SEVERITY_RANK.MEDIUM;
-  return s >= t;
-}
-
-export const dispatchAlertsNode = {
-  name: 'dispatch_alerts',
-  outputSchema: DispatchAlertsOutputSchema,
-  timeout: 5 * 60 * 1000, // 5min — generous for fan-out across 20 children
-  execute: async (context) => {
-    const state = (context?.state && typeof context.state.getAll === 'function')
-      ? context.state.getAll()
-      : context;
-
-    const issues = state?.filter_noise?.kept || state?.fetch_issues?.issues || [];
-    const classifications = state?.classify?.classifications || [];
-    const classMap = new Map(classifications.map((c) => [c.issueId, c]));
-    const threshold = state.severityThreshold || 'MEDIUM';
-    const worker = state.notifyWorker || 'notify-slack';
-
-    // Validate the right per-provider config field is set.
-    if (worker === 'notify-slack' && !state.slackChannel) {
-      throw new Error('sentry-triage: slackChannel is required when notifyWorker=notify-slack');
-    }
-    if (worker === 'notify-lark' && !state.larkReceiveId) {
-      throw new Error('sentry-triage: larkReceiveId is required when notifyWorker=notify-lark');
-    }
-
-    const dispatched = [];
-    for (const issue of issues) {
-      const classification = classMap.get(String(issue.id));
-      const severity = classification?.severity || 'LOW';
-
-      if (!meetsSeverityThreshold(severity, threshold)) {
-        dispatched.push({
-          issueId: String(issue.id),
-          severity,
-          status: 'skipped',
-          detail: `severity ${severity} below threshold ${threshold}`,
-        });
-        continue;
-      }
-
-      const payload = buildNotifyPayload({ issue, classification, state });
-      try {
-        // Sync sub-graph dispatch. The in-process executor returns the
-        // child's finalState (or the extracted `output`). We pull
-        // messageTs / messageId by checking both shapes since the parent
-        // is provider-agnostic at this layer.
-        const result = await dispatchSubgraph(worker, {
-          input: payload,
-          async: false,
-        });
-        dispatched.push({
-          issueId: String(issue.id),
-          severity,
-          status: 'sent',
-          messageTs: result?.notify_slack?.messageTs || result?.messageTs,
-          messageId: result?.notify_lark?.messageId  || result?.messageId,
-        });
-      } catch (err) {
-        dispatched.push({
-          issueId: String(issue.id),
-          severity,
-          status: 'failed',
-          detail: err?.message || String(err),
-        });
-      }
-    }
-
-    const summary = {
-      total: dispatched.length,
-      sent: dispatched.filter((d) => d.status === 'sent').length,
-      skipped: dispatched.filter((d) => d.status === 'skipped').length,
-      failed: dispatched.filter((d) => d.status === 'failed').length,
-    };
-    return { dispatched, summary };
-  },
-};

package/sentry-triage/nodes/filter-noise-node.js

@@ -1,112 +0,0 @@
-/**
- * filter-noise node — deterministic regex-based pre-LLM filter.
- *
- * Cuts LLM cost ~80% on a typical Sentry stream by dropping issues
- * that are obviously noise BEFORE we pay for classification. The
- * patterns are deliberately conservative — anything ambiguous goes
- * through to the LLM classifier rather than being killed here.
- *
- * Noise categories (matched in order; first hit wins):
- *
- *   1. Cross-origin / opaque errors:
- *      - "Script error." (literal, with period) — useless without CORS
- *      - "Non-Error promise rejection captured"
- *
- *   2. Browser-internal benign loops:
- *      - "ResizeObserver loop limit exceeded"
- *      - "ResizeObserver loop completed with undelivered notifications"
- *
- *   3. Browser-extension noise — any frame URL with extension scheme:
- *      - chrome-extension://, safari-extension://, moz-extension://
- *
- *   4. Cancelled/aborted requests (user navigated away):
- *      - "AbortError", title containing "cancelled" / "Failed to fetch"
- *        AND empty stack frames
- *
- *   5. Bot/crawler traffic — usually surfaces via specific tag patterns;
- *      v1 doesn't have the tags in our payload shape so we skip. Add
- *      when the event-detail path is wired in.
- *
- * Anything not matching falls through to the LLM. The output carries
- * BOTH the kept list and the dropped list (with reason) so the
- * downstream dispatcher can report on filter activity ("auto-ignored
- * 14 noise issues this hour").
- */
-
-import { z } from 'zod';
-
-const FilterNoiseOutputSchema = z.object({
-  kept: z.array(z.any()).describe('Issues that survive the noise filter — passed to LLM classifier.'),
-  dropped: z.array(z.object({
-    id: z.string(),
-    reason: z.string(),
-  })).describe('Issues filtered out and why — surfaced in the final summary.'),
-});
-
-/** Test hook — exposes the rule table so unit tests can assert
- *  per-pattern matching without re-typing them. */
-export const NOISE_RULES = Object.freeze([
-  { reason: 'cross-origin opaque error',     test: (issue) => /^Script error\.?$/i.test((issue.title || '').trim()) },
-  { reason: 'non-Error promise rejection',   test: (issue) => /Non-Error promise rejection captured/i.test(issue.title || '') },
-  { reason: 'ResizeObserver loop',           test: (issue) => /ResizeObserver loop (limit exceeded|completed)/i.test(issue.title || '') },
-  { reason: 'browser-extension frame',       test: (issue) => isExtensionUrl(issue?.metadata?.filename) || isExtensionUrl(issue?.culprit) },
-  { reason: 'analytics SDK',                 test: (issue) => /\b(gtag|fbq|_paq|dataLayer|googletagmanager|piwik)\b/i.test(`${issue.title || ''} ${issue.culprit || ''}`) },
-  { reason: 'aborted/cancelled request',     test: (issue) => /AbortError|cancelled|Load failed/i.test(issue.title || '') && (!issue.userCount || issue.userCount < 3) },
-]);
-
-function isExtensionUrl(url) {
-  if (!url || typeof url !== 'string') return false;
-  return /^(?:chrome-extension|safari-extension|moz-extension|webkit-masked-url):\/\//.test(url)
-    || /chrome-extension:\/\//.test(url)
-    || /safari-extension:\/\//.test(url);
-}
-
-/**
- * Run the noise filter on an array of issues. Returns
- * `{ kept, dropped }`. Pure function — exposed so tests can call it
- * without going through the node's execute wrapper.
- */
-export function filterNoiseIssues(issues) {
-  const kept = [];
-  const dropped = [];
-  for (const issue of issues || []) {
-    if (!issue || typeof issue !== 'object' || !issue.id) {
-      // Defensive: malformed entries go to dropped rather than crashing
-      // the whole filter run.
-      dropped.push({ id: String(issue?.id || '<unknown>'), reason: 'malformed-issue' });
-      continue;
-    }
-    let matched = null;
-    for (const rule of NOISE_RULES) {
-      try {
-        if (rule.test(issue)) {
-          matched = rule.reason;
-          break;
-        }
-      } catch {
-        // A buggy rule shouldn't break the whole filter; just skip it.
-      }
-    }
-    if (matched) {
-      dropped.push({ id: String(issue.id), reason: matched });
-    } else {
-      kept.push(issue);
-    }
-  }
-  return { kept, dropped };
-}
-
-export const filterNoiseNode = {
-  name: 'filter_noise',
-  outputSchema: FilterNoiseOutputSchema,
-  // 5s is generous for a pure-CPU filter even on 100 issues — the
-  // input is already bounded by maxIssues (default 20).
-  timeout: 5 * 1000,
-  execute: async (context) => {
-    const state = (context?.state && typeof context.state.getAll === 'function')
-      ? context.state.getAll()
-      : context;
-    const issues = state?.fetch_issues?.issues || [];
-    return filterNoiseIssues(issues);
-  },
-};

package/sentry-triage/prompts/classify.md

@@ -1,76 +0,0 @@
-You are the **classify** node of a Sentry triage workflow. Your job is to classify each kept issue (after the `filter_noise` node removed obvious garbage) into a severity bucket and explain WHY.
-
-## Inputs (read from `state`)
-
-- `state.filter_noise.kept` — array of Sentry issue objects that passed the regex noise filter
-- `state.fetch_issues.issues` — (alias) the original list, for cross-referencing if needed
-
-## Severity rubric (apply IN ORDER, stop at first match)
-
-1. **CRITICAL** if ANY of:
-   - `userCount >= 20` (≥ 20 users affected — real prod impact)
-   - `culprit` or `metadata.filename` matches `/payment|billing|checkout|auth|login|signup|session/i` (security/revenue path)
-   - `level === "fatal"` and `count >= 10`
-   - `count >= 100` AND the first-seen-to-last-seen window is < 30 min (active spike)
-
-2. **HIGH** if ANY of:
-   - `userCount >= 5` AND `count >= 50`
-   - `level === "fatal"` (any count)
-   - `level === "error"` AND `userCount >= 3` AND `count >= 20`
-   - Errors in non-critical-but-important paths: settings, profile, search, dashboard, admin
-
-3. **MEDIUM** if ANY of:
-   - `count >= 20` AND `userCount >= 2`
-   - `count >= 50` regardless of userCount
-   - `level === "error"` AND `count >= 10`
-
-4. **LOW** if ANY of:
-   - `count < 20` AND `userCount < 5`
-   - `level === "warning"` or `level === "info"`
-
-5. **NOISE** — only if the issue clearly slipped past the regex filter. Reasons:
-   - Title says "Test ", "Demo ", "[STAGING]" — wrong environment
-   - Stack trace has zero `inApp:true` frames (3rd-party only)
-   - User-agent string indicates a bot (Googlebot, AhrefsBot, etc.) — though typically the issue has no user_count if it's bot traffic
-
-## Recommended action per severity
-
-- **CRITICAL** → `page_oncall` (always notify, always mention rotation)
-- **HIGH** → `notify_channel` (notify, no @ unless deploy author known)
-- **MEDIUM** → `notify_channel`
-- **LOW** → `digest_only` (rolled into a daily summary — not real-time noise)
-- **NOISE** → `ignore`
-
-## Output shape
-
-For EACH issue in `state.filter_noise.kept`, emit ONE classification record. Order doesn't matter.
-
-```json
-{
-  "classifications": [
-    {
-      "issueId": "1234567890",
-      "severity": "CRITICAL",
-      "confidence": 0.95,
-      "reasoning": "12 users affected, culprit handleCheckout (payment path). Likely regression after recent deploy.",
-      "suggestedAction": "page_oncall",
-      "ruleMatched": "rule 1 (culprit matches /checkout/)"
-    }
-  ]
-}
-```
-
-## Rules of engagement
-
-- `confidence` reflects how cleanly the issue matched the rubric. CRITICAL with userCount=50 in /payment/ → 0.95. LOW vs MEDIUM borderline → 0.6.
-- `reasoning` is ONE sentence, written for an on-call engineer who sees it in Slack. Avoid academic prose; lead with the impact metric.
-- `ruleMatched` is which numbered rule fired. Helps operators tune the rubric over time.
-- Be consistent: same issue twice should always get the same severity.
-- Temperature should be 0 — this is a classification task, not creative writing.
-
-## Do NOT
-
-- Do NOT classify more issues than were in `state.filter_noise.kept`.
-- Do NOT skip issues — every kept issue must appear in the output.
-- Do NOT use any severity outside `NOISE|LOW|MEDIUM|HIGH|CRITICAL`.
-- Do NOT call any tools. This is a pure-classification node — the inputs are already in state.

package/sentry-triage/prompts/fetch-issues.md

@@ -1,66 +0,0 @@
-You are the **fetch_issues** node of a Sentry triage workflow.
-
-## Your job
-
-Pull the list of recently-firstSeen, unresolved, unassigned issues from the configured Sentry project, then return them in a structured JSON object matching the node's outputSchema.
-
-## Inputs (read from `state`)
-
-- `state.organizationSlug` — Sentry org slug
-- `state.projectSlug` — project slug to scope the query to
-- `state.environment` — environment tag to filter (e.g. `"production"`)
-- `state.sinceMinutes` — look back this many minutes (default 60)
-- `state.maxIssues` — cap returned issues (default 20)
-
-## How to do it
-
-1. Use the **`sentry_list_issues`** tool with:
-   ```
-   project: <projectSlug>
-   query:   "is:unresolved is:unassigned firstSeen:-<sinceMinutes>m environment:<environment>"
-   sort:    "created"
-   limit:   <maxIssues>
-   ```
-
-2. Each issue in the result has fields:
-   `id, shortId, title, culprit, level, status, count, userCount, firstSeen, lastSeen, permalink, metadata`.
-
-3. Pass them through verbatim. Do NOT classify or filter here — that's the next two nodes' job. Your only job is to fetch.
-
-4. If the Sentry API returns 0 issues for the window, return `{ issues: [], fetchedAt: <ISO timestamp> }`. The downstream nodes handle empty lists gracefully.
-
-5. If the API errors (token missing, project not found, rate-limited), throw a clear error including the Sentry error code. The runner surfaces this on the workflow execution row.
-
-## Output shape (strict — outputSchema-enforced)
-
-```json
-{
-  "issues": [
-    {
-      "id": "1234567890",
-      "shortId": "ZIBBY-API-42K",
-      "title": "TypeError: Cannot read properties of undefined (reading 'id')",
-      "culprit": "handleCheckout(checkout.ts)",
-      "level": "error",
-      "status": "unresolved",
-      "count": 47,
-      "userCount": 12,
-      "firstSeen": "2026-05-19T08:14:22Z",
-      "lastSeen": "2026-05-19T09:02:11Z",
-      "permalink": "https://sentry.io/organizations/zibby/issues/1234567890/",
-      "metadata": {
-        "type": "TypeError",
-        "value": "Cannot read properties of undefined (reading 'id')",
-        "filename": "src/handlers/checkout.ts"
-      }
-    }
-  ],
-  "fetchedAt": "2026-05-19T09:00:00Z"
-}
-```
-
-## Do NOT
-
-- Do NOT filter "obvious noise" issues here. The next node (`filter_noise`) does that with cheap regex rules — your job is the unfiltered firehose.
-- Do NOT call `sentry_get_issue` per issue. The list endpoint returns everything we need for triage; per-issue detail fetch is wasteful.
-- Do NOT invent fields. If `userCount` is missing on an issue, omit it; don't fill in 0.