ToshqulovLaziz/naqsh

Was macht naqsh?

v0.6. <skill> bezeichnet unten das Basisverzeichnis dieses Skills. Skripte benötigen Node ≥ 22 und einen lokalen Chrome/Edge; nichts zu installieren.

1. Route

Gib vor allem anderen in einer Zeile die Oberfläche und den Modus an.

Oberfläche	Signale	Lesen
page	Landing, Portfolio, Marketing, Produkt, One-Pager	references/page.md
app	ERP, Admin, Dashboard, Tabelle, Formular, Einstellungen, CRUD	references/app.md

Modus	Berührt Code?	Ausgabe
build	ja, neue UI	UI + DESIGN.md
redesign	ja; Verhalten, Daten und Text bleiben erhalten	UI + DESIGN.md
audit	nein	sortierte Ergebnisse mit file:line und Fix

Lies immer references/rules.md, bevor du Prüfungen ausführst. Falls niemand Fragen beantworten kann, entscheide selbst und dokumentiere warum.

2. Kontext

• Stack, Styling, vorhandene Tokens, Schriftarten und wie sie geladen werden, Theme-Umschaltung (+ ihr localStorage-Key), i18n (+ Locale-Key), Routen, Build-Befehl.
• Was sich ändern darf und was nicht (andere Seiten, gemeinsame Komponenten, Geschäftslogik).
• Locales: Wenn eine davon Kyrillisch verwendet, muss jede gewählte Schriftart es abdecken.

3. Baseline

Führe beide Prüfungen auf dem aktuellen Zustand aus und behalte die Ausgabe: Sie ist das „Vorher“ des Reports und zeigt oft echte Bugs (Schriftarten werden nie geladen, Kontrast, Überlauf).

node <skill>/scripts/lint.mjs <projectRoot>
node <skill>/scripts/inspect.mjs http://localhost:PORT --surface <surface> --routes ... --locales ... --themes ...

audit-Modus: Folge ab hier references/audit.md und stoppe. Bearbeite keine Projektdateien.

4. Inventar

• Gegenstand: 8–12 Dinge, die nur dieses Produkt oder diese Person hat (Namen, Orte, echte Zahlen, echte Arbeit).
• Material: Markiere für jeden visuellen Slot real, picture (ehrlich beschaffbar) oder absent. Erfinde niemals Belege: keine gefälschten Logos, Testimonials, Metriken oder Screenshots.
• Zielgruppe und Aufgabe: Wer schaut, was sie tun oder zuerst lernen müssen.

5. Richtung (austeilend, geschmacksgesteuert)

node <skill>/scripts/deal.mjs --surface <page|app> --options 3 --project <projectRoot>

Das Skript bewertet die Bibliothek anhand des Geschmacksprofils des Benutzers (~/.naqsh/taste.json, pro Projekt überschreibbar in <project>/.naqsh/taste.json) und aktueller Auswahlen und teilt 3 Richtungen aus verschiedenen Familien zu.

• Wenn der Benutzer anwesend ist, zeige die drei (Idee, Typografie, Palette, Hero) und lass ihn wählen. Wähle andernfalls die beste Passung für den Inhalt und begründe warum.
• deal.mjs --pick <id> gibt das vollständige Blatt aus (Sektionen, Bewegung, Schriftarten-Import, Hell/Dunkel-Tokens) und protokolliert die Auswahl. Baue vom Blatt aus: Sein Typ, seine Palette und sein Hero sind der Vertrag. Passe Größen und Sektionen an den echten Inhalt an; weiche nur mit einer schriftlichen Begründung ab (z. B. fehlendes Material).
• page: Lies auch references/page.md. app: Lies auch references/app.md; der system-Block des Blatts bestimmt Shell, Dichte, KPI, Tabelle, Status- und Diagrammstil.

Brief vs. Geschmack. Adjektive in einem Brief („ruhig“, „minimal“, „professionell“) beschreiben die Aufgabe, nicht das Aussehen. Erfülle sie durch Klarheit, Dichte und Zurückhaltung in der Bewegung, nicht indem du eine Richtung wählst, die das Geschmacksprofil vermeidet. Verwerfe niemals eine Richtung nur, weil sie kühner ist als das Adjektiv des Briefs; wenn Brief und Geschmack wirklich in Konflikt geraten, wähle für den Geschmack und vermerke es in DESIGN.md.

Geschmacks-Feedback. Wenn der Benutzer sagt, was ihm an einem Ergebnis gefällt oder nicht gefällt, aktualisiere ~/.naqsh/taste.json (boldness 1–5, temperature warm|cool|neutral|any, typeStyles, likes, avoid, notes) und teile es ihm mit. Präferenzen, die nur für eine Oberfläche gelten, kommen in den entsprechenden page- oder app-Block, der die allgemeinen Schlüssel überschreibt.

6. Basisregeln (niemals aufgehoben; Skripte prüfen die meisten)

• Sichtbarer Text aus i18n in jedem Locale; kein erfundener Text.
• Schriftarten laden und decken jedes Locale-Skript ab; das längste Locale passt bei 375 px.
• Schriftart @import oberhalb von @import "tailwindcss"; Element-Stile innerhalb von @layer base.
• Kein horizontales Seiten-Scrolling; overflow-x: clip, niemals hidden/100vw.
• Kontrast ≥ 4,5:1 (3:1 groß) in jedem Theme; Fokus sichtbar; Ziele ≥ 24 px (44 empfohlen).
• prefers-reduced-motion respektiert; kein transition: all; animiere transform/opacity.
• Neue Tokens so eingegrenzt, dass unberührte Seiten sich nicht ändern.

7. KI-generierte UI-Anzeichen (Reflex: nur aufheben, wenn das ausgeteilte Blatt es erlaubt)

Standard-Tailwind-Indigo/Violett; Leuchteffekte, Glas, Aurora-Blobs, orbitierende Icons, Schimmer-Buttons, verlaufender Text; durchgehend großgeschriebene „Eyebrow“-Texte über jeder Überschrift; identische abgerundete+schattierte Kartenraster; ein Hero-Band mit runden Metriken; der gleiche Name oder Titel, der in einem Bildschirm wiederholt wird. Kühne Skalierung, starke Farbe und Serif/Sans-Kontrast sind keine Anzeichen – auch Zaghaftigkeit ist ein Fehler: Wenn das Ergebnis als Vorlage durchgehen könnte, pushe die Idee des Blatts stärker.

8. Build-Schleife

1. Tokens (eingegrenzt) → Hauptbildschirm / Hero → der Rest.
2. Nach jedem Schritt: lint. Nach dem Hauptbildschirm: Bau, Vorschau, inspect nur auf dieser Route (breiteste + schmalste Breite, erstes Locale, beide Themes). Zum Schluss: die vollständige Matrix. Öffne die Screenshots und schau sie dir jedes Mal an. Korrigiere, wiederhole – maximal 3 Durchgänge nach dem ersten vollständigen Durchlauf. Lies nur die Dateien, die du änderst; halte die Runden kurz.
3. Detail-Durchgang: Lies references/components.md; jedes Steuerelement ist danach gebaut (kein native-control ohne Aufhebung). Führe inspect ... --details aus und öffne jeden Ausschnitt in <out>/details/; korrigiere, bis jeder bei 2x absichtlich aussieht.
4. Wenn der Detail-Durchgang abgeschlossen ist und der Build bei 0 Basisregel-FAIL steht, schreibe DESIGN.md (Entwurf) und starte den Reviewer in einem frischen Kontext – Agent-Tool, subagent_type: "naqsh:naqsh-reviewer" – mit: Projekt-Root, Oberfläche, Modus, Richtungs-ID, <skill>-Pfad, Screenshot-Ordner (mit details/), Vorschau-URL und den Inspect-Flags. Wende dessen floor-, idea- und fidelity-Korrekturen an (andere nach eigenem Ermessen), führe die Prüfungen erneut aus. Eine Review-Runde; eine zweite nur, wenn das Urteil rework war. Falls kein Agent-Tool verfügbar ist, führe die Überprüfung selbst mit agents/naqsh-reviewer.md durch, nachdem du die Screenshots erneut gelesen hast.
5. Beende mit 0 Basisregel-FAIL, jedem Reflex korrigiert oder aufgehoben, und dem Build des Projekts, der bestanden wird. Stoppe den Vorschau-Server.

9. Bericht

Schreibe DESIGN.md im Projekt-Root (oder wo der Benutzer es angibt): ausgeteilte Optionen und die Auswahl, Idee-Satz, Tokens, Typografie, wichtige Entscheidungen, der Signatur-Moment, Vorher → Nachher-Prüfungszahlen, Aufhebungen mit Gründen, beurteilte Prüfungen, offene Punkte. Beende mit der Frage, was dem Benutzer gefällt und was nicht, damit sich das Geschmacksprofil verbessert.