Frågeguiden för Experience Modernization Agent prompting-guide

Migreringen följer ett arbetsflöde i sju steg:

1. Agenten klipper ut källsidan.
2. Det identifierar avsnittsstrukturen.
3. Den utför redigeringsanalyser.
4. Innehållet mappas till blockvarianter.
5. Den genererar kod.
6. Det skapar importinfrastruktur.
7. Resultatet förhandsgranskas.

Agenten analyserar sidor med hjälp av en hierarki på två nivåer:

• Först identifieras avsnittsgränser (bakgrundsändringar, mellanrumsskift)
• Sedan identifieras innehållssekvenser i varje avsnitt.

Redigeringsanalysen följer David's Model.

• för varje innehållssekvens kontrolleras först"Kan en författare skapa detta med vanlig typning?"
• Standardinnehåll (rubriker, stycken, listor, textbundna bilder) är att föredra framför block.

Agenten försöker återanvända befintliga block från databasens blockbibliotek innan nya skapas.

• När innehåll inte kan mappas till ett befintligt block skapas nya blockvarianter.
• Du kan fråga efter ändringar, begära nya varianter eller justera mappningar interaktivt.

Blockvarianter spåras med metadata.

• När du migrerar flera sidor läser agenten in befintliga anpassade varianter först och återanvänder dem när formateringen matchar (tröskelvärde på 70 % likhet baserat på syfte, färger, typografi, mellanrum, layout).

Sidhuvud, navigering och sidfot tas inte med vid sidmigrering. Dessa hanteras av särskilda färdigheter.

Varje migrering skapar importinfrastruktur (sidmallar, blockparser, transformatorer) för framtida bulkimport.

• Detta inkluderar sidmallar (avsnittsstruktur), transformerare (platsomfattande DOM-rensning) och parsrar (blockspecifik HTML till tabellkonvertering).

• Det ger inga fördelar med helt nya mallar.

• Det går inte att blanda mallar i en enda körning.

Den här uppmaningen anropas vanligtvis automatiskt som det första steget i sidmigreringen.

Innehåll som döljs via CSS hämtas också om de finns i DOM.

Lazyfyllda bilder och renderat innehåll på klientsidan hanteras genom att bläddra igenom sidan i Chromium utan rubrik och låta skript köras.

WebP-/AVIF/SVG-bilder konverteras till PNG för kompatibilitet.

Metadata extraheras med titel, beskrivning, Open Graph-taggar, JSON-LD-strukturerade data, kanoniska URL:er.

Bilder i DOM är fasta.

• background-image konverteras till img.
• Bildelement är uppackade
• src
• Relativa URL:er konverteras till absoluta
• Textbundna SVG konverteras till img-filer.

Sanitifierade dokumentsökvägar genereras (gemener utan tillägget .html).

Följande utdata produceras:

• screenshot.png
• cleaned.html (inga skript/format)
• metadata.json
• Mappen images/ med lokala kopior

Användare kan fråga om skärmbildsdimensioner och begära specifika enhetsstorlekar (mobil, dator) för att extrahera innehåll.

Genom att extrahera innehåll vid flera brytpunkter förlängs bearbetningstiden.

Designmigreringen har två faser:

1. Fas 1 (hela platsen) extraherar följande till styles/styles.css:

   • Global färgpalett och dekorfärger
   • Typografisystem (teckensnitt, storlekar, vikter)
   • Mellanrumssystem (utfyllnad, marginaler, mellanrum)
   • Sektionsbakgrund (ljusa, mörka, färgade)
   • Grundkomponentformat (knappar, länkar, bilder)
   • Utdata till

2. Fas 2 migrerar enskilda blockformat och skapar blockspecifik CSS i /blocks/{name}/{name}.css.

Blockformatering (fas 2) kräver att platsomfattande design (fas 1) är klar först.

• Det globala designsystemet innehåller anpassade CSS-egenskaper som blockerar referenser.

Beräknad tid:

• Fas 1: 5-10 minuter
• Fas 2: 10-15 minuter

Tvetydiga begäranden om att slutföra migreringen (båda faserna) ska vara standard.

Blockkritiker jämför ett migrerat block med dess ursprungliga källa och tillämpar upprepade CSS-korrigeringar tills en visuell likhet på 85 % uppnås eller tre iterationer slutförs.

Kompetensen kräver att blocket har skapats av sidmigrering först.

En blockkritik följer ett arbetsflöde i sex steg:

1. Det hämtar originalblocket från källsidan med en XPath-väljare.
2. Den initierar kritikersessionen.
3. Den inspekterar originalblocket (skärmbilder, format, HTML).
4. Den inspekterar det migrerade blocket.
5. Den jämför element och genererar en likhetspoäng med CSS-korrigeringar.
6. Korrigeringar och kontroller utförs tills målet på 85 % har uppnåtts.

Varje upprepning visar en komplett kritikerrapport med alla skillnader, tillämpar alla CSS-korrigeringar (som prioriteras efter visuell effekt), verifierar i förhandsgranskning, inspekterar om och visar förbättringsmått.

Använd blockkritiken när designmigreringen har slutförts.

Sidkritiker utför en helsidig visuell jämförelse mellan den ursprungliga sidan och den migrerade sidan. Den itererar tills ett 85-procentigt likhetsmål uppnås eller tre iterationer slutförs.

En sidkritiker har ett arbetsflöde i fem steg:

1. Initierar en kritisk session.
2. Den undersöker alla element på originalsidan.
3. Den undersöker alla element på den migrerade sidan.
4. Den jämför och genererar en likhetspoäng med prioriterade CSS-korrigeringar.
5. Korrigeringar och kontroller utförs tills målet på 85 % har uppnåtts.

En sidkritiker behöver källsidans URL och den migrerade sökvägen (t.ex."/about") som indata.

Använd sidkritiker när du validerar övergripande sidåtergivning eller validerar flera block samtidigt.

Använd blockkritik för fokuserad validering av specifika komponenter.

Följande arbetsflöde rekommenderas:

1. Migrera en sida.
2. Tillämpa en design.
3. Köra en blockkritik på nyckelblock
4. Kör ålderskritik för fullständig validering.

Den här kompetensen migrerar ett block i taget, inte hela sidor eller fullständiga Figma-filer.

Bästa resultat:

• Markera det specifika block som du vill migrera i Figma och kopiera länken (med node-id) eller namnet.
• Ange parametern node-id i URL:en för att ange det exakta blocket som mål.

När du kör den här kompetensen utförs följande steg automatiskt i värdmiljön:

1. Identifiering av blockstruktur - Agenten läser Figma-noden för att förstå lager och komponenter.
2. Global style extraction - Agenten hämtar färger, typografi och mellanrum till styles/styles.css som anpassade CSS-egenskaper (designtoken).
3. Blockspecifik formatskapande - Agenten skapar ytterligare anpassade CSS-egenskaper som är specifika för det block som migreras.
4. Mappning till befintliga block - Agenten identifierar det närmaste matchande blocket i projektets blockbibliotek och skapar en anpassad variant.
5. CSS-generering - Agenten skriver format som refererar till de extraherade anpassade CSS-egenskaperna, vilket ger en konsekvent design.
6. Resurshämtning - Agenten sparar bilder och ikoner från Figma till värdmiljöns arbetsyta.
7. Edge Delivery Services-innehållsgenerering - Agenten skapar markeringsfilen efter EDS-blockstrukturen
8. Utdatavalidering - Agenten förhandsgranskar resultatet och utför visuell jämförelse med den ursprungliga Figma-designen.

Kunskapen läser först metadata (steg 1) för att förstå strukturen, och extraherar sedan detaljerad designkontext (steg 2-5).

• Detta stegvisa tillvägagångssätt förhindrar problem med stora eller komplexa Figma-filer.

Den här kompetensen sätter stilar först.

• Alla format extraheras som anpassade CSS-egenskaper (designvariabler) innan CSS skrivs.
• Detta garanterar att det migrerade blocket följer ditt designsystem.

Kommandot kräver Figma-URL (med fileKey och valfri node-id) eller en Figma-filnyckel direkt som indata.

Edge Delivery Services-navigering tvingar fram en struktur med tre avsnitt (påtvingad av header.js):

1. Varumärke (avsnitt 1): Länk för logotyp och primärt varumärke
2. Avsnitt (avsnitt 2): Huvudnavigeringsmeny med valfria listrutor
3. Verktyg (avsnitt 3): Verktygslänkar (prenumeration, inloggning, kundvagn)

Navigeringsinnehållet finns i nav.md i rotkatalogen.

Avsnitt avgränsas med (---) markörer.

Fet objekt (**Text**) med kapslade listor skapar listrutor.

Länkar i navigering kan återges som knappar på grund av dokumentredigeringens automatiska radbrytningsbeteende.

• Rubrikblocket innehåller kod för att ta bort knappklasser från navigeringslänkar.

Medlet följer innehållsstyrd utveckling (CDD), en obligatorisk process för all Edge Delivery Services-utveckling.

• Den frågar om innehållsmodeller och testar innehåll innan den skriver kod.

CDD-filosofin är att författaren måste komma innan utvecklaren behöver det.

• Innehållsmodellerna måste vara intuitiva för författarna, även om det innebär mer komplex dekorationskod.

När du skapar testinnehåll först får du:

• Omedelbar testkapacitet
• PR-valideringslänkar för PSI-kontroller
• Livedokumentation för författare
• Identifiering av kantfall som inte kan hanteras med kod först

Agenten söker efter liknande block i Blocksamling och Blockera grupp innan den implementerar för att hitta mönster och återanvändbar kod.

Hoppa endast över CDD för triviala CSS-förbättringar (men identifiera fortfarande testinnehåll för validering).

Edge Delivery Services har fyra typer av kanoniska modeller:

• Fristående: distinkta visuella/berättande element (hjälte, blockquote)
  • En tabell med blockinnehåll
• Samling: Upprepat halvstrukturerat innehåll (kort, karusell)
  • Tabell med upprepat radmönster
• Konfiguration: API-drivet eller dynamiskt innehåll där config-kontroller visas (blogglista, sökresultat)
  • Tabell med nyckelvärdeskonfigurationsrader.
• Automatiskt blockerad: Komplexa strukturer som författare skapar som avsnitt/standardinnehåll och sedan omformas (flikar, YouTube-inbäddade)

Det finns en gräns på fyra celler per rad.

• Gruppera relaterade element i celler.

Använd blockvarianter framför config-celler för formatskillnader.

Följ Postels lag: Var flexibel när det gäller indatastrukturen.

• Ett hjälteblock ska fungera oavsett om innehållet finns i en cell, delas över två celler eller i separata rader.

Den här kompetensen anropas vanligtvis automatiskt av innehållsdriven utveckling när block skapas.

Blocksamlingen underhålls av Adobe och kontrolleras för bästa praxis, utmärkt innehållsmodellering, höga prestanda och tillgänglighet.

• Den är begränsad till vanliga block. Börja här.

Blockgruppen är communitydriven och erbjuder en bredare variation, bland annat experimentella metoder.

• Det innehåller även plugin-program för sidospark, verktyg för bygge (webpack, vite, sass) och integreringar.
• Används när blocksamlingen inte har det du behöver.

Tänk på alternativa namn när du söker

• Vanliga frågor = dragspelspanel
• Galleri = karusell/bildspel
• Navigering = meny/rubrik

Blockparten returnerar endast godkända/förvaltade poster.

Testningen följer en "value vs. cost"-filosofi där du skapar och underhåller tester när deras värde överstiger kostnaden.

• Innehavartester (enhetstester) är för logiktunga verktyg, databearbetning och API-integreringar. Dessa är snabba, enkla att underhålla och fångar upp regressioner i återanvänd kod.
• Throwaway-tester (webbläsartester) är för DOM-omvandlingar och visuell validering. Använd för att validera implementeringen, ta skärmdumpar för PR-granskning och sedan ta bort dem.

Throwaway-tester går in test/tmp/ och testar innehåll i drafts/tmp/ (båda gitignored).

Innan du öppnar en PR ska du se till att

• Befintliga tester godkänns
• Enhetstester skrivs för ny logik
• Valideringen av webbläsaren är klar
• Alla varianter testas
• Responsiv funktion har verifierats
• Linting pass

Vanliga problem har kända mönster:

• Bilder som visar "about:error": createOptimizedPicture-anrop saknas vanligtvis i block-JS, eller anropas före DOM-omstrukturering
• Blocken återger inte: Kontrollera blocknamnsformatet i markeringen och verifiera att blocket har både .js och .css filer i blocks/.
• CSS läses inte in: Kontrollera filsökvägar, verifiera att CSS-filen finns och kontrollera fliken Nätverk i webbläsaren.
• Ändringar visas inte: Kodsynkronisering tar 3-5 sekunder. Prova att uppdatera (Ctrl+Skift+R).

Agenten kontrollerar varje lager systematiskt:

1. Source-filer
2. Återgivna utdata
3. Blockera kod
4. Webbläsarkonsol

Agenten kan kontrollera lokala förhandsvisningar på http://localhost:3000.