@zibby/workflow-templates 0.7.0 → 0.9.0

package/index.js

@@ -173,7 +173,7 @@ export const TEMPLATES = {
     description: 'Reusable child workflow — posts a structured Block Kit alert to a Slack channel. Dispatched by other workflows (Sentry triage, autofix, incident) via sub-graph.',
     path: join(__dirname, 'notify-slack'),
     defaultSlug: 'alert-slack',
-    deps: { zod: '^3.23.0' },
+    deps: { zod: '^3.23.0 || ^4.0.0', '@zibby/skills': '^0.1.28' },
     features: [
       'Single-node, no LLM — deterministic ~500ms post',
       'Block Kit message with severity-coded color + emoji',
@@ -215,7 +215,7 @@ export const TEMPLATES = {
     description: 'Reusable child workflow — posts a structured Interactive Card to a Lark / Feishu chat. Dispatched by other workflows via sub-graph.',
     path: join(__dirname, 'notify-lark'),
     defaultSlug: 'alert-lark',
-    deps: { zod: '^3.23.0' },
+    deps: { zod: '^3.23.0 || ^4.0.0', '@zibby/skills': '^0.1.28' },
     features: [
       'Single-node, no LLM',
       'Lark Interactive Card with severity template (red/orange/yellow/grey)',

package/notify-lark/package.json

@@ -10,7 +10,8 @@
   },
   "dependencies": {
     "@zibby/core": "^0.5.1",
-    "zod": "^3.23.0"
+    "@zibby/skills": "^0.1.28",
+    "zod": "^3.23.0 || ^4.0.0"
   },
   "devDependencies": {
     "vitest": "^2.1.5"

package/notify-slack/package.json

@@ -10,7 +10,8 @@
   },
   "dependencies": {
     "@zibby/core": "^0.5.1",
-    "zod": "^3.23.0"
+    "@zibby/skills": "^0.1.28",
+    "zod": "^3.23.0 || ^4.0.0"
   },
   "devDependencies": {
     "vitest": "^2.1.5"

package/package.json

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

package/sentry-triage/graph.mjs

@@ -1,28 +1,35 @@
 /**
  * sentry-triage — parent workflow. Hourly Sentry issue triage.
  *
- * Pipeline (3 LLM nodes, end-to-end agent-driven):
+ * Agent-driven first. Nodes are LLM agents by default — because nobody
+ * hand-edits these in practice, they point an AGENT at the prompt and say
+ * "make billing always critical" / "page #oncall after 9pm". A deterministic
+ * for-loop can't be told that in English; an agent can. We drop to
+ * deterministic ONLY where it genuinely makes sense — a pure mechanical step
+ * with zero judgment and nothing a customer would ever want to tune.
  *
- *   fetch_issues    (LLM + SKILLS.SENTRY)        → list recent unresolved issues
+ *   fetch_issues    (deterministic + SKILLS.SENTRY) → pull recent unresolved/
+ *                                                      unassigned issues + suspect
+ *                                                      commits. Pure API pull, no
+ *                                                      judgment, nothing to tune →
+ *                                                      the one place a for-loop
+ *                                                      wins (faster, free, no
+ *                                                      hallucinated queries).
  *        ↓
- *   classify        (LLM, no tools)              → label NOISE/LOW/MEDIUM/HIGH/CRITICAL
+ *   classify        (LLM agent)                     → label NOISE…CRITICAL. Stays
+ *                                                      an agent BECAUSE the rubric
+ *                                                      is customer-tunable, and
+ *                                                      they tune it by having an
+ *                                                      agent edit this prompt — not
+ *                                                      by touching code.
  *        ↓
- *   dispatch_alerts (LLM + SKILLS.CHAT_NOTIFY)   → batch + post to Slack OR Lark for
- *                                                   issues ≥ SEVERITY_THRESHOLD
+ *   dispatch_alerts (LLM agent + SKILLS.CHAT_NOTIFY) → one human-voice digest;
+ *                                                      routing is the user's
+ *                                                      (DISPATCH_RULES) to own.
  *
- * 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.
- *
- * 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).
+ * Also: LLM dispatch BATCHES related issues into one message and DE-DUPs —
+ * a for-loop can't. outputSchema enforcement → every above-threshold issue
+ * gets a "sent" or explicit "skipped/failed" record; no silent drops.
  */
 
 import { WorkflowAgent, WorkflowGraph } from '@zibby/core';
@@ -48,7 +55,17 @@ export class SentryTriageAgent extends WorkflowAgent {
     graph.addNode('dispatch_alerts', dispatchNode);
 
     graph.setEntryPoint('fetch_issues');
-    graph.addEdge('fetch_issues',    'classify');
+    // Short-circuit when Sentry returned nothing for this window. The
+    // empty-list case is the common idle path (steady-state apps don't
+    // throw new errors every hour), and running classify + dispatch on
+    // an empty input wastes two Claude calls per run — at hourly cadence
+    // across many tenants that adds up. Cleaner to route directly to END
+    // at the graph level than to short-circuit inside each downstream
+    // node's prompt (which still spends a model round-trip).
+    graph.addConditionalEdges('fetch_issues', (state) => {
+      const issues = state?.fetch_issues?.issues || [];
+      return issues.length === 0 ? 'END' : 'classify';
+    });
     graph.addEdge('classify',        'dispatch_alerts');
     graph.addEdge('dispatch_alerts', 'END');
 

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

@@ -1,41 +1,86 @@
 /**
- * dispatch_alerts node — LLM-driven dispatcher.
+ * dispatch_alerts node — LLM-driven dispatcher with author routing.
  *
- * 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.
+ * The agent reads each classified issue (+ its Sentry suspectCommits
+ * author, when available) and decides per-issue where to send the
+ * alert. Three layers of decisioning, top-down:
  *
- * 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.
+ *   1. `DISPATCH_RULES` (free-form natural-language override)
+ *      — when set, the agent applies these rules verbatim and treats
+ *        the structured env vars below as defaults. For advanced
+ *        routing ("security tag always pages @security regardless of
+ *        severity", "weekend hours quiet unless CRITICAL", etc.).
  *
- * Reliability: outputSchema enforces a `dispatched` record per
- * group + summary counts. A malformed LLM response triggers a retry
- * with the schema embedded.
+ *   2. Structured env vars (the 90% path):
+ *        SLACK_CHANNEL / LARK_RECEIVE_ID   — pick provider, channel fallback
+ *        SEVERITY_THRESHOLD                — skip anything below
+ *        ROUTING_PREFER_AUTHOR             — if suspectCommit.author email
+ *                                            resolves to a user, DM them
+ *        ROUTING_HIGH_SEVERITY_GROUP       — handle/id of a Slack
+ *                                            usergroup (@oncall) that gets
+ *                                            mentioned on CRITICAL/HIGH
+ *        SLACK_MENTIONS / LARK_MENTIONS    — flat mention list, CRITICAL only
  *
- * ENV tab config:
- *   SLACK_CHANNEL OR LARK_RECEIVE_ID  — required, pick one
+ *   3. Built-in defaults (when neither rules nor env set anything):
+ *        - threshold MEDIUM, no author DM, channel-only post.
+ *
+ * Author-routing tools the agent has access to (from the slack/lark
+ * skills via SKILLS.CHAT_NOTIFY):
+ *   slack:
+ *     - slack_lookup_user_by_email   email → user id (DM target)
+ *     - slack_list_usergroups        list @oncall etc., with handle + count
+ *     - slack_get_usergroup_members  expand a group → user ids
+ *     - slack_post_message           DM user id OR channel
+ *   lark:
+ *     - lark_lookup_user_by_email    email → open_id (DM target)
+ *     - lark_send_message            DM open_id OR oc_* group chat
+ *
+ * Provider selection: chatNotifySkill.resolve() picks slack or lark
+ * based on which env var (`SLACK_CHANNEL` or `LARK_RECEIVE_ID`) the
+ * project sets. The LLM only sees one provider's tools, so it can't
+ * accidentally fan out to the wrong workspace.
+ *
+ * Reliability: outputSchema enforces a per-dispatch record + summary.
+ * A malformed LLM response triggers a retry with the schema embedded.
+ *
+ * ENV tab config — required:
+ *   SLACK_CHANNEL OR LARK_RECEIVE_ID  — provider selector + channel fallback
+ *
+ * ENV tab config — optional:
  *   SEVERITY_THRESHOLD                — NOISE|LOW|MEDIUM|HIGH|CRITICAL (default MEDIUM)
- *   SLACK_MENTIONS OR LARK_MENTIONS   — JSON array, optional, CRITICAL only
+ *   ROUTING_PREFER_AUTHOR             — "true" enables suspectCommit author DM
+ *   ROUTING_HIGH_SEVERITY_GROUP       — e.g. "@oncall" or "S012ABC" (Slack usergroup id)
+ *   SLACK_MENTIONS / LARK_MENTIONS    — JSON array of mentions on CRITICAL
+ *   DISPATCH_RULES                    — free-form natural-language overrides
  */
 
 import { z, SKILLS } from '@zibby/core';
 import { SEVERITY_LEVELS } from '../state.js';
 
+const DispatchedRecordSchema = 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']),
+  // Every field below a skipped/failed record can't populate is nullish
+  // (not optional) on purpose: the LLM emits an explicit `null` rather than
+  // omitting the key, and `.optional()` rejects null → ZodError → the whole
+  // dispatch node fails even though it did exactly the right thing (skip
+  // below-threshold). So recipient (no send → null), messageTs/messageId (no
+  // message id), and detail all tolerate null.
+  // Who actually received this message. Helps post-hoc auditing of
+  // routing decisions ("why did the agent send this to @sarah?").
+  recipient: z.object({
+    kind: z.enum(['channel', 'user_dm', 'usergroup']).nullish(),
+    id: z.string().nullish(),
+    label: z.string().nullish(),
+  }).nullish(),
+  messageTs: z.string().nullish(),  // Slack
+  messageId: z.string().nullish(),  // Lark
+  detail: z.string().nullish(),
+});
+
 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(),
-  })),
+  dispatched: z.array(DispatchedRecordSchema),
   summary: z.object({
     total: z.number().describe('Number of messages POSTED (not issues — batched groups count as 1).'),
     sent: z.number(),
@@ -44,77 +89,211 @@ const DispatchAlertsOutputSchema = z.object({
   }),
 });
 
+const SEVERITY_ORDER = ['NOISE', 'LOW', 'MEDIUM', 'HIGH', 'CRITICAL'];
+
+// Turn the trigger's sinceMinutes into a phrase a human would actually say,
+// so the digest can open with the time span ("past hour", "last 3 days")
+// instead of leaving the reader to guess how much history this covers.
+function humanWindow(min) {
+  const m = Number(min);
+  if (!m || m < 1) return 'recently';
+  if (m < 90) return `the past ${Math.round(m)} minutes`;
+  if (m < 1440) return `the past ${Math.round(m / 60)} hours`;
+  const days = Math.round(m / 1440);
+  return days === 1 ? 'the past day' : `the past ${days} days`;
+}
+
 const DISPATCH_PROMPT = (state = {}) => {
   const issues = state?.fetch_issues?.issues || [];
   const classifications = state?.classify?.classifications || [];
+  const windowLabel = humanWindow(state?.sinceMinutes);
+  const fetchedAt = state?.fetch_issues?.fetchedAt || '';
+
+  const threshold       = process.env.SEVERITY_THRESHOLD       || 'MEDIUM';
+  const slackChannel    = process.env.SLACK_CHANNEL            || '';
+  const larkReceiveId   = process.env.LARK_RECEIVE_ID          || '';
+  const preferAuthor    = /^(1|true|yes|on)$/i.test(process.env.ROUTING_PREFER_AUTHOR || '');
+  const highSevGroup    = process.env.ROUTING_HIGH_SEVERITY_GROUP || '';
+  const dispatchRules   = process.env.DISPATCH_RULES           || '';
+
+  // ── No-op short-circuit ─────────────────────────────────────────
+  // The three "nothing to do this run" cases — keep the run green without a
+  // model round-trip or forcing channel setup.
+  const minSeverityRank = SEVERITY_ORDER.indexOf(threshold);
+  const aboveThreshold = minSeverityRank < 0
+    ? classifications
+    : classifications.filter((c) => SEVERITY_ORDER.indexOf(c.severity) >= minSeverityRank);
 
-  const threshold     = process.env.SEVERITY_THRESHOLD || 'MEDIUM';
-  const slackChannel  = process.env.SLACK_CHANNEL      || '';
-  const larkReceiveId = process.env.LARK_RECEIVE_ID    || '';
+  if (issues.length === 0 || classifications.length === 0 || aboveThreshold.length === 0) {
+    const reason =
+      issues.length === 0          ? 'fetch_issues returned no issues' :
+      classifications.length === 0 ? 'classifier emitted no records' :
+                                     `all ${classifications.length} issue(s) below SEVERITY_THRESHOLD=${threshold}`;
+    return `No Sentry issues to dispatch this run (${reason}).
+
+Return this exact JSON envelope and call no tools:
+
+\`\`\`json
+{ "dispatched": [], "summary": { "total": 0, "sent": 0, "skipped": 0, "failed": 0 } }
+\`\`\`
+`;
+  }
 
-  let provider, toolName, recipientLine, mentionsRaw;
+  // ── Provider selection ──────────────────────────────────────────
+  let provider, postTool, lookupTool, channelId, 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: "…" })`;
+    provider    = 'slack';
+    postTool    = 'slack_post_message';
+    lookupTool  = 'slack_lookup_user_by_email';
+    channelId   = slackChannel;
     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: "…" })`;
+    provider    = 'lark';
+    postTool    = 'lark_send_message';
+    lookupTool  = 'lark_lookup_user_by_email';
+    channelId   = larkReceiveId;
     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.');
+    throw new Error(
+      'sentry-triage has issues to dispatch but no destination configured. ' +
+      'Go to Project Settings -> ENV and set ONE of:\n' +
+      '  - SLACK_CHANNEL=#your-alerts-channel    (uses connected Slack integration)\n' +
+      '  - LARK_RECEIVE_ID=oc_xxxxxxxx           (uses connected Lark integration)\n' +
+      'The integration OAuth token gives the workflow auth, but you still need to tell it WHERE to post.'
+    );
   }
 
   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.
+  // ── Routing policy ──────────────────────────────────────────────
+  // Routing is the USER'S to own. We give the agent only the bare facts it
+  // always needs; everything past that is policy:
+  //   - If DISPATCH_RULES is set, those rules ARE the policy. Hand over the
+  //     facts + the rules and get out of the way — do NOT also stack the
+  //     built-in author-DM / usergroup defaults on top. The user chose to
+  //     drive this themselves; don't fight them.
+  //   - With no DISPATCH_RULES, fall back to sensible built-in defaults
+  //     (channel post + opt-in author-DM / escalation from env vars).
+  const facts = [`Skip anything classified below ${threshold}.`];
+  // Only mention a channel when one is actually configured — never render a
+  // "post here" line pointing at an empty value.
+  if (channelId) facts.push(`Channel configured: ${JSON.stringify(channelId)} (${provider}).`);
+  facts.push(`Post with the \`${postTool}\` tool.`);
+
+  let policyLines;
+  let overrideBlock = '';
+  if (dispatchRules) {
+    policyLines = facts.concat([
+      'Past the facts above, follow YOUR rules below — who gets paged / DM\'d, where, when, what to suppress. They override anything the built-in defaults would have implied.',
+    ]);
+    overrideBlock = `\n\n# Your routing rules (authoritative)\n${dispatchRules.trim()}\n`;
+  } else {
+    policyLines = [...facts];
+    if (channelId) policyLines.push('Every alert at minimum goes to the channel above.');
+    if (preferAuthor) {
+      policyLines.push(
+        `Author-DM: when an issue has \`suspectCommits[0].authorEmail\`, FIRST call \`${lookupTool}({ email })\`. ` +
+        `If \`ok:true\`, DM that user (their id as the recipient) AND still post the channel for team visibility. ` +
+        `If \`ok:false\` or no email, channel-only.`
+      );
+    }
+    if (highSevGroup) {
+      policyLines.push(
+        provider === 'slack'
+          ? `On CRITICAL/HIGH, mention the Slack usergroup ${JSON.stringify(highSevGroup)} in the channel message. ` +
+            `Handle (@…): call \`slack_list_usergroups\` once to resolve → id, mention as \`<!subteam^ID>\`. Id (S…): use \`<!subteam^${highSevGroup}>\`.`
+          : `On CRITICAL/HIGH, also send to ${JSON.stringify(highSevGroup)} (Lark receive_id).`
+      );
+    }
+    if (mentions.length > 0) policyLines.push(`CRITICAL messages prepend: ${JSON.stringify(mentions.join(' '))}`);
+  }
 
-# Recipient
-${recipientLine}
+  const policyBlock = policyLines.map((l, i) => `${i + 1}. ${l}`).join('\n');
 
-# Severity threshold
-Skip any issue below: ${threshold}
-(Severity order, low → high: ${SEVERITY_LEVELS.join(' < ')})
+  // Slack → a Block Kit card (rich, scannable, clickable View buttons). Lark →
+  // the human-voice text digest (no Block Kit there). The JUDGMENT is identical
+  // either way — the one-line read, the grouping, what's urgent — only the
+  // rendering differs by provider.
+  const writeGuide = provider === 'slack'
+    ? `# How to report it — like a human on-call, in TWO messages
+Don't cram everything into one card. Report the way a sharp on-call engineer actually would: FIRST a quick human heads-up so people get the situation in ONE glance, THEN the detailed board. So you call \`slack_post_message\` TWICE.
 
-# Mentions
-CRITICAL messages only — prepend: ${JSON.stringify(mentions.join(' '))}
-HIGH/MEDIUM/LOW — no mentions.
+## Message 1 — greeting + the headline (text only, NO blocks)
+\`slack_post_message({ channel, text })\` with just text. Open with a greeting ("👋 Hey team"). Say the ONE thing that matters most — the headline STORY, not a count ("billing/auth is broken in 3 spots, almost certainly one deploy"). Page plainly if something needs it ("on-call should grab these now"). End pointing down at the list ("Full breakdown 👇"). 2–4 sentences, sounds like a person typed it — THIS is the "one glance and you get it" message.
+Example:
+"👋 *Hey team — Sentry triage, ${windowLabel}.* Headline: *billing/auth is broken in 3 places* (formatSubscription, webhook timeout, Unauthorized) — almost certainly one bad deploy, on-call should grab these now. Plus a cluster of undefined-ref fatals (module/import wiring) and the usual synthetic test noise. Full breakdown 👇"
 
-# 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 2 — the Block Kit board (blocks)
+Then \`slack_post_message({ channel, text, blocks })\` — the scannable card. \`text\` = one-line fallback. \`blocks\`, real Block Kit objects only:
+1. \`header\` — title with the window:
+{ "type": "header", "text": { "type": "plain_text", "text": "🚨 Sentry Triage — ${windowLabel}", "emoji": true } }
+2. \`context\` — ONE-line read of the window (counts + the shape; your call):
+{ "type": "context", "elements": [{ "type": "mrkdwn", "text": "*${aboveThreshold.length}* at *${threshold}+* of ${issues.length} · <your one-line read of what's going on>" }] }
+3. Per group — group by ROOT CAUSE or severity (your call; the header says what connects them). A divider, a section header, then per issue a section (with a View button) FOLLOWED BY a one-line context note:
+{ "type": "divider" }
+{ "type": "section", "text": { "type": "mrkdwn", "text": "🔴 *CRITICAL — billing/auth, page on-call*" } }
+{ "type": "section", "text": { "type": "mrkdwn", "text": "*<title>* — <where> · <the one metric that matters>" }, "accessory": { "type": "button", "text": { "type": "plain_text", "text": "View →", "emoji": true }, "url": "<permalink>", "action_id": "v_<issueId>" } }
+{ "type": "context", "elements": [{ "type": "mrkdwn", "text": "↳ <one short useful detail>" }] }
+   The context line is grey small text under the issue — ~6-12 words of a CONCRETE fact pulled straight from the issue's data, NEVER a vague guess. Use what's actually there: the error value (\`metadata.value\`, e.g. "Cannot read 'plan' of undefined"), the culprit fn/file, a real suspect commit ("a1b2c3 by sarah@"), or first/last-seen spread ("first seen 3d ago, 1.6k/h now"). BANNED — filler with no information: "could exacerbate latency", "potential breach attempt", "needs attention", "affects capacity". If you don't have a concrete fact for an issue, OMIT its context line entirely. Never speculate to fill space.
+4. final \`context\` — what needs a human now vs. just FYI.
 
-# 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/
-\`\`\`
+Rules:
+- TWO slack_post_message calls: the text heads-up FIRST, then the blocks card. Both go to the same channel.
+- header text is plain_text; section & context text is mrkdwn (*bold*, \`code\`, <url|label>).
+- One tight line per issue in the section text; the button carries the link — don't also inline it.
+- Group dots: 🔴 CRITICAL · 🟠 HIGH · 🟡 MEDIUM. Mention a suspect commit only if there genuinely is one.
+- Below-threshold (skipped) issues do NOT appear in the blocks at all.
+- Real Block Kit types only (header / section / divider / context + button accessory) — don't invent types.`
+    : `# How to write it — talk like a human, not a report generator
+You're a teammate dropping a note in the channel, not a dashboard. Open with a real sentence about ${windowLabel} (time span baked in). Group issues that are the same story (same file/area/deploy) and SAY why they're connected. Per issue: what broke, the one number that matters, and the link. End straight: what needs a human now vs. FYI. No "*[SEVERITY]*" form blocks, no "no suspect commits" filler.
 
-# Output (outputSchema-enforced)
+Example tone:
+Over ${windowLabel} it's been mostly quiet, but billing's having a bad time — three errors on the checkout/subscription path, almost certainly the same deploy: \`formatSubscription is not a function\` (BillingPage, 1 user), \`POST /billing/webhook\` timing out (6×), \`countWorkflowExecutionsInPeriod\` 15× in usage-limiter. <links> Whoever shipped the billing refactor should roll back. Rest is synthetic test traffic — ignoring it.`;
 
-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.
+  // ── Prompt body ─────────────────────────────────────────────────
+  return `You are the dispatch_alerts node of a Sentry triage workflow. Post chat alerts using the **${postTool}** tool (and the lookup helpers below for author routing).
+
+# Routing
+${policyBlock}${overrideBlock}
+
+# Severity scale
+${SEVERITY_LEVELS.join(' < ')}
+
+# Tools you should use
+- \`${postTool}\` — post the message (channel id OR user/DM id for the recipient field).
+- \`${lookupTool}\` — resolve an email to a user id. **Important**: this can return \`{ ok: false }\` — handle that by falling back to channel-only, don't retry with variations of the email.
+${provider === 'slack' ? '- `slack_list_usergroups` / `slack_get_usergroup_members` — expand @group → user ids.' : ''}
+
+# Context for THIS run — weave it in, don't make the reader guess
+- Time span: every issue below is unresolved + unassigned from **${windowLabel}**${fetchedAt ? ` (pulled ${fetchedAt})` : ''}. OPEN with the span so people know what they're looking at — "Past hour was quiet…", "Over the last 30 days…". Never leave it out; a reader who doesn't know the window can't judge urgency.
+- Volume: ${aboveThreshold.length} issue(s) at or above ${threshold}, out of ${issues.length} fetched. Mention the count only if it helps the read.
+
+${writeGuide}
+
+A standalone CRITICAL that should page someone can get its OWN message. Routing still applies: digest → channel; if author-DM is on and an issue has a known author, also DM that person a short note about just theirs; mention the escalation group on CRITICAL/HIGH.
+
+# Output (outputSchema-enforced)
+Return ONE record per dispatch call you actually made (or skipped/failed). \`issueIds\` is an array — batched messages carry every issue in the group. \`recipient\` records who got the message (channel id, user id, or usergroup id) so the audit trail shows the routing decision.
 
 \`\`\`json
 {
   "dispatched": [
-    { "issueIds": ["1", "5", "7"], "severity": "CRITICAL", "status": "sent"${provider === 'slack' ? ', "messageTs": "1716109330.555"' : ', "messageId": "om_xxxxx"'} }
+    {
+      "issueIds": ["1", "5"],
+      "severity": "CRITICAL",
+      "status": "sent",
+      "recipient": { "kind": "user_dm", "id": "U012ABC", "label": "sarah@acme.com" }${provider === 'slack' ? ',\n      "messageTs": "1716109330.555"' : ',\n      "messageId": "om_xxxxx"'}
+    }
   ],
   "summary": { "total": 1, "sent": 1, "skipped": 0, "failed": 0 }
 }
 \`\`\`
 
-# Issues + classifications
+# Issues + classifications + suspect commits
 
-Each entry below has the Sentry issue plus the classifier's verdict + reasoning. Use both.
+Each entry is a Sentry issue with the classify agent's \`classification\` (severity + reasoning) and any suspect commits Sentry's GitHub integration could blame. **An empty \`suspectCommits\` array means the team hasn't set up Sentry's GitHub integration OR the file wasn't touched in the last 14 days** — just don't mention a commit in that case.
 
 \`\`\`json
 ${JSON.stringify(
@@ -128,10 +307,11 @@ ${JSON.stringify(
 \`\`\`
 
 # 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.
+- The digest is usually ONE channel message → ONE \`sent\` record whose \`issueIds\` lists every issue you mentioned in it. An extra author-DM or a standalone-CRITICAL message each get their own record too.
+- Skipped (below-threshold) issues: roll them into a single \`skipped\` record (issueIds = all of them) — no chat call, no per-issue noise — so the run record stays complete without bloating it.
+- DON'T invent severities, issue IDs, or email addresses. Only use what's in the data block above.
+- DON'T pad the digest. If the hour is quiet, a two-line message is the right answer — don't manufacture structure.
+- DO post if in doubt — under-paging is worse than over-paging.
 `;
 };
 

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

@@ -26,7 +26,21 @@
 
 import { z } from 'zod';
 import { SKILLS } from '@zibby/core';
-import { sentryListIssues } from '@zibby/skills/sentry';
+import { sentryListIssues, sentryGetIssue } from '@zibby/skills/sentry';
+
+// Per-commit shape Sentry returns under `suspectCommits[]`. We only
+// surface what the dispatch agent actually uses for routing — author
+// email (→ slack_lookup_user_by_email) + a short SHA + the commit
+// message so the agent can sanity-check "is this commit plausibly the
+// cause?". Everything else (date, repository url, etc.) is dropped to
+// keep the per-issue payload small.
+const SuspectCommitShape = z.object({
+  id: z.string().optional(),
+  shortId: z.string().optional(),
+  message: z.string().optional(),
+  authorEmail: z.string().optional(),
+  authorName: z.string().optional(),
+});
 
 const IssueShape = z.object({
   id: z.string(),
@@ -45,6 +59,11 @@ const IssueShape = z.object({
     value: z.string().optional(),
     filename: z.string().optional(),
   }).optional(),
+  // Populated by the per-issue sentryGetIssue() fetch below. Empty
+  // array when Sentry's GitHub integration can't blame the issue's
+  // stack frames to any recent commits (no integration / no code
+  // mapping / file untouched in 14 days).
+  suspectCommits: z.array(SuspectCommitShape).optional(),
 });
 
 const FetchIssuesOutputSchema = z.object({
@@ -65,10 +84,24 @@ export const fetchIssuesNode = {
       : context;
 
     const sinceMinutes = Number(state?.sinceMinutes) || 60;
+    const query = `is:unresolved is:unassigned firstSeen:-${sinceMinutes}m`;
+
+    // Surface intent BEFORE the call. Deterministic nodes don't go
+    // through an LLM that would print its reasoning, so the activity
+    // panel would otherwise just show "started" then a result count —
+    // operators have no way to tell what query ran or whether the empty
+    // result was "Sentry returned nothing" vs "we asked the wrong
+    // question". Two-line preamble fixes that without log-spam.
+    console.log(`Sentry query: ${query}`);
+    console.log(`Sort: new (firstSeen desc) · Limit: 100`);
 
     const issues = await sentryListIssues({
-      query: `is:unresolved is:unassigned firstSeen:-${sinceMinutes}m`,
-      sort: 'created',
+      query,
+      // Sentry's /projects/{org}/{project}/issues/ endpoint only accepts
+      // these sort keys: date | new | priority | freq | user. `new` sorts
+      // by firstSeen desc which matches our triage intent (newest issues
+      // surface first). `created` was wrong and made Sentry return 400.
+      sort: 'new',
       // 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
@@ -77,8 +110,55 @@ export const fetchIssuesNode = {
       limit: 100,
     });
 
+    // Always log the count + a head sample. On 0 issues this prints
+    // "Fetched 0 issues" which is the actionable signal — operator
+    // knows the query worked but there's nothing new to triage.
+    console.log(`Fetched ${issues.length} issue${issues.length === 1 ? '' : 's'} from Sentry`);
+    if (issues.length > 0) {
+      const preview = issues.slice(0, 5).map((i) => `  - ${i.shortId || i.id} [${i.level || '?'}] ${i.title || '(no title)'}`);
+      console.log(preview.join('\n'));
+      if (issues.length > 5) console.log(`  ... (${issues.length - 5} more)`);
+    }
+
+    // Enrich each issue with `suspectCommits` (author email + SHA +
+    // commit message). The /issues/ list endpoint does NOT include
+    // suspectCommits — only /issues/<id>/ does. So we do N parallel
+    // GETs to hydrate. Practical concerns:
+    //
+    //   - N is capped at 100 (the list limit above). One parallel
+    //     batch finishes in ~1-2s against sentry.io.
+    //   - Per-issue failures are swallowed (logged + empty array)
+    //     so one 404 doesn't break the entire run. The classifier
+    //     downstream doesn't NEED suspectCommits to function — it's
+    //     a routing hint, not a classification input.
+    //   - When the customer hasn't installed Sentry's GitHub
+    //     integration OR hasn't configured Code Mappings, every
+    //     issue will come back with suspectCommits=[]. That's the
+    //     designed-for steady state; dispatch agent falls back to
+    //     channel-only routing.
+    const enriched = await Promise.all(
+      issues.map(async (issue) => {
+        try {
+          const detail = await sentryGetIssue(issue.id);
+          const sc = (detail?.suspectCommits || []).map((c) => ({
+            id: c.id,
+            shortId: c.shortId || (c.id ? String(c.id).slice(0, 7) : undefined),
+            message: c.message,
+            authorEmail: c.author?.email,
+            authorName: c.author?.name,
+          }));
+          return { ...issue, suspectCommits: sc };
+        } catch (err) {
+          console.warn(`  · suspectCommits fetch failed for ${issue.shortId || issue.id}: ${err.message}`);
+          return { ...issue, suspectCommits: [] };
+        }
+      })
+    );
+    const withAuthor = enriched.filter((i) => (i.suspectCommits || []).some((c) => c.authorEmail)).length;
+    console.log(`Hydrated suspectCommits — ${withAuthor}/${enriched.length} issue(s) have an identifiable author.`);
+
     return {
-      issues,
+      issues: enriched,
       fetchedAt: new Date().toISOString(),
     };
   },

package/sentry-triage/package.json

@@ -10,7 +10,7 @@
   },
   "dependencies": {
     "@zibby/core": "^0.5.1",
-    "@zibby/skills": "^0.1.25",
+    "@zibby/skills": "^0.1.26",
     "zod": "^3.23.0"
   },
   "devDependencies": {

package/browser-test-automation/node_modules/.vite/vitest/da39a3ee5e6b4b0d3255bfef95601890afd80709/results.json

@@ -1 +0,0 @@
-{"version":"4.1.5","results":[[":__tests__/preflight-early-exit.test.mjs",{"duration":6.5747499999999945,"failed":false}]]}

package/code-analysis/node_modules/.vite/vitest/da39a3ee5e6b4b0d3255bfef95601890afd80709/results.json

@@ -1 +0,0 @@
-{"version":"4.1.5","results":[[":nodes/__tests__/middleware.integration.test.js",{"duration":0,"failed":true}],[":nodes/__tests__/finalizeNode.test.js",{"duration":8.396791000000007,"failed":false}]]}