@zibby/workflow-templates 0.9.5 → 0.10.2

package/browser-test-automation/nodes/execute-live.mjs

@@ -10,43 +10,41 @@
  */
 
 import { z, SKILLS } from '@zibby/core';
-import { formatAssertionChecklist } from './utils.mjs';
 
 export const executeLiveNode = {
   name: 'execute_live',
   skills: [SKILLS.BROWSER, SKILLS.MEMORY],
   timeout: 600000,
 
-  prompt: (state) => {
-    const ctx = state.context;
-    const contextInfo = ctx ? `
-Domain Knowledge & Environment:
-${ctx.global || ''}
-${ctx.pathBased ? `Test-Specific Info:\n${ctx.pathBased}\n` : ''}
-${ctx.env ? `Environment Config:\n${JSON.stringify(ctx.env, null, 2)}\n` : ''}
----
-` : '';
-
-    const assertionChecklist = formatAssertionChecklist(state.preflight?.assertions);
-    
-    return `⚠️  CRITICAL: At the END, output ONLY the JSON object. NO explanations after the JSON.
+  // Declarative Handlebars prompt (editable in the UI). Dynamic bits:
+  //   {{testSpec}}, {{#if context}}…{{/if}}, and the assertion checklist via
+  //   {{#each preflight.assertions}} + the {{inc}} helper.
+  prompt: `⚠️  CRITICAL: At the END, output ONLY the JSON object. NO explanations after the JSON.
 
 🎯 YOUR GOAL: Execute the test steps and collect evidence for script generation.
    You don't need perfect verification - just capture the key actions and results.
    The next node will generate the actual test script from your execution.
 
-${contextInfo}
-${state.testSpec}
-${assertionChecklist ? `
+{{#if context}}
+Domain Knowledge & Environment:
+{{context.global}}
+{{#if context.pathBased}}Test-Specific Info:
+{{context.pathBased}}
+{{/if}}{{#if context.env}}Environment Config:
+{{json context.env}}
+{{/if}}---
+{{/if}}
+{{testSpec}}
+{{#if preflight.assertions.length}}
 ═══════════════════════════════════════════════════
 🎯 ASSERTION CHECKLIST (MANDATORY - from test spec)
 You MUST include ALL of these in your 'assertions' array.
 Report each as passed: true or passed: false with evidence.
 DO NOT skip any. DO NOT add extras.
 
-${assertionChecklist}
-═══════════════════════════════════════════════════
-` : ''}
+{{#each preflight.assertions}}{{inc @index}}. {{this.description}} → expected: {{this.expected}}
+{{/each}}═══════════════════════════════════════════════════
+{{/if}}
 ⚠️  CRITICAL RULES (STRICT ENFORCEMENT):
 1. DO NOT get stuck in read loops - if a snapshot is large, move on
 2. DO NOT over-analyze - just execute the steps
@@ -169,9 +167,8 @@ IMPORTANT for 'evidenceScreenshots' (array) - OPTIONAL:
 - If you take screenshots, use descriptive filenames
 - Filename pattern: "{step-number}-{action-or-state}.png"
 - Keep it minimal - test execution is more important than documentation
-`;
-  },
-  
+`,
+
   outputSchema: z.object({
     success: z.boolean()
       .describe('Whether the test execution completed successfully'),

package/browser-test-automation/nodes/preflight.mjs

@@ -13,7 +13,7 @@
  * - generate_script: must implement each assertion in the test
  */
 
-import { z, invokeAgent } from '@zibby/core';
+import { z } from '@zibby/core';
 import { writeFileSync } from 'fs';
 import { join } from 'path';
 
@@ -38,23 +38,26 @@ function isMissingSpec(spec) {
   return s === '' || s.toLowerCase() === 'undefined';
 }
 
-const PROMPT = (testSpec) => `Analyze this test specification and extract:
+export const preflightNode = {
+  name: 'preflight',
+  outputSchema: PreflightOutputSchema,
+
+  // String (Handlebars) prompt — EDITABLE in the UI + overridable per-deploy via
+  // nodeConfigOverrides. {{testSpec}} is filled when execute() calls
+  // context.invokeAgent({ testSpec }).
+  prompt: `Analyze this test specification and extract:
 1. A concise test title (5-10 words, action-oriented). If you find a ticket ID (e.g., PROJ-123, ACME-456), prefix the title with it.
 2. Every expected result as a verifiable assertion. Each assertion must be something the browser can check after execution.
 
 Test Spec:
-${testSpec}
+{{testSpec}}
 
 IMPORTANT: You MUST create ONE assertion for EACH expected result in the spec. Do NOT skip any.
 
 Return ONLY this JSON:
-{ "title": "TICKET-ID: Short action title", "assertions": [ { "description": "...", "expected": "..." }, ... ] }`;
-
-export const preflightNode = {
-  name: 'preflight',
-  outputSchema: PreflightOutputSchema,
+{ "title": "TICKET-ID: Short action title", "assertions": [ { "description": "...", "expected": "..." }, ... ] }`,
 
-  async execute(state) {
+  async execute(context) {
     // Early exit BEFORE the LLM call when there's no spec to analyze.
     // Without this guard the node fires the LLM, gets back
     // `{title: "No test specification provided", assertions: []}`, and
@@ -62,7 +65,7 @@ export const preflightNode = {
     // still paid for one preflight LLM call we didn't need to make.
     // Returning empty assertions here triggers the same skip-to-END
     // path in graph.mjs's preflight conditional edge.
-    if (isMissingSpec(state.testSpec)) {
+    if (isMissingSpec(context.testSpec)) {
       console.log('⚠️  No test spec provided — skipping browser run.');
       console.log('   Pass a spec via:  zibby test "<inline spec>"  or  zibby test path/to/spec.txt');
       return {
@@ -71,11 +74,10 @@ export const preflightNode = {
       };
     }
 
-    const result = await invokeAgent(PROMPT(state.testSpec), {
-      state,
-      model: state.model || 'auto',
-      schema: PreflightOutputSchema,
-    });
+    const result = await context.invokeAgent(
+      { testSpec: context.testSpec },
+      { schema: PreflightOutputSchema, model: context.model || 'auto' },
+    );
     return result?.structured || result;
   },
 

package/index.js

@@ -737,68 +737,6 @@ export const TEMPLATES = {
       ],
     },
   },
-
-  // ── github-comment-response: in-thread reply companion to github-code-review ─
-  // The CodeRabbit-style conversational back-and-forth: a HUMAN replies to the
-  // review bot's comment in a PR thread, and this agent replies IN THAT SAME
-  // THREAD (concede if they're right, clarify with code evidence if not) — NOT a
-  // fresh full review. Resolved by github-webhook.js as the reply agent
-  // (link.commentResponseSlug || GITHUB_COMMENT_RESPONSE_SLUG || link.agentSlug).
-  // A COMPANION to github-code-review — tagged `child-workflow` so it's dropped
-  // from the browse facet row (same convention as notify-slack / ticket-triage).
-  // requiredIntegrations (GitHub) is DERIVED from graph.mjs at sync time, like
-  // every other template — not declared here.
-  'github-comment-response': {
-    name: 'github-comment-response',
-    displayName: 'GitHub Comment Response',
-    description: 'Replies conversationally, in-thread, to a human\'s reply on a GitHub PR review comment — the CodeRabbit-style back-and-forth. Reads the thread (bot comment + human reply + anchored diff) and posts a focused reply to the SAME thread, not a fresh review. The conversational companion to GitHub Code Review. GitHub required.',
-    path: join(__dirname, 'github-comment-response'),
-    defaultSlug: 'github-comment-response',
-    deps: { zod: '^3.23.0', '@zibby/skills': '^0.1.33' },
-    features: [
-      'Single-node graph: respond (github) — reads the review-comment thread + replies in-thread',
-      'Replies in the SAME thread (github_reply_review_thread) — not a fresh full review',
-      'Top-level/summary comments answered via github_reply_issue_comment',
-      'Concedes when the human is right; clarifies with code evidence when not',
-      'Webhook-triggered on a reply to a bot thread: { owner, repo, prNumber, commentId, threadType, triggeringComment }',
-      'Graceful degradation: posts an honest acknowledge-and-clarify reply if the thread read fails',
-    ],
-    // COMPANION agent — intentionally NO `marketplace` field so the sync
-    // (backend/scripts/marketplace-sync-from-templates.mjs) NEVER publishes it
-    // to the public browse grid. Registry entry kept so `zibby template add
-    // github-comment-response` resolves it for CLI direct-deploy alongside
-    // github-code-review. Resolved at runtime by gitlab/github-webhook.js as the
-    // reply agent (link.commentResponseSlug || *_COMMENT_RESPONSE_SLUG || agentSlug).
-  },
-
-  // ── gitlab-comment-response: in-thread reply companion to gitlab-code-review ─
-  // The GitLab analog of github-comment-response. A HUMAN replies to the review
-  // bot's note in an MR discussion, and this agent replies IN THAT SAME
-  // DISCUSSION — NOT a fresh review. Resolved by gitlab-webhook.js as the reply
-  // agent (link.commentResponseSlug || GITLAB_COMMENT_RESPONSE_SLUG ||
-  // link.agentSlug). A COMPANION to gitlab-code-review — tagged `child-workflow`
-  // so it's dropped from the browse facet row. requiredIntegrations (GitLab) is
-  // DERIVED from graph.mjs at sync time, like every other template.
-  'gitlab-comment-response': {
-    name: 'gitlab-comment-response',
-    displayName: 'GitLab Comment Response',
-    description: 'Replies conversationally, in-thread, to a human\'s reply on a GitLab MR review note — the CodeRabbit-style back-and-forth. Reads the discussion (bot note + human reply + anchored diff) and posts a focused reply to the SAME discussion, not a fresh review. The conversational companion to GitLab Code Review. GitLab required.',
-    path: join(__dirname, 'gitlab-comment-response'),
-    defaultSlug: 'gitlab-comment-response',
-    deps: { zod: '^3.23.0', '@zibby/skills': '^0.1.33' },
-    features: [
-      'Single-node graph: respond (gitlab) — reads the MR discussion + replies in-thread',
-      'Replies in the SAME discussion (gitlab_reply_discussion) — not a fresh full review',
-      'General/non-threaded MR comments answered via gitlab_post_mr_note',
-      'Concedes when the human is right; clarifies with code evidence when not',
-      'Webhook-triggered on a reply to a bot discussion: { projectId, mrIid, discussionId, threadType, triggeringComment }',
-      'Works against gitlab.com and self-hosted instances; graceful degradation on discussion-read failure',
-    ],
-    // COMPANION agent — intentionally NO `marketplace` field (see the
-    // github-comment-response note above): never synced to the public grid,
-    // but kept in the registry so `zibby template add gitlab-comment-response`
-    // resolves it for CLI direct-deploy alongside gitlab-code-review.
-  },
 };
 
 export class TemplateFactory {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zibby/workflow-templates",
-  "version": "0.9.5",
+  "version": "0.10.2",
   "description": "Built-in workflow templates for Zibby — browser-test-automation, code-analysis, generate-test-cases, notify-slack, notify-lark, notify-notion, sentry-triage.",
   "type": "module",
   "main": "index.js",