CLI Tool: Plugin Templates Library

[coderabbitai]

Overview

Create comprehensive library of plugin templates for triggers and actions.

Templates

1. Webhook Trigger - webhook config, executor, dialog
2. Polling Trigger - polling config, onPoll(), state management
3. Manual Trigger - simple trigger
4. Generic Action - basic action structure
5. HTTP Action - REST API integration
6. Database Action - database operations

Requirements

• Token placeholders ({{PLUGIN_NAME}}, etc.)
• TODO comments for customization
• Proper TypeScript types
• Example implementations

Acceptance Criteria

• All 6 templates created
• Token replacement works
• Templates compile after token replacement
• templates.json metadata file

Effort: Large (10-12 hours)
Related: PR #40, Issue #48, Issue #42

[github-actions]

👋 Thanks for opening another issue, @coderabbitai[bot]! We appreciate your continued engagement with the project.

Quick checklist:

• Clear description of the issue
• Steps to reproduce (if applicable)
• Expected vs actual behavior

We'll take a look as soon as possible!

[coderabbitai]

Coding Plan

Approach

Create a comprehensive library of 6 plugin templates (3 triggers, 3 actions) with token placeholders, TODO comments, and a metadata file that enables future CLI-based scaffolding of workflow nodes.

Observations

The codebase implements a node-based workflow system using React Flow for the visual editor and Inngest for backend execution. Each workflow node follows a strict 4-file pattern: node.tsx (UI component), executor.ts (execution logic), dialog.tsx (configuration form), and actions.ts (realtime token provider). Nodes are registered in four places: Prisma schema (NodeType enum), component registry, executor registry, and node selector UI. The existing Manual Trigger and HTTP Request nodes serve as reference implementations. Inngest supports event-driven triggers via inngest.send() and scheduled triggers via cron syntax, with realtime status updates through dedicated channels.

Assumptions

Assumption 1: Token replacement mechanism

Options Considered:

1. Use Handlebars-style {{TOKEN}} syntax (consistent with existing HTTP Request templating)
2. Use EJS-style <%= TOKEN %> syntax
3. Use custom delimiters like __TOKEN__

Chosen Option: 1

Rationale: Handlebars-style {{TOKEN}} maintains consistency with the existing Handlebars usage in the HTTP Request executor and is widely recognized.

Assumption 2: Polling trigger architecture

Options Considered:

1. Single cron function that queries all polling workflows and triggers each
2. Per-workflow dedicated cron functions created dynamically
3. Polling executor that stores state in Node.data and relies on external scheduler

Chosen Option: 3

Rationale: The template will show the executor pattern with state storage in Node.data, as the cron function setup is infrastructure-level and would be shared across all polling triggers. This keeps templates focused on node-specific code.

Assumption 3: Webhook trigger API route location

Options Considered:

1. Generic /api/webhook/[workflowId]/route.ts that all webhook triggers share
2. Plugin-specific routes /api/webhooks/{{PLUGIN_NAME}}/route.ts

Chosen Option: 1

Rationale: A generic webhook route template is more practical since the route logic (receive request, validate, trigger workflow) is consistent across webhook types. Plugin-specific validation happens in the executor.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Template Foundation and Metadata

Establish the template directory structure and create the metadata configuration that describes all templates, their tokens, and file mappings.

Task 1: Create Template Directory Structure

Set up the /templates/ directory at the project root with organized subdirectories for triggers and actions.

• Create /templates/ root directory with README.md documenting template usage
• Create /templates/triggers/ subdirectory for trigger node templates
• Create /templates/actions/ subdirectory for action node templates
• Create /templates/shared/ subdirectory for shared files like Inngest channel template

Task 2: Define Token Specification

Create a consistent token naming convention document and the templates.json metadata file.

• Create /templates/templates.json with metadata for all 6 templates including: template name, description, category (trigger/action), required tokens, and file mappings
• Define standard tokens: {{PLUGIN_NAME}} (kebab-case), {{PLUGIN_NAME_PASCAL}} (PascalCase for types/components), {{PLUGIN_NAME_CAMEL}} (camelCase for variables), {{PLUGIN_NAME_UPPER_SNAKE}} (CONSTANT_CASE for enums), {{PLUGIN_DESCRIPTION}}
• Include targetDirectory patterns showing where generated files should be placed relative to src/
• Document registration points that need manual updates (Prisma schema, component registry, executor registry, node selector)

🤖 Prompt for AI agents

This phase establishes the foundational directory structure and metadata
configuration for the plugin template library. The goal is to create an
organized template system that future CLI tools can use for scaffolding workflow
nodes.

**Directory Structure Setup:**
- Create `/templates/` directory at project root
- Add a comprehensive `README.md` explaining template usage, token placeholders,
and the 4-file node pattern
- Create three subdirectories: `/templates/triggers/`, `/templates/actions/`,
and `/templates/shared/`

**Metadata Configuration:**
- Create `/templates/templates.json` as the central metadata file
- For each of the 6 templates (manual-trigger, webhook-trigger, polling-trigger,
generic-action, http-action, database-action), define:
  - Template name and description
  - Category (trigger or action)
  - List of required tokens
  - File mappings showing which template files exist and their purposes
- Define standard token placeholders:
  - `{{PLUGIN_NAME}}` - kebab-case version
  - `{{PLUGIN_NAME_PASCAL}}` - PascalCase for types/components
  - `{{PLUGIN_NAME_CAMEL}}` - camelCase for variables
  - `{{PLUGIN_NAME_UPPER_SNAKE}}` - CONSTANT_CASE for enums
  - `{{PLUGIN_DESCRIPTION}}` - human-readable description
- Include `targetDirectory` patterns showing where generated files should be
placed relative to `src/`
- Document the four registration points that require manual updates: Prisma
schema (NodeType enum), component registry, executor registry, and node selector
UI

Phase 2: Trigger Templates

Create the three trigger template sets, each following the established 4-file node pattern plus supporting files.

Task 1: Manual Trigger Template

Create the simplest trigger template based on the existing manual-trigger implementation.

• Create /templates/triggers/manual-trigger/node.tsx.template with placeholder icon, name, and description
• Create /templates/triggers/manual-trigger/executor.ts.template implementing NodeExecutor interface with pass-through context logic
• Create /templates/triggers/manual-trigger/dialog.tsx.template with configurable form fields section marked with TODO
• Create /templates/triggers/manual-trigger/actions.ts.template for realtime token provider
• Create /templates/triggers/manual-trigger/channel.ts.template for Inngest realtime channel definition with status topic
• Add TODO comments marking customization points: icon selection, configuration schema, executor logic

Task 2: Webhook Trigger Template

Create a webhook trigger template that includes an API route for receiving external HTTP requests.

• Create /templates/triggers/webhook-trigger/node.tsx.template extending BaseTriggerNode with webhook-specific UI elements
• Create /templates/triggers/webhook-trigger/executor.ts.template that processes incoming webhook payload from context, validates webhook-specific data, and publishes status
• Create /templates/triggers/webhook-trigger/dialog.tsx.template with configuration for webhook URL display, optional secret/signature validation settings
• Create /templates/triggers/webhook-trigger/actions.ts.template for realtime token
• Create /templates/triggers/webhook-trigger/channel.ts.template for webhook status channel
• Create /templates/triggers/webhook-trigger/api-route.ts.template for /api/webhook/[workflowId]/route.ts showing: request validation, payload extraction, inngest.send() to trigger workflow with webhook data in initialData
• Include TODO comments for: signature validation logic, payload transformation, allowed HTTP methods

Task 3: Polling Trigger Template

Create a polling trigger template with state management patterns for tracking poll cursors and timestamps.

• Create /templates/triggers/polling-trigger/node.tsx.template with polling-specific UI showing last poll time indicator
• Create /templates/triggers/polling-trigger/executor.ts.template demonstrating: retrieving last poll state from Node.data, performing poll operation (marked TODO), calculating new state/cursor, returning updated context with poll results
• Create /templates/triggers/polling-trigger/dialog.tsx.template with polling interval configuration, endpoint/resource configuration fields
• Create /templates/triggers/polling-trigger/actions.ts.template for realtime token
• Create /templates/triggers/polling-trigger/channel.ts.template for polling status channel
• Create /templates/triggers/polling-trigger/types.ts.template defining polling state interface (lastPollTime, cursor, etc.) and poll result types
• Add TODO comments for: poll logic implementation, state persistence strategy, change detection algorithm, cron function registration

🤖 Prompt for AI agents

This phase creates three trigger node templates following the established 4-file
pattern (node.tsx, executor.ts, dialog.tsx, actions.ts) plus supporting files.
The goal is to provide reference implementations for manual, webhook, and
polling trigger architectures.

**Manual Trigger Template:**
- Create `/templates/triggers/manual-trigger/node.tsx.template` with token
placeholders for component name, icon, and description
- Implement the UI component structure with placeholder values
- Create `executor.ts.template` implementing the `NodeExecutor` interface with
simple pass-through context logic
- Create `dialog.tsx.template` with a basic form structure and TODO comments for
configurable fields
- Create `actions.ts.template` for realtime token provider functionality
- Create `channel.ts.template` showing Inngest realtime channel definition with
status topic
- Add TODO comments at key customization points: icon selection, configuration
schema definition, and executor logic implementation

**Webhook Trigger Template:**
- Create `node.tsx.template` extending BaseTriggerNode with webhook-specific UI
elements (webhook URL display)
- Create `executor.ts.template` that processes incoming webhook payload from
context, validates webhook-specific data, and publishes status updates
- Create `dialog.tsx.template` with configuration form showing webhook URL
display and optional secret/signature validation settings
- Create `actions.ts.template` for realtime token provider
- Create `channel.ts.template` for webhook status updates
- Create `api-route.ts.template` for `/api/webhook/[workflowId]/route.ts`
demonstrating:
  - Request validation pattern
  - Payload extraction from incoming request
  - Using `inngest.send()` to trigger workflow with webhook data in initialData
- Add TODO comments for: signature validation logic, payload transformation
logic, and allowed HTTP methods configuration

**Polling Trigger Template:**
- Create `node.tsx.template` with polling-specific UI showing last poll time
indicator
- Create `executor.ts.template` demonstrating the polling pattern:
  - Retrieving last poll state from Node.data
  - Performing poll operation (marked with TODO)
  - Calculating new state/cursor values
  - Returning updated context with poll results
- Create `dialog.tsx.template` with polling interval configuration and
endpoint/resource configuration fields
- Create `actions.ts.template` for realtime token provider
- Create `channel.ts.template` for polling status channel
- Create `types.ts.template` defining:
  - Polling state interface (lastPollTime, cursor, etc.)
  - Poll result types
- Add TODO comments for: poll logic implementation, state persistence strategy,
change detection algorithm, and cron function registration requirements

All templates should use Handlebars-style `{{TOKEN}}` placeholders for plugin
name, descriptions, and other customizable values.

Phase 3: Action Templates

Create the three action template sets for generic operations, HTTP requests, and database operations.

Task 1: Generic Action Template

Create a minimal action template that serves as a starting point for any custom action.

• Create /templates/actions/generic-action/node.tsx.template extending BaseExecutionNode with configurable icon and labels
• Create /templates/actions/generic-action/executor.ts.template with skeleton NodeExecutor implementation showing: data extraction, status publishing pattern, context modification, error handling with NonRetriableError
• Create /templates/actions/generic-action/dialog.tsx.template with placeholder form using react-hook-form and zod validation pattern
• Create /templates/actions/generic-action/actions.ts.template for realtime token
• Create /templates/actions/generic-action/channel.ts.template for action status channel
• Include comprehensive TODO comments explaining each section's purpose and customization options

Task 2: HTTP Action Template

Create an HTTP action template for REST API integrations, referencing the existing HTTP Request implementation patterns.

• Create /templates/actions/http-action/node.tsx.template with HTTP-specific iconography and method display
• Create /templates/actions/http-action/executor.ts.template demonstrating: Handlebars template compilation for URL/body, fetch execution with configurable method/headers, response parsing, error handling for network failures
• Create /templates/actions/http-action/dialog.tsx.template with form fields for: endpoint URL, HTTP method selector, headers configuration, request body with template variable support
• Create /templates/actions/http-action/actions.ts.template for realtime token
• Create /templates/actions/http-action/channel.ts.template for HTTP action status channel
• Create /templates/actions/http-action/types.ts.template defining request configuration interface and response structure types
• Add TODO comments for: authentication header injection, response transformation, retry logic, timeout configuration

Task 3: Database Action Template

Create a database action template showing Prisma integration patterns for workflow database operations.

• Create /templates/actions/database-action/node.tsx.template with database-themed icon and operation type display
• Create /templates/actions/database-action/executor.ts.template demonstrating: Prisma client import from @/lib/db, operation type switching (create/read/update/delete), Handlebars template compilation for dynamic queries, transaction usage pattern, result storage in context
• Create /templates/actions/database-action/dialog.tsx.template with form fields for: operation type selector, model/table selector, query parameters with template variable support, variable name for result storage
• Create /templates/actions/database-action/actions.ts.template for realtime token
• Create /templates/actions/database-action/channel.ts.template for database action status channel
• Create /templates/actions/database-action/types.ts.template defining database operation enum, configuration interface, and result types
• Add TODO comments for: custom model references, complex query building, transaction boundaries, error mapping

Task 4: Create Shared Channel Template

Extract the common Inngest channel pattern into a reusable template.

• Create /templates/shared/channel.ts.template with the standard channel definition pattern including status topic with nodeId and status fields
• Document channel naming convention using {{PLUGIN_NAME}}-execution pattern
• Include comment explaining channel registration in Inngest function configuration

🤖 Prompt for AI agents

This phase creates three action node templates and a shared channel template.
The goal is to provide reference implementations for generic actions, HTTP
requests, and database operations, all following the 4-file node pattern.

**Generic Action Template:**
- Create `/templates/actions/generic-action/node.tsx.template` extending
BaseExecutionNode with token placeholders for icon and labels
- Create `executor.ts.template` with skeleton `NodeExecutor` implementation
demonstrating:
  - Data extraction from node configuration
  - Status publishing pattern for realtime updates
  - Context modification to pass data to downstream nodes
  - Error handling using `NonRetriableError` for terminal failures
- Create `dialog.tsx.template` with placeholder form structure using
react-hook-form and zod validation pattern
- Create `actions.ts.template` for realtime token provider
- Create `channel.ts.template` for action status channel
- Include comprehensive TODO comments explaining each section's purpose and
customization options

**HTTP Action Template:**
- Create `node.tsx.template` with HTTP-specific iconography and method display
- Create `executor.ts.template` demonstrating HTTP request patterns:
  - Handlebars template compilation for URL and request body
  - Fetch execution with configurable HTTP method and headers
  - Response parsing (JSON, text, etc.)
  - Error handling for network failures and non-200 responses
- Create `dialog.tsx.template` with form fields for:
  - Endpoint URL input
  - HTTP method selector (GET, POST, PUT, DELETE, etc.)
  - Headers configuration (key-value pairs)
  - Request body with template variable support
- Create `actions.ts.template` for realtime token provider
- Create `channel.ts.template` for HTTP action status channel
- Create `types.ts.template` defining:
  - Request configuration interface (method, url, headers, body)
  - Response structure types
- Add TODO comments for: authentication header injection, response
transformation logic, retry logic, and timeout configuration

**Database Action Template:**
- Create `node.tsx.template` with database-themed icon and operation type
display
- Create `executor.ts.template` demonstrating Prisma integration:
  - Prisma client import from `@/lib/db`
  - Operation type switching (create, read, update, delete)
  - Handlebars template compilation for dynamic query parameters
  - Transaction usage pattern for atomic operations
  - Result storage in context for downstream nodes
- Create `dialog.tsx.template` with form fields for:
  - Operation type selector (dropdown)
  - Model/table selector
  - Query parameters with template variable support
  - Variable name for storing results in context
- Create `actions.ts.template` for realtime token provider
- Create `channel.ts.template` for database action status channel
- Create `types.ts.template` defining:
  - Database operation enum (CREATE, READ, UPDATE, DELETE)
  - Configuration interface
  - Result types
- Add TODO comments for: custom model references, complex query building,
transaction boundaries, and error mapping from Prisma errors

**Shared Channel Template:**
- Create `/templates/shared/channel.ts.template` with the standard Inngest
channel definition pattern
- Include status topic with nodeId and status fields
- Document the channel naming convention: `{{PLUGIN_NAME}}-execution`
- Add comment explaining how to register the channel in Inngest function
configuration

All templates should use Handlebars-style `{{TOKEN}}` placeholders consistently
and follow the existing codebase patterns for React Flow nodes and Inngest
executors.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

This phase establishes the foundational directory structure and metadata
configuration for the plugin template library. The goal is to create an
organized template system that future CLI tools can use for scaffolding workflow
nodes.

**Directory Structure Setup:**
- Create `/templates/` directory at project root
- Add a comprehensive `README.md` explaining template usage, token placeholders,
and the 4-file node pattern
- Create three subdirectories: `/templates/triggers/`, `/templates/actions/`,
and `/templates/shared/`

**Metadata Configuration:**
- Create `/templates/templates.json` as the central metadata file
- For each of the 6 templates (manual-trigger, webhook-trigger, polling-trigger,
generic-action, http-action, database-action), define:
  - Template name and description
  - Category (trigger or action)
  - List of required tokens
  - File mappings showing which template files exist and their purposes
- Define standard token placeholders:
  - `{{PLUGIN_NAME}}` - kebab-case version
  - `{{PLUGIN_NAME_PASCAL}}` - PascalCase for types/components
  - `{{PLUGIN_NAME_CAMEL}}` - camelCase for variables
  - `{{PLUGIN_NAME_UPPER_SNAKE}}` - CONSTANT_CASE for enums
  - `{{PLUGIN_DESCRIPTION}}` - human-readable description
- Include `targetDirectory` patterns showing where generated files should be
placed relative to `src/`
- Document the four registration points that require manual updates: Prisma
schema (NodeType enum), component registry, executor registry, and node selector
UI
===============================================================================

Task: 2

This phase creates three trigger node templates following the established 4-file
pattern (node.tsx, executor.ts, dialog.tsx, actions.ts) plus supporting files.
The goal is to provide reference implementations for manual, webhook, and
polling trigger architectures.

**Manual Trigger Template:**
- Create `/templates/triggers/manual-trigger/node.tsx.template` with token
placeholders for component name, icon, and description
- Implement the UI component structure with placeholder values
- Create `executor.ts.template` implementing the `NodeExecutor` interface with
simple pass-through context logic
- Create `dialog.tsx.template` with a basic form structure and TODO comments for
configurable fields
- Create `actions.ts.template` for realtime token provider functionality
- Create `channel.ts.template` showing Inngest realtime channel definition with
status topic
- Add TODO comments at key customization points: icon selection, configuration
schema definition, and executor logic implementation

**Webhook Trigger Template:**
- Create `node.tsx.template` extending BaseTriggerNode with webhook-specific UI
elements (webhook URL display)
- Create `executor.ts.template` that processes incoming webhook payload from
context, validates webhook-specific data, and publishes status updates
- Create `dialog.tsx.template` with configuration form showing webhook URL
display and optional secret/signature validation settings
- Create `actions.ts.template` for realtime token provider
- Create `channel.ts.template` for webhook status updates
- Create `api-route.ts.template` for `/api/webhook/[workflowId]/route.ts`
demonstrating:
  - Request validation pattern
  - Payload extraction from incoming request
  - Using `inngest.send()` to trigger workflow with webhook data in initialData
- Add TODO comments for: signature validation logic, payload transformation
logic, and allowed HTTP methods configuration

**Polling Trigger Template:**
- Create `node.tsx.template` with polling-specific UI showing last poll time
indicator
- Create `executor.ts.template` demonstrating the polling pattern:
  - Retrieving last poll state from Node.data
  - Performing poll operation (marked with TODO)
  - Calculating new state/cursor values
  - Returning updated context with poll results
- Create `dialog.tsx.template` with polling interval configuration and
endpoint/resource configuration fields
- Create `actions.ts.template` for realtime token provider
- Create `channel.ts.template` for polling status channel
- Create `types.ts.template` defining:
  - Polling state interface (lastPollTime, cursor, etc.)
  - Poll result types
- Add TODO comments for: poll logic implementation, state persistence strategy,
change detection algorithm, and cron function registration requirements

All templates should use Handlebars-style `{{TOKEN}}` placeholders for plugin
name, descriptions, and other customizable values.
===============================================================================

Task: 3

This phase creates three action node templates and a shared channel template.
The goal is to provide reference implementations for generic actions, HTTP
requests, and database operations, all following the 4-file node pattern.

**Generic Action Template:**
- Create `/templates/actions/generic-action/node.tsx.template` extending
BaseExecutionNode with token placeholders for icon and labels
- Create `executor.ts.template` with skeleton `NodeExecutor` implementation
demonstrating:
  - Data extraction from node configuration
  - Status publishing pattern for realtime updates
  - Context modification to pass data to downstream nodes
  - Error handling using `NonRetriableError` for terminal failures
- Create `dialog.tsx.template` with placeholder form structure using
react-hook-form and zod validation pattern
- Create `actions.ts.template` for realtime token provider
- Create `channel.ts.template` for action status channel
- Include comprehensive TODO comments explaining each section's purpose and
customization options

**HTTP Action Template:**
- Create `node.tsx.template` with HTTP-specific iconography and method display
- Create `executor.ts.template` demonstrating HTTP request patterns:
  - Handlebars template compilation for URL and request body
  - Fetch execution with configurable HTTP method and headers
  - Response parsing (JSON, text, etc.)
  - Error handling for network failures and non-200 responses
- Create `dialog.tsx.template` with form fields for:
  - Endpoint URL input
  - HTTP method selector (GET, POST, PUT, DELETE, etc.)
  - Headers configuration (key-value pairs)
  - Request body with template variable support
- Create `actions.ts.template` for realtime token provider
- Create `channel.ts.template` for HTTP action status channel
- Create `types.ts.template` defining:
  - Request configuration interface (method, url, headers, body)
  - Response structure types
- Add TODO comments for: authentication header injection, response
transformation logic, retry logic, and timeout configuration

**Database Action Template:**
- Create `node.tsx.template` with database-themed icon and operation type
display
- Create `executor.ts.template` demonstrating Prisma integration:
  - Prisma client import from `@/lib/db`
  - Operation type switching (create, read, update, delete)
  - Handlebars template compilation for dynamic query parameters
  - Transaction usage pattern for atomic operations
  - Result storage in context for downstream nodes
- Create `dialog.tsx.template` with form fields for:
  - Operation type selector (dropdown)
  - Model/table selector
  - Query parameters with template variable support
  - Variable name for storing results in context
- Create `actions.ts.template` for realtime token provider
- Create `channel.ts.template` for database action status channel
- Create `types.ts.template` defining:
  - Database operation enum (CREATE, READ, UPDATE, DELETE)
  - Configuration interface
  - Result types
- Add TODO comments for: custom model references, complex query building,
transaction boundaries, and error mapping from Prisma errors

**Shared Channel Template:**
- Create `/templates/shared/channel.ts.template` with the standard Inngest
channel definition pattern
- Include status topic with nodeId and status fields
- Document the channel naming convention: `{{PLUGIN_NAME}}-execution`
- Add comment explaining how to register the channel in Inngest function
configuration

All templates should use Handlebars-style `{{TOKEN}}` placeholders consistently
and follow the existing codebase patterns for React Flow nodes and Inngest
executors.

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For assumption 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!