Eleven phases.
One prompt each.
<SITE_URL> throughout, run one phase per prompt, and start a fresh session at any phase boundary.You provide up front
<SITE_URL> — the live site to migrate. That's it. Phases 1–7 need nothing else.
You provide before Phase 8
The EDS project repo, the DA org/folder, a DA_TOKEN in the environment, and font-licensing confirmation for any private cuts the extraction captures.
Read the site. Score it. Lock the direction.
01
Extract — discovery snapshot
Capture the brand surface.
/stardust:extract <SITE_URL>
A default five-page, template-diverse crawl — home, program, listing, article, form — with brand-surface extraction, descriptive PRODUCT and DESIGN docs, and a brand-review.html.
Check before continuing: open
stardust/current/brand-review.html; the per-page evidence table should showlive: yeson every row, and the Tensions section is your decision agenda. Widen with--cap 25/--pages a,b,conly if the five pages missed a template.
02
Audit — scored baseline
Establish the baseline you'll beat.
/stardust:audit <SITE_URL>
Reuses the fresh extraction and produces a seven-dimension scorecard with P1–P3 findings, benchmarks, and uplift directions. The findings ledger becomes the fix list for Phase 3, and the closing audit in Phase 11 is measured against this baseline.
03
Direct — lock the direction
The one prompt to get right.
For a brand-faithful migration — the common case, and this playbook's path:
/stardust:direct keep the brand, consider the brand style unique choices and do not average them into standard design. keep all the videos, images and animations. look at audit and fix identified issues while maintaining the brand. Brand faithful, IA verbatim!!
The phrase pins brand-faithful Mode A with verbatim information architecture and media preservation, and scopes the work to the audit findings. Expect exactly one question back — the density tier; answer balanced unless the site is editorial. Outputs: target PRODUCT.md / DESIGN.md / DESIGN.json, stardust/direction.md, and the improvements list.
Variants: replace the phrase with --rebrand ... for a new identity, or append "3 variants" for an A/B/C fork. Everything downstream reads the direction file.
Approve the home, plan the site, migrate every page.
04
Prototype — home + approve
Home becomes the canon-author.
/stardust:prototype
The agent shows the home shape brief → reply Render it (or edit the brief) → render plus quality gates (critique / audit / adapt / vision) → open in browser. Iterate with plain phrases — "tighten the hero", "make the cards quieter" — then:
approve index
The approved home authors the canon every later archetype inherits.
05
Analysis + implementation plan
Map the whole site before building it.
Run a full analysis of the website: identify and document the full list of URLs that are part of the website, then analyse which page types should be prototyped. Then identify all the dynamic capabilities of the site that we will have to reimplement in our EDS implementation (item lists, indexes, search, API integrations, martech, etc.). Then write an implementation plan we will follow, all based on stardust skills: stardust:prototype all the page types identified, stardust:migrate the prototypes, stardust:deploy them, then build all the dynamic capabilities and migrate all the pages (use stardust:rollout if better). I will provide the EDS project and DA folder later.
Outputs under stardust/analysis/: site-inventory.md (plus a URL inventory typed into archetypes), dynamic-capabilities.md (each capability mapped to an EDS approach), and implementation-plan.md — the phase list the rest of this playbook follows.
06
Prep cascade — fresh session
The handoff prompt — resume in a fresh session.
/stardust:prepare-migration <SITE_URL>
Context: this project is mid-pipeline — read stardust/journal.md (last 3 entries), stardust/state.json, and stardust/analysis/implementation-plan.md before doing anything.
Where we are:
- Extract, audit, and direct are done. Direction is LOCKED (stardust/direction.md): brand-faithful Mode A, ia-fidelity VERBATIM, density balanced, all media/animations preserved, audit findings are the fix list. Do not re-run direct's questions.
- The home prototype (stardust/prototypes/index-proposed.html) is APPROVED and is the canon-author.
- Full analysis is on disk: stardust/analysis/site-inventory.md, dynamic-capabilities.md, implementation-plan.md.
Do next, per that plan:
1. extract --prep: full junk-filtered live crawl, types stamped into state.json, module candidates, typed slots. Synthesis is forbidden; the prep summary must show live provenance <total>/<total>. Use the project copy of the crawler (stardust/scripts/crawl.mjs — it carries site-specific consent fixes) and re-probe playwright importability first (npm i -D playwright --no-save --legacy-peer-deps).
2. direct --prep: confirm the type/module catalogs against site-inventory.md. Put the open decisions from the plan to me (e.g. search depth, analytics attribution).
3. prototype --prep: one archetype per type, in the plan's order. Verbatim IA, all gates, my approval per archetype. Canon extracts from the approved home.
Not yet: migrate/deploy/rollout — EDS repo, DA folder, DA_TOKEN, and font licensing come later.
The context block at the top — read the journal, the state file, and the plan; the direction is locked; don't re-ask — is the template for resuming any phase in a fresh session. During this phase you'll be prompted once per archetype:
approve <slug>
07
Migrate — all pages
Every page, as platform-agnostic HTML.
/stardust:migrate
Context: read stardust/journal.md and stardust/state.json first. All archetypes are approved and canon is written. Fork approved templates across sibling pages per type; render unique-typed pages as one-offs. Refuse to ship any [data-placeholder] — legal pages must be verbatim. Preserve the 1:1 URL map.
Prove the pipeline, build the dynamics, roll out the site.
08
Deploy one page — pipeline proof
One page through the whole pipe.
/stardust:deploy index
The EDS project repo is <GITHUB_ORG/REPO>, the DA org/folder is <DA_ORG>/<DA_FOLDER>, DA_TOKEN is set in the environment. Deploy the approved home: section→block conversion, DA source PUT → preview → live. Then run stardust:diff index against the approved prototype and show me the fidelity report before we go further.
Also in this phase — same prompt or a follow-up: self-host fonts (licensing confirmed), favicon, the metadata sheet skeleton, the consent bar, and the delayed.js martech scaffold.
09
Dynamic capabilities
Rebuild what the CMS used to do.
Build the dynamic capabilities from stardust/analysis/dynamic-capabilities.md in the EDS project, in this order: (1) helix-query.yaml + query index with the metadata columns; (2) the listing/grid block with facets + batched reveal; (3) related-content; (4) search block over the index; (5) form blocks posting to the incumbent forms API with lazy captcha; (6) media blocks (video hero + player facade) per the approved prototype; (7) martech in delayed.js gated by the consent bar; (8) metadata sheet, JSON-LD per template, llms.txt, redirects sheet, sitemap. Validate each block page with stardust:diff, and re-run the CWV check — mobile TBT must land ≤200ms.
10
Rollout — whole site
The full inventory, gated and batched.
/stardust:rollout
Context: read stardust/journal.md, stardust/state.json, and the implementation plan. Roll out the full migrated inventory to EDS with coverage + delivery gates. Batch by type: static-legal first, then articles, programs, then listings last (behind their blocks). The audit findings with known check ids (canonical, jsonld, single-h1, duplicate-title) should flow into the ledger for autofix. Stop before the DNS/go-live step and give me the go-live checklist.
11
QA + closing audit
Close the loop against the Phase 2 baseline.
/stardust:qa <LIVE_EDS_URL>
then
/stardust:audit <LIVE_EDS_URL>
Compare against the Phase 2 baseline: the P1 findings should be resolved and the overall score materially up. Anything left feeds a fix loop — Phase 9 blocks or rollout's optimize pass — until clean.
One phase per session is fine.
Approvals are explicit
Nothing auto-approves. You gate each artifact with approve <slug> — the home first, then one approval per archetype.
Iteration is plain language
"Make the hero bolder", "tighten the grid" — against any prototype. The agent maps the phrase to design commands and re-runs the quality gates.
The two prompts that shape everything
The Phase 3 direction phrase (fidelity vs rebrand, verbatim vs reimagined) and the Phase 5 analysis ask (produces the plan every later prompt points back to). Spend your words there.
Hands-off alternative
Append --hands-off to the Phase 1 or Phase 6 prompt and the interactive gates auto-resolve with named assumptions — quality gates still run at full strength. Approvals record as approvedBy: hands-off.
One-shot presales alternative
/stardust:uplift <SITE_URL> replaces Phases 1–4 with three differentiated variants in one run — when the goal is a pitch, not a migration.
Session-break contract
Every prompt from Phase 3 onward begins by pointing the agent at the on-disk state — stardust/journal.md and stardust/state.json. That's what makes phase boundaries safe places to stop.