Von der Anforderungsaufnahme über Implementierung, Review und Dokumentation bis zum Deployment — jede Phase als versionierter Skill, ausgeführt in Ihrer eigenen Agent-Laufzeit.
Ein Paket trägt einen vollständigen, KI-gestützten Delivery-Prozess: Jede Phase im Leben einer User Story läuft als versionierter, nachvollziehbarer Skill — als Slash-Command direkt in Ihrer Agent-Laufzeit (/help listet den gesamten Katalog).
Meeting-Transkripte werden zu strukturierten Jira-Stories mit Akzeptanzkriterien.
Codebase-Analyse erzeugt nachvollziehbare, reviewbare Implementierungsnotizen.
KI-generierte erste Implementierungsentwürfe mit Tests — im Tech-Stack des Kunden.
Rubrik-bewertete Reviews, PR-Tooling und deterministische Testdaten.
Umgebungs-Promotion, Release Notes und Dokumentation.
Vom Story-Entwurf aus Meeting-Transkripten über parallele Implementierung ganzer Epics bis zu Release-PRs, Dokumentation in vier Typen und einem lokalen Business-Chat über die eigene Lösung — jeder Workflow-Schritt ist ein Slash-Command.
Skills, Adapter und ein Node-Installer — kein CloudRise-Server im Ablauf, keine Telemetrie, kein Phone-Home. Ihr Code, Ihre Tickets und Ihre Transkripte verlassen Ihre Umgebung nicht.
Semantische Versionierung mit VERSION, CHANGELOG und unveränderlichen Releases. Jede Skill-Ausführung hinterlässt ein schema-validiertes Protokoll — auditierbar im eigenen Repository.
Kein Skill enthält einen Kundennamen, ein Vendor-Tool oder ein Laufzeit-Primitiv. Fünf unabhängige Achsen werden bei der Ausführung aus der Konfiguration aufgelöst — eine neue Plattform, Laufzeit oder Git-Strategie ist ein neues Adapter-Dokument, nie ein Fork der Skills.
Identität, Zugänge, Namenskonventionen, Locale und Pfade — Ihr eigenes Konfigurations-Repository, verknüpft bei der Installation.
Stack-spezifische Kommandos und Standards — Salesforce, Node/Cloudflare und weitere. Plattform-spezifische Skills brechen sauber ab, wo sie nicht gelten.
Claude Code, OpenAI Codex, Gemini CLI, lokales LLM oder gehosteter Endpoint — pro Lauf wechselbar, mit Cross-Runtime-Review.
Cloud (MCP-Tools) oder Data Center (REST mit Token) — dieselben Jira- und Confluence-Workflows in beiden Welten.
Feature-Branch, Trunk-based oder Gitflow — Branching, PR-Gates und Story-Promotion folgen Ihrem Modell.
Ein Skill enthält keine Kundenfakten. Bei jedem Prompt löst er den aktiven Kunden auf und liest dessen Konfigurationsset — und die Best Practices der Plattform — bevor er irgendetwas tut. Derselbe Skill, ein anderer Kunde: Nur die Verknüpfungen zeigen woandershin.
Kundenkonventionen schlagen Plattform-Best-Practices bei Stil und Benennung. Bei Korrektheit, Sicherheit, Ressourcenlimits und Deployability gewinnt die Plattform — eine Konvention kann das nicht aufheben. Scheint ein Kundendokument das zu tun, wird es als Dokumentationsfehler gemeldet, nie stillschweigend befolgt.
Kunden liefern eigene Skills im eigenen Konfigurations-Repository; ein Skill-Ordner mit dem Namen eines ausgelieferten Skills ersetzt ihn — nur für diesen Kunden. setup.sh <kunde> wechselt den gesamten Kontext in Sekunden.
Jeder Konfigurationszugriff läuft über ein einziges Werkzeug — kein Skill parst Markdown selbst. Eine neue Laufzeit, Plattform oder Git-Strategie ist ein neuer Adapter-Ordner, keine Änderung an den Skills.
Die Skills existieren genau einmal — und laufen nativ dort, wo Sie arbeiten. Auch datensouverän: mit einem lokalen LLM oder einem europäischen Endpoint Ihrer Wahl als Datenperimeter.
Volle Fähigkeiten: parallele Subagenten, Worktree-Isolation, MCP, Websuche.
Native Skill-Ausführung mit reduzierter Parallelität.
Natives MCP, sequenzielle Verarbeitung.
Ollama / llama.cpp — für Datenschutz- und Offline-Szenarien.
Jeder OpenAI-kompatible Endpoint — z. B. Scaleway, OVHcloud, IONOS, STACKIT. Der API-Schlüssel gelangt nie in die Konfiguration, nur der Name seiner Umgebungsvariable.
Der Score wird berechnet, nie in Prosa summiert: Ein Rubrik-Scorer liest Rubrik und Befundliste der Runde und liefert Teilwerte je Achse — eine nicht gemessene Achse ist null, kein Bestehen. Das Gate ist deterministisch: Es entscheidet aus gezählten Blockern und Majors, Schwellwert und Rundenlimit über Bestehen, Weitermachen oder Abbruch.
Jeder Skill nennt seinen Geltungsbereich, bevor er arbeitet. Plattform- und Laufzeit-Guards brechen sauber ab statt zu raten. Ein Story-Gate verweigert Design, Implementierung und Abschluss bei offenen Fragen oder unbelegten Akzeptanzkriterien. Secrets gelangen nie in die Konfiguration.
Jede Skill-Ausführung schreibt ein schema-validiertes JSON-Protokoll in Ihr eigenes Repository — mit Urteil je Prüfung (pass / fail / unchecked), Review-Schleife (Runden, Score je Achse, Exit-Grund) und Wissensdosis. /pipeline-stats liest sie, /improve-skills handelt danach.
Jeder Lauf hinterlässt ein Protokoll, jedes Review hinterlässt Befunde. /improve-skills wertet diese Evidenz aus, bündelt, was sich wiederholt, und schlägt die exakte Änderung an dem Dokument vor, das den Fehler hätte verhindern sollen.
Eine Korrektur an einem Skill oder einer Plattformregel erreicht mit dem nächsten Release jeden Kunden; eine Konvention oder Domänenregel bleibt bei dem Kunden, von dem sie stammt. Jeder Vorschlag benennt, welches von beidem gilt.
Protokolle und Berichte liegen im Repository des jeweiligen Kunden. Jedes Zitat wird gegen seine Quelle geprüft, bevor ein Mensch den Vorschlag sieht — ein Vorschlag ohne belegbare Evidenz wird zurückgezogen, nicht abgeschwächt.
Freigabe erfolgt pro Vorschlag, nie pauschal. Alles, was eine Prüfung abschwächen würde, wird markiert und separat begründet. Eine Schleife, die ihr Budget ausschöpft, ist ein Grund, den Skill zu reparieren — nicht, das Limit zu erhöhen.
/implement-us verlangt jetzt je neuer Verzweigung einen benannten Test und prüft die Diff-Hygiene vor jedem Commit; /design-us hält bestätigte Annahmen aus dem Gate für offene Fragen heraus.Ein lokaler Business-Chat über die eigene Lösung — fundiert, zitiert, ehrlich bei Lücken. Und eine Schleife, die die Wissensbasis mit jeder Story pflegt.
/ask beantwortet eine Frage, /serve-chat stellt dieselbe Engine als lokale Chat-Oberfläche bereit — ohne Cloud-Dienst dazwischen. Antworten kommen ausschließlich aus dem aufgebauten Index; jedes Zitat verlinkt seine Quelle, eine zweite Laufzeit prüft jede Antwort gegen die Quellen.
Dieselbe Engine leitet für neue Teammitglieder einen rollenbezogenen Lernpfad ab — Business Case und Projekthistorie zuerst, Mechanik danach — mit Briefings und Quizzes, Fortschritt inklusive.
Unbeantwortbare Fragen landen im Gap-Log für den nächsten /build-knowledge-Lauf. Jede geänderte Komponente wird auf betroffene Dokumente abgebildet — im Design und nach der Implementierung — und als Wissensschuld geführt, bis sie abgetragen ist. Die Wissensdosis jedes Laufs steht neben seinem Qualitätsscore im Protokoll.
Der Harness und Ihr Konfigurations-Repository sind privat. Beim Onboarding richten wir zwei Zugänge ein — prüfen Sie beide einmal pro Rechner, bevor Sie installieren.
cloudrise-license.json — Sie erhalten sie zusammen mit der Rechnung@aethon-x/harness ist ein privates npm-Paket. Ihr npm-Konto wird in die aethon-x-Organisation eingeladen; danach genügt einmalig npm login pro Rechner. Wichtig: Ohne Zugang meldet npm 404 Not Found — das ist npm, das ein privates Paket verbirgt, kein falscher Paketname. Fehlt die Einladung, melden Sie sich bei CloudRise.
harness init klont beim ersten Lauf Ihr Konfigurations-Repository — standardmäßig von GitHub. Liegt es woanders (eigene GitHub-Organisation, GitLab, Bitbucket, interner Git-Server), zeigt die Umgebungsvariable PIPELINE_CUSTOMER_REPO_URL beim ersten init auf eine beliebige Git-URL. Danach aktualisiert sich das Repository per gewöhnlichem git pull.
npm install --save-dev @aethon-x/harnessLegen Sie die erhaltene cloudrise-license.json in das Projektverzeichnis (oder nach ~/.config/cloudrise/). Die Prüfung erfolgt offline über eine Ed25519-Signatur — es wird nichts übertragen.
harness init klont Ihre Konfiguration, verknüpft sie, wählt Laufzeit und Git-Strategie und stellt die Skills als Slash-Commands bereit. Der Befehl ist idempotent — nach jedem Upgrade oder Konfigurationswechsel einfach erneut ausführen.
npx harness init <ihr-konfigurationsname>npx harness doctorDanach die Agent-Laufzeit im Projektverzeichnis starten — die Skills erscheinen als Slash-Commands (/help listet sie).
Vier Kommandos bestätigen, dass alles steht — jedes nennt im Fehlerfall den nächsten Schritt.
npx harness version → AI Harness 2.2.0 (@aethon-x/[email protected]) npx harness license → License VALID — Lizenznehmer, Plätze und Hauptversion werden angezeigt npx harness doctor → "All checks passed." — jede fehlgeschlagene Zeile nennt das Kommando, das sie behebt npx harness init --dry-run → Vorschau, was ein erneutes init ändern würde — es wird nichts geschrieben
Minor- und Patch-Releases sind in Ihrer Hauptversion enthalten. Das Update ist ein Zweischritt:
npx harness upgrade # neueste Version innerhalb Ihrer lizenzierten Hauptversion npx harness init <konfiguration> # Arbeitsstruktur danach neu aufbauen
Der Aethon-X Harness ist eine Bibliothek KI-gestützter Delivery-Workflows — von der Anforderungsaufnahme über Implementierung, Review und Dokumentation bis zum Deployment. Jede Phase ist als versionierter Skill paketiert und läuft als Slash-Command in Ihrer eigenen Agent-Laufzeit.
Nein. Der Harness wird als Text ausgeliefert — Skills, Adapter und ein Node-Installer — und läuft vollständig in der Agent-Laufzeit, die Sie bereits nutzen. Es gibt keinen CloudRise-Server im Ablauf, keine Telemetrie und kein Phone-Home. Auch die Lizenzprüfung erfolgt offline.
Claude Code (empfohlen), OpenAI Codex CLI, Google Gemini CLI, lokale LLMs (Ollama / llama.cpp) sowie beliebige gehostete Endpoints, die die OpenAI-Chat-Completions-API sprechen — etwa Scaleway, OVHcloud, IONOS oder STACKIT. Die Skills existieren nur einmal und passen sich zur Laufzeit an.
Ja. Standardmäßig wird das Konfigurations-Repository von GitHub geklont, aber jede Git-URL funktioniert — eigene GitHub-Organisation, GitLab, Bitbucket oder ein interner Git-Server. Die URL wird nur für den ersten Clone benötigt; danach aktualisiert sich das Repository per gewöhnlichem git pull.
Die Lizenz gilt unbefristet pro Hauptversion; Minor- und Patch-Updates sind enthalten. Die Lizenzdatei trägt eine Ed25519-Signatur, die das CLI offline gegen einen im Paket kompilierten öffentlichen Schlüssel prüft — es wird nichts übertragen und kein Lizenzserver kontaktiert.
Über seine eigenen Protokolle. /improve-skills wertet Skill-Ausführungsprotokolle und Review-Berichte aus, bündelt wiederkehrende Fehlermuster ab drei unabhängigen Vorkommen, ordnet jedes dem Dokument zu, das es hätte verhindern sollen — Skill, Plattform-Best-Practices, Kundenkonventionen oder Domänenwissen — und schlägt die exakte Textänderung vor. Jede Änderung wird einzeln freigegeben; Skill- und Plattformkorrekturen erreichen mit dem nächsten Release jeden Kunden, Kundenkonventionen bleiben beim Kunden.
Erfahren Sie in einem unverbindlichen Gespräch, wie der Harness Ihre Delivery-Prozesse beschleunigt — inklusive Live-Demo im Workflow Ihres Teams.
Kostenlose Erstberatung vereinbaren