Build any site into an OF1 demo.
A multistep pipeline that turns any web domain into a branded, generative website — powered by Stardust, Snowflake and OF1. Run it all from SLICC with a single prompt.
Multistep pipeline · SLICC-powered · skills-v2
Overview
The OF1 demo pipeline takes a URL and produces a fully deployed, working generative website — complete with the brand's real visual identity, an EDS block library, AI-trained config, and a live OF1 search experience. You own each review gate; SLICC does the rest.
Start here: Install the skills pack (upskill command below), open SLICC, and say: "Build me an OF1 demo of [domain.com]." The /of1-demo orchestrator opens a sprinkle panel and walks you through every step.
Choose your skills version
The pipeline is published in two skills branches. Pick the version you want to install — each row below gives the exact install command, source branch, and a one-click SLICC handoff link.
Prerequisites
Four plugins are required. Install them once — they persist across sessions.
Required
OF1 Demo Skills
The orchestrator and all pipeline skills. Install via upskill from SLICC.
See install command below
Required
Adobe Skills
Provides stardust:extract and stardust:prototype — used for site crawling and prototype generation.
claude plugins install adobe/skills
Required
Impeccable
Frontend design skill used to generate pixel-perfect HTML prototypes from brand extraction.
claude plugins install pbakaus/impeccable
Required
Snowflake
Converts stardust prototypes to EDS block format. Provides the stardust-to-snowflake skill for EDS provisioning.
claude plugins install ai-ecoverse/snowflake
Also needed: Playwright (playwright-cli) must be available — used for screenshots, DOM extraction, and auth token retrieval. DA_TOKEN env var is needed for DA.live uploads in step 6.
The upskill command
The OF1 demo skills are published on GitHub. Install them in SLICC with the upskill command — this fetches the skills-v2 branch and makes the full pipeline available.
The pipeline
13 steps. The orchestrator runs these steps in order, pausing at review gates for your approval. Steps 8–11 run in parallel once step 7 is approved.
Phases: steps 01–03 setup & discovery, steps 04–06 EDS provisioning, steps 07–11 OF1 provisioning, steps 12–13 review & deploy.
Step 1 — Install dependencies
skill: of1-setup · automated — Auto
Verifies all required skills, plugins, and tools are installed and up to date. Checks for playwright-cli, node, and DA_TOKEN. Re-runs upskill to ensure latest versions. Reports a pass/fail summary — fails block the pipeline, warnings do not.
|
Checks
|
Output
|
Note: Can run before a domain is entered — it checks global prerequisites only.
Step 2 — Setup AEM / DA repo
skill: of1-repo-setup — Review gate
Creates or connects an AEM Edge Delivery Services repository. Prompts you to provide an existing repo URL or create a new one from the of1-boilerplate template. Handles GitHub repo creation, AEM Code Sync app installation, DA mounting, and end-to-end preview verification.
|
Inputs (from you)
|
Output
|
Important: Every subsequent step reads repo-config.json. Never skip or short-circuit this step — it is the shared context for the entire pipeline.
Step 3 — Discovery
skill: of1-discovery — Review gate
Crawls the target domain using Playwright (headed Chrome). Visits the homepage and 5–10 navigation pages. Proposes a demo focus, persona narrative, and the 2–3 key pages to reproduce. Generates a styled HTML discovery report and pushes it to the EDS repo as a deliverable.
|
What it analyzes
|
Output
|
Your job at this gate: Confirm the demo focus — which product line and persona — or redirect to a different part of the site. Everything downstream depends on this choice.
Step 4 — Extraction
skill: stardust:extract (adobe/skills plugin) — Review gate
Runs the stardust extraction pipeline on the target domain. Crawls the site, captures screenshots, extracts the full design system (colors, typography, spacing, logo, icons), and produces structured brand data. Generates a brand-review.html deliverable with all extracted assets.
|
What gets extracted
|
Output
|
Logo gotcha: Stardust can extract truncated SVG logos from sprites. The step scoop post-processes the extraction to verify the full logo SVG and replace it if truncated. Always check the brand-review deliverable before approving.
Step 5 — Prototype
skill: stardust:prototype (adobe/skills plugin) — Review gate
Generates pixel-perfect HTML prototypes of the target pages using the extracted brand data. Uses real images from the live site DOM, the actual brand logo, and the real icon set. Runs a screenshot diff loop (up to 3 iterations per page) comparing prototype output to live site screenshots and auto-fixing significant visual gaps.
|
Screenshot diff loop
|
Output
|
Never redesign: The goal is a pixel-perfect copy, not a redesign. Never use placeholder images, colored boxes, or invented icons. Extract real image URLs with playwright-cli eval against the live site DOM.
Step 6 — Snowflake, EDS conversion
skill: of1-snowflake + stardust-to-snowflake — Review gate
Converts the HTML prototypes into a full AEM Edge Delivery Services site. Creates custom EDS blocks (JS + CSS) for each section, uploads content pages to DA.live, triggers preview, and runs another screenshot diff loop comparing the EDS preview to the prototype. Also installs the OF1 block infrastructure (blocks/of1/) and creates the block catalog page.
|
What gets built
|
Critical EDS rules
|
Review deliverable: The step sends multiple preview URLs to the sprinkle — one per content page. Open each to verify layout, images, and nav/footer before approving.
Step 7 — OF1 styling
skill: generative-block-styler — Review gate, Hard stop
Generates the brand-aligned CSS for the OF1 generative block — the visual layer over all dynamically-generated sections. Reads DESIGN.json and styles/styles.css to produce hero treatment, card grids, comparison tables, skeleton loading animations, and the follow-up suggestions UI. Uses the site's actual CSS custom properties throughout.
|
CSS sections generated
|
Hard stop
|
Steps 8, 9, 10, and 11 run in parallel after you approve step 7.
Step 8 — Brand voice + content metadata
skills: brand-voice-extractor + content-metadata — Parallel
Two scoops run simultaneously. Brand voice crawls 5–8 pages to extract tone, vocabulary, personality and avoid-words — producing brand-voice.json. Content metadata scrapes product data, personas, use cases, features, and FAQs — producing 5 separate JSON config files.
|
brand-voice.json fields
|
Content files
|
Step 9 — Block guide
skill: block-guide-builder — Parallel, Review gate
Analyzes every block in blocks/, evaluates each for LLM generation suitability, selects 6–9 blocks that cover all intent types (discovery, deep-dive, comparison, recommendation), and generates block-guide.json — the prompt string that teaches the OF1 worker how to output structured JSON blocks. Also creates a block catalog page for visual reference.
Most critical config file: The block guide directly controls what the LLM generates. Every block example MUST use real image URLs from products.json. Never use invented paths — the LLM mirrors example patterns. Bad examples mean broken generation.
Step 10 — Suggestions
skill: quick-suggestions — Parallel
suggestions.json.Step 11 — CTA template
skill: cta-template-builder — Parallel
cta-template.json with fallback content, color tokens, and button styles.Step 12 — Config review
orchestrator-inline — no scoop — Review gate, Inline
The orchestrator runs this step directly (no scoop). Builds a single review page — deliverables/config-review.html — showing all config files side by side: block guide vs block catalog, products grid, brand voice, personas, suggestions, CTA template. This is your final check before deploy.
What to check:
- Are the right blocks selected? (the guide should be a subset of the catalog)
- Do all products have working image URLs?
- Is the brand voice specific — not just "professional and friendly"?
- Do suggestion chips cover discovery, deep-dive, and comparison intents?
- Are persona keywords realistic search terms?
Step 13 — Deploy
skill: of1-deploy — Review gate
Commits all config files to of1/config/, pushes to GitHub (EDS serves them as static files), calls POST /api/tenants/{id}/sync on the OF1 worker to fetch and index everything, then runs a generation test. Builds the Demo Hub page linking all deliverables.
|
Config files deployed
|
Final URLs
|
Running the demo
Once the pipeline completes, you have two ways to experience OF1. Use them together for the most compelling demo — start with the extension to build context, then let the /of1 page do the reveal.
Mode A
Direct — the /of1 page
Go straight to /of1, type a query or click a suggestion chip, and watch a personalized page generate in real time.
Mode B
Extension — browse to personalise
Browse the original site with the OF1 Preview extension active. A profile builds silently. Hit Personalise — the page glows, a CTA appears, click it to open /of1 with no prompt needed.
The /of1 page
Mode A. Your generative search experience. Every query produces a full branded page — assembled from the blocks you built, styled with the brand tokens you extracted, and written in the voice you configured.
- Prompt — type any query. The search input accepts any natural language query. The OF1 worker matches it against your products, personas, and use cases, then instructs the LLM to assemble a relevant page using your block guide. The result streams in section by section.
- Quick suggestions — guided intent. Below the input, branded suggestion chips offer pre-set queries — generated during the pipeline from your products and use cases. Each chip launches a generation immediately, no typing required. Ideal for demos where you want a predictable, polished result on the first click.
- Keep exploring — refine and go deeper. At the bottom of every generated page, follow-up suggestions appear — contextual chips that narrow or pivot the experience. A visitor looking at running shoes sees suggestions like "trail vs road", "for overpronation", or "under $120". Each click regenerates the page around the refined intent, creating a guided discovery loop without a search box in sight.
Demo tip: Click a suggestion chip for your first demo — it guarantees a strong result. Then show the prompt input for "what if" questions, and use Keep Exploring to show the conversation deepening naturally.
Extension flow
Mode B. The OF1 Preview chrome extension turns any browsing session on the original site into a personalisation trigger — no query needed.
-
Download the extension. Download the zip, unpack it, then load it in Chrome via chrome://extensions → Developer mode → Load unpacked. It activates on the domain your demo was built for.
-
Set up — enter your tenant ID and activate. Navigate to the original site, then open the extension. You'll be prompted for a tenant ID — this tells the extension which OF1 demo to connect to. Not sure what yours is? Ask SLICC: "What is my OF1 tenant ID?" — it will read it from the deployed config. Once entered, hit Activate. The extension is now live on this domain and ready to build a profile. Tenant ID format:
main--{repo}--{owner}— e.g.main--acme-demo--myorg. SLICC knows it from the repo config written during step 2 of the pipeline. -
Browse the original site. Navigate to the original site — the one your demo was modelled on. Browse naturally: visit product pages, read categories, follow your interests. The extension watches every page visit and builds a silent user profile in the background. No input required from the user.
-
Profile builds — context accumulates. As you navigate, the extension accumulates intent signals — what categories you visited, which products you lingered on, what paths you followed. Once enough context exists, the Personalise button becomes available. The richer the browsing, the more precise the eventual generation. Demo tip: browse 3–5 pages with a clear theme (e.g. all from one product category). Consistent intent produces a more dramatic, specific personalisation than scattered browsing.
-
Press Personalise — the page glows. Back on the homepage, open the extension panel and press Personalise. The page transforms — a visual glow effect signals activation, and a branded CTA is injected into the page based on the user profile the extension has built.
-
Click the CTA — /of1 opens, no prompt needed. The injected CTA opens the /of1 page and passes the user profile as context — no typing, no prompt. The generation begins immediately, producing a page tailored to exactly what the user browsed. The profile replaces the query. This is the reveal moment: the site already knew what they were looking for.
The reveal: The power of the extension flow is that the user never typed anything — yet the generated page is specific to them. Use this to close the demo: "The site figured out what you were here for. You didn't ask. It just knew."
Key concepts
Glossary. Terms you'll encounter throughout the pipeline.
adobe/skills plugin). It crawls a live site, captures its visual design system — colors, typography, spacing, logo, icons, screenshots — and stores it in a structured stardust/current/ directory with DESIGN.json and PRODUCT.md. The prototype step then uses this to generate pixel-perfect HTML pages. Stardust is not used to redesign the site — it extracts and faithfully reproduces it.ai-ecoverse/snowflake plugin). It takes the stardust prototypes (HTML files) and converts them into a working AEM Edge Delivery Services site — creating custom blocks/ directories with JS and CSS, generating EDS-compatible content HTML for DA, and building a block catalog page. The result is a real EDS site that previews at https://main--{repo}--{owner}.aem.page/.decorate(block) function that transforms raw HTML table markup into the final rendered component. Preview URLs follow the pattern https://main--{repo}--{owner}.aem.page/. Live URLs use .aem.live. Static files in git (like /deliverables/*.html) are served at their exact path including the .html extension.PUT https://admin.da.live/source/{owner}/{repo}/{page}.html) and then previewed via the AEM Admin API (POST https://admin.hlx.page/preview/...). DA requires both Authorization and x-content-source-authorization headers with the IMS token. Critical limitation: DA strips all <img>, <picture>, and inline <svg> from programmatically uploaded HTML. Images must be stored as plain text URLs in block cells.of1-gen-web-service.franklin-prod.workers.dev that handles AI generation. Each demo gets a tenant — identified by main--{repo}--{owner}. Config JSON files are committed to the git repo at of1/config/, served as static files by EDS, then synced to the worker's R2 storage via POST /api/tenants/{id}/sync. The worker auto-indexes vectors for products, features, and FAQs during sync. Generation is tested via POST /api/generate.of1/config/block-guide.json) is a prompt string (stored in a "guide" field) that teaches the OF1 LLM what JSON to output. It defines each block with a description, rules, and a complete rows-format example. The worker's json-to-html.js converts the LLM output to EDS block HTML at runtime. Blocks are output as separate JSON objects separated by === — never wrapped in an array. The guide is the single most important config file for generation quality.scoop_scoop()) that handles a specific task. A sprinkle is a persistent UI panel that the cone (orchestrator scoop) communicates with via sprinkle send. The of1-demo orchestrator is a cone — it opens the sprinkle panel, spawns step scoops named of1-s1 through of1-s13, polls for status files, and pushes status updates to the sprinkle UI. Step scoops never call sprinkle send directly — they write status files and the cone picks them up.