A-ISL Compile (In-Agent-Compiler)

Du erzeugst bin-<stackId>/ aus ISL (Standard-Stack react-js → bin-react-js). Builder / Queue / Packet / Lock / Preflight CLIs sind erlaubt. Kostenpflichtige isl-generator / Gemini / OpenAI sind verboten.

Funktioniert mit jedem Coding-Agenten, der diese Skill lädt (Cursor, Claude Code, GitHub Copilot, …). Gleiche npm-Laufzeitumgebung wie im Repo-Root.

Benutzeranforderungstor (nicht verhandelbar)

Die Änderung der bin-* erfolgt nur durch Compile und nur auf ausdrückliche Anfrage des Benutzers.

Betrete diese Skill / schreibe unter bin-* nur, wenn der menschliche Benutzer explizit nach einem Compile fragt (z.B. „compila“, /a-isl-compile, „build bin“, „regenerate implementation“, „run compile for …“).
Nur-Spezifikation-Nachrichten, NL-Feature-Ideen oder UX-Anpassungen ohne explizite Compile-Anfrage DÜRFEN KEINE Implementierungsschreibvorgänge auslösen – leite sie an a-isl-spec-author (oder die Spezifikationsphase) weiter und stoppe.
Führe keine automatische Kompilierung nach Spezifikationsänderungen durch, „weil die Demo sonst kaputt ginge“ oder „um den Kreislauf abzuschließen“.
Implementierungsordner werden nur durch diesen Compile-Workflow aktualisiert (Packet → Schreiben → Lock). Behandle Ad-hoc Patches unter bin-* nicht als A-ISL-Pfad, es sei denn, der Mensch bittet explizit um eine einmalige Ausnahme.
Wenn der Mensch nicht nach einem Compile gefragt hat: Weigere dich, bin-* zu bearbeiten, und sage, dass eine explizite Compile-Anfrage nötig ist.

Wann zu verwenden

Mensch hat die Spezifikationsphase abgeschlossen und bittet um Build/Compile/Regenerate
Angleichung der bin-<stack>/ eines Projekts an aktualisierte *.isl.md weil der Mensch Compile angefordert hat

Harte Einschränkungen

Führe keine kostenpflichtigen Generatoren oder API-Codegen-Clients aus.
Du schreibst jede Implementierungsdatei unter dem Stack-Bin-Verzeichnis aus dem Packet targetPath (vollständiger Code, keine TODO-Platzhalter).
Das Aktualisieren von gen-lock.json allein ist kein Compile – nur Lock nach echten Schreibvorgängen unter bin-<stack>/.
Wenn ISL mehrdeutig oder widersprüchlich ist: Stoppe und teile dem Benutzer mit, dass er zu a-isl-spec-author zurückkehren soll. Erfinde keine Anforderungen.
Öffne während des Compile nicht vendor/isl-spec/ (nur Spec-Agent), es sei denn, der Benutzer fragt explizit danach.
Bevorzuge eine Einheit nach der anderen über queue --next + leichtes Packet. Lade standardmäßig nicht das gesamte Queue-JSON oder die vollständige .build.md.

Ausgabeverzeichnis

Standard: bin-<stackId> neben den Spezifikationen (z.B. --stack react-js → bin-react-js). Überschreibe mit --bin falls nötig. Derselbe Workspace kann bin-react-js und bin-csharp nebeneinander enthalten.

Token-sparender Workflow (Standard)

preflight → builder (einmal) → Schleife: queue --next → packet → [tests dann] impl schreiben → (batch) lock
         → (optional) npm run verify

0. Preflight (einmal)

npm run preflight -- --root examples/connect-four-workspace

Nur strukturelles/Graphen/Lint-Tor – beweist nicht die Korrektheit der Implementierung. Wenn es fehlschlägt, korrigiere Spec/Lint vor dem Compile.

1. Builder (einmal pro Batch)

npm run builder -- examples/connect-four-workspace

Die topologische Reihenfolge befindet sich in build/build-manifest.json (Skript-eigen). Du erfindest keine Compile-Reihenfolge.

2. Nur nächste Einheit

npm run queue -- --root examples/connect-four-workspace --next

Gib --stack <id> bei jedem Queue/Packet-Aufruf in der Schleife mit (Standard react-js → bin-react-js/):

npm run queue  -- --root <project> --next --stack blazor
npm run packet -- --root <project> --next --stack blazor

IDs: react-js, blazor, winforms, csharp (nur Bibliothek), python, python-fastapi. Optional überschreibt --bin <pfad> den Ausgabeordner.

Gezielte Neukompilierung – wenn der Mensch darum bittet, eine oder wenige Einheiten neu zu generieren (Lock würde sie sonst überspringen):

npm run queue  -- --root <project> --next --only dungeon --stack react-js
npm run packet -- --root <project> --next --only dungeon --stack react-js
# oder packet nach Name:
npm run packet -- --root <project> --only dungeon --stack react-js

--only kann wiederholt werden. Token: Einheiten-Basename (dungeon), dungeon.isl.md oder ./dungeon. Grund im Queue-JSON: force-only. Verwende kein Workspace-weites --force, wenn nur eine Teilmenge angefordert wird.

Verwende next.buildFile / next.targetPath. Wenn next null ist, stoppe (Queue leer). Verwende volles --json Queue nur, wenn der Mensch nach einem Überblick fragt.

3. Leichtes Packet (Standardkontext)

npm run packet -- --root examples/connect-four-workspace --build-file "<abs.build.md>"
# oder
npm run packet -- --root examples/connect-four-workspace --next

Packet enthält: SOURCE Markdown für diese Einheit, Zielpfad, Stack-Constraint-Teilmenge, Pfade zu Abhängigkeitsdateien im selben bin-<stack>/. Es schließt keine eingebetteten .ref.md-Blobs ein.

Schreibe Dateien aus dem Packet (siehe EXT-001 Reihenfolge unten). Importiere echte Abhängigkeitsmodule aus den aufgelisteten Pfaden.

3a. Deklarationsnachschlag für Abhängigkeiten (EXT-002)

Wenn du die genaue Deklaration eines Abhängigkeitssymbols (Methode / Funktion / Typ) benötigst, bevor du diese Einheit schreibst:

npm run lookup-decl -- --stack <id> --name <SpecOrCallName> --file <abs-or-rel-bin-path> [--workspace <project>]
# oder durchsuche einen Bin-Ordner (generierte *.test.* / *.Tests.cs werden übersprungen, außer --include-tests):
npm run lookup-decl -- --stack <id> --name <Name> --dir <bin-<stack>> --workspace <project>

Exit 0 = Treffer, 2 = no_match, 3 = Nutzungs-/Pfad-/Stack-Fehler.
Lese stdout JSON: verwende candidates[selected] (signatureText, leadingContext, enclosingType, pro-Kandidat kind). Erfinde keine Regexes oder öffne die gesamte Abhängigkeitsdatei, um Signaturen zu jagen.
Muster und callSymbol leben in der Stack-Konfiguration (declaration-patterns.ts / stacks.config.ts) – die Skill darf nur dieses CLI aufrufen.
Pfade müssen unter --workspace und einem bin-* Segment aufgelöst werden (Symlink-Escape → Exit 3).

3b. EXT-001 generierte Tests (wenn Spec teilnimmt)

Verifizierbare Szenarien = Test-Szenarien mit sowohl `id: …` als auch - Call: … (siehe docs/isl-agent-profile.md). Spec-Autor entscheidet; jede Rolle kann teilnehmen.

Pro Einheit, gleicher Durchlauf:

Wenn SOURCE ≥1 berechtigtes Szenario hat: überschreibe die generierte Testdatei zuerst (Pfad = Impl-Basename + stack.verify.testSuffix im selben bin-<stack>/, z.B. domain-sheet.test.js / domain-sheet.Tests.cs). Behaupter nur aus Spec-Szenarien + Signatur; bilde Call → Symbol via stack.verify.callSymbol (as-is | pascal-case | snake-case in stacks.config.ts). react-js Domain/Logic: Jeder Call MUSS ein benannter Export sein; Tests MÜSSEN import { <Call> } from "./<file>" verwenden – niemals import Unit from …; Unit().<Call>(). Wenn der Workspace bench/call-map.json enthält, löse export aus "<unit>.<Call>" auf und importiere diesen Namen (gleicher Vertrag wie gefrorener Score). Erfinde keine Fälle für reine Prosa-Szenarien; öffne/editiere die Impl-Datei nicht, bevor die Testdatei geschrieben ist.
Dann schreibe die Impl bei targetPath, sodass sie diese Tests und den Vertrag erfüllt. react-js Domain/Logic: export function <Call> / export const <Call> für jede Capability; VERBOTENE Standard-Export-Factory, die Capabilities kapselt.
Wenn null berechtigte Szenarien: schreibe nur Impl; lösche eine zuvor generierte Testdatei für diese Einheit, falls sie noch existiert. Verwende weiterhin benannte Capability-Exporte für Domain/Logic.
Bei Verify-Fehler: du darfst --only die Impl nur neu kompilieren (behalte die Testdatei). DARFST NICHT Tests umschreiben, um sie bestehen zu lassen (einschließlich Änderung benannter Importe zu Standard-Factories). Wenn das Szenario/Call/Erwartung falsch aussieht → STOP und sende den Menschen zu a-isl-spec-author.
Nach einem Domain/Logic (oder anderen berechtigten) Batch, darfst du npm run verify -- --root <project> --stack <id> vorschlagen; verlange kein Grün für Lock. Lock bleibt ein Build-Hash-Cache.

Vollständige Neukompilierung einer Einheit nach Spec-Änderung: generiere die gesamte Testdatei aus der aktuellen Spec neu, dann Impl (kein Merge mit alten Tests).

4. Lock (Batch wenn möglich)

Nach 1–5 erfolgreichen Schreibvorgängen:

npm run lock -- --root examples/connect-four-workspace --build-file "<abs1>" --build-file "<abs2>"

5. Agent-Batching nach Komplexität (Kontexthygiene)

Eine lange Agent-Sitzung, die viele Einheiten kompiliert, neigt zur Unterimplementierung von späteren oder großen Packeten (Kontext mit vorherigen Bins gefüllt). Bevorzuge:

Einheitenart	Wie kompilieren
Blatt / klein	Gleicher Agent, batche mehrere `queue --next` → schreiben → lock
Schwer / Hub	Neuer Agent / neuer Chat: `--only <unit>` → packet → implementiere jede Capability in SOURCE → lock
Reparatur nach Review/Playtest	Neuer Agent + `--only` auf die fehlerhafte(n) Einheit(en) nur

Behandle eine Einheit als schwer, wenn einer dieser Punkte zutrifft (Stack-unabhängig):

Lange SOURCE / viele #### Capabilities in einer .isl.md
Hoher Fan-In: viele andere Einheiten referenzieren sie, oder sie referenziert viele Abhängigkeiten
Präsentation oder Logik, die einen großen Teil des Graphen orchestriert (Shell / Fassade / Sitzungsgrenze)
Packet oder vorheriger Compile dieser Einheit hat eine Historie von ausgelassenen Flows

Starte keinen Agenten pro Blatt standardmäßig (Kosten). Führe keinen gesamten großen Workspace in einem Agenten aus, ohne bei Hubs aufzufrischen.

Eingabeaufforderung für eine schwere Einheit: Repo-Root, --stack, --only <unit>, „implementiere jede Capability in SOURCE; keine ausgelassenen Flows.“ Folge agent-skills/a-isl-compile/SKILL.md (oder der Host-Kopie unter .cursor/skills, .claude/skills oder .github/skills).

Eskalationstabelle (wenn leichter Zugriff nicht ausreicht)

Situation	Aktion
Packet ok, Dep-Bins existieren, ISL klar	Nur leicht → Datei schreiben
Packet Exit / `missingDependencyBins`	STOP – behebe Queue/Reihenfolge; erfinde keine APIs
Benötige genaue Deklaration/Signatur einer Dep	`npm run lookup-decl` (EXT-002); verwende JSON `selected` – erfinde keine APIs
`lookup-decl` Exit 2 (`no_match`)	Überprüfe Spec Call/Name + Dep-Pfad; erfinde keine Signaturen
Packet unvollständig / kein SOURCE-Marker	Lese die `fullBuildFile` dieser Einheit einmal
Mehrdeutiges / widersprüchliches ISL	STOP → Spec Agent; kein Vendor-Tauchen
Mensch fordert vollständigen Rebuild-Audit	`--force` / volles Queue `--json` erlaubt

Pro-Einheit Schreibregeln

Kopfzeile auf jeder generierten Datei:

/**
 * DO NOT EDIT THIS FILE DIRECTLY
 * ----------------------------------
 * This file was generated by ISL Compiler.
 * Source: <basename-of-.isl.md>
 * Edit the ISL file instead.
 */

Folge den Stack-Regeln (react-js Standard). Vollständige Implementierung – keine TODO-Platzhalter.

Pfade

Werkzeug	Einstieg
Preflight	`npm run preflight -- --root <project>`
Builder	`npm run builder -- <project>`
Queue next	`npm run queue -- --root <project> --next`
Packet	`npm run packet -- --root <project> --next`
Lock	`npm run lock -- --root <project> --build-file <abs>…`
Verify	`npm run verify -- --root <project> [--stack <id>] [--only <unit>]`
Lookup decl	`npm run lookup-decl -- --stack --name --file
Lint	`npm run lint -- <file.isl.md>`

a-isl-compile (In-Agent-Compiler)

Was ist a-isl-compile (In-Agent-Compiler)?

In Ihrer bevorzugten KI fragen

Dokumentation