DDD-Ecosystem mit KI-Unterstützung inklusive
Jedes Jardis-Package bringt seinen eigenen KI-Skill mit. Ein composer require, und dein Agent (Claude Code, Cursor, Continue, Aider) kennt Regeln, APIs und Patterns jedes installierten Packages. Kein Opt-in, keine Konfiguration, keine separaten Downloads. Skill + Code leben im selben Repository und reisen gemeinsam.
Installation
composer require --dev jardis/dev-skillsQuelle & Issues: github.com/jardisTools/dev-skills
Das Plugin scannt nach der Installation alle Jardis-Packages in vendor/, kopiert ihre Skills nach .claude/skills/ und aggregiert die AGENTS.md deiner Packages zu einer Projekt-AGENTS.md. Agent-Tools finden sie beim Arbeiten im Projekt automatisch.
Wie es funktioniert
- Skill + Code im selben Package — jedes Jardis-Package enthält seine Skill-Datei unter
<package>/.claude/skills/<name>/SKILL.md. Package-Maintainer pflegen API-Regeln an einer einzigen Stelle. - Plugin scannt
vendor/jardis*/*beim Install/Update und synchronisiert nach.claude/skills/im Projekt. Updates fließen übercomposer updateautomatisch mit. AGENTS.mdwird aggregiert — jedes Package liefert seine Agent-Hinweise, das Plugin merged sie in einen verwalteten Block (<!-- BEGIN jardis/dev-skills ... -->/<!-- END -->) deiner Projekt-AGENTS.md. Alles außerhalb des Blocks bleibt unberührt.- Cross-Agent-Standard — Cursor, Continue, Aider lesen
AGENTS.mdnativ; Claude Code zusätzlich die.claude/skills/-Struktur. Ein Setup, alle Agents.
Erkennung per Präfix
Das Plugin identifiziert Skills ausschließlich über das Verzeichnisname-Präfix. Diese Präfixe sind für Jardis reserviert, alles andere lässt das Plugin unangetastet:
| Präfix | Quelle |
|---|---|
adapter-* | jardisadapter/* (HTTP, Cache, Messaging, Mailer, …) |
core-* | jardiscore/* (App, Kernel) |
support-* | jardissupport/* (Repository, Validation, Workflow, …) |
tools-* | jardistools/* (DbSchema) |
schema-* | Plugin-Bundled (schema-authoring) |
platform-* | Plugin-Bundled (platform-implementation, platform-usage, platform-versioning, platform-workflow, platform-cookbook) |
rules-* | Plugin-Bundled (rules-architecture, rules-patterns, rules-testing) |
Nach dem Install siehst du im Composer-Output eine Zeile wie:
Jardis Skills installed: 14 skills, 3 AGENTS.md aggregated. See https://docs.jardis.io/skillsDie Zahl variiert: Sie zählt die in vendor/ gefundenen Vendor-Skills plus die aktivierten Methodik-Skills, nicht jedes Projekt installiert alle.
Voraussetzungen: PHP ≥ 8.3, Composer ≥ 2.
Drei Zonen — neun Methodik-Skills
Neben den 22 Vendor-Skills liefert das Plugin neun paket-übergreifende Methodik-Skills, gegliedert entlang des Jardis-Designer-Workflows: Pre-Designer (Idee → Schema), Designer (visuelles Modell als Single Source of Truth: Board, Aggregate, Process), Post-Designer (Code → Fachlogik). Darüber liegt der Crosscut mit Architektur- und Pattern-Regeln, die überall gelten.
schema-authoring
- Board
- Aggregate
- Process
platform-implementationplatform-usageplatform-versioningplatform-workflowplatform-cookbook
rules-architecturerules-patternsrules-testing
Architektur- & Pattern-Regeln, die überall gelten
Vendor-Skills — automatisch ausgerollt
Sobald ein Jardis-Package in deinem vendor/-Verzeichnis liegt, wird sein Skill ohne weitere Konfiguration nach .claude/skills/ ausgerollt.
Adapter (8)
| Skill | Package | Beschreibung |
|---|---|---|
adapter-cache | jardisadapter/cache | PSR-16 Multi-Layer-Cache mit Write-Through über L1→L2→L3. |
adapter-dbconnection | jardisadapter/dbConnection | PDO-Connection-Management mit Pool, Read/Write-Splitting und Failover. |
adapter-eventdispatcher | jardisadapter/eventdispatcher | PSR-14 Event Dispatcher mit Priority, Typ-Hierarchie und Deferred-Dispatch. |
adapter-filesystem | jardisadapter/filesystem | Filesystem-Abstraktion für Local und S3 mit Path-Traversal-Schutz. |
adapter-http | jardisadapter/http | PSR-18 HTTP-Client auf cURL mit Handler-Pipeline und Retry. |
adapter-logger | jardisadapter/logger | PSR-3 Logging-Pipeline mit 20+ Handlern, 7 Formattern, 6 Enrichern. |
adapter-mailer | jardisadapter/mailer | SMTP-Mailer mit STARTTLS, Attachments und Batch-Keepalive. |
adapter-messaging | jardisadapter/messaging | Messaging-API über Redis, Kafka, RabbitMQ, Database und InMemory. |
Core (2)
| Skill | Package | Beschreibung |
|---|---|---|
core-app | jardiscore/app | HTTP-Delivery: FastRoute-Router, PSR-15-Pipeline, kanonischer DomainResponse → PSR-7-Envelope. |
core-kernel | jardiscore/kernel | Der Koffer: immutabler DomainKernel + optionaler ENV-Packer BuildDomainKernelFromEnv. |
Tools (1)
| Skill | Package | Beschreibung |
|---|---|---|
tools-dbschema | jardistools/dbSchema | Schema-Analyse und DDL-Export für MySQL, PostgreSQL und SQLite über PDO. |
Support (11)
| Skill | Package | Beschreibung |
|---|---|---|
support-auth | jardissupport/auth | Session, Passwort-Hashing und RBAC nach Closure-Orchestrator-Pattern. |
support-classversion | jardissupport/classVersion | Versionierte Klassen via Namespace-Injection und Proxy-Registry. |
support-data | jardissupport/data | Entity-Hydration, Change-Tracking, Identity-Generierung — reflektionsbasiert, ohne ORM. |
support-dbquery | jardissupport/dbQuery | Fluent SQL-Query-Builder für MySQL, MariaDB, PostgreSQL, SQLite mit Prepared-Statements. |
support-dotenv | jardissupport/dotenv | .env-Loader mit Public/Private-Modus, Cascade-Includes und Cast-Chain. |
support-factory | jardissupport/factory | Minimaler PSR-11-Container mit Reflection-Fallback. |
support-repository | jardissupport/repository | Generisches CRUD-Repository mit Read/Write-Splitting und PK-Strategien. |
support-scheduling | jardissupport/scheduling | Pure-Logic-Scheduling: Cron-Parsing + Task-Schedule, ohne Ausführung. |
support-secret | jardissupport/secret | Secret-Resolution für .env via AES-256-GCM und Sodium als DotEnv-Plugin. |
support-validation | jardissupport/validation | Objekt-Graph-Validierung via Reflection mit 21 stateless Validator-Singletons. |
support-workflow | jardissupport/workflow | Multi-step-Orchestrierung über benanntes Status-Routing (sieben ON_*-Status) mit typisiertem Execution-Context. |
Methodik-Skills — opt-in
Die neun Methodik-Skills sind nicht Package-gebunden und werden nur auf Wunsch installiert. Aktivierung über die composer.json deines Projekts:
{
"extra": {
"jardis/dev-skills": {
"bundled-skills": true
}
}
}Akzeptierte Werte:
| Wert | Effekt |
|---|---|
Schlüssel fehlt oder false | Keine Methodik-Skills (Default) |
true | Alle neun Methodik-Skills |
["rules-*", "schema-authoring"] | Whitelist über Shell-Globs (fnmatch()) |
{ "include": [...], "exclude": [...] } | Erst include anwenden, dann exclude abziehen |
Beispiele:
"bundled-skills": ["rules-*"]Installiert rules-architecture, rules-patterns, rules-testing.
"bundled-skills": { "include": ["rules-*"], "exclude": ["rules-patterns"] }Installiert rules-architecture und rules-testing. rules-patterns wird ausgeschlossen.
Synchronisation: Die composer.json ist die Wahrheit. Engst du bundled-skills ein (z. B. von true auf ["rules-*"]), entfernt der nächste composer install die abgewählten Methodik-Skills aus .claude/skills/, auch wenn du sie lokal verändert hast. Vendor-Skills und Skills ohne Jardis-Präfix (my-*, internal-*) bleiben unberührt.
Ungültige Werte (z. B. bundled-skills: 42) erzeugen eine Warnung im Composer-Output und fallen auf den Default "keine" zurück, kein Abbruch.
Pre-Designer
| Skill | Beschreibung |
|---|---|
schema-authoring | Aus einer Idee zur Schema.yaml für den Designer-Import: Tabellen ableiten, Indexe vorschlagen, Designer-Format treffen. Beiliegendes examples/Schema.yaml (MeterDevice) als vollständige Referenz. |
Das frühere YAML-Vokabular der Designer-Output-Files (vormals der
tools-definition-Skill) ist nicht mehr Teil des Bundles. Es lebt jetzt im Builder-Tooling selbst.
Post-Designer — Active
| Skill | Beschreibung |
|---|---|
platform-implementation | Fachlogik auf Designer-erzeugtem Code im Platform-Dir-Layout: Generator-Output liegt unter {Agg}/Platform/ (bei jedem Build neu geschrieben), Developer-Code direkt unter {Agg}/ parallel zu Platform/. V1–V12-Verbote, Decision-Tree, sieben Implementierungs-Stufen, DomainResponse-Konstruktion, Werkzeugkasten-Querverweis. ClassVersion → platform-versioning, Workflow-Engine → platform-workflow, Rezepte/Troubleshooting → platform-cookbook. |
platform-usage | Designer-erzeugte Commands/Queries aus eigenem Code aufrufen: Bootstrap, 4-Hop-Api-Registry-Aufrufpfad, DomainResponse-zu-Transport-Mapping (HTTP-Status, CLI-Exit, Queue-ack/nack), Error-Handling. Framework-agnostisch — PSR-15, Symfony Console, Queue-Worker. |
platform-versioning | ClassVersion-Auflösung und Versionierungs-Modell: 7-Stage-Lookup über LoadClassFromExtensions mit segmentNames: ['', 'Platform'], Baseline- vs. versionierte Overrides (v1, v2, …), ClassVersionConfig-Setup, fünf Leitsätze (additiv vor Version, Version ändert Verhalten nie API, Datenbruch = neues Aggregat, …). |
platform-workflow | Workflow-Engine-API für FlowDesigner-erzeugte Use-Case-Orchestratoren: sechs Routing-Status (ON_SUCCESS/ON_FAIL/ON_TIMEOUT/ON_SKIP/ON_CANCEL/ON_EVENT), WorkflowBuilder-Graph-Konstruktion, handlerFactory-Closure-Konventionen, drei WorkflowContext-Slots, R5-Routing-Safety. |
platform-cookbook | Phase-3-Rezepte und Troubleshooting für Designer-Code: Event-Transport über <Agg>EventRouter.php (Kafka/RabbitMQ/Redis/HTTP-Webhook/in-process), sechs Rezepte (VO in Hydrate, Domain Service, neues Command/Query, Event zu Kafka, Flow-DTO input.extends, Response-Shapes), Troubleshooting-Tabelle. |
Crosscut
| Skill | Beschreibung |
|---|---|
rules-architecture | Architektur-Säulen (SoC, SRP, Composition, Data-Behavior-Separation, explizite Dependencies), Hexagonal Architecture, Closure-Orchestrator-Pattern. |
rules-patterns | Pattern-Katalog (Facade, Strategy, Adapter, Value Object, Factory, Repository, Decorator, Chain of Responsibility, Lazy Init, Priority-Layers). |
rules-testing | Integration über Unit, Mock nur an Port-Boundaries, Pflicht-Process für fehlschlagende Tests ohne Assertion-Schwächung. |
FAQ
Ist das Claude-spezifisch?
Nein. AGENTS.md ist ein Cross-Agent-Standard, den Cursor, Continue und Aider nativ lesen. Die .claude/skills/-Struktur ist optional für Claude-Code-User: wer sie nicht nutzt, ignoriert den Ordner einfach.
Was wenn ich eigene Skills habe?
Skills ohne Jardis-Präfix (my-*, internal-*, …) bleiben unberührt. Bei Namens-Kollisionen verschiebt das Plugin das existierende Verzeichnis als Geschwister-Ordner nach .claude/skills/<name>.backup/ und installiert darüber die neue Version, mit Warnung im Composer-Output. Der Backup-Ordner wird nie automatisch gelöscht; du entscheidest, wann du ihn brauchst.
Für die AGENTS.md gilt: Existiert bereits eine AGENTS.md ohne Jardis-Marker, wird sie einmalig nach AGENTS.md.backup umbenannt; dein Inhalt wird in die neue Datei übernommen und der verwaltete Jardis-Block angehängt. Bei Re-Installs wird nur der Block zwischen den Markern ersetzt. Alles außerhalb bleibt erhalten, inklusive Position.
Wie deinstalliere ich?
composer remove jardis/dev-skills entfernt alle Verzeichnisse mit Jardis-Präfix (adapter-*, core-*, support-*, tools-*, schema-*, platform-*, rules-*) und löscht den verwalteten Block aus der AGENTS.md. Steht in der AGENTS.md nur der Jardis-Block, wird die Datei komplett entfernt. Enthält sie weiteren Inhalt, bleibt die Datei erhalten und nur der Block verschwindet. .backup-Verzeichnisse und Skills ohne Jardis-Präfix bleiben immer erhalten.
Werden die Vendor-Skills automatisch installiert?
Ja. Sobald ein jardisadapter/*-, jardiscore/*-, jardissupport/*- oder jardistools/*-Package in vendor/ liegt, wird sein Skill ohne weitere Konfiguration nach .claude/skills/ ausgerollt.
Und die neun Methodik-Skills?
Opt-in. Über extra."jardis/dev-skills"."bundled-skills" in deiner composer.json aktivierst du sie: true für alle, Whitelist wie ["rules-*"] oder {"include": [...], "exclude": [...]} für feinere Auswahl. Default ist keine, damit du bewusst entscheidest.
Gibt es Upgrade-Notes?
Ja, mit dem letzten Overhaul wurden die drei plan-*-Skills (plan-requirements, plan-ddd-modeling, plan-data-discovery) retiriert und durch den fokussierten schema-authoring ersetzt. tools-builder ist in platform-implementation aufgegangen (Layout der generierten Klassen ist jetzt §1 dort). Der tools-definition-Skill wurde aus dem Bundle entfernt. Sein YAML-Vokabular lebt jetzt im Builder-Tooling. Und platform-implementation wurde in fünf fokussierte platform-*-Skills aufgeteilt: implementation, usage, versioning, workflow, cookbook. Wer ein Projekt mit älteren Jardis-Skills upgradet, findet übriggebliebene plan-*- und tools-definition-Verzeichnisse unangetastet vor. Sie gelten jetzt als Custom-Skills.