Communitygithub.com

prajwalacharyaa/mochi-redesign

Nehmen Sie eine schlichte, schlampige oder 'KI-Vorlagen'-Website (Portfolio, persönliche Seite, Landingpage, kleine Produktseite) und gestalten Sie sie gemeinsam mit dem Besitzer Schritt für Schritt neu – zu einer klaren, auffälligen, durchdachten und responsiven Seite mit eigener Identität.

Was ist mochi-redesign?

Dieses Skill führt einen geführten Redesign-Workflow aus, der kein festes Aussehen aufsetzt, sondern einen festen Prozess vorgibt: die Person hinter der Website verstehen, ein Konzept finden, ein kleines Designsystem aufbauen, alle wichtigen Inhalte auf dem ersten Bildschirm als Karten anordnen, Details in reichhaltige Popups und eigene Seiten auslagern, ehrliche Texte schreiben und jede Änderung vor der Präsentation auf echten Bildschirmgrößen überprüfen. Der Workflow wurde aus einem echten Portfolio destilliert, das von einer schlichten einspaltigen Vorlage zu einer Bento-ähnlichen Seite über mehrere Feedback-Runden mit dem Besitzer wurde. Das Skill ist plattformunabhängig und kann mit jedem Agentenframework (Claude, Cursor, Codex) ausgeführt werden. Es arbeitet phasenweise mit klaren Toren (Gates) am Ende jeder Phase: Der Besitzer muss Screenshots sehen und zustimmen, bevor es weitergeht. Nicht verhandelbare Regeln sind u. a.  ehrliche Texte, Sichtbarkeit aller wichtigen Inhalte auf dem ersten Bildschirm ohne Scrollen, Überprüfung auf tatsächlichen Bildschirmgrößen statt im Kopf, kleine reversible Schritte und Barrierefreiheit als Minimum. Die Dateien `references/` enthalten detaillierte Anleitungen für jede Phase sowie eine Liste der Anti-Patterns aus der ersten Umsetzung.

Funktioniert mit✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/prajwalacharyaa/mochi-redesign/tree/HEAD
Original anzeigen→Alle Skills durchsuchen

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Dokumentation

/mochi-redesign

Ein geführter Redesign-Workflow. Er wendet kein festes Aussehen an. Er wendet einen festen Prozess an: die Person verstehen, ein Konzept finden, ein kleines Designsystem aufbauen, alles Wichtige auf dem ersten Bildschirm als Karten darstellen, Details in reichhaltige Popups und eigene Seiten auslagern, ehrliche Texte schreiben und jede Änderung auf echten Bildschirmgrößen prüfen, bevor sie gezeigt wird.

Der Workflow wurde aus einem echten Portfolio destilliert, das von einer schlichten einspaltigen Vorlage über viele Feedback-Runden des Besitzers zu einer Bento-ähnlichen Seite wurde. Die Lehren aus diesen Runden (was funktioniert hat, was abgelehnt wurde, was kaputt ging) sind unten und in references/ codiert.

Das Ergebnis darf niemals so aussehen wie die Seite, von der dieses Skill abstammt. Gleiche Disziplin, andere Identität: neues Konzept, neue Schriften, neue Farben, neues charakteristisches Detail. Wenn Sie sich dabei erwischen, zu einem Ringelblumen-Pinselstrich, einem Maskottchen oder einem Bento-Raster zu greifen, nur „weil das Skill das so macht“, halten Sie an und gehen Sie zurück zu Phase 1.

So führen Sie es aus

Argumente sind optionaler Freitext, z. B. /mochi-redesign client/ oder /mochi-redesign nur die Startseite, den Blog unverändert lassen.

Arbeiten Sie die Phasen in der angegebenen Reihenfolge durch. Jede Phase endet mit einem Tor: Zeigen Sie dem Besitzer das Ergebnis (Screenshots, keine Beschreibungen) und warten Sie auf seine Reaktion, bevor Sie fortfahren. Redesigns scheitern, wenn mehrere ungeprüfte Entscheidungen aufeinander türmen.

PhaseZuerst lesenTor
0. Aufnahme und Auditreferences/01-intake-audit.mdBesitzer bestätigt Ziele, Zielgruppe, Umfang, was unverändert bleiben muss
1. Konzept und Systemreferences/02-concept-system.mdBesitzer wählt eine Richtung aus; Tokens werden notiert
2. Wahrheit im Inhaltreferences/03-content.mdBesitzer stimmt Behauptungen zu (keine Übertreibungen)
3. Erster Bildschirmreferences/04-layout.mdPasst auf einen Laptop-Bildschirm bei jeder Zielgröße
4. Detailebenereferences/05-interaction.mdPopups scrollen innen, blockieren die Seite, kein Layout-Shift
5. Sekundärseitenreferences/06-content-pages.mdListen- und Leseseiten passen zum System
6. Medien (optional)references/07-media.mdEchte Walkthroughs, komprimiert, spielen nur im Viewport ab
7. Polieren und QAreferences/08-qa.mdClip-Check bestanden, beide Themes, mobil, Lint, Build
8. Übergabereferences/09-feedback-and-handoff.mdSauberer Diff, Design-Dokument aktualisiert, Besitzer entscheidet über Commit

references/10-anti-patterns.md ist die Liste der Fehler, die beim ersten Mal gemacht wurden. Lesen Sie sie einmal vor Phase 1 und noch einmal vor Phase 7.

Nicht verhandelbare Regeln

  1. Hinsehen, bevor Sie ändern. Lesen Sie den vorhandenen Code, führen Sie die Seite aus, machen Sie Screenshots in den Zielgrößen. Niemals nur vom Code aus redesignen.
  2. Eine Identität pro Seite. Das Konzept kommt vom Subjekt (was die Person oder das Produkt tatsächlich ist), nicht von einem Trend oder vom Ursprung dieses Skills.
  3. Alles Wichtige auf dem ersten Bildschirm. Besucher sollten sehen, wer, was und Belege (beste Arbeiten) ohne zu scrollen. Details sind einen Klick entfernt, nicht fünf Bildschirme weiter unten.
  4. Ehrliche Texte. Keine Behauptung, hinter der der Besitzer nicht in einem Vorstellungsgespräch stehen kann. Bevorzugen Sie „geübt“, „habe getan“, „wo es passt“ statt „jede/r/s“, „immer“, „alle“. Zeigen Sie Belege (Zahlen, veröffentlichte Dinge) statt Adjektive.
  5. Auf Größen prüfen, nicht im Kopf. Jede visuelle Änderung wird vom Clip-Check (scripts/clip-check.mjs) und mindestens einem Screenshot begleitet. Melden Sie niemals „erledigt“ für eine Änderung, die Sie nicht angesehen haben.
  6. Kleine, umkehrbare Schritte. Ändern Sie eine Sache, zeigen Sie sie, hören Sie zu. Lehnt der Besitzer etwas zweimal ab, hören Sie auf zu raten: bieten Sie 2–3 konkrete Optionen mit Vorschauen an und lassen Sie ihn wählen. Bittet er um Rückgängigmachung, stellen Sie exakt die vorherige Version wieder her, keinen „ungefähr passenden“ Neubau.
  7. Zerstören Sie nicht, was live ist. Behalten Sie alte Routen bei, berühren Sie keine irrelevanten Seiten, formatieren Sie keine Dateien neu, die Sie nicht ändern mussten (Formatierungsrauschen versteckt den echten Diff), committen oder pushen Sie nicht ungefragt.
  8. Barrierefreiheits-Minimum. Per Tastatur erreichbar, sichtbarer Fokus, echte Buttons und Links, prefers-reduced-motion respektiert, Kontrast in beiden Themes geprüft, nichts Wichtiges wird nur durch Hover vermittelt.

Wie „fertig“ aussieht

  • Ein erster Bildschirm, der auf einen Laptop (1280×720 bis 1920×1080) passt, mit keinem abgeschnittenen Inhalt, keinem horizontalen Scrollen und einem klaren Blickfang.
  • Ein kleines, schriftliches Designsystem (Tokens, Typographie, Radien, Bewegungsregeln), das jede neue Komponente verwendet.
  • Karten, die reichhaltige Details öffnen (Dialoge oder Seiten) statt langem Scrollen.
  • Texte, die der Besitzer Zeile für Zeile abgesegnet hat.
  • Sekundärseiten (Listen, Leseseiten, Fallstudien), die sich wie die gleiche Seite anfühlen.
  • Ein Design-Dokument im Repository (DESIGN.md oder ähnlich), das das System und die Entscheidungen beschreibt, damit die nächste Person (oder der nächste Agent) die Konsistenz bewahrt.

Dateien in diesem Skill

SKILL.md                         diese Datei: Workflow, Tore, Regeln
references/01-intake-audit.md    Fragen, die zu stellen sind; wie man die aktuelle Seite auditet
references/02-concept-system.md  Ein Konzept finden; Tokens, Typographie, charakteristisches Detail
references/03-content.md         Wahrheitsgetreue, scanbare, hervorgehobene Texte schreiben
references/04-layout.md          Bento-Layout für den ersten Bildschirm und Kartenrezepte
references/05-interaction.md     Dialoge, Hover, Bewegung, kleine Freuden
references/06-content-pages.md   Blog-/Listen-/Leserseiten, die die Leute weiterlesen lassen
references/07-media.md           Walkthroughs und Trailer von echter Arbeit aufnehmen
references/08-qa.md              Viewport-Matrix, Clip-Check, Themes, Barrierefreiheit
references/09-feedback-and-handoff.md  Mit dem Besitzer iterieren; sauber abschließen
references/10-anti-patterns.md   Was beim ersten Mal schiefging, und die Lösung
scripts/clip-check.mjs           CDP-Skript: abgeschnittene Karten, Überlauf, Falzanpassung
scripts/shots.mjs                CDP-Skript: Screenshots pro Viewport und Theme
templates/                       Framework-unabhängige Snippets (React + Tailwind)

Verwandte Skills

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community