Open Workflow Library: an n8n workflow collection with an audit tool bolted on

The problem is a folder of n8n JSON nobody has read

If you have collected n8n workflows from tutorials, shared exports or your own past projects, you end up with a directory of JSON files whose contents you cannot describe. Which ones call a webhook? Which ones embed a Code node with credentials inlined? Which ones are near-duplicates of each other under different titles? The README frames the project as an open workflow intelligence effort for collecting, indexing, validating, repairing and eventually generating automation workflows across frameworks, starting with n8n. The near-term audience is narrower than that sentence: it is someone who wants a machine-readable index of an existing n8n corpus, plus a scan for secret-like strings, without standing up n8n or installing a package. The README states plainly that nothing is installed globally, nothing is published, and nothing requires n8n on the local machine. That constraint shapes everything else in the repository.

Four schemas define the data model, and they are the real interface

The repository is not just a workflow dump. Under schemas/ sit four JSON Schema files: workflow-ir.schema.json for a Universal Workflow IR, workflow-metadata.schema.json for catalog metadata, repair-proposal.schema.json for human-reviewable repair proposals, and learning-event.schema.json for evidence feeding the self-improvement loop. The catalog at catalog/workflows.index.json is generated to conform to the metadata schema, and the README says each entry carries detected integrations, trigger type, credential references, code and webhook presence, and a coarse risk level. This is the part worth reading first if you are evaluating the project for interoperability. The IR is described as framework-agnostic by design, and the architecture documentation reportedly accommodates additional importers and exporters. The catch is that framework-agnostic in schema form is not the same as framework-agnostic in practice: the audit tool understands n8n workflow files, and the catalog currently indexes n8n only. The schema is the promise; the importer is the delivery, and only one importer exists.

How the audit tool actually behaves

tools/audit_workflows.py is standard-library Python 3.12 and, per the README, read-only. It catalogues the existing workflow files, detects code and webhook usage, redacts secret-like values, and writes three artifacts: reports/workflow-audit.json, reports/workflow-audit.md, and catalog/workflows.index.json. The README states the tool never modifies, moves or deletes workflow files, and never prints real secret values, replacing matches against secret-like patterns with [REDACTED] before anything reaches disk. That redaction happens before writing, not at display time, which matters because the JSON report is the artifact most likely to be committed or shared. The README also notes that a current run reports zero findings. Treat that number carefully: zero findings means the patterns did not match, not that the corpus is clean. A secret scan is only as good as its pattern list, and the README does not enumerate the patterns.

Running it: six commands, no install step

The Quickstart gives the whole surface. python tools/audit_workflows.py audits the collection. python tools/validate_generated_pack.py validates the generated expansion pack, described as 420 templates, structurally only. python tools/build_unified_catalog.py builds the unified catalog with deterministic quality scores. python tools/search_workflows.py --query "lead qualification" --top 5 runs keyword and filter search over that catalog. python tools/prompt_to_n8n.py "Create a workflow that receives website leads, scores them, saves them to CRM, and alerts Slack." takes a prompt through IR to an n8n workflow and then static validation, with no runtime and no LLM. python tools/build_review_queue.py aggregates everything needing human review. There is no pip install line, which is the point: every tool is standard-library Python 3.12 or newer. The trade-off is that schema validation degrades. The README says validation uses jsonschema if available and falls back to a lightweight required-field check otherwise, so the depth of validation depends on what happens to be installed on the machine running it.

The quality score is deterministic, and the README says so twice

Two phrases in the status table deserve attention. The catalog and unified search row notes a deterministic quality score, not a correctness score. The static n8n validation row notes structural only, not a behavioural test. Together these set the ceiling on what the tooling can tell you. A workflow can score well and still be broken at runtime, because nothing here imports a workflow into n8n. The README is explicit that behavioural n8n execution is not implemented and that no workflow has been imported into n8n by this repository. The same honesty applies to repair: the repair engine emits proposals only and never auto-applies them, and the duplicate analysis surfaces exact and title-similarity candidates without auto-dedupe. If your goal is confidence that a workflow runs, this project does not provide it and does not claim to.

Prompt to n8n is keyword rules, not a model

The prompt_to_n8n.py tool is the most likely source of misunderstanding. The status table labels prompt to IR as an MVP, deterministic and keyword-rule, explicitly not LLM-backed, and IR to n8n export as an MVP with a conservative node whitelist and safe placeholders only. LLM-backed prompt-to-workflow is listed as not implemented. So the demo command produces a structurally valid workflow skeleton whose nodes come from a fixed whitelist, not a generated automation tailored to your stack. The conservative whitelist is a defensible safety choice: it means the exporter cannot emit a node it does not understand. It also means anything outside that whitelist will not appear, and the README does not list the whitelist contents. If you need generation today, this is the wrong tool; if you need a deterministic scaffold you can inspect and extend, the constraint is the feature.

The alternative is n8n's own import and test loop

The obvious comparison is n8n itself. You can import a workflow JSON into an n8n instance, wire credentials, and execute it to see what happens. That gives behavioural truth, which this project cannot give. The difference in approach is the direction of the guarantee: n8n tells you whether a workflow runs, while Open Workflow Library tells you what is inside a corpus of workflow files without running any of them. The second is useful precisely when the first is impractical, for example when you are triaging hundreds of files you did not write and do not want to import. The two are complementary rather than competing, and the README's own framing supports that: n8n is described as the starting dataset and the first framework with practical tooling support, not the endpoint.

Licence, maintenance and what to verify

The licence is MIT, which permits commercial use and modification provided the copyright notice and permission notice are retained. That is a permissive default and lowers the cost of vendoring the tools into an internal repository. The maintenance picture is less settled. The repository is not archived and the last push is dated 2026-05-24, but no releases were retrieved, so there is no versioned artifact to pin against and no changelog to read. Upgrading means tracking the main branch, and any local modifications to the audit tool's secret patterns will need re-applying by hand each time. The status table is the most valuable file in the repository because it names the gaps: behavioural execution, multi-framework export and LLM-backed generation are all marked not implemented, and autonomous self-improvement is out of scope, with promotion into the curated wiki requiring human review. Verify that your Python is 3.12 or newer, check whether jsonschema is present if you want schema-level validation rather than required-field checks, and read docs/security.md before trusting the redaction on credentials that do not match the tool's patterns.

Editorial conclusion

Adopt it if you already have a pile of n8n workflow JSON files and want a read-only audit, a deterministic catalog with quality scores, and secret-pattern redaction without installing anything beyond Python 3.12. Do not adopt it expecting behavioural validation, LLM-backed generation, or Dify, LangGraph, Make or Zapier export: the README marks all three as not implemented. Before you rely on it, run python tools/audit_workflows.py against a copy of your own workflows and read reports/workflow-audit.md to confirm the secret scan catches the credential shapes you actually use, because the quality score in catalog/workflows.index.json is deterministic and structural, not a correctness score.

Official sources

1. Issues
2. License: MIT
3. oxbshw/Open-Workflow-Library on GitHub
4. README