Stardust

stardust

Modernise an existing website, with or without a redesign, and ship it.

Stardust is a Claude Code plugin for improving a website that already exists and delivering the result. It started as a redesign tool and still puts design first, but design is one of several things a modern site needs. Stardust measures and works on all of them, and you choose which ones move. The design craft itself comes from impeccable; stardust owns the job of taking a live site from where it is to where you want it, with every decision reasoned in the open before code runs.

What stardust improves

Dimension	Outcome
Design	The site keeps its current design, gets a new one resolved from your intent, or adopts a donor's. The result is measured against the source or the target spec, and template-looking output is rejected.
Performance	Core Web Vitals are scored on the live site before and after. Delivered pages swap fonts without layout shift, reserve space for late-loading chrome, and load the first image eagerly.
SEO and technical	Every page has a title, description and canonical. The site has a sitemap, redirects for changed paths, robots rules and structured data. Internal links resolve on the new origin instead of bouncing to the old one.
LLM and AI-search visibility	Key facts sit in server-rendered HTML where crawlers and AI bots read them. llms.txt and schema coverage are checked.
Accessibility	Contrast, alt text, landmarks and a single <h1> per page, verified with axe on the delivered site.
Content fidelity	Copy is carried verbatim and counted per page. Nothing is dropped, invented or reworded without a logged reason.
Platform	A static HTML tree that runs on any host, or a delivery to the target platform through the delivery layer.

Two layers

Stardust has a platform-agnostic core and an EDS-specific delivery layer.

platform-agnostic core                          EDS delivery
────────────────────────────────────────────    ─────────────────────────────
extract → direct → prototype → migrate     ──▶  deploy → rollout → qa
replica ─────────────────────┘                  (diff is used by both)
reskin ──────────────────────┘
audit, uplift (standalone)

Platform-agnostic core. Eleven skills that read a live site and produce a redesign, a replica or a reskin as self-contained static HTML under stardust/. Nothing in them assumes a CMS.

• extract crawls the site (capped, multi-page) and writes the captured design system, brand surface, per-page inventory and rendered DOM to stardust/current/ (with --dynamics, set by the migration flows, also the per-page reach signals of the dynamic surface).
• direct resolves your intent into a target PRODUCT.md and DESIGN.md, with reference research when the refero MCP is present and the reasoning kept in stardust/direction.md.
• prototype renders before/after pages under stardust/prototypes/ and iterates them through impeccable's craft loop.
• prepare-migration runs extract, direct and prototype in --prep mode with confirmation gates, for the redesign migration flow, and closes with the dynamic-surface gate (dynamics Phases 1–3): every API, search box, form, modal, player, tag and client-rendered surface gets a disposition before import.
• replica recreates one archetype per page type as clean HTML/CSS that matches the live site near pixel-perfect, proven by a measured gate.
• reskin re-lays byte-faithful content onto a donor design system.
• migrate applies the approved design or replica to every page and writes the deployable static tree to stardust/migrated/, one fidelity tier per page.
• audit scores any URL across the dimensions above.
• uplift turns a URL into three presales redesign variants without further input.
• diff compares any prototype with any build, pixel and structure, through an eds or generic profile.
• stardust is the master skill: setup, routing, state report, hands-off mode.

Outputs: stardust/current/, stardust/prototypes/, stardust/migrated/, stardust/state.json, stardust/status.jsonl, stardust/learnings.md.

EDS delivery. Four skills that take the migrated tree to AEM Edge Delivery Services.

• deploy converts one page into EDS blocks under blocks/ and Document Authoring content under content/, then writes it through the DA Source API. Each prototype section becomes a block. Content structure passes the David's Model lint, blocks pass the Experience Workspace editability gate, internal links are localized, and a per-page atomic contract checks the delivered page before it counts as deployed.
• rollout delivers the whole site: coverage ledger, block dedup, per-page delivery through deploy, site assembly (sitemap, redirects, multilingual trees), the dynamic features phase (dynamics Phases 4–5: index-backed listings and search, modal loader, forms, tags, off-origin data, parity replay), full-site verify and link audit, an optimize gate that aggregates accessibility, SEO, AI-search and brand-tension findings, deterministic AEM autofixes, and a report.
• dynamics is the dynamic surface of a migration: detect on archetypes, classify, triage on four axes (class, disposition, reproducibility, status), implement from a pattern catalogue, replay parity. Default-on in both migration flows, never for redesign-only work.
• spec measures a site before a migration (inventory, redirects, 404s, templates and layout variants, blocks per page with reuse verdicts against a block library, dynamic features, martech, locales) and records the judgement calls and open questions with defaults, as committed knowledge files with a documented contract that any client can read.
• qa sweeps the live EDS site read-only: routing, content fidelity against the capture, template conformance, rendered integrity, visual regression, metadata and JSON-LD, links, axe accessibility, performance budgets, editability. It reports and never fixes.

Outputs: blocks/, content/, stardust/rollout/ (ledger, coverage, findings, dashboard), stardust/qa/.

What goes to git

Stardust keeps its own files under stardust/ and ships its own ignore file there (stardust/.gitignore, installed at setup). Everything under stardust/ is meant to be committed: it cost tokens to produce or captured a site that will not exist after launch, and a clone in another environment resumes from it. Not tracked by default: screenshots wherever a skill writes them, gate images (their JSON verdicts stay), two heavy folders rewritten on every run (migrated/assets/, rollout/qa/), run residue under stardust/.work/, and captured session state. The project's own .gitignore is left alone apart from a managed block for .env; on an EDS project stardust/ is added to .hlxignore so nothing in it is served. The per-directory table is in skills/stardust/reference/artifact-map.md § Versioning.

Two migration flows

A migration to EDS starts with one question: does the design stay or change? The answer picks the flow. The delivery layer is the same for both, the two flows are never mixed, and the master skill names the chosen flow in its first reply to any "how do I migrate this site" question.

	Keep the design	Redesign on the way
Core (agnostic)	replica → migrate	prepare-migration (or extract → direct → prototype) → migrate
Delivery (EDS)	deploy for a pilot page, rollout for the site, qa after	same
Design source	The captured site. Changes only through an inconsistency register, which is usually empty.	Your intent, resolved into a target spec.
Prep step	None besides replica itself. Never run prepare-migration with it.	prepare-migration, or the three skills by hand.

Keep the design: replica → migrate → deploy / rollout

Two things set a replica migration apart. First, it does two jobs in the same pass: it migrates the page or site, and while doing so it extracts the design definition (PRODUCT.md, DESIGN.md, DESIGN.json and the lifted tokens). With both in place you can build new pages on the same design system after the migration, not only re-platform the existing ones. Second, it follows stardust's prototyping approach: it first builds a static HTML clone of each page to migrate, gates that clone against the live site, and only then hands the static HTML to stardust:deploy, which converts it into EDS blocks and content (the snowflake approach). Going through the static prototype usually gives higher fidelity from the first independent migration pass than converting the live page straight into blocks.

1. extract --prep runs as replica's first phase and captures the full inventory.
2. The captured design system becomes the target spec by mechanical promotion. The only permitted design changes are the entries of an explicit inconsistency register.
3. One archetype per page type is recreated as clean semantic HTML/CSS with values lifted from the source's own CSS. Never a DOM copy.
4. Each archetype is gated against the live site per breakpoint: structural content diff, visual heuristics, stitched pixel diff with a three-iteration cap, a crop gate for header, footer and sticky strips, a computed-style chrome-parity probe, and interaction parity observed at runtime rather than inferred from CSS.
5. Siblings are cloned through migrate at the sibling tier after a live variance probe has budgeted template deltas as block variants.
6. EDS delivery, with the final gate run against the published origin rather than a local harness.

Redesign on the way: prepare-migration → migrate → deploy / rollout

1. extract --prep crawls the full inventory and types the pages.
2. direct --prep resolves the intent into PRODUCT.md and DESIGN.md and confirms page types and the module catalog.
3. prototype --prep produces one archetype prototype per page type plus the design canon, through impeccable's craft loop with anti-template, brand-tension and vision-verified checkpoints.
4. migrate applies canon and modules to every page with a declared fidelity tier (archetype, sibling or thin), content preserved verbatim and counted.
5. EDS delivery.

Other entry points

• audit <url> when you want the scorecard before deciding anything.
• reskin when the content stays and the design comes from another live site or from local prototypes. Content is gated byte for byte; the layout adapts to the donor's modules. Delivery is the same EDS layer.
• uplift <url> when you need a pitch: three differentiated variants, one of them cinematic, from the URL alone.
• extract → direct → prototype → migrate when you want a redesign as static HTML with no platform change.

Hands-off mode

Production migrations run the whole chain without conversational gates. Decisions that would normally pause for you are resolved from the captured evidence and logged, run status streams to stardust/status.jsonl, and each run appends to stardust/learnings.md. General findings from that ledger are folded back into the skills. The chrome crop gate, the sizing-model lift, the editability contract, link localization and the glyph-noise floor all entered the plugin that way.

Installing

Stardust is packaged as a Claude Code plugin, and GitHub Copilot reads the same manifests, so both install from the adobe/skills marketplace. Impeccable is a hard dependency and is installed separately; Copilot does not resolve plugin dependencies.

Claude Code:

/plugin marketplace add adobe/skills
/plugin install stardust@adobe-skills
/plugin marketplace add pbakaus/impeccable
/plugin install impeccable@impeccable

GitHub Copilot CLI (also picked up by Copilot in VS Code and the cloud agent; verified 2026-09-17 with Copilot CLI 1.0.85):

copilot plugin marketplace add adobe/skills
copilot plugin install stardust@adobe-skills
copilot plugin marketplace add pbakaus/impeccable
copilot plugin install impeccable@impeccable

In Copilot CLI the skills are addressed by their bare names (stardust, extract, deploy), not as stardust:extract. Where a skill body uses the Claude Code form, use the bare name.

Other agents install the skills without plugin grouping. npx skills add adobe/skills --list shows all 109 skills in this repository as one flat list, so name stardust's sixteen explicitly, and install impeccable the same way:

npx skills add adobe/skills -s stardust -s extract -s direct -s prototype \
  -s migrate -s prepare-migration -s replica -s reskin -s audit -s uplift \
  -s diff -s deploy -s rollout -s dynamics -s qa -s spec
npx skills add pbakaus/impeccable -s impeccable

gh skill install adobe/skills --all (GitHub CLI 2.90 or later) is the equivalent for the agents it supports. Both paths copy loose skills: no plugin grouping, no dependency check, updates through npx skills update or gh skill update.

Verified on

Harness	Version	Date	What was run
Claude Code	2.1.x plugin	continuous	evals/runner suite
GitHub Copilot CLI	1.0.85	2026-09-17	evals/copilot-smoke/run.sh: skill listing, bare-name load, master Setup
Grok Build, Amp			expected to work (Claude plugin compatible), not run
Codex, Cursor, Gemini CLI, OpenCode, Kiro and other .agents/skills adopters			installable through npx skills add; not run

Prerequisites

Stardust's bundled scripts run under Node 22 or later and need Playwright with Chromium resolvable from the project (npm i -D playwright && npx playwright install chromium). Several skills call playwright-cli from the adobe/skills web plugin. No harness installs these for you; the skills probe for them and print the install command when they are missing.

Dependencies

Stardust requires impeccable and has no fallback. The dependency is deliberately unpinned so that the design craft is always the current release, and the setup step prints one line when a newer impeccable is available than the one installed.

Three integrations are used when present and skipped when absent: the refero MCP for direct's reference research, modern-web-guidance for platform best practices, and the marketing-skills seo-audit, schema, ai-seo and site-architecture skills, which feed audit and rollout's optimize gate.

Status

v0.19.x folds a series of field harvests from same-design migrations into the skills: element-anchored chrome crop gates, chrome-parity and row-profile instruments, rendered-DOM capture, link localization as a deploy stage, dropped-content and script-text detectors, sibling variance probing, and the impeccable update hint. CHANGELOG.md has the full list.

License

Apache-2.0