Hier ist ein Fehlschlag, der nichts mit Intelligenz zu tun hat.
Bitten Sie einen gut fundierten KI-Assistenten, eine Spark-Regel in SkySpark zu erstellen. Er kennt Axon. Er hat die Funktionsbibliothek indiziert. Er schreibt Ihnen sauberen, syntaktisch gültigen Code — und liefert einen Record zurück.
Eine funktionierende Spark-Regel braucht zwei: einen func-Record mit der Erkennungslogik und einen sparkRule-Record, der konfiguriert, wie und wo die Regel greift. Beide müssen zueinander passen. Fehlt der zweite, gibt es keine Fehlermeldung — Sie haben schlicht eine Regel, die nie auslöst, an einem Standort, den Sie für überwacht hielten.
Kein noch so großes Syntaxwissen verhindert das. Es ist kein Sprachproblem. Es ist ein Verfahrensproblem, und das Verfahren ist genau die Hälfte, die wir bisher weggelassen haben.
Was ein Workflow eigentlich ist
Ein Workflow ist eine Markdown-Datei. Das ist der ganze Trick.
Sie trägt ein wenig Frontmatter, damit sie katalogisiert werden kann, dann schlichten Fließtext und Tabellen, die beschreiben, wie man eine Sache richtig macht:
---
title: Create Spark Rule
description: Step-by-step guide for creating a Spark rule with func and sparkRule records
category: fault-detection
tags: [spark, rule, fault, automation]
version: 1.0
---
Beide MCP-Server laden beim Start jede .md-Datei aus ihrem workflows/-Verzeichnis und stellen sie über das Model Context Protocol als lesbare Ressourcen unter einer workflow://-URI bereit. Dem Assistenten muss man nicht sagen, dass es sie gibt — er kann sie auflisten, durchsuchen und den vollständigen Text bei Bedarf mitten in der Arbeit abrufen.
Der Fantom MCP Server überwacht dieses Verzeichnis. Legen Sie eine neue Datei ab, und sie ist ohne Rebuild oder Neustart verfügbar.
Die beiden Kataloge heute
Fantom MCP Server — 13 Workflows, für die Bau- und Wartungsseite:
ai-coding-loop · api-migration-reference · connector-workflow · create-pod · create-skyspark-extension · explore-code-relations · haxall-basics · haxall-coding-standards · haxall-methods-workflow · skyspark-4x-migration · unit-testing · use-fanr · xeto-spec-guide
Axon MCP Server — 10 Workflows, für die Analytik- und Betriebsseite:
app-creation · axon-func-update · axon-lang-information · curRule-computed-points · html-email-skyspark · job-status-check · recform-template-design · spark-rule-creation · task-subscriber-permissions · visualytik-mcp-authoring
Dreiundzwanzig Dateien. Das ist das gesamte kodierte Verfahrenswissen dieser Toolchain zum jetzigen Zeitpunkt — und das ist bei Weitem nicht genug.
Wie ein guter Workflow aussieht
Das Paradebeispiel ist ai-coding-loop. Er bringt einem Assistenten bei, Code zu ändern, ohne dass der Index darunter verrottet. Das strukturelle Gedächtnis des Servers umfasst 240+ Projekte und 156K+ Funktionen; eine Änderung, die nicht neu indiziert wird, macht jede nachfolgende Suche auf subtile Weise falsch.
Die Regel, an der die gesamte Schleife hängt, ist ein einziger Satz: Rufen Sie nach jeder Codeänderung reindexChangedFiles für die berührten Pfade auf. Neu parsen, Graphknoten und -kanten neu aufbauen, neu einbetten. Lassen Sie das aus, antwortet die nächste semantische Suche aus einer Codebasis, die es nicht mehr gibt.
Beachten Sie, was dieser Workflow nicht ist. Er ist keine Dokumentation einer API — das leisten die Tool-Beschreibungen bereits. Er ist die Reihenfolge der Arbeitsschritte, also das, was offensichtlich ist, sobald es jemand sagt, und unsichtbar, solange es niemand tut.
Diese Datei enthält außerdem eine Zeile, die man klauen sollte: "Live verifiziert am 10.06.2026 gegen sedonaWebEditor." Ein Workflow mit Verifizierungsdatum ist ein Workflow, dem man vertrauen oder den man ausmustern kann. Einer ohne ist ein Gerücht.
Warum das der Flaschenhals ist
Der Instinkt sagt: Bessere Modelle schließen diese Lücke. Tun sie nicht — und es lohnt sich, genau zu sein, warum.
Die Schwäche eines Modells in dieser Domäne ist nicht das Schlussfolgern und zunehmend auch nicht die Syntax — fundierte Indizes erledigen die Syntax. Die Schwäche ist, dass Verfahrenswissen in der Gebäudeautomation nie in einer ausführbaren Form aufgeschrieben wurde. Es lebt in den Köpfen einiger tausend Fachleute weltweit und wird per Lehrjahre weitergegeben: Sie lernen, dass eine Spark-Regel zwei Records braucht, weil ein erfahrener Ingenieur zugesehen hat, wie Sie eine ausgeliefert haben, die nie auslöste.
Dieser Übertragungsmechanismus skaliert nicht, und er übersteht keine Jobwechsel. Jeder Integrator leitet dieselben Verfahren erneut selbst her. Derselbe Nachmittag geht parallel in einem Dutzend Firmen verloren.
Ein Workflow ist genau dieser Lehrmoment — einmal aufgeschrieben, von da an von jedem Assistenten in jedem Projekt ausgeführt.
Warum es die Community sein muss
Hier kommt der Teil, den ich nicht allein schaffe — und keine einzelne Firma auch.
Die Leute, die dieses Wissen haben, schreiben meist keine Server. Der Techniker, der die richtige Inbetriebnahme-Reihenfolge für ein Dachgerät kennt oder weiß, welches curRule-Muster bei berechneten Punkten tatsächlich hält, ist ein Regelungsfachmann — kein TypeScript-Entwickler. Wenn ein Beitrag einen Pull Request gegen eine Indizierungs-Engine erfordern würde, bliebe sein Wissen, wo es ist.
Das ist nicht nötig. Ein Workflow ist eine Markdown-Datei. Frontmatter, eine Überschrift, die Schritte in der richtigen Reihenfolge, die Fallstricke. Wenn Sie aufschreiben können, wie Sie es machen, können Sie einen beitragen.
Die Ökonomie spricht absurd deutlich für uns. Ein Workflow kostet einen Nachmittag Schreibarbeit. Er spart danach jedem Ingenieur einen Nachmittag, der ihn sonst neu hergeleitet hätte — quer über alle Firmen, unbegrenzt. Es gibt wenige Stellen in der Software, an denen die Hebelwirkung so einseitig ist.
Und die Domäne ist zu klein, um sich zu zersplittern. Gebäudeautomation ist keine Webentwicklung; es kommt keine Armee von Beitragenden. Wenn die Leute, die Sedona, Haxall, Axon und Xeto kennen, ihre Verfahren jeweils für sich behalten, zahlen alle weiter dasselbe Lehrgeld. Dreiundzwanzig Dateien sind das, was eine Handvoll von uns geschafft hat. Zweihundert, geprüft und datiert, würden verändern, was ein Neuling in seiner ersten Woche leisten kann.
Die ehrlichen Risiken
Ein Workflow-Katalog ist nicht automatisch gut, und etwas anderes zu behaupten, würde das Ganze zum Scheitern verurteilen.
Ein falscher Workflow ist schlimmer als gar keiner. Ein Assistent folgt ihm selbstbewusst und liefert ein selbstbewusst falsches Ergebnis. Fehlendes Verfahren erzeugt immerhin Zögern; schlechtes Verfahren erzeugt schlechte Inbetriebnahmen. Review zählt hier mehr als bei den meisten Dokumentationen.
Workflows veralten, und zwar lautlos. SkySpark 4.0 hat das Extension-Format geändert und reale Verfahren über Nacht ungültig gemacht. Ein Workflow merkt nicht, dass er gealtert ist. Daher version: im Frontmatter und, besser noch, ein explizites Verifizierungsdatum samt Projekt, gegen das zuletzt geprüft wurde.
Disziplin beim Zuschnitt. Ein Workflow, der alles erklären will, lehrt nichts. Die guten erledigen eine Aufgabe — dieses Ding erstellen, jenes Ding migrieren, den Index frisch halten.
Nichts davon spricht gegen den Ansatz. Es spricht dafür, dass Review, Datierung und Neuverifizierung von Anfang an dazugehören und nicht erst bei zweihundert Dateien nachgerüstet werden.
Bauen Sie den Katalog mit
Beide Server sind source-available, und die Workflow-Verzeichnisse sind der denkbar einfachste Einstieg:
- FantomMcpServer —
workflows/, 13 Dateien, Bauen und Warten - AxonMcpServer —
workflows/, 10 Dateien, Analytik und Betrieb
Die Lücken sind nicht subtil. Es gibt keinen Workflow für BACnet-Punktbenennungskonventionen, keinen für die Inbetriebnahme einer Kältemaschinen-Sequenz, keinen für das halbe Dutzend Haystack-Tagging-Entscheidungen, die in jedem Projekt neu ausgefochten werden.
Wenn Sie eines dieser Verfahren kennen — wirklich kennen, inklusive der Stellen, an denen es schiefgeht — dann ist das ein Workflow, und im Moment hat ihn niemand aufgeschrieben.
Bringen Sie ihn ins Forum, wo sich die Arbeitsgruppen abstimmen, oder eröffnen Sie einen Pull Request gegen eines der beiden Repositories. Eine Markdown-Datei ist eine bewusst niedrige Hürde.
Mehr dazu, wie diese Server funktionieren: Axon MCP Server · sprachübergreifende Code-Intelligenz · die Sidecar-Flotte und das RLM.