Open Workflow Library

repository·main·Indexed 19 days ago

https://github.com/oxbshw/open-workflow-library

An open workflow intelligence project designed to collect, index, validate, and generate automation workflows across multiple frameworks. While architected as a universal workflow knowledge base, it currently uses n8n as its primary dataset. The library includes a Catalog layer for machine-readable indexing of workflows and a collection of pre-built n8n automation templates for services such as AWS, Spotify, Notion, Webflow, and MongoDB.

Tokens
38.2K
Snippets
61
Records
225
Agent score
65%

What's inside Open Workflow Library

  1. Overview of Open Workflow Library capabilities

    main

    Open Workflow Library is an open workflow intelligence project designed to collect, index, validate, and propose repairs for automation workflows across various frameworks. While it currently focuses on n8n, the tooling is designed to be framework-agnostic.

    Core capabilities include:

    • Workflow Collection & Indexing: Consolidating workflows into a unified catalog.
    • Security Sanitization: Scanning for secret patterns and replacing them with [REDACTED] to ensure safety before any write operations.
    • Validation: Structural validation of generated expansion packs (e.g., using tools/validate_generated_pack.py) and static n8n compatibility validation.
    • Intelligence & Repair: Duplicate analysis, schema validation, and generating repair proposals for workflows.
    • Universal IR (Intermediate Representation): Using JSON schemas for IR, metadata, repairs, and learning events to decouple workflows from specific frameworks.
    • Exporting: Currently supports exporting from IR to n8n. Future plans include Dify and LangGraph exporters.
  2. Understand the Open Workflow Library vision and capabilities

    main

    The Open Workflow Library is an open workflow intelligence project designed to collect, index, validate, repair, and generate automation workflows across multiple frameworks (e.g., n8n, Dify, LangGraph, Node-RED, Make, Zapier, Pipedream, Airflow, Temporal).

    Core Capabilities

    The project is evolving into a five-part system:

    1. Library: Workflows from multiple frameworks stored in their native formats.
    2. Catalog: A structured index of workflows including detected integrations, triggers, risks, and validation status.
    3. Universal Workflow IR: A framework-agnostic intermediate representation (IR) used to reason about workflows regardless of their source framework.
    4. Validator and Repair Engine: Performs schema and behavioral validation and generates human-reviewed repair proposals for broken or stale workflows.
    5. Prompt-to-Workflow Generator: A pipeline that takes natural language goals, retrieves relevant catalog/wiki data, assembles a Universal Workflow IR, validates it, and exports it to a target framework.

    Key Constraints and Mental Models

    • Human-in-the-loop: The system is not autonomous. All repairs and self-improvement loops (learning events) are human-gated. Workflows are never mutated without a reviewed proposal.
    • Layer, not Engine: This project is a layer around workflow engines. It does not provide a managed runtime or a hosted service; workflows still run on their respective engines (like n8n or Dify).
    • IR-First: The project prioritizes the Universal Workflow IR over specific file formats to ensure long-term utility across different automation tools.
  3. Understand the Schema Validation Report structure

    main

    The Schema Validation Report provides a summary of the structural integrity of the workflow library's data assets. It operates in lightweight-required-fields-and-enums mode when jsonschema is not installed, performing only top-level checks for required fields and enum values.

    The report validates three main categories of files:

    1. Schema files: The JSON schemas defining the data structures (e.g., workflow-ir.schema.json).
    2. Catalog files: The indexed workflow collections (e.g., catalog/unified-workflows.index.json).
    3. Generated IR files: The Intermediate Representation (IR) files generated from prompts.

    Validation success is determined by passing four specific gates: schemasParse, catalogsParse, catalogEntriesValid, and generatedIrValid.

  4. Access Data From Bubble Application workflow

    main
    This workflow enables on-demand interaction with external data sources by triggering an HTTP request to a specific API endpoint via a manual 'execute' button. It is designed to simplify the process of fetching data (e.g., user data from a customer database) and integrating it into n8n workflows without requiring complex programming.
  5. Workflow Capabilities: Hacker News to Airtable/SMS

    main

    The workflow performs the following automated tasks:

    • Data Retrieval: Fetches the top 3 articles from Hacker News.
    • Text Processing: Extracts unique words from article titles and filters out numbers.
    • Translation: Uses the LingvaNex API to translate extracted English words into German.
    • Data Storage: Saves both the English and German word pairs to an Airtable database.
    • Notification: Sends a daily SMS message containing the translated 'words of the day'.
  6. Current status of supported frameworks

    main

    The Open Workflow Library maintains a conservative definition of framework support. The current status of various automation and orchestration frameworks is as follows:

    FrameworkStatusCurrent Implementation Details
    n8ninitial source library / initial toolingBulk of workflow collection. Heuristic classification via tools/audit_workflows.py. No dedicated importer yet.
    DifyplannedIR mapping notes only (see wiki/framework-guides/).
    LangGraphplannedDesign discussion only; requires code parsing.
    Node-REDplannedIR mapping notes only.
    MakeplannedRequires exported JSON or scenario manifests.
    Zapier (MCP / action plans)plannedRequires separate IR work due to different trigger/action models.
    PipedreamplannedNo current implementation.
    Airflowfuture researchDifferent problem domain (durable data pipelines).
    Temporalfuture researchDifferent problem domain (durable execution).
  7. Track Changes Of Product Prices workflow

    main

    This workflow monitors product prices across various websites, maintains a local JSON file containing the latest prices, and triggers email notifications when a price drop is detected. It is designed for automated price comparison and tracking.

    Key Capabilities

    • Automated Price Monitoring: Uses a cron trigger to execute price checks at regular intervals.
    • Price Comparison and Updates: Compares current scraped prices against previously saved prices in a local file and updates the file when changes occur.
    • Email Notifications: Sends an email alert when a better (lower) price is found, including the updated price and a direct link to the product.
  8. Get Company Data and Store It In Airtable workflow

    main

    This workflow automates the retrieval of brand information from Brandfetch and stores the resulting data in an Airtable table. It is designed to streamline brand asset management (such as logos, icons, and names) by automatically fetching and mapping data fields to a centralized database.

    Key Capabilities

    • Automated Brand Retrieval: Fetches data directly from Brandfetch.
    • Customizable Data Mapping: Allows you to set specific data fields for the brand information being stored.
    • Airtable Integration: Seamlessly appends data to Airtable for centralized management.
  9. Understand n8n Workflow Static Validation

    main

    Static validation is a process used to verify the structural integrity of an n8n workflow JSON file without executing it in a live n8n environment. It checks for the presence of essential components like triggers, webhooks, and response nodes, and counts nodes and connections.

    Important Limitations:

    • No Runtime Execution: The workflow is NOT imported into n8n during this process.
    • No Behavioral Testing: The validation does not perform actual execution to see if the workflow logic works as intended.
    • Structural Only: It focuses on the schema and presence of required nodes rather than the functional outcome of the workflow.
  10. Use the Universal Workflow IR and associated schemas

    main

    The pipeline relies on a Universal Workflow Intermediate Representation (IR) to decouple the generation logic from specific framework formats. This IR is the central contract used for generation, validation, and repair.

    Key schema files involved in this process:

    • schemas/workflow-ir.schema.json: Defines the structure for the universal workflow representation. All generated workflows must conform to this before being exported.
    • schemas/repair-proposal.schema.json: Defines the format for repair suggestions when a workflow fails validation.

    By using this IR, the system ensures that the same validator and repair engine can be used both for generating new workflows and for fixing existing ones.

  11. Understand the structure of a Failure Case

    main

    A failure case in the Open Workflow Library is a documented record of a workflow failure mode. It is used as an evidence base to generate repair rules and patterns. A failure case consists of the following fields:

    • Framework: The workflow engine used (e.g., n8n, Dify).
    • First observed: The date the issue was first identified.
    • Symptom: The observable behavior reported by the user.
    • Root cause: The actual technical reason for the failure.
    • Fix: The specific action or pattern that resolved the issue.
    • Generalises to: References to specific repair rules or patterns that prevent this class of error.
    ## <Short name>
    
    - **Framework:** n8n / Dify / ...
    - **First observed:** YYYY-MM-DD
    - **Symptom:** what the user saw
    - **Root cause:** what it actually was
    - **Fix:** what resolved it
    - **Generalises to:** pattern / repair-rule references