Getting updates
Your project is a copy, not a fork with a shared history. NuxtStart keeps shipping after you copy it, and nothing pushes those changes to you — you pull them when you want them.
Two things make that manageable: a notification when there's something to pull, and a skill that does the reconciling with you.
Hear about a release
Watch the NuxtStart repository on GitHub and set your watch settings to releases. Changelog has the same list.
Adopt with the skill
Your project ships a skill for this. It's already in your tree at
skills/adopt-nuxtstart-changes/, so there's nothing to install — open your AI coding agent and
run:
/adopt-nuxtstart-changes
It works out what changed upstream since your last adoption, sorts those paths into areas, and records a decision for each one. Answer the questions it asks: the conflicts it raises are the ones where your code and NuxtStart's have both moved, and only you know which should win.
Adopt by hand
The skill does the steps below with a memory of what you already adopted. Do them yourself when you want the change to be small and deliberate.
Confirm the remote
Local setup adds it. Check that it's there:
git remote get-url nuxtstart
If it isn't, add it:
git remote add nuxtstart https://github.com/NuxtStart/NuxtStart.git
Merge published, and only published
git fetch nuxtstart --prune
git merge nuxtstart/published
Your first merge may report refusing to merge unrelated histories, because your project started
as a copy rather than a clone. Pass --allow-unrelated-histories that once.
published and no other upstream branch. NuxtStart's development, staging, and
main branches carry its own account identifiers and migration lineage, and neither belongs in your
tree — not even for a single fix. published is downstream-only: never merge it back into a
promotion branch. Merge rather than rebase or reset: both of those discard your work instead of
adopting theirs.Resolve the conflicts
pnpm-lock.yaml conflicts are the routine one, and you don't merge them by hand. Take your own side
of the file, then let pnpm rebuild it:
git checkout --ours pnpm-lock.yaml
pnpm install
git add pnpm-lock.yaml
.env.project.schema conflicts on PROJECT_SLUG, PROJECT_DISPLAY_NAME, and PROJECT_ZONE every
time, because upstream carries REPLACE_ME where you carry your own. Take your own side of those
three assignments and adopt upstream's surrounding comments — a REPLACE_ME merged in holds back
every deploy of both applications.
Generate a migration if the schema moved
Your project owns its migration history, so an upstream schema change arrives as schema only. Turn it into a migration of your own:
cd apps/web
pnpm db:generate
Commit what it writes. Database covers when migrations are applied, and Migration publication covers why you own the lineage.
Review before you push
Read the merge commit rather than trusting it. A dependency upgrade upstream can need a matching change in code you own, and that change is yours to make — the merge won't do it. Comparing against what NuxtStart did in the same release is usually the fastest way to see what's needed.
Then push, and let the pipeline deploy the branch you merged into.
Where to merge
Merge into development and promote from there. The pipeline deploys the branch you push, so
merging straight into main deploys upstream's changes to production without them ever having run
anywhere else. Deployment pipeline has the promotion order.
Next steps
- Changelog — what changed, and when
- Deployment pipeline — which branch deploys where
- Discord community — ask when an adoption goes sideways