Project Migration

This is a strict guideline. Follow these rules exactly.

Migrate an existing project to the current infrastructure and tooling standards. Unlike project-setup (which scaffolds from scratch), this skill works with existing code and configs — it must be non-destructive and interactive.

Core Principles

• Never overwrite without asking. If a config file already exists, present a diff of what would change and ask before replacing.
• Work on a branch. All changes happen on a dedicated branch. Rollback is a branch reset.
• Ask early, not late. When intent is ambiguous (e.g., a custom eslint config that partially overlaps with the standard), ask whether to merge, replace, or skip. Do not assume.
• Fragments are the source of truth. Use fragment files from loxosceles/project-blueprints for all standard configs. Common fragments (fragments/common/) are assembled with stack-specific injections (fragments/injections/{stack}/) and Dockerfiles (fragments/dockerfiles/{stack}/). The result is one clean file per output — no runtime includes or sourcing. Do not improvise alternatives.
• devcontainer-state is the shared config repo. All containers mount from ~/.devcontainer-state (overridable via DEVCONTAINER_STATE env var). SSH and AWS use ${SSH_PATH:-~/.ssh} and ${AWS_PATH:-~/.aws}. All mounts are directories — no file mounts.

Workflow