@sweny-ai/core 0.1.79 → 0.1.81

package/dist/claude.d.ts

@@ -74,3 +74,12 @@ export declare class ClaudeClient implements Claude {
  * `"42"`). Preserving the string is safer than guessing.
  */
 export declare function parseToolResultContent(content: unknown): unknown;
+/**
+ * Produce a short, single-line description of a tool-error payload suitable
+ * for the CI log stream. The full parsed value stays on the ToolCall for
+ * verify and downstream tooling — this is only for inline observability.
+ *
+ * Collapses newlines, trims whitespace, and caps to 300 chars so a huge
+ * API response body doesn't flood the log.
+ */
+export declare function summarizeToolError(parsed: unknown): string;

package/dist/claude.js

@@ -157,6 +157,15 @@ export class ClaudeClient {
                             call.status = isError ? "error" : "success";
                             const parsed = parseToolResultContent(block.content);
                             call.output = isError ? { error: parsed } : parsed;
+                            // Surface tool errors in the CI log stream at warn level so
+                            // postmortems don't have to reconstruct them from verify-time
+                            // tool-call summaries. Without this, "verify failed: tool X
+                            // did not succeed" never answers the WHY question, because
+                            // the error body is buried in the per-call output captured
+                            // only for in-memory verify evaluation.
+                            if (isError) {
+                                this.logger.warn(`  tool ${call.tool} failed: ${summarizeToolError(parsed)}`);
+                            }
                         }
                     }
                 }
@@ -359,6 +368,33 @@ export function parseToolResultContent(content) {
         return content;
     }
 }
+/**
+ * Produce a short, single-line description of a tool-error payload suitable
+ * for the CI log stream. The full parsed value stays on the ToolCall for
+ * verify and downstream tooling — this is only for inline observability.
+ *
+ * Collapses newlines, trims whitespace, and caps to 300 chars so a huge
+ * API response body doesn't flood the log.
+ */
+export function summarizeToolError(parsed) {
+    let raw;
+    if (typeof parsed === "string") {
+        raw = parsed;
+    }
+    else if (parsed && typeof parsed === "object") {
+        try {
+            raw = JSON.stringify(parsed);
+        }
+        catch {
+            raw = String(parsed);
+        }
+    }
+    else {
+        raw = String(parsed);
+    }
+    const collapsed = raw.replace(/\s+/g, " ").trim();
+    return collapsed.length > 300 ? collapsed.slice(0, 297) + "..." : collapsed;
+}
 // ─── JSON Schema → Zod conversion ───────────────────────────────
 /**
  * Convert a JSON Schema object to a Zod raw shape for the agent SDK.

package/dist/executor.js

@@ -17,6 +17,7 @@ import { resolveSources } from "./source-resolver.js";
 import { evaluateVerify } from "./verify.js";
 import { evaluateRequires } from "./requires.js";
 import { buildRetryPreamble } from "./retry.js";
+import { buildToolAliases } from "./skills/index.js";
 /**
  * Execute a workflow from entry to completion.
  *
@@ -37,6 +38,10 @@ export async function execute(workflow, input, options) {
     const nodeRunCounts = new Map(); // node → times executed
     const trace = { steps: [], edges: [], sources: {} };
     validate(workflow, skills);
+    // Build a verify-time alias table from the loaded skills. Each skill owns
+    // its own mapping between skill-tool names and equivalent MCP names. Core
+    // stays vendor-neutral — this call just unions what the skills declare.
+    const toolAliases = buildToolAliases(skills.values(), logger);
     // ── Source resolution phase ─────────────────────────────────────
     // Resolve all Source values (node instructions + rules/context at every
     // level) into plain text before the main execution loop. This eagerly
@@ -159,7 +164,7 @@ export async function execute(workflow, input, options) {
             // Retry only triggers on verify failure — bail on tool/API errors.
             if (result.status !== "success")
                 break;
-            const verifyError = evaluateVerify(node.verify, result);
+            const verifyError = evaluateVerify(node.verify, result, toolAliases);
             if (!verifyError)
                 break;
             // Apply verify failure to the result.

package/dist/schema.d.ts

@@ -236,6 +236,7 @@ export declare const skillZ: z.ZodEffects<z.ZodObject<{
         command?: string | undefined;
         args?: string[] | undefined;
     }>>;
+    mcpAliases: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodArray<z.ZodString, "many">>>;
 }, "strip", z.ZodTypeAny, {
     id: string;
     name: string;
@@ -260,6 +261,7 @@ export declare const skillZ: z.ZodEffects<z.ZodObject<{
         command?: string | undefined;
         args?: string[] | undefined;
     } | undefined;
+    mcpAliases?: Record<string, string[]> | undefined;
 }, {
     id: string;
     name: string;
@@ -284,6 +286,7 @@ export declare const skillZ: z.ZodEffects<z.ZodObject<{
         description: string;
         input_schema: Record<string, unknown>;
     }[] | undefined;
+    mcpAliases?: Record<string, string[]> | undefined;
 }>, {
     id: string;
     name: string;
@@ -308,6 +311,7 @@ export declare const skillZ: z.ZodEffects<z.ZodObject<{
         command?: string | undefined;
         args?: string[] | undefined;
     } | undefined;
+    mcpAliases?: Record<string, string[]> | undefined;
 }, {
     id: string;
     name: string;
@@ -332,6 +336,7 @@ export declare const skillZ: z.ZodEffects<z.ZodObject<{
         description: string;
         input_schema: Record<string, unknown>;
     }[] | undefined;
+    mcpAliases?: Record<string, string[]> | undefined;
 }>;
 /**
  * NodeSources: either an array of Sources (additive — inherits cascade)

package/dist/schema.js

@@ -61,6 +61,7 @@ export const skillZ = z
     tools: z.array(toolZ).default([]),
     instruction: z.string().optional(),
     mcp: mcpServerConfigZ.optional(),
+    mcpAliases: z.record(z.array(z.string().min(1)).min(1)).optional(),
 })
     .refine((s) => s.tools.length > 0 || s.instruction || s.mcp, {
     message: "Skill must provide at least one of: tools, instruction, or mcp",

package/dist/skills/github.js

@@ -183,4 +183,21 @@ export const github = {
             },
         },
     ],
+    // Equivalent tool names on GitHub's official MCP server
+    // (github.com/github/github-mcp-server). Aliases declared for every
+    // GitHub MCP name that does NOT also exist on Linear's MCP. The
+    // executor's buildToolAliases already drops any name claimed by more
+    // than one loaded skill, so these declarations are safe even if a
+    // future provider starts using the same name — declare what this
+    // skill knows, let the runtime resolve conflicts.
+    //
+    // Names that currently exist on both Linear and GitHub MCPs and are
+    // therefore intentionally NOT aliased on either side: `get_issue`,
+    // `list_issues`.
+    mcpAliases: {
+        github_create_pr: ["create_pull_request"],
+        github_add_comment: ["add_issue_comment"],
+        github_create_issue: ["create_issue"],
+        github_search_issues: ["search_issues"],
+    },
 };

package/dist/skills/index.d.ts

@@ -7,7 +7,7 @@
  * Custom skill discovery (filesystem-based) lives in `./custom-loader.js`,
  * which is Node-only and re-exported from `@sweny-ai/core` (the Node entry).
  */
-import type { Skill, SkillCategory } from "../types.js";
+import type { Logger, Skill, SkillCategory } from "../types.js";
 import { github } from "./github.js";
 import { linear } from "./linear.js";
 import { slack } from "./slack.js";
@@ -86,3 +86,24 @@ export declare function validateWorkflowSkills(workflow: {
         skills: string[];
     }>;
 }, available: Map<string, Skill>, inlineSkills?: Record<string, InlineSkillDef>): SkillValidationResult;
+/**
+ * Build a symmetric tool-name alias table from the loaded skills.
+ *
+ * Each skill declares its own `mcpAliases` (canonical name → list of
+ * equivalent MCP tool names). This function:
+ *
+ *   1. Collects every alias pair declared by every loaded skill.
+ *   2. Flattens each pair into one equivalence group (symmetric closure).
+ *   3. Drops any MCP name claimed by more than one skill (ambiguous).
+ *
+ * Core stays vendor-neutral: nothing here knows Linear or GitHub by name.
+ * Skills own their own naming, and ambiguity is detected at map-build
+ * time so a call to one provider's `get_issue` can never spuriously
+ * satisfy another provider's `any_tool_called` verify rule.
+ *
+ * @returns a map from every participating name to the full set of names
+ *   that count as equivalent to it (including itself). Names that do not
+ *   participate in any alias are absent — callers should fall back to
+ *   name-equality when a lookup returns `undefined`.
+ */
+export declare function buildToolAliases(skills: Iterable<Skill>, logger?: Logger): ReadonlyMap<string, ReadonlySet<string>>;

package/dist/skills/index.js

@@ -144,3 +144,94 @@ export function validateWorkflowSkills(workflow, available, inlineSkills) {
     }
     return { configured, missing, errors, warnings };
 }
+/**
+ * Build a symmetric tool-name alias table from the loaded skills.
+ *
+ * Each skill declares its own `mcpAliases` (canonical name → list of
+ * equivalent MCP tool names). This function:
+ *
+ *   1. Collects every alias pair declared by every loaded skill.
+ *   2. Flattens each pair into one equivalence group (symmetric closure).
+ *   3. Drops any MCP name claimed by more than one skill (ambiguous).
+ *
+ * Core stays vendor-neutral: nothing here knows Linear or GitHub by name.
+ * Skills own their own naming, and ambiguity is detected at map-build
+ * time so a call to one provider's `get_issue` can never spuriously
+ * satisfy another provider's `any_tool_called` verify rule.
+ *
+ * @returns a map from every participating name to the full set of names
+ *   that count as equivalent to it (including itself). Names that do not
+ *   participate in any alias are absent — callers should fall back to
+ *   name-equality when a lookup returns `undefined`.
+ */
+export function buildToolAliases(skills, logger) {
+    // First pass: record which skill(s) claim each MCP alias name.
+    const mcpClaims = new Map(); // mcp name → skill ids that declared it
+    const pairs = []; // [canonical, mcpAlias]
+    for (const skill of skills) {
+        if (!skill.mcpAliases)
+            continue;
+        for (const [canonical, aliases] of Object.entries(skill.mcpAliases)) {
+            for (const alias of aliases) {
+                if (canonical === alias)
+                    continue;
+                pairs.push([canonical, alias]);
+                const claimers = mcpClaims.get(alias);
+                if (claimers) {
+                    if (!claimers.includes(skill.id))
+                        claimers.push(skill.id);
+                }
+                else {
+                    mcpClaims.set(alias, [skill.id]);
+                }
+            }
+        }
+    }
+    // Drop ambiguous MCP names (claimed by >1 skill) and log once.
+    const ambiguous = new Set();
+    for (const [name, claimers] of mcpClaims) {
+        if (claimers.length > 1) {
+            ambiguous.add(name);
+            logger?.warn(`Tool alias "${name}" is declared by multiple skills (${claimers.join(", ")}); dropping from verify alias table to avoid cross-provider false positives.`);
+        }
+    }
+    // Second pass: union-find over the remaining pairs.
+    const parent = new Map();
+    const find = (x) => {
+        let cur = parent.get(x) ?? x;
+        while (cur !== (parent.get(cur) ?? cur))
+            cur = parent.get(cur) ?? cur;
+        parent.set(x, cur);
+        return cur;
+    };
+    const union = (a, b) => {
+        const ra = find(a);
+        const rb = find(b);
+        if (ra !== rb)
+            parent.set(ra, rb);
+    };
+    // `find` registers previously-unseen nodes via `parent.get(x) ?? x` and
+    // writes them back, so `union` handles first-contact pairs on its own.
+    for (const [canonical, alias] of pairs) {
+        if (ambiguous.has(alias))
+            continue;
+        union(canonical, alias);
+    }
+    // Build the result: each name → its full equivalence set.
+    const groups = new Map();
+    for (const name of parent.keys()) {
+        const root = find(name);
+        let group = groups.get(root);
+        if (!group) {
+            group = new Set();
+            groups.set(root, group);
+        }
+        group.add(name);
+    }
+    const result = new Map();
+    for (const group of groups.values()) {
+        for (const name of group)
+            result.set(name, group);
+    }
+    return result;
+}

package/dist/skills/linear.js

@@ -144,4 +144,24 @@ export const linear = {
             },
         },
     ],
+    // Equivalent tool names on Linear's official remote MCP server (mcp.linear.app).
+    //
+    // Linear's MCP uses upsert naming: a single `save_issue` handles both
+    // create and update. The executor builds symmetric equivalence groups, so
+    // both `linear_create_issue` and `linear_update_issue` end up in one group
+    // with `save_issue`. A `save_issue` call satisfies verify rules for either
+    // canonical name — verify cannot distinguish create from update when the
+    // agent uses the remote MCP. That reflects the provider's reality, not a
+    // shortcoming of the alias layer.
+    //
+    // Names that also exist on GitHub's MCP server (`get_issue`, `list_issues`,
+    // `get_team`) are left out. `buildToolAliases` also drops any MCP name
+    // claimed by more than one loaded skill as a defensive backstop.
+    mcpAliases: {
+        linear_create_issue: ["save_issue"],
+        linear_update_issue: ["save_issue"],
+        linear_search_issues: ["list_issues"],
+        linear_add_comment: ["save_comment"],
+        linear_list_teams: ["list_teams"],
+    },
 };

package/dist/types.d.ts

@@ -36,6 +36,25 @@ export interface Skill {
     instruction?: string;
     /** External MCP server definition wired for nodes referencing this skill. */
     mcp?: McpServerConfig;
+    /**
+     * Tool-name aliases recognized by `verify`.
+     *
+     * When a workflow references `any_tool_called: [linear_create_issue]` and
+     * the agent instead calls the equivalent MCP tool exposed by this skill's
+     * MCP server (e.g. `save_issue` on Linear's remote MCP), the two names
+     * should count as equivalent. Each skill owns the mapping for its own
+     * domain — core stays vendor-neutral.
+     *
+     * Key: a canonical tool name (usually one of this skill's `tools[].name`,
+     * but any name the skill wants to equate is valid).
+     * Value: list of equivalent names, typically tool names exposed by this
+     * skill's external MCP server.
+     *
+     * Aliases are symmetric: a verify rule naming either side matches a call
+     * on either side. Omit names that are ambiguous across providers
+     * (e.g. `get_issue` is exposed by both Linear and GitHub MCP servers).
+     */
+    mcpAliases?: Record<string, string[]>;
 }
 /**
  * Per-node rules or context.

package/dist/verify.d.ts

@@ -9,9 +9,10 @@ export type Resolution = {
 };
 export declare function resolvePath(data: unknown, path: string): Resolution;
 export declare function isErrorOutput(output: unknown): boolean;
-export declare function checkAnyToolCalled(required: string[], toolCalls: ToolCall[]): string | null;
-export declare function checkAllToolsCalled(required: string[], toolCalls: ToolCall[]): string | null;
-export declare function checkNoToolCalled(forbidden: string[], toolCalls: ToolCall[]): string | null;
+export type ToolAliases = ReadonlyMap<string, ReadonlySet<string>>;
+export declare function checkAnyToolCalled(required: string[], toolCalls: ToolCall[], aliases?: ToolAliases): string | null;
+export declare function checkAllToolsCalled(required: string[], toolCalls: ToolCall[], aliases?: ToolAliases): string | null;
+export declare function checkNoToolCalled(forbidden: string[], toolCalls: ToolCall[], aliases?: ToolAliases): string | null;
 export declare function checkOutputRequired(paths: string[], data: unknown): string | null;
 export declare function checkOutputMatches(matches: OutputMatch[], data: unknown): string | null;
 /**
@@ -21,4 +22,4 @@ export declare function checkOutputMatches(matches: OutputMatch[], data: unknown
  * Deterministic and side-effect free — the executor calls this synchronously
  * after the LLM finishes.
  */
-export declare function evaluateVerify(verify: NodeVerify | undefined, result: NodeResult): string | null;
+export declare function evaluateVerify(verify: NodeVerify | undefined, result: NodeResult, aliases?: ToolAliases): string | null;

package/dist/verify.js

@@ -105,73 +105,32 @@ function succeededTools(toolCalls) {
 function calledList(toolCalls) {
     return toolCalls.map((c) => c.tool).join(", ") || "none";
 }
-// Tool aliases: first-party SWEny skill tool names ↔ their MCP-server equivalents.
-//
-// When an external MCP server is wired for the same provider a skill covers
-// (e.g. the Linear HTTP MCP server alongside the `linear` skill), both sets of
-// tools are presented to the agent and the agent may pick either. The calls
-// are functionally equivalent — same backend, same effect — but the names
-// differ, so a verify rule that lists one will fail when the agent picked the
-// other. These aliases let either call satisfy the rule.
-//
-// Only unambiguous MCP tool names are aliased. Names that collide across
-// providers (e.g. `get_issue` exists on both Linear and GitHub MCP servers)
-// are deliberately omitted so a call to one provider cannot spuriously
-// satisfy a rule about the other.
-const TOOL_ALIAS_GROUPS = [
-    // Linear (official remote MCP at mcp.linear.app — upsert naming)
-    ["linear_search_issues", "list_issues"],
-    ["linear_create_issue", "save_issue"],
-    ["linear_update_issue", "save_issue"],
-    ["linear_add_comment", "save_comment"],
-    ["linear_list_teams", "list_teams"],
-    // GitHub (github.com/github/github-mcp-server)
-    ["github_create_issue", "create_issue"],
-    ["github_search_issues", "search_issues"],
-    ["github_add_comment", "add_issue_comment"],
-    ["github_create_pr", "create_pull_request"],
-];
-const TOOL_ALIASES = (() => {
-    const map = new Map();
-    for (const group of TOOL_ALIAS_GROUPS) {
-        for (const name of group) {
-            let set = map.get(name);
-            if (!set) {
-                set = new Set();
-                map.set(name, set);
-            }
-            for (const other of group)
-                set.add(other);
-        }
-    }
-    return map;
-})();
-function expandAliases(name) {
-    return TOOL_ALIASES.get(name) ?? new Set([name]);
+function expandAliases(name, aliases) {
+    return aliases?.get(name) ?? new Set([name]);
 }
-function anyAliasIn(name, set) {
-    for (const alias of expandAliases(name)) {
+function anyAliasIn(name, set, aliases) {
+    for (const alias of expandAliases(name, aliases)) {
         if (set.has(alias))
             return true;
     }
     return false;
 }
-export function checkAnyToolCalled(required, toolCalls) {
+export function checkAnyToolCalled(required, toolCalls, aliases) {
     const succeeded = succeededTools(toolCalls);
-    if (required.some((t) => anyAliasIn(t, succeeded)))
+    if (required.some((t) => anyAliasIn(t, succeeded, aliases)))
         return null;
     return `any_tool_called: required one of [${required.join(", ")}] to succeed, called: [${calledList(toolCalls)}]`;
 }
-export function checkAllToolsCalled(required, toolCalls) {
+export function checkAllToolsCalled(required, toolCalls, aliases) {
     const succeeded = succeededTools(toolCalls);
-    const missing = required.filter((t) => !anyAliasIn(t, succeeded));
+    const missing = required.filter((t) => !anyAliasIn(t, succeeded, aliases));
     if (missing.length === 0)
         return null;
     return `all_tools_called: missing successful calls to [${missing.join(", ")}], called: [${calledList(toolCalls)}]`;
 }
-export function checkNoToolCalled(forbidden, toolCalls) {
+export function checkNoToolCalled(forbidden, toolCalls, aliases) {
     const calledNames = new Set(toolCalls.map((c) => c.tool));
-    const violated = forbidden.filter((t) => anyAliasIn(t, calledNames));
+    const violated = forbidden.filter((t) => anyAliasIn(t, calledNames, aliases));
     if (violated.length === 0)
         return null;
     return `no_tool_called: forbidden tools were invoked: [${violated.join(", ")}], called: [${calledList(toolCalls)}]`;
@@ -363,22 +322,22 @@ function describeOperator(c) {
  * Deterministic and side-effect free — the executor calls this synchronously
  * after the LLM finishes.
  */
-export function evaluateVerify(verify, result) {
+export function evaluateVerify(verify, result, aliases) {
     if (!verify)
         return null;
     const failures = [];
     if (verify.any_tool_called && verify.any_tool_called.length > 0) {
-        const e = checkAnyToolCalled(verify.any_tool_called, result.toolCalls);
+        const e = checkAnyToolCalled(verify.any_tool_called, result.toolCalls, aliases);
         if (e)
             failures.push(e);
     }
     if (verify.all_tools_called && verify.all_tools_called.length > 0) {
-        const e = checkAllToolsCalled(verify.all_tools_called, result.toolCalls);
+        const e = checkAllToolsCalled(verify.all_tools_called, result.toolCalls, aliases);
         if (e)
             failures.push(e);
     }
     if (verify.no_tool_called && verify.no_tool_called.length > 0) {
-        const e = checkNoToolCalled(verify.no_tool_called, result.toolCalls);
+        const e = checkNoToolCalled(verify.no_tool_called, result.toolCalls, aliases);
         if (e)
             failures.push(e);
     }

package/dist/workflows/browser.js

@@ -1,3 +1,3 @@
-export const triageWorkflow = {"id":"triage","name":"Alert Triage","description":"Investigate a production alert, determine root cause, create an issue, implement a fix, and notify the team","entry":"gather","nodes":{"gather":{"name":"Gather Context","instruction":"You are investigating a production alert. Gather all relevant context using the available tools:\n\n1. **Observability**: Pull error details, stack traces, recent logs, metrics, and active incidents around the time of the alert. Use whichever observability tools are available to you.\n2. **Source control**: Check recent commits, pull requests, and deploys that might be related.\n3. **Issue tracker**: Search for similar past issues or known problems.\n\nBe thorough — the investigation step depends on complete context. Use every tool available to you.","skills":["github","sentry","datadog","betterstack","linear"]},"investigate":{"name":"Root Cause Analysis","instruction":"Based on the gathered context, classify every distinct issue you found into one of two buckets: **novel** or **duplicate**.\n\nFor EACH issue found:\n1. Identify the root cause and affected code/service.\n2. Assess severity: critical (service down), high (major feature broken), medium (degraded), low (cosmetic/minor).\n3. Assess fix complexity: \"simple\" (a few lines, clear change), \"moderate\" (multiple files but well-understood), or \"complex\" (architectural, risky, or unclear).\n4. **Novelty check (REQUIRED — you MUST call tools for this step):** Filing a duplicate ticket is worse than under-reporting — the team inherits sprawl that humans have to clean up later. Complete EVERY step below before classifying anything as novel. Do NOT skip these searches even if the gather context already mentions existing issues or branches — you must verify independently.\n4a. **Search broadly — THIS REQUIRES TOOL CALLS.** You MUST call `linear_search_issues` (or `github_search_issues`) with multiple queries against the issue tracker (BOTH open AND closed): the affected file or module path, the error message or log string verbatim, the feature or service name, and the symptom family (e.g. \"startup crash\", \"data dropped silently\"). Do not rely on a single keyword — a narrow search is how duplicates slip through. If you skip this search, the verify check will fail.\n4b. **Read the full body of every promising candidate — do NOT match on title alone.** For each top match, open the issue and read its entire description, including any \"Recommended Fix\", \"Proposed Fix\", \"Action Items\", or \"Acceptance Criteria\" section. An existing open issue whose recommended fix already prescribes the change you were about to propose IS a duplicate, even if the symptom you just observed is a new instance of the same underlying bug.\n4c. **Check for meta-issues and bug families.** If an existing ticket names a pattern that your finding is another instance of (same root cause, same function/module, different input or caller), treat your finding as a sibling of that family and comment on the existing ticket. Do not file a parallel ticket per instance — that is the exact pattern that produces backlog sprawl.\n4d. **When uncertain, comment don't file.** If you are less than ~80% confident a finding is truly novel after steps 4a–4c, classify it as a duplicate and add a \"+1 — another instance\" comment to the closest existing issue with the new context. Over-reporting duplicates is cheap; ticket sprawl is expensive.\n\n   - If matched → **duplicate**. Record the existing issue ID in `duplicate_of`.\n   - If no match after 4a–4d → **novel**.\n\n**Output rules:**\n- `findings`: array of ALL issues found (both novel and duplicate).\n- `novel_count`: how many findings are novel (not duplicates).\n- `highest_severity`: the highest severity across ALL findings.\n- `recommendation`: what should happen next.\n\nDownstream nodes will act ONLY on novel findings. Duplicates will be +1'd automatically.\n\n**IMPORTANT — scope boundaries for this node:**\n- DO NOT create issues (Linear, GitHub, or any tracker). A downstream `create_issue` node handles that.\n- DO NOT create branches, commits, or pull requests. A downstream `implement` node handles that.\n- DO NOT call any write tools (`linear_create_issue`, `github_create_issue`, `github_create_pr`, `linear_add_comment`, `github_add_comment`, etc.). Downstream nodes handle all writes — issue creation, +1 comments, and PRs.\n- Your ONLY job is read, search, classify, and output. If you create an issue or add a comment here, the downstream verify check will fail or duplicate work.","skills":["github","linear"],"verify":{"any_tool_called":["linear_search_issues","github_search_issues"]},"output":{"type":"object","properties":{"findings":{"type":"array","items":{"type":"object","properties":{"title":{"type":"string","description":"Short description of the issue"},"root_cause":{"type":"string"},"severity":{"type":"string","enum":["critical","high","medium","low"]},"affected_services":{"type":"array","items":{"type":"string"}},"is_duplicate":{"type":"boolean"},"duplicate_of":{"type":"string","description":"Existing issue ID/URL if duplicate"},"fix_approach":{"type":"string"},"fix_complexity":{"type":"string","enum":["simple","moderate","complex"]}},"required":["title","root_cause","severity","is_duplicate"]}},"novel_count":{"type":"number","description":"Count of novel (non-duplicate) findings"},"highest_severity":{"type":"string","enum":["critical","high","medium","low"]},"recommendation":{"type":"string"}},"required":["findings","novel_count","highest_severity","recommendation"]}},"create_issue":{"name":"Create Issues & Triage Duplicates","instruction":"Process ALL findings from the investigation. The findings array contains both novel and duplicate issues.\n\n**For each NOVEL finding** (is_duplicate = false):\n1. **First, check if a prior triage run already created an issue for this exact bug.** Call `linear_search_issues` (or `github_search_issues`) with the error message or root cause. If a matching issue already exists with the same root cause:\n   - Treat it as a duplicate: DO NOT create a new issue.\n   - Populate `issueIdentifier`, `issueTitle`, and `issueUrl` from the existing issue.\n   - Add a \"+1\" comment if appropriate (using `linear_add_comment` or `github_add_comment`).\n   - Set the `action` to `updated` in the `issues` array.\n   - This prevents duplicate tickets when the same alert fires multiple times.\n\n2. If no matching issue exists, create a new one with a clear, actionable title by invoking `linear_create_issue` or `github_create_issue`. You MUST actually call the tool — do NOT synthesize an identifier from an alert ID, commit SHA, or your own imagination. If the tool errors, stop and report the failure; do not invent a fallback identifier. **Use the exact tool names above** — do NOT use generic alternatives like `create_issue` or `create_pull_request` from ToolSearch. The verify check requires the specific tool names listed here.\n3. Include: root cause, severity, affected services, reproduction steps, and recommended fix.\n4. Add appropriate labels (bug, severity level, affected service).\n5. Link to relevant commits, PRs, or existing issues.\n6. Copy the identifier returned by the tool verbatim into the `issueIdentifier` output field. The identifier must match `^[A-Z][A-Z0-9]*-\\d+$` (e.g. `OFF-1234`) — do not prefix it with anything else.\n\n**For each DUPLICATE finding** (is_duplicate = true):\n1. Find the existing issue (check duplicate_of field).\n2. Check the issue's comments — if the most recent comment is already from SWEny (contains \"+1\") within the last 24 hours, skip adding another comment.\n3. Otherwise add a SHORT comment: \"+1 — seen again {UTC timestamp}. {one sentence of new context}.\" (Keep it under 2 lines. No markdown headers, no emoji, no formatting.)\n4. If the existing issue is closed/done, reopen it.\n\nIf context.issueTemplate is provided, use it as the format for new issue bodies. Otherwise use a clear structure with: Summary, Root Cause, Impact, Steps to Reproduce, and Recommended Fix.\n\nUse the issue tracker specified in context (e.g. Linear, Jira, or GitHub Issues) — do NOT fall back to a different tracker. Output the created/updated issue identifiers.\n\n**IMPORTANT — scope boundaries for this node:**\n- DO NOT create branches, commits, or pull requests. The `implement` and `create_pr` nodes handle that.\n- DO NOT call `create_pull_request`, `github_create_pr`, or any PR/branch tools.\n- Your job is issue creation and duplicate management ONLY.","skills":["linear","github"],"verify":{"any_tool_called":["linear_create_issue","github_create_issue","linear_search_issues","github_search_issues","linear_add_comment","github_add_comment"]},"output":{"type":"object","properties":{"issueIdentifier":{"type":"string","pattern":"^[A-Z][A-Z0-9]*-\\d+$","description":"Primary issue identifier (e.g. OFF-1234). MUST be the identifier returned by `linear_create_issue` / `github_create_issue` — do NOT invent a value from a Sentry short-ID or commit SHA. Used by downstream nodes for branch naming and PR linking."},"issueTitle":{"type":"string","description":"Title of the primary issue created"},"issueUrl":{"type":"string","pattern":"^https?://","description":"URL of the primary issue created, as returned by the create-issue tool"},"issues":{"type":"array","minItems":1,"description":"All issues created or updated during this step","items":{"type":"object","properties":{"identifier":{"type":"string"},"title":{"type":"string"},"url":{"type":"string"},"action":{"type":"string","enum":["created","updated","reopened"]}},"required":["identifier","action"]}}},"required":["issueIdentifier","issueTitle","issueUrl","issues"]}},"skip":{"name":"Skip — All Duplicates or Low Priority","instruction":"Every finding from the investigation was either a duplicate or low-priority. No new issues need to be created.\n\nFor each **duplicate** finding (check the findings array for items where is_duplicate = true):\n1. Find the existing issue (check duplicate_of field).\n2. Check the issue's comments — if the most recent comment is already from SWEny (contains \"+1\") within the last 24 hours, skip adding another comment.\n3. Otherwise add a SHORT comment: \"+1 — seen again {UTC timestamp}. {one sentence of new context}.\" (Keep it under 2 lines. No markdown headers, no emoji, no formatting.)\n4. If the issue is closed/done, reopen it.\n\nFor **low priority** findings, log a brief note about why they were skipped.","skills":["linear","github"]},"implement":{"name":"Implement Fix","instruction":"Implement the fix identified during investigation. The issue created in the previous step is in your context — use its identifier for branch naming and commit messages.\n\n0. **Precondition — verify context.create_issue.issueIdentifier is well-formed.**\n   The identifier MUST match `^[A-Z][A-Z0-9]*-\\d+$` (e.g. `OFF-1234`). If it is\n   missing, empty, or matches a Sentry short-ID / slug / any other shape, STOP\n   immediately — do NOT invent a branch name from the Sentry event, commit SHA,\n   or alert payload. Return a failed status with a clear message instead; the\n   workflow will route to notify and a human will pick it up.\n\n1. Create a feature branch from the base branch (check context for baseBranch, default \"main\").\n   **Branch name MUST include the issue identifier** exactly as provided in\n   `context.create_issue.issueIdentifier`. Format: lowercase the identifier and use\n   it as a prefix, e.g. `off-1234-fix-null-check`. If the repository uses a different\n   branch convention (check context.branchPattern or the rules/CLAUDE.md for a\n   regex), follow that — but the identifier piece MUST still come from\n   `context.create_issue.issueIdentifier`, never from a Sentry short-ID.\n2. Read the relevant source files to understand the current code.\n3. Make the necessary code changes — fix the bug, nothing more.\n4. Run any existing tests if available to verify the fix doesn't break anything.\n5. Stage and commit with a clear commit message. Start the message with the issue identifier in brackets,\n   e.g. `[OFF-1234] fix: guard null projectId before database lookup`.\n\nKeep changes minimal and focused. Do not refactor surrounding code or add unrelated improvements.\n\nIf the fix turns out to be more complex than expected, stop and explain why — do not force a bad fix.","skills":["github"]},"create_pr":{"name":"Open Pull Request","instruction":"Open a pull request for the fix. The issue identifier and URL are in your context from the create_issue step.\n\n1. Push the branch to the remote.\n2. Create the PR using the `github_create_pr` tool. **Use this exact tool name** — do NOT use `create_pull_request` or any other variant from ToolSearch. The verify check requires `github_create_pr` specifically.\n3. PR title MUST start with the issue identifier in brackets. Format: `[{context.create_issue.issueIdentifier}] fix: {short description}`.\n4. In the PR body, include: summary of the bug, what the fix does, and a link to the issue (context.create_issue.issueUrl). If the investigation found a Sentry issue, include \"Fixes {sentryShortId}\" in the PR body so Sentry auto-resolves on merge.\n5. Add appropriate labels if available.\n\nIf context.prTemplate is provided, use it as the format for the PR body. Otherwise use a clear structure with: Summary, Changes, Testing, and Related Issues.\n\nIf context.cloudRunId is provided, append this HTML comment to the end of the PR body: <!-- sweny:run_id:{context.cloudRunId} -->\n\nReturn the PR URL and number.","skills":["github"],"verify":{"any_tool_called":["github_create_pr"]}},"notify":{"name":"Notify Team","instruction":"Send a notification summarizing the triage result:\n\n1. Include: alert summary, severity, root cause (1-2 sentences), and links to any created issues or PRs.\n2. For critical/high severity, make the notification urgent.\n3. For medium/low, a standard notification is fine.\n\nUse whichever notification channel is available to you.","skills":["slack","notification"]}},"edges":[{"from":"gather","to":"investigate"},{"from":"investigate","to":"create_issue","when":"novel_count is greater than 0 AND highest_severity is medium or higher"},{"from":"investigate","to":"skip","when":"novel_count is 0, OR highest_severity is low"},{"from":"create_issue","to":"implement","when":"at least one novel finding has fix_complexity simple or moderate AND fix_approach is provided"},{"from":"create_issue","to":"notify","when":"all novel findings have fix_complexity complex, OR no clear fix_approach"},{"from":"skip","to":"notify"},{"from":"implement","to":"create_pr"},{"from":"create_pr","to":"notify"}],"skills":{}};
+export const triageWorkflow = {"id":"triage","name":"Alert Triage","description":"Investigate a production alert, determine root cause, create an issue, implement a fix, and notify the team","entry":"gather","nodes":{"gather":{"name":"Gather Context","instruction":"You are investigating a production alert. Gather all relevant context using the available tools:\n\n1. **Observability**: Pull error details, stack traces, recent logs, metrics, and active incidents around the time of the alert. Use whichever observability tools are available to you.\n2. **Source control**: Check recent commits, pull requests, and deploys that might be related.\n3. **Issue tracker**: Search for similar past issues or known problems.\n\nBe thorough — the investigation step depends on complete context. Use every tool available to you.","skills":["github","sentry","datadog","betterstack","linear"]},"investigate":{"name":"Root Cause Analysis","instruction":"Based on the gathered context, classify every distinct issue you found into one of two buckets: **novel** or **duplicate**.\n\nFor EACH issue found:\n1. Identify the root cause and affected code/service.\n2. Assess severity: critical (service down), high (major feature broken), medium (degraded), low (cosmetic/minor).\n3. Assess fix complexity: \"simple\" (a few lines, clear change), \"moderate\" (multiple files but well-understood), or \"complex\" (architectural, risky, or unclear).\n4. **Novelty check (REQUIRED — you MUST call tools for this step):** Filing a duplicate ticket is worse than under-reporting — the team inherits sprawl that humans have to clean up later. Complete EVERY step below before classifying anything as novel. Do NOT skip these searches even if the gather context already mentions existing issues or branches — you must verify independently.\n4a. **Search broadly — THIS REQUIRES TOOL CALLS.** You MUST call `linear_search_issues` (or `github_search_issues`) with multiple queries against the issue tracker (BOTH open AND closed): the affected file or module path, the error message or log string verbatim, the feature or service name, and the symptom family (e.g. \"startup crash\", \"data dropped silently\"). Do not rely on a single keyword — a narrow search is how duplicates slip through. If you skip this search, the verify check will fail.\n4b. **Read the full body of every promising candidate — do NOT match on title alone.** For each top match, open the issue and read its entire description, including any \"Recommended Fix\", \"Proposed Fix\", \"Action Items\", or \"Acceptance Criteria\" section. An existing open issue whose recommended fix already prescribes the change you were about to propose IS a duplicate, even if the symptom you just observed is a new instance of the same underlying bug.\n4c. **Check for meta-issues and bug families.** If an existing ticket names a pattern that your finding is another instance of (same root cause, same function/module, different input or caller), treat your finding as a sibling of that family and comment on the existing ticket. Do not file a parallel ticket per instance — that is the exact pattern that produces backlog sprawl.\n4d. **When uncertain, comment don't file.** If you are less than ~80% confident a finding is truly novel after steps 4a–4c, classify it as a duplicate and add a \"+1 — another instance\" comment to the closest existing issue with the new context. Over-reporting duplicates is cheap; ticket sprawl is expensive.\n\n   - If matched → **duplicate**. Record the existing issue ID in `duplicate_of`.\n   - If no match after 4a–4d → **novel**.\n\n**Output rules:**\n- `findings`: array of ALL issues found (both novel and duplicate).\n- `novel_count`: how many findings are novel (not duplicates).\n- `highest_severity`: the highest severity across ALL findings.\n- `recommendation`: what should happen next.\n\nDownstream nodes will act ONLY on novel findings. Duplicates will be +1'd automatically.\n\n**IMPORTANT — scope boundaries for this node:**\n- DO NOT create issues (Linear, GitHub, or any tracker). A downstream `create_issue` node handles that.\n- DO NOT create branches, commits, or pull requests. A downstream `implement` node handles that.\n- DO NOT call any write tools (`linear_create_issue`, `github_create_issue`, `github_create_pr`, `linear_add_comment`, `github_add_comment`, etc.). Downstream nodes handle all writes — issue creation, +1 comments, and PRs.\n- Your ONLY job is read, search, classify, and output. If you create an issue or add a comment here, the downstream verify check will fail or duplicate work.","skills":["github","linear"],"verify":{"any_tool_called":["linear_search_issues","github_search_issues"]},"output":{"type":"object","properties":{"findings":{"type":"array","items":{"type":"object","properties":{"title":{"type":"string","description":"Short description of the issue"},"root_cause":{"type":"string"},"severity":{"type":"string","enum":["critical","high","medium","low"]},"affected_services":{"type":"array","items":{"type":"string"}},"is_duplicate":{"type":"boolean"},"duplicate_of":{"type":"string","description":"Existing issue ID/URL if duplicate"},"fix_approach":{"type":"string"},"fix_complexity":{"type":"string","enum":["simple","moderate","complex"]}},"required":["title","root_cause","severity","is_duplicate"]}},"novel_count":{"type":"number","description":"Count of novel (non-duplicate) findings"},"highest_severity":{"type":"string","enum":["critical","high","medium","low"]},"recommendation":{"type":"string"}},"required":["findings","novel_count","highest_severity","recommendation"]}},"create_issue":{"name":"Create Issues & Triage Duplicates","instruction":"Process ALL findings from the investigation. The findings array contains both novel and duplicate issues.\n\n**For each NOVEL finding** (is_duplicate = false):\n1. **First, check if a prior triage run already created an issue for this exact bug.** Call `linear_search_issues` (or `github_search_issues`) with the error message or root cause. If a matching issue already exists with the same root cause:\n   - Treat it as a duplicate: DO NOT create a new issue.\n   - Populate `issueIdentifier`, `issueTitle`, and `issueUrl` from the existing issue.\n   - Add a \"+1\" comment if appropriate (using `linear_add_comment` or `github_add_comment`).\n   - Set the `action` to `updated` in the `issues` array.\n   - This prevents duplicate tickets when the same alert fires multiple times.\n\n2. If no matching issue exists, create a new one with a clear, actionable title by invoking `linear_create_issue` or `github_create_issue`. You MUST actually call the tool — do NOT synthesize an identifier from an alert ID, commit SHA, or your own imagination. If the tool errors, stop and report the failure; do not invent a fallback identifier. **Use the exact tool names above** — do NOT use generic alternatives like `create_issue` or `create_pull_request` from ToolSearch. The verify check requires the specific tool names listed here.\n3. Include: root cause, severity, affected services, reproduction steps, and recommended fix.\n4. Add appropriate labels (bug, severity level, affected service).\n5. Link to relevant commits, PRs, or existing issues.\n6. Copy the identifier returned by the tool verbatim into the `issueIdentifier` output field. The identifier must match `^[A-Z][A-Z0-9]*-\\d+$` (e.g. `OFF-1234`) — do not prefix it with anything else.\n\n**For each DUPLICATE finding** (is_duplicate = true):\n1. Find the existing issue (check duplicate_of field).\n2. Check the issue's comments — if the most recent comment is already from SWEny (contains \"+1\") within the last 24 hours, skip adding another comment.\n3. Otherwise add a SHORT comment: \"+1 — seen again {UTC timestamp}. {one sentence of new context}.\" (Keep it under 2 lines. No markdown headers, no emoji, no formatting.)\n4. If the existing issue is closed/done, reopen it.\n\nIf context.issueTemplate is provided, use it as the format for new issue bodies. Otherwise use a clear structure with: Summary, Root Cause, Impact, Steps to Reproduce, and Recommended Fix.\n\nUse the issue tracker specified in context (e.g. Linear, Jira, or GitHub Issues) — do NOT fall back to a different tracker. Output the created/updated issue identifiers.\n\n**IMPORTANT — scope boundaries for this node:**\n- DO NOT create branches, commits, or pull requests. The `implement` and `create_pr` nodes handle that.\n- DO NOT call `create_pull_request`, `github_create_pr`, or any PR/branch tools.\n- Your job is issue creation and duplicate management ONLY.","skills":["linear","github"],"verify":{"any_tool_called":["linear_create_issue","github_create_issue","linear_search_issues","github_search_issues","linear_add_comment","github_add_comment"]},"output":{"type":"object","properties":{"issueIdentifier":{"type":"string","pattern":"^[A-Z][A-Z0-9]*-\\d+$","description":"Primary issue identifier (e.g. OFF-1234). MUST be the identifier returned by `linear_create_issue` / `github_create_issue` — do NOT invent a value from a Sentry short-ID or commit SHA. Used by downstream nodes for branch naming and PR linking."},"issueTitle":{"type":"string","description":"Title of the primary issue created"},"issueUrl":{"type":"string","pattern":"^https?://","description":"URL of the primary issue created, as returned by the create-issue tool"},"issues":{"type":"array","minItems":1,"description":"All issues created or updated during this step","items":{"type":"object","properties":{"identifier":{"type":"string"},"title":{"type":"string"},"url":{"type":"string"},"action":{"type":"string","enum":["created","updated","reopened"]}},"required":["identifier","action"]}}},"required":["issueIdentifier","issueTitle","issueUrl","issues"]},"retry":{"max":1,"instruction":{"auto":true}}},"skip":{"name":"Skip — All Duplicates or Low Priority","instruction":"Every finding from the investigation was either a duplicate or low-priority. No new issues need to be created.\n\nFor each **duplicate** finding (check the findings array for items where is_duplicate = true):\n1. Find the existing issue (check duplicate_of field).\n2. Check the issue's comments — if the most recent comment is already from SWEny (contains \"+1\") within the last 24 hours, skip adding another comment.\n3. Otherwise add a SHORT comment: \"+1 — seen again {UTC timestamp}. {one sentence of new context}.\" (Keep it under 2 lines. No markdown headers, no emoji, no formatting.)\n4. If the issue is closed/done, reopen it.\n\nFor **low priority** findings, log a brief note about why they were skipped.","skills":["linear","github"]},"implement":{"name":"Implement Fix","instruction":"Implement the fix identified during investigation. The issue created in the previous step is in your context — use its identifier for branch naming and commit messages.\n\n0. **Precondition — verify context.create_issue.issueIdentifier is well-formed.**\n   The identifier MUST match `^[A-Z][A-Z0-9]*-\\d+$` (e.g. `OFF-1234`). If it is\n   missing, empty, or matches a Sentry short-ID / slug / any other shape, STOP\n   immediately — do NOT invent a branch name from the Sentry event, commit SHA,\n   or alert payload. Return a failed status with a clear message instead; the\n   workflow will route to notify and a human will pick it up.\n\n1. Create a feature branch from the base branch (check context for baseBranch, default \"main\").\n   **Branch name MUST include the issue identifier** exactly as provided in\n   `context.create_issue.issueIdentifier`. Format: lowercase the identifier and use\n   it as a prefix, e.g. `off-1234-fix-null-check`. If the repository uses a different\n   branch convention (check context.branchPattern or the rules/CLAUDE.md for a\n   regex), follow that — but the identifier piece MUST still come from\n   `context.create_issue.issueIdentifier`, never from a Sentry short-ID.\n2. Read the relevant source files to understand the current code.\n3. Make the necessary code changes — fix the bug, nothing more.\n4. Run any existing tests if available to verify the fix doesn't break anything.\n5. Stage and commit with a clear commit message. Start the message with the issue identifier in brackets,\n   e.g. `[OFF-1234] fix: guard null projectId before database lookup`.\n\nKeep changes minimal and focused. Do not refactor surrounding code or add unrelated improvements.\n\nIf the fix turns out to be more complex than expected, stop and explain why — do not force a bad fix.","skills":["github"]},"create_pr":{"name":"Open Pull Request","instruction":"Open a pull request for the fix. The issue identifier and URL are in your context from the create_issue step.\n\n1. Push the branch to the remote.\n2. Create the PR using the `github_create_pr` tool. **Use this exact tool name** — do NOT use `create_pull_request` or any other variant from ToolSearch. The verify check requires `github_create_pr` specifically.\n3. PR title MUST start with the issue identifier in brackets. Format: `[{context.create_issue.issueIdentifier}] fix: {short description}`.\n4. In the PR body, include: summary of the bug, what the fix does, and a link to the issue (context.create_issue.issueUrl). If the investigation found a Sentry issue, include \"Fixes {sentryShortId}\" in the PR body so Sentry auto-resolves on merge.\n5. Add appropriate labels if available.\n\nIf context.prTemplate is provided, use it as the format for the PR body. Otherwise use a clear structure with: Summary, Changes, Testing, and Related Issues.\n\nIf context.cloudRunId is provided, append this HTML comment to the end of the PR body: <!-- sweny:run_id:{context.cloudRunId} -->\n\nReturn the PR URL and number.","skills":["github"],"verify":{"any_tool_called":["github_create_pr"]},"retry":{"max":1,"instruction":{"auto":true}}},"notify":{"name":"Notify Team","instruction":"Send a notification summarizing the triage result:\n\n1. Include: alert summary, severity, root cause (1-2 sentences), and links to any created issues or PRs.\n2. For critical/high severity, make the notification urgent.\n3. For medium/low, a standard notification is fine.\n\nUse whichever notification channel is available to you.","skills":["slack","notification"]}},"edges":[{"from":"gather","to":"investigate"},{"from":"investigate","to":"create_issue","when":"novel_count is greater than 0 AND highest_severity is medium or higher"},{"from":"investigate","to":"skip","when":"novel_count is 0, OR highest_severity is low"},{"from":"create_issue","to":"implement","when":"at least one novel finding has fix_complexity simple or moderate AND fix_approach is provided"},{"from":"create_issue","to":"notify","when":"all novel findings have fix_complexity complex, OR no clear fix_approach"},{"from":"skip","to":"notify"},{"from":"implement","to":"create_pr"},{"from":"create_pr","to":"notify"}],"skills":{}};
 export const implementWorkflow = {"id":"implement","name":"Implement Fix","description":"Implement a code fix for an issue and open a pull request","entry":"analyze","nodes":{"analyze":{"name":"Analyze Issue","instruction":"Read the issue details and understand what needs to be fixed:\n\n1. Fetch the issue from the tracker (GitHub or Linear).\n2. Read the relevant source files to understand the current code.\n3. Identify the exact files and lines that need to change.\n4. Plan the fix approach.\n\nOutput a clear analysis of what needs to change and why.","skills":["github","linear"],"output":{"type":"object","properties":{"issue_summary":{"type":"string"},"files_to_change":{"type":"array","items":{"type":"string"}},"fix_plan":{"type":"string"},"risk_level":{"type":"string","enum":["low","medium","high"]}},"required":["issue_summary","fix_plan"]}},"implement":{"name":"Implement Fix","instruction":"Implement the planned fix:\n\n1. Create a feature branch.\n2. Make the necessary code changes.\n3. Ensure changes are minimal and focused — fix the bug, nothing more.\n4. Stage and commit with a clear commit message referencing the issue.\n\nIf the fix is too risky or complex, explain why and skip.","skills":["github"]},"create_pr":{"name":"Open Pull Request","instruction":"Open a pull request for the fix:\n\n1. Push the branch to the remote.\n2. Create a PR with a clear title and description.\n3. Reference the original issue in the PR body.\n4. Add appropriate reviewers or labels if possible.\n\nIf context.prTemplate is provided, use it as the format for the PR body. Otherwise use a clear structure with: Summary, Changes, Testing, and Related Issues.\n\nIf context.cloudRunId is provided, append this HTML comment to the end of the PR body: <!-- sweny:run_id:{context.cloudRunId} -->\n\nReturn the PR URL.","skills":["github"]},"notify":{"name":"Notify","instruction":"Send a notification about the implementation result:\n\n1. Include: issue reference, PR link, brief summary of changes.\n2. Keep it concise — one message, not a wall of text.","skills":["slack","notification"]},"skip":{"name":"Skip — Too Complex","instruction":"The fix was determined to be too complex or risky for automated implementation.\nAdd a comment to the issue explaining what was found and why it needs manual attention.","skills":["github","linear"]}},"edges":[{"from":"analyze","to":"implement","when":"Fix risk level is low or medium and a clear plan exists"},{"from":"analyze","to":"skip","when":"Fix is too complex, risky, or unclear"},{"from":"implement","to":"create_pr"},{"from":"skip","to":"notify"},{"from":"create_pr","to":"notify"}],"skills":{}};
 export const seedContentWorkflow = {"id":"seed-content","name":"Content Generation Pipeline","description":"Audit content gaps, generate educational content, validate quality, and publish to Supabase","entry":"audit","nodes":{"audit":{"name":"Audit Content Gaps","instruction":"You are auditing an educational platform's content library.\n\nUse supabase_count to check how many items exist for each combination of:\n- Content types: worksheets, games, lessons\n- Subjects: math, science, english, history, geography, economics, music, art, life-skills, foreign-language\n- Difficulties: beginner, easy, medium, hard\n\nAlso check the input parameters — if the user specified a subject, topic, difficulty, and count,\nskip the full audit and just report what they want generated.\n\nReturn a structured content plan: what to generate, how many, at what difficulty and grade level.\nPrioritize gaps where a subject has ZERO content of a given type.","skills":["supabase"],"output":{"type":"object","properties":{"plan":{"type":"array","items":{"type":"object","properties":{"contentType":{"type":"string"},"subject":{"type":"string"},"topic":{"type":"string"},"difficulty":{"type":"string"},"gradeLevel":{"type":"string"},"count":{"type":"number"},"reason":{"type":"string"}},"required":["contentType","subject","topic","difficulty","count"]}},"summary":{"type":"string"}},"required":["plan","summary"]}},"generate":{"name":"Generate Content","instruction":"You are an expert educator creating content for children ages 5-14.\n\nFor each item in the content plan from the previous step, generate the content directly.\nThe content must be high-quality, engaging, age-appropriate, and educationally sound.\n\n**For worksheets:**\nGenerate a JSON array of problems. Each problem needs: \"problem\", \"answer\", \"format\" (answer-line | multiple-choice | write-on).\nRequirements:\n- Every answer MUST be correct. Double-check math, facts, spelling.\n- Problems must progress in difficulty within the set.\n- Use at least 2 different problem structures (e.g., equations + word problems for math).\n- Vary phrasing — no two problems should feel copy-pasted.\n- For the target grade level, use appropriate vocabulary and complexity.\n\n**For lessons:**\nGenerate complete HTML + CSS + JS for an interactive lesson.\nRequirements:\n- Must have substantial educational content (not just a shell with navigation).\n- Include interactive elements: quizzes, click-to-reveal, drag-and-drop.\n- Must be visually engaging with colors, icons, and clear typography.\n- Include practice exercises with immediate feedback.\n- Minimum 5 teaching sections plus 2 practice activities.\n\n**For games:**\nGenerate a description and educational requirements only (actual game code is generated\nby the platform's Phaser-based generator).\n\nUse supabase_insert to write each piece of content to the appropriate table.\n\nTable schemas:\n- worksheets: id (auto), title, subject, topic, difficulty, grade_level, num_questions, problems (jsonb), status='published', source='ai-seed'\n- lessons: id (auto), title, subject, difficulty, grade_level, lesson_type, html_code, css_code, js_code, status='published', source='ai-seed'\n- games: id (auto), title, subject, difficulty, grade_level, game_type, html_code, css_code, js_code, status='published', source='ai-seed'\n\nReturn a summary of what was generated and inserted.","skills":["supabase"],"output":{"type":"object","properties":{"generated":{"type":"array","items":{"type":"object","properties":{"contentType":{"type":"string"},"title":{"type":"string"},"subject":{"type":"string"},"id":{"type":"string"},"status":{"type":"string"}}}},"totalGenerated":{"type":"number"},"errors":{"type":"array","items":{"type":"string"}}},"required":["generated","totalGenerated"]}},"validate":{"name":"Validate Content Quality","instruction":"Review the content that was just generated and inserted.\n\nFor each item, use supabase_query to fetch it back and verify:\n\n**Worksheets:**\n- Parse the problems JSON — are all answers correct?\n- Are problems diverse (not repetitive)?\n- Is difficulty appropriate for the stated grade level?\n- Are there the right number of questions?\n\n**Lessons:**\n- Is the HTML substantial (> 500 characters)?\n- Does it contain actual educational content (not just navigation shells)?\n- Are there interactive elements?\n\n**Games:**\n- Does the HTML contain a working game structure?\n\nFlag any issues. If critical issues are found (wrong answers, empty content),\nuse supabase_update to set status='draft' and add a note.\n\nReturn a quality report.","skills":["supabase"],"output":{"type":"object","properties":{"totalReviewed":{"type":"number"},"passed":{"type":"number"},"flagged":{"type":"number"},"issues":{"type":"array","items":{"type":"object","properties":{"id":{"type":"string"},"title":{"type":"string"},"issue":{"type":"string"},"severity":{"type":"string"},"action":{"type":"string"}}}},"summary":{"type":"string"}},"required":["totalReviewed","passed","flagged","summary"]}},"report":{"name":"Generate Report","instruction":"Compile a final report of the content generation run.\n\nInclude:\n- Total content generated by type and subject\n- Quality validation results\n- Any issues found and actions taken\n- Recommendations for next content generation run (what gaps remain)\n\nFormat as a clean markdown summary that a solo operator can scan in 30 seconds.","skills":[],"output":{"type":"object","properties":{"markdown":{"type":"string"},"nextPriorities":{"type":"array","items":{"type":"string"}}},"required":["markdown"]}}},"edges":[{"from":"audit","to":"generate"},{"from":"generate","to":"validate"},{"from":"validate","to":"report"}],"skills":{}};

package/dist/workflows/triage.yml

@@ -289,6 +289,10 @@ nodes:
         - issueTitle
         - issueUrl
         - issues
+    retry:
+      max: 1
+      instruction:
+        auto: true
   skip:
     name: Skip — All Duplicates or Low Priority
     instruction: >-
@@ -378,6 +382,10 @@ nodes:
     verify:
       any_tool_called:
         - github_create_pr
+    retry:
+      max: 1
+      instruction:
+        auto: true
   notify:
     name: Notify Team
     instruction: |-

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sweny-ai/core",
-  "version": "0.1.79",
+  "version": "0.1.81",
   "type": "module",
   "bin": {
     "sweny": "./dist/cli/main.js"