iot

Überblick über den iot-Skill

Der iot-Skill hilft dir dabei, IoT-Architekturdiagramme in PlantUML mit Stencil-Icons für Geräte, Sensoren, Gateways und Cloud-Services zu erstellen. Er eignet sich besonders dann, wenn ein Diagramm zeigen soll, wie physische Dinge mit Edge- und Cloud-Systemen verbunden sind: Smart Home, Industrial IoT, Flotten-Telemetrie, Sensornetzwerke, Digital Twins und Robotik.

Dieser iot-Skill ist kein allgemeiner Abkürzungsweg für Diagramme. Er richtet sich an Leser, die die passende IoT-Terminologie und Iconografie brauchen, nicht nur Kästen und Pfeile. Wenn du Datenflüsse, Standortgrenzen, Protokoll-Hops oder den Lebenszyklus von Geräten so dokumentieren willst, dass Ingenieure es schnell erfassen können, passt dieser Skill gut. Wenn du nur generische Cloud-Infrastruktur oder Software-UML brauchst, nimm lieber einen anderen Skill.

Wofür iot gedacht ist

Verwende iot fürs Diagramming, wenn das Diagramm zeigen muss, wie Geräte, Gateways und Services in der realen Welt zusammenhängen: was vor Ort installiert ist, was am Edge läuft, was in die Cloud reicht und was nach Standort oder Zone gruppiert wird. Der größte Mehrwert liegt in der Klarheit für IoT-spezifische Komponenten und Muster, nicht in der Dekoration.

Wann dieser Skill die richtige Wahl ist

Wähle den iot-Skill, wenn du Diagramme brauchst für:

• Smart-Home-Hubs und Gerätegruppen
• Fertigungslinien, PLCs, Sensoren und Edge-PCs
• Fahrzeugflotten und Telemetrie-Pipelines
• LoRaWAN- oder gateway-aggregierte Sensornetzwerke
• Digital-Twin- und Asset-Model-Flows
• Robotik- oder Edge-ML-Deployments

Was ihn unterscheidet

Der wichtigste Unterschied ist die stencil-basierte PlantUML-Ausgabe mit AWS-artigen IoT-Icons wie Sensoren, Gateways, Greengrass, IoT Core, SiteWise, FleetWise und Device-Management-Komponenten. Das liefert dir einen glaubwürdigeren iot-Leitfaden für Architektur-Reviews als schlichte Rechtecke, vor allem wenn das Publikum bereits service-spezifische Symbole erwartet.

So verwendest du den iot-Skill

Skill installieren und laden

Nutze für die Installation den Standard-Repo-Flow für einen iot-Install:
npx skills add markdown-viewer/skills --skill iot

Öffne danach die Skill-Dateien in dieser Reihenfolge:

1. SKILL.md für Regeln und Syntax
2. examples/*.md für wiederverwendbare Muster
3. jede verlinkte Stencil-Referenz, die im Skill-Text genannt wird

Starte mit dem Diagrammauftrag, nicht mit der Icon-Liste

Ein guter Prompt für diesen Skill sollte das eigentliche Architekturziel beschreiben, nicht nur „mach ein IoT-Diagramm“. Nenne:

• die Domäne: Smart Home, Fabrik, Flotte usw.
• die Gerätetypen
• die Edge-Schicht, falls vorhanden
• die beteiligten Cloud-Services
• das Protokoll oder den Datenpfad
• die Zielgruppe, wenn sie den Detaillierungsgrad beeinflusst

Beispiel für eine starke Anfrage:
„Erstelle ein iot-Architekturdiagramm für eine Smart-Factory-Linie mit Temperatur- und Vibration-Sensoren, einer PLC, Greengrass am Edge, IoT Core, SiteWise und ereignisbasiertem Alerting. Zeige den Datenpfad von den Sensoren über Edge zur Cloud und gruppiere die Komponenten nach Produktionslinie und Cloud-Plattform.“

Lies die Beispiele, bevor du deinen eigenen Prompt schreibst

Die Beispiel-Dateien sind der schnellste Weg, die bevorzugten Muster des Skills zu verstehen:

• examples/smart-home.md
• examples/smart-factory.md
• examples/edge-computing.md
• examples/fleet-telemetry.md
• examples/digital-twin.md
• examples/sensor-network.md
• examples/device-management.md
• examples/robotics.md

Daran siehst du, welche Stencils gut zusammenpassen und wie die Diagramme typischerweise gruppiert werden. Das ist wichtiger, als sich jeden einzelnen Icon-Namen zu merken.

Nutze die Skill-Regeln, die die Ausgabequalität beeinflussen

Einige Regeln verändern das Ergebnis spürbar:

• Ausgabe in ```plantuml oder ```puml einschließen
• mit @startuml beginnen und mit @enduml enden
• für typische Geräte-zu-Cloud-Flows left to right direction verwenden
• Systeme mit rectangle oder package gruppieren
• gerichtete Pfeile für Flüsse und gestrichelte Pfeile für asynchrone Updates bevorzugen
• kein generisches Color-Tuning anfordern, außer du brauchst es wirklich

Wenn du die Zielumgebung schon kennst, sag es ausdrücklich. Zum Beispiel: „verwende MQTT von Sensoren zum Gateway“ oder „zeige OPC-UA von der PLC zum Edge“. Solche Details verbessern die iot-Nutzung, weil sie das Diagramm auf die tatsächliche Integration festnageln und nicht nur auf die visuelle Struktur.

iot-Skill-FAQ

Ist iot nur für AWS-Diagramme?

Nein. Der Skill nutzt AWS-artige mxgraph.aws4.*-Stencils, aber die Diagramme sind trotzdem für breitere IoT-Architekturen nützlich. Entscheidend ist die IoT-Visuelsprache und der PlantUML-Workflow, nicht ein Vendor-Lock-in.

Kann ich das statt eines normalen Prompts verwenden?

Ja, wenn du konsistente IoT-spezifische Symbole und eine konsistente Struktur willst. Ein einfacher Prompt kann ein Diagramm beschreiben, aber der iot-Skill gibt dir ein wiederholbares Muster für die Zusammensetzung aus Gerät, Edge und Cloud.

Ist der iot-Skill einsteigerfreundlich?

Ja, wenn du dein System in einfachem Englisch beschreiben kannst. Du musst PlantUML-Syntax nicht vorher kennen, aber du solltest wissen, welche Geräte, Flows und wichtigen Services dargestellt werden sollen.

Wann sollte ich iot nicht verwenden?

Verwende ihn nicht für generische App-Architekturen, CRUD-Backends oder Standard-Cloud-only-Diagramme. Der iot-Skill ist vor allem dann sinnvoll, wenn physische Geräte oder Edge-Verarbeitung im Mittelpunkt stehen.

So verbesserst du den iot-Skill

Gib dem Skill die echte Bereitstellungsform

Die besten Inputs für einen iot-Leitfaden sind konkret: wie viele Zonen es gibt, wo das Edge-System sitzt und was lokal versus cloudbasiert läuft. „Fabrik mit Sensoren“ ist zu schwach. „Zwei Produktionslinien, jeweils mit Temperatur- und Vibration-Sensoren, ein Greengrass-Gateway pro Linie und zentrale SiteWise-Analytik“ ist deutlich besser.

Gib Protokoll und Datenpfad an

Die Ausgabequalität steigt, wenn du den Pfad explizit nennst:

• sensor → gateway → core
• PLC → industrial PC → cloud
• vehicle edge agent → telemetry service → analytics

Das hilft dem iot-Skill, bessere Pfeile, Labels und Gruppierungen zu wählen. Außerdem verhindert es ein generisches Diagramm, das zwar plausibel aussieht, aber die echte Integration verschleiert.

Achte auf die typischen Fehlermuster

Die häufigsten Probleme sind ein vager Scope, zu viele Services und fehlende Grenzen. Wenn du nicht sagst, was zum Edge gehört, kann das Diagramm alles in eine einzige Schicht glätten. Wenn du zu viele Services anforderst, wird das Ergebnis schnell überladen und schwerer lesbar als eine einfachere iot-für-Diagramming-Ausgabe.

Iteriere, indem du jeweils eine Ebene präzisierst

Wenn das erste Diagramm zu breit angelegt ist, schärfe es schrittweise:

1. die physischen Geräte bestätigen
2. die Edge-Komponenten bestätigen
3. die Cloud-Services bestätigen
4. die Gruppierung nach Standort, Flotte oder Produktlinie bestätigen

Diese Iterationsart funktioniert besonders gut für iot-Install-Workflows, weil der Skill dann am stärksten ist, wenn die Architektur bereits bekannt ist und du eine saubere, servicebewusste visuelle Übersetzung willst.