Skip to content

README.md

Latest commit

 

History

History
58 lines (40 loc) · 2.74 KB

README.md

File metadata and controls

58 lines (40 loc) · 2.74 KB
Raw

LLM Wiki

The wiki is the knowledge base that sits alongside the workflow catalog. The catalog answers "what workflows do we have?"; the wiki answers "what do we know about workflows?" — patterns, integration quirks, common failure modes, repair rules, and framework-specific guidance.

It is meant to be consumed both by humans and by LLMs (during retrieval for prompt-to-workflow generation, repair, and validation).

Current scope

This pass establishes the structure and seeds each section with a small number of realistic, hand-written entries. The wiki is not comprehensive yet. It will grow as workflows are audited, validated, and (eventually) generated against it.

Layout

Folder Purpose
patterns/ Reusable workflow patterns — retry, fan-out/fan-in, chunked LLM calls, idempotent webhook handlers, etc.
integrations/ Per-service playbooks — auth model, rate limits, gotchas, recommended node settings.
repair-rules/ Rules used (or proposed) by the repair engine — "if the workflow has X but not Y, propose Z".
failure-cases/ Documented failure modes with root cause and the fix that worked. Feeds repair-rules over time.
framework-guides/ Framework differences — n8n vs Dify vs LangGraph vs Make, IR mapping notes, exporter quirks.

Authoring conventions

Each entry is a Markdown file with a short YAML-ish header followed by prose:

---
title: Short title
applies_to: [n8n]   # or planned, or multiple
tags: [http, retry, idempotency]
last_reviewed: 2026-05-23
---

## When this applies
...

## What to do
...

## Why
...

## References
...

last_reviewed is meaningful: if it is more than ~12 months old and the entry references concrete versions or APIs, treat the content as stale until re-reviewed.

Honest limitations

  • The wiki is in its first pass. Most patterns and integrations are not documented yet.
  • Repair rules listed here are candidates. They are not automatically applied. The repair engine that consumes them is on the roadmap (see ../docs/self-improvement.md).
  • Framework guides are partial. Only n8n has practical content. Other frameworks are described at the design level.

How this gets used (planned)

  1. Prompt-to-workflow: the generator retrieves relevant patterns + integration playbooks before assembling a Universal Workflow IR.
  2. Repair engine: candidate repair rules are matched against detected failures; proposals are written to reports/ for human review.
  3. Learning loop: validated failure-and-fix pairs become learning-event records, which can be promoted into new repair rules — only after human review.