Prompted Guide for Experience Modernization Agent prompting-guide

Migratie volgt een workflow in zeven stappen:

1. De agent schrapt bronpagina.
2. Het identificeert sectiestructuur.
3. Het voert ontwerpanalyse uit.
4. De inhoud wordt toegewezen aan blokvarianten.
5. Er wordt een markeringseffect gegenereerd.
6. Er wordt importinfrastructuur gemaakt.
7. Het geeft een voorvertoning van het resultaat.

De agent analyseert pagina's gebruikend een hiërarchie op twee niveaus:

• Eerst worden de sectiegrenzen geïdentificeerd (wijzigingen in de achtergrond, verschuivingen in de tussenruimte)
• Vervolgens worden de inhoudsreeksen binnen elke sectie geïdentificeerd.

De auteursanalyse volgt ​ Model van David.

• voor elke inhoudsequentie controleert het eerst "Kan een auteur dit door normaal typen tot stand brengen?"
• De standaardinhoud (koppen, alinea's, lijsten, inline-afbeeldingen) heeft de voorkeur boven blokken.

De agent probeert bestaande blokken uit de blokbibliotheek van de repository opnieuw te gebruiken voordat er nieuwe worden gemaakt.

• Wanneer inhoud niet aan een bestaand blok kan worden toegewezen, leidt het tot nieuwe blokvarianten.
• U kunt vragen om wijzigingen, nieuwe varianten aanvragen of toewijzingen interactief aanpassen.

Blokelementen worden bijgehouden met metagegevens.

• Wanneer het migreren van veelvoudige pagina's, laadt de agent eerst bestaande douanevarianten en hergebruikt hen wanneer het stileren gelijken (70% gelijkenisdrempel die op doel, kleuren, typografie, het uit elkaar plaatsen, lay-out wordt gebaseerd).

Koptekst, navigatie en voettekst zijn uitgesloten van paginamigratie. Deze worden behandeld door specifieke vaardigheden.

Elke migratie maakt importinfrastructuur (paginasjablonen, blokparsers, transformatoren) voor toekomstige bulkimport.

• Dit zijn paginasjablonen (sectiestructuur), transformatoren (DOM-opruiming voor de hele site) en parsers (blokspecifieke HTML naar tabelconversie).

• Sjablonen worden niet helemaal opnieuw afgeleid.

• Het mengen van sjablonen in één uitvoering wordt niet ondersteund.

Deze herinnering wordt gewoonlijk automatisch aangehaald als eerste stap van paginamigratie.

Inhoud die via CSS is verborgen, wordt ook vastgelegd als deze aanwezig is in het DOM.

Lazy geladen afbeeldingen en door de client gegenereerde inhoud worden verwerkt door in Chromium zonder kop door de pagina te schuiven en scripts te laten uitvoeren.

WebP-/AVIF-/SVG-afbeeldingen worden voor compatibiliteit omgezet in PNG.

Metagegevens worden geëxtraheerd, zoals titel, beschrijving, Open Graph-tags, JSON-LD gestructureerde gegevens, canonieke URL.

Afbeeldingen in DOM zijn hersteld.

• background-image wordt omgezet in img.
• Afbeeldingselementen worden losgekoppeld
• srcset is omgezet in src
• Relatieve URL's worden omgezet in absolute waarden
• Inline SVG die wordt omgezet in img-bestanden.

Geanimeerde documentpaden worden gegenereerd (kleine letters zonder .html extensie).

De volgende outputs worden geproduceerd:

• screenshot.png
• cleaned.html (geen scripts/stijlen)
• metadata.json
• images/ -map met lokale kopieën

Gebruikers kunnen vragen naar schermafbeeldingsafmetingen en specifieke apparaatformaten (mobiel, bureaublad) aanvragen voor het extraheren van inhoud.

Door inhoud op meerdere onderbrekingspunten te extraheren neemt de verwerkingstijd toe.

Ontwerpmigratie heeft twee fasen:

1. Fase 1 (voor de hele site) extraheert het volgende naar styles/styles.css :

   • Globaal kleurenpalet en accentkleuren
   • Typografiesysteem (lettertypen, grootten, gewichten)
   • Tussenruimte (opvulling, marges, tussenruimten)
   • Sectieachtergronden (licht, donker, gekleurd)
   • Stijlen van basiscomponenten (knoppen, koppelingen, afbeeldingen)
   • Uitvoer naar

2. Fase 2 migreert afzonderlijke blokstijlen en maakt blokspecifieke CSS in /blocks/{name}/{name}.css .

Voor blokopmaak (fase 2) moet het ontwerp voor de hele site (fase 1) eerst worden voltooid.

• Het algemene ontwerpsysteem biedt aangepaste CSS-eigenschappen die referentie blokkeren.

Geschatte tijd:

• Fase 1: 5-10 minuten
• Fase 2: 10-15 minuten

De dubbelzinnige verzoeken standaard om migratie te voltooien (beide fasen).

Blokkritiek vergelijkt een gemigreerd blok met zijn oorspronkelijke bron en past herhaaldelijk CSS-correcties toe totdat een visuele gelijkenis van 85% is bereikt of drie herhalingen zijn voltooid.

De vaardigheid vereist dat het blok eerst door paginamigratie is gecreeerd.

Een blokkritiek volgt een zes-stap werkschema:

1. Het oorspronkelijke blok van de bronpagina wordt vastgelegd met een XPath-kiezer.
2. De kritische sessie wordt geïnitialiseerd.
3. Het originele blok wordt geïnspecteerd (screenshots, stijlen, HTML).
4. Het inspecteert het gemigreerde blok.
5. Hiermee worden elementen vergeleken en wordt een score voor gelijkenis gegenereerd met CSS-correcties.
6. Het past fixes toe en herinspecteert tot het doel van 85% wordt bereikt.

Elke herhaling toont een volledig kritiek rapport met alle verschillen, past alle CSS moeilijke situaties (die door visueel effect worden voorrang gegeven) toe, verifieert in voorproef, herinspecteert, en toont verbeteringsmetriek.

Gebruik de blokkritiek nadat ​ ontwerpmigratie ​ volledig is.

Paginacritique voert een visuele vergelijking van volledige pagina uit tussen het origineel en de gemigreerde pagina, die zich herhaalt totdat een 85% gelijkenisdoel is bereikt of drie herhalingen zijn voltooid.

Een paginacritique heeft een workflow in vijf stappen:

1. Er wordt een kritische sessie geïnitialiseerd.
2. Alle elementen op de oorspronkelijke pagina worden gecontroleerd.
3. Alle elementen op de gemigreerde pagina worden gecontroleerd.
4. De methode vergelijkt en genereert een score voor gelijkenis met geprioriteerde CSS-oplossingen.
5. Het past fixes toe en herinspecteert tot het doel van 85% wordt bereikt.

Voor een paginacritique zijn de URL van de bronpagina en het gemigreerde pad (bijvoorbeeld "/about") vereist als invoer.

Gebruik paginacritique bij het valideren van de algehele paginafrouwbaarheid of bij het gelijktijdig valideren van meerdere blokken.

​ blokkritiek van het Gebruik ​ voor geconcentreerde bevestiging op specifieke componenten.

De volgende workflow wordt aanbevolen:

1. Een pagina migreren.
2. Pas een ontwerp toe.
3. Blokkritiek uitvoeren op sleutelblokken
4. Voer paginacritique uit voor volledige validatie.

Deze vaardigheid migreert één blok tegelijkertijd, niet volledige pagina's of volledige dossiers van Figma.

Voor de beste resultaten:

• Selecteer het specifieke blok dat u wilt migreren in Figma en kopieer de koppeling (met node-id ) of naam.
• Geef de parameter node-id op in de URL om het exacte blok als doel in te stellen.

Wanneer u deze vaardigheid in werking stelt, worden de volgende stappen automatisch uitgevoerd in het ontvangen milieu:

1. de structuurontdekking van het Blok - de agent leest de knoop van Figma om lagen en componenten te begrijpen.
2. Globale stijlextractie - de agent trekt kleuren, typografie, en het uit elkaar plaatsen in styles/styles.css als CSS douaneeigenschappen (ontwerptekenen).
3. blokspecifieke stijlverwezenlijking - de agent leidt extra CSS douaneeigenschappen specifiek voor het blok dat wordt gemigreerd.
4. Toewijzing aan bestaande blokken — De agent identificeert het dichtste passende blok in de het blokbibliotheek van uw project en leidt tot een douanevariant.
5. CSS generatie — De agent schrijft stijlen die naar de gehaalde CSS douaneeigenschappen van verwijzingen voorzien, die ontwerpconsistentie verzekeren.
6. download van Activa — De agent bewaart beelden en pictogrammen van Cijfer aan de ontvangen werkruimte van het milieu.
7. de inhoudsgeneratie van Edge Delivery Services — De agent leidt tot het markeringsdossier na het blokstructuur EDS
8. bevestiging van de Output - de agent previews het resultaat en voert visuele vergelijking tegen het originele ontwerp van Figma uit.

De vaardigheid leest eerst meta-gegevens (stap 1) om structuur te begrijpen, en haalt dan gedetailleerde ontwerpcontext (stappen 2-5) uit.

• Deze gefaseerde aanpak voorkomt problemen met grote of complexe figuurbestanden.

Deze vaardigheid neemt een stijl-eerste benadering.

• Alle stijlen worden geëxtraheerd als aangepaste CSS-eigenschappen (ontwerptokens) voordat er CSS wordt geschreven.
• Hierdoor blijft het gemigreerde blok consistent met uw ontwerpsysteem.

Voor de vraag is de figma-URL (met fileKey en optioneel node-id ) of een figuurbestandssleutel rechtstreeks als invoer vereist.

Edge Delivery Services-navigatie dwingt een structuur met drie secties af (afgedwongen door header.js):

1. Merk (sectie 1): Logo en primaire branding verbinding
2. Secties (sectie 2): Het belangrijkste navigatiemenu met facultatieve dalingen
3. Hulpmiddelen (sectie 3): De verbindingen van het nut (subscribe, login, kar)

Navigatie-inhoud woont in nav.md in de hoofdmap.

Secties worden gescheiden door markeringen (---).

Vette items (**Text**) met geneste lijsten maken vervolgkeuzelijsten.

Koppelingen in navigatie kunnen als knoppen worden weergegeven vanwege het gedrag van Document Authoring in automatische omloop.

• Het headerblok bevat code om knopklassen van navigatiekoppelingen te verwijderen.

De agent volgt Content-Driven Development (CDD), een verplicht proces voor alle Edge Delivery Services-ontwikkeling.

• Er wordt gevraagd naar inhoudsmodellen en de inhoud wordt getest voordat code wordt geschreven.

De CDD-filosofie is dat de auteur behoefte heeft voordat ontwikkelaars iets nodig hebben.

• Inhoudsmodellen moeten intuïtief zijn voor auteurs, ook al betekent dit complexere versiecode.

Eerst wordt testinhoud gemaakt:

• Directe testmogelijkheden
• PR-validatiekoppelingen voor PSI-controles
• Levende documentatie voor auteurs
• Detectie van randgevallen waarbij code-first-benaderingen ontbreken

De agent zal naar gelijkaardige blokken in de ​ Inzameling van het Blok ​ zoeken en ​ Partij van het Blok ​ alvorens uit te voeren, om patronen en herbruikbare code te vinden.

Sla CDD alleen over voor triviale CSS-alleen-tweaks (maar identificeer nog steeds testinhoud voor validatie).

Edge Delivery Services heeft vier canonieke modeltypen:

• Zelfstandig: Afzonderlijke visuele/narratieve elementen (held, blockquote)
  • Eén tabel met blokinhoud
• Inzameling: Herhalende semi-gestructureerde inhoud (kaarten, carrousel)
  • Tabel met patroon van herhalende rijen
• Configuratie: API-gedreven of dynamische inhoud waar de config controles tonen (bloglijst, onderzoeksresultaten)
  • Lijst met sleutel-waarde config rijen.
• auto-Geblokkeerd: Complexe structuren die de auteurs als secties/standaardinhoud tot stand brengen, dan getransformeerd worden (lusjes, sluit YouTube in)

Er geldt een limiet van vier cellen per rij.

• Groepeer verwante elementen in cellen.

Voorkeur voor blokvarianten boven configuratiecellen voor opmaakverschillen.

​ volg de Wet van Postel ​: ben flexibel over inputstructuur.

• Een hoofdblok moet werken of de inhoud zich in één cel bevindt, over twee cellen wordt gesplitst of in afzonderlijke rijen.

Deze vaardigheid wordt gewoonlijk aangehaald automatisch door inhoud-gedreven Ontwikkeling tijdens blokverwezenlijking.

De ​ Inzameling van het Blok ​ is Adobe-gehandhaafd en voor beste praktijken, uitstekende inhoud modellering, hoge prestaties, en toegankelijkheid gecontroleerd.

• Het is beperkt tot blokken die vaak nodig zijn. Begin hier.

De ​ Partij van het Blok ​ is gemeenschap-gedreven en biedt een bredere verscheidenheid met inbegrip van experimentele benaderingen aan.

• Het omvat ook secundaire plug-ins, buildtools (webpack, vite, sass) en integratie.
• Gebruik wanneer de Inzameling van het Blok niet heeft wat u nodig hebt.

Denk na over alternatieve namen wanneer het zoeken

• Veelgestelde vragen = accordeon
• Galerie = carrousel/presentatie
• Navigation = menu/header

De Partij van het Blok keert slechts goedgekeurde/gekromde ingangen terug.

Het testen volgt een "waarde vs. kosten"filosofie waar u tests creeert en handhaaft wanneer hun waarde kosten overschrijdt.

• de tests van de Houder (eenheidstests) zijn voor logica-zware nut, gegevensverwerking, API integratie. Deze zijn snel, gemakkelijk te handhaven, en vangst regressies in hergebruikte code.
• de tests van de Throwaway (browser tests) zijn voor de transformaties van DOM en visuele bevestiging. Gebruik om implementatie te valideren, schermafbeeldingen vast te leggen voor PR-revisie en vervolgens te verwijderen.

De wegtests gaan in test/tmp/ en testen de inhoud in drafts/tmp/ (beide opgegeven).

Controleer voordat u een PR opent of:

• Bestaande tests geslaagd
• De tests van de eenheid worden geschreven voor nieuwe logica
• Browservalidatie is voltooid
• Alle varianten worden getest
• Responsief gedrag wordt geverifieerd
• Linkerpassingen

Vaak voorkomende problemen zijn bekende patronen:

• Beelden die "over :error tonen: Gewoonlijk ontbrekende createOptimizedPicture vraag in blok JS, of geroepen vóór DOM het herstructureren
• Blokken niet teruggevend: Het formaat van de bloknaam van de controle in prijsdaling en verifieert dat het blok zowel .js als .css dossiers in blocks/ heeft.
• CSS die niet laadt: De dossierwegen van de controle, verifieert CSS dossier bestaat, en controleert het lusje van het Netwerk in browser.
• Veranderingen verschijnen niet: De synchronisatie van de code neemt 3-5 seconden. Vernieuw de tekst op papier (Ctrl+Shift+R).

De agent controleert systematisch elke laag:

1. Source-bestanden
2. Gerenderde uitvoer
3. Blokcode
4. Browserconsole

De agent kan lokale voorvertoningen bij http://localhost:3000 controleren.