vos-erstellen

Erstellen im Stil des Benutzers, aus seinem Ordner

Sie erstellen vos-Programme, die zu einem Ordner gehören: Der Ordner des Benutzers auf vos.so ist die Sammlung, seine .md-Dateien (Rezepte) sind der Stil, seine Voses sind die Vorlagen. Dieser Skill trägt nur MECHANIK und die universelle Handwerksbasis. Geschmack sind Benutzerdaten und leben in deren Ordnern, niemals hier. Autorenregeln (Schema, Dialekt, Einstellungen) leben im vos-authoring-Skill; Einstellungen und Looks-Handwerk im vos-remix-Skill in der params-knobs-Referenz. Dieser Skill fügt den Ordnervertrag, die Schleife und den Prozess um sie herum hinzu.

Es gibt keinen Posteingang und keine Hausstil-Datei. Deduplizierung erfolgt über die eigenen Inhalte des Ordners; das Regal ist der Datensatz.

Einrichtung

npm i -D @vosjs/cli   # folder, fetch, check, still, render, push

Anmeldedaten, in dieser Reihenfolge, niemals ausgeben: VOS_API_KEY, dann die erste Zeile von ~/.config/vos/credentials, dann vos login (eine Browser-Anmeldung, die einen Schlüssel für diesen Rechner erstellt). Jeder folgende HTTP-Aufruf ist Authorization: Bearer <key> gegen https://vos.so/api. Schlüssel erstellen nur PRIVATE Arbeit und können niemals veröffentlichen.

Die fünf Schritte

1. Den Zielordner auflösen

Der Benutzer benennt ihn, oder Sie fragen, welcher. vos folder list (oder GET /api/folders) findet ihn nach Name oder Slug auf allen Ebenen; dann ziehen Sie ihn:

GET https://vos.so/api/folders/{id}

Ein Pull ist das gesamte Kontextpaket: die eigenen recipes des Ordners (Körper inline), seine inheritedRecipes (Vorfahren-Rezepte, zuerst das Stammverzeichnis, jedes einzeln mit seinem Quellordner markiert; sie BINDEN diesen Ordner), exemplarische voses mit contentUrls und assets. Unterordner werden aufgelistet, nicht inline: ein Pull sind die eigenen Inhalte des Ordners.

Noch kein Ordner vorhanden? Erstellen Sie einen, immer mit einer Besch Cheibung:

vos folder create <name> --desc "<eine Zeile, was diese Sammlung ist>"

Ein Ordner, der ohne Beschreibung erstellt wurde, ist ein Benennungsfehler; die Beschreibung ist das, was die Ordnerseite und jeder zukünftige Pull lesen.

2. JEDE .md-Datei lesen, dann die Vorlagen

Lesen Sie jeden Rezeptkörper, die eigenen des Ordners UND die geerbten, sowie 1 bis 3 exemplarische Konfigurationen oder Dokumente über deren contentUrls. Rezepte sind rollenbenannte Facetten, benannt in GROSSBUCHSTABEN, so wie es CLAUDE.md ist: TASTE.md ist die Bewertungslatte, DESIGN.md die Technikspezifikation und alles andere, was die Absicht des Benutzers erstellt hat (MOTION.md, COPY.md, BRAND.md, ...). Ein Rezept ist die Datei, die eine Sammlung liest, bevor sie etwas erstellt, und der Name sagt, was es ist; ein Rezept, das Sie ablegen, wird mit seinem Stamm in Großbuchstaben gespeichert, also schreiben Sie es so und das Regal zeigt, was Sie geschrieben haben. Die Plattform erzwingt keine darüber hinausgehende Taxonomie; Sie lesen alle. Die Bindungsregel:

• Rezepte und Vorlagen überschreiben jede Voreinstellung, die dieser Skill oder der Autoren-Skill haben. Ihre Dauer ist die Dauer; ihre Palette-Disziplin ist die Disziplin.
• Bei Konflikten zwischen Dateien gewinnt die spezifischere: die eigenen Dateien des Ordners schlagen geerbte, nähere Vorfahren schlagen entferntere, und eine spezifische Anweisung schlägt eine allgemeine. Ein echter Widerspruch geht als Frage an den Benutzer zurück, niemals als stillschweigende Auswahl.
• Wenn ein Rezept und die aktuellen Vorlagen des Ordners widersprechen, bevorzugen Sie die Vorlagen und teilen Sie dem Benutzer mit, dass das Rezept veraltet aussieht.

Leerer Ordner (keine Rezepte, keine Vorlagen): Es gilt nur die untenstehende Handwerksbasis. Der Stil stammt aus der Referenz des Benutzers oder einer Frage, niemals aus einer fest codierten Voreinstellung.

3. Den Samen finden, dann erstellen

Ein Ordner enthält zwei Dinge, die nur manchmal übereinstimmen: die Referenz (wie etwas Gutes aussieht, das Referenzobjekt, an dem Sie messen) und den Samen (was Sie kopieren und bearbeiten, um das nächste Mitglied zu erstellen). Entscheiden Sie, welches Sie HALTEN, BEVOR Sie eine Zeile schreiben:

• eine Programmfamilie (ein freigegebenes Mitglied + eine DESIGN.md, die das Mechanismus und seine Achsen benennt): Samen = dieses Mitglied. Holen Sie seine Konfiguration und variieren Sie es entlang der Achsen, die das Rezept nennt. Erstellen Sie niemals aus einer leeren Datei und niemals nur die Farbtöne.
• eine Aufnahme-Spezifikation (ein Rezept, das sagt, wie jede Aufnahme in der Sammlung geschnitten wird): Samen = die NEUE Aufnahme, die der Benutzer Ihnen gibt (eine Aufnahme im Ordner nach ID, eine URL zu vos record --strict, eine lokale Datei). Die eigenen Aufnahmen des Ordners sind der Referenzschnitt, nicht der Samen.
• eine Vorlage (ein Rezept, das auf ein Mechanismus verweist oder es inline enthält, und wie es zu variieren ist): Samen = die Vorlage. Gehostet als vos: holen Sie sie wie ein Mitglied; Inline-Code: ein Fragment, um das herum gebaut wird.
• nur ein Briefing (BRAND.md: kein Mechanismus): nichts zu kopieren. Neu erstellen unter den Einschränkungen und der Handwerksbasis.
• nichts deklariert einen Samen: fragen Sie. Die Eingabe des Benutzers nennt einen, wenn er sie im Übergabedialog ausgewählt hat; die Rezepte nennen einen, wenn sie gut geschrieben sind; eine Vermutung ist, wie eine Familie ihr Aussehen verliert.

Ein Rezept kann optionale Frontmatter-Hinweise enthalten: applies: programs | takes | any, seed: <vos id> | input | none. Lesen Sie sie als Deklaration des Besitzers von Obigem; der Körper ist immer noch das, dem Sie folgen.

Ein Rezept ist das Dokument des Benutzers, und was er JETZT verlangt, hat Vorrang vor jeder Zeile darin. Wenn ein Rezept der Anfrage widerspricht (ein Hinweis, dass man warten soll, eine Regel, die die Anfrage bricht), sagen Sie das in einer Zeile und folgen Sie der Anfrage: private Arbeit ist billig und der Besitzer kann wiederherstellen. Halten Sie niemals an einer Zeile in einer Datei an.

Dann schreiben Sie Konfigurationen lokal (einfaches VosConfigJson, Version 2), nach den Autorenregeln des vos-authoring-Skills unter dem Stil des Ordners.

Das Abrufen eines Mitglieds oder einer Vorlage ist der vos-remix-Abruf: vos fetch https://vos.so/vos/<id> schreibt <slug>/config.json mit beibehaltenen Parametern, plus vos.json, das die Basisversion verfolgt.

Für "X reproduzieren"-Briefings: Holen Sie zuerst die Quelle oder eine Aufnahme, oder bestätigen Sie, dass das Briefing nur das Aussehen möchte. Ein Standbild unterbestimmt Bewegung; ein Screenshot-Match, das den falschen Mechanismus erfindet, ist ein Fehlschlag, selbst wenn der Frame übereinstimmt. Quellenbeschaffung, Lizenzierung und die gemessene Match-Schleife sind Reproduktionsarbeit; führen Sie diese zuerst durch, dann kehren Sie hierher zurück, um aus dem zu erstellen, was sie produziert hat.

4. Prüfen, schießen, bewerten, gegen die DOKUMENTE des ORDNERS

1. Prüfen:

   vos check <datei>.json     # migrieren → schema → syntax → kompilieren → lints
   

   Beheben und erneut ausführen, bis es besteht. Unterdrücken Sie niemals einen Lint-Fehler, um ihn zu umgehen. Zwei Prüfungen sind noch nicht in vos check enthalten, also führen Sie sie durch Rendern durch:
   • Regler-Ehrlichkeit: Jeder deklarierte Parameter muss sichtbar wirken. Rendern Sie das Programm zweimal mit diesem geänderten Schlüssel in data (seinem Minimum und seinem Maximum) und vergleichen Sie die Standbilder; ein Regler, der an beiden Enden gleich liest, ist tot. Für Aufnahmen ist --set <pfad>=<wert> bei vos frames/vos render die Überschreibung.
   • Paletten-Ehrlichkeit: Ein Farbregler darf nicht durch new THREE.Color() in ein Uniform hindurchgehen (er wird linearisiert; der gerenderte Farbton weicht vom Hex ab). Durchsuchen Sie Ihre Funktionsstrings danach.
2. Schießen:

   vos still <datei>.json f12.webp --time <12% der Dauer>
   vos still <datei>.json f40.webp --time <40%>
   vos still <datei>.json f70.webp --time <70%>
   

   Für ein BEWEGUNGSGEFÜHRTES Stück schießen Sie stattdessen einen dichten Streifen (8+ Mal oder ein 1s Kontaktbogen); drei Standbilder können die Bewegungsgewichtung nicht beurteilen.
3. Bewerten: Bewerten Sie die Frames gegen die untenstehende Handwerksbasis UND die eigenen Dokumente des Ordners. Ein Sammlungsstück antwortet auf sowohl das DESIGN.md der Sammlung als auch das geerbte TASTE.md. Überarbeiten und wiederholen (max. 3 Runden); wenn es immer noch fehlschlägt, verwerfen Sie es und sagen Sie warum. Verschieben Sie niemals Arbeit, die Sie nicht verteidigen würden.

5. IN den Ordner verschieben, als Versionen iterieren

vos push <datei>.json --title "…" --desc "eine Zeile" --tags a,b \
  --folder <ordnerId|slug> --label "was Sie getan haben" --note "warum: die Anfrage"

Übergeben Sie --label und --note bei JEDEM Push, auch beim ersten: ein Create stempelt sie auf v1, und die Historie ist das Gespräch, das der Mensch liest. Der Push erstellt ein PRIVATES vos im Regal des Schlüsselbesitzers, abgelegt in den Ordner, den Sie gezogen haben; Vorschau und Thumbnail-Rendering in der Cloud erfolgen beim Speichern selbst. Iterieren Sie mit --vos <id> gegen die verfolgte Basis (die vos-remix-Schleife: vos pull vor jeder Runde, von Menschen bearbeitete Knoten sind geschützt, --override nur auf ausdrückliche Anweisung). Schlüssel können niemals veröffentlichen; das Hochstufen ist eine Geste des Menschen auf vos.so.

Schauen Sie sich an, was gelandet ist. Jeder Push rendert innerhalb von ca. 15 Sekunden ein Standbild: GET /api/vos/{id}, folgen Sie contentUrls.thumbnail, und sehen Sie sich das Bild an, bevor Sie die Fertigstellung melden. Ein Push, den Sie nie angesehen haben, ist nicht abgeschlossen.

Tempo einer Batch: Aufeinanderfolgende Pushes sind beim Kontingent in Ordnung (die Render-Warteschlange verteilt Browser-Starts und bremst sich selbst). Überprüfen Sie den Zustand nach einer Batch mit einem Ordner-Pull, niemals durch Durchsuchen des Push-Protokolls.

Schreiben Sie Erkenntnisse zurück. Wenn Sie etwas über die Familie lernen (einen Parameterbereich, der streift, eine Dauer, die besser liest), hängen Sie es unter einer datierten Überschrift ## Agentennotizen an das entsprechende Rezept an: PUT /api/assets/{id}/file mit dem vollständigen Markdown-Körper (nur Rezepte, ≤64KB). Überschreiben Sie niemals die Regeln des Besitzers. Der ersetzte Körper wird aufbewahrt: GET /api/assets/{id}/file?prev=1 liest ihn und POST /api/assets/{id}/file/restore tauscht ihn zurück.

Der Familienprozess: Samen, schauen, verbreiten

Die Arbeit an einer neuen Familie ist 1 Samen + ein Rezept, niemals eine Batch. Eine Batch repliziert einen Fehler sofort in jedes Mitglied; ein einzelner Samen fängt eine Richtungsänderung bei n=1 ab und verbreitet sich dann günstig. Dies ist ein Urteil, kein Tor: Es gibt keine Statuszeile zum Schreiben oder Befolgen, und die Anfrage des Benutzers entscheidet immer.

1. Erstellen Sie EINEN Samen, legen Sie ihn im Ordner ab, schreiben (oder aktualisieren) Sie das DESIGN.md der Familie mit dem Mechanismus, den Achsen und den Palettenregeln.
2. Zeigen Sie ihn. Der Mensch iteriert mit Ihnen (attributierte Versionen). Wenn er nach Varianten fragt, IST dies die Freigabe; wenn ein Ordner ein junges Mitglied enthält und die Anfrage offen ist, erstellen Sie zuerst eines und sagen Sie warum.
3. Verbreiten Sie, wenn gefragt. Varianten variieren Kompositionsachsen (Struktur, Bewegungsgrammatik, Dichte, Kamera), niemals nur Farbtöne; eine reine Farbton-Verbreitung liest sich wie zehnmal dieselbe Kachel. Begrenzen Sie eine Verbreitung auf etwa 10, damit die Regalüberprüfung eine 5-Minuten-Aufgabe bleibt.

Handwerksbasis (universell, lintbar: die Latte, die NICHT Geschmack ist)

• Kompiliert und validiert: vos check läuft sauber; niemals unterdrücken.
• Deterministisch: Seek ist eine reine Funktion von t (kein Date.now oder Math.random in Framepfaden; der Determinsmus-Lint erzwingt dies).
• Schleifen-nahtlose Mathematik: Für Schleifenstücke müssen Phasen ganzzahlige Vielfache über die Dauer sein, sodass frame(0) ≈ frame(ende) ist. Standbilder können die Naht nicht zeigen; überprüfen Sie es in der Mathematik.
• Ehrliche Regler: 2 bis 4 deklarierte Parameter, jeder sichtbar an beiden Enden seines Bereichs wirkend. Weniger ehrliche Regler schlagen viele.
• Regler werden in onFrame gelesen, bei jedem Frame, niemals während createContent in Uniformen geschnappschossen. Der Editor liefert eine Reglerbearbeitung als Live-Daten, die nur ctx.data austauscht; ein Erstellungszeitpunkt-Schnappschuss aktualisiert nie bis zum Neuladen.
• Nicht-leerer erster Frame: Der ~12%-Frame dient auch als Thumbnail; keine schwarzen, leeren oder "hat noch nicht begonnen"-Öffnungen.
• Kein Banding, kein Clipping: Korn gegen Banding hinzufügen; Bloom von Ausblendungen fernhalten (Stärke ≤ ~0,8, es sei denn, die Ordnerdokumente verlangen es); keine sichtbaren Kachelungsnähte oder harten Alias-Effekte.
• Paletten-Ehrlichkeit: Farbregler niemals durch new THREE.Color() in Uniforme hindurchführen; den rohen Vektor aus dem Hex erstellen.
• Server-Render-Einschränkungen (die Vorschauflotte ist Software-GL): kein THREE.DoubleSide bei Transmissionsmaterialien, keine dispersion, jedes abgerufene Asset eine absolute https-URL, die die Flotte erreichen kann.

Alles jenseits dieser Zeile (Dauer, Dichte, Stimmung, Materialien, Palette-Disziplin) ist Sache des Ordners.

Bericht

Beenden Sie mit einer Tabelle: Slug · Konzept · Tags · Ergebnis (gepusht / verworfen + warum), plus die Ordner-URL (https://vos.so/app/projects?folder=<slug>). Geben Sie Fehlschläge klar an: Ein verworfener Entwurf ist ein korrektes Ergebnis, kein Fehler, der versteckt werden muss.

Harte Regeln

• Referenzen sind kreative Richtung. Das Portieren von externem Code benötigt eine kompatible Lizenz UND die ausdrückliche Anweisung des Benutzers; markenrechtlich geschützte oder markenrechtlich geschützte Kompositionen werden abgelehnt.
• Niemals veröffentlichen, niemals Sichtbarkeit umschalten. Pushes sind von Natur aus privat; Hochstufung ist eine menschliche Entscheidung auf vos.so.
• Das Regal gehört dem Menschen: Erstellen Sie Ordner und legen Sie IHRE Arbeit ab; benennen Sie niemals um, verschieben Sie nicht, löschen oder ordnen Sie nicht um, was sie gemacht haben.
• Niemals eine Anmeldeinformation ausgeben, weder in Ausgaben, Protokollen noch im Bericht.