fix(skills): add a polylith- prefix for all the migration skills (#448)

* fix(skills): add a polylith- prefix for all the migration skills

* bump CLI to 1.48.1

Author: DavidVujic

.agents/skills/polylith/README.md

@@ -8,7 +8,7 @@
 Two kinds of skill live under this directory; the distinction matters when picking an entry point:
 
 - **Atomic skills (`polylith-*`).** Each maps to one `poly` CLI command (or one focused concept). Safe to load in isolation; individually composable. These cover everyday Polylith workflows — creating bricks, syncing, checking, inspecting, and so on.
-- **Orchestrated skill set (`migrate-project/migrate-*`).** A multi-phase workflow with shared state (`migration/<PROJECT>/state.md`) and a git safety net. **Never load an individual `migrate-*` skill directly** — always load `migrate-orchestrator` and let it drive the phases in order. See [`migrate-project/README.md`](./migrate-project/README.md). This is an advanced, explicit-opt-in workflow used for migrating a **non-Polylith** project into a Polylith workspace, **not** part of daily Polylith use.
+- **Orchestrated skill set (`migrate-project/polylith-migrate-*`).** A multi-phase workflow with shared state (`migration/<PROJECT>/state.md`) and a git safety net. **Never load an individual `polylith-migrate-*` skill directly** — always load `polylith-migrate-orchestrator` and let it drive the phases in order. See [`migrate-project/README.md`](./migrate-project/README.md). This is an advanced, explicit-opt-in workflow used for migrating a **non-Polylith** project into a Polylith workspace, **not** part of daily Polylith use.
 
 ## Available Skills (daily Polylith workflows)
 
@@ -31,4 +31,4 @@ Two kinds of skill live under this directory; the distinction matters when picki
 
 ## Advanced workflow
 
-For migrating an existing **non-Polylith** Python project into a Polylith workspace, see [`migrate-project/README.md`](./migrate-project/README.md). This is a destructive, multi-phase, explicit-opt-in workflow — start with the `migrate-orchestrator` skill, not any individual `migrate-*` sub-skill.
+For migrating an existing **non-Polylith** Python project into a Polylith workspace, see [`migrate-project/README.md`](./migrate-project/README.md). This is a destructive, multi-phase, explicit-opt-in workflow — start with the `polylith-migrate-orchestrator` skill, not any individual `polylith-migrate-*` sub-skill.

.agents/skills/polylith/migrate-project/README.md

@@ -1,10 +1,10 @@
 # Project Migration Skills
 
-> **Note for contributors:** this README is a **human reference** and a skill **index**. Agents load each `migrate-*/SKILL.md` independently via the skill loader; this README is **not** auto-loaded with any skill. Anything an agent must know to act has to live in the relevant `SKILL.md` itself, not here.
+> **Note for contributors:** this README is a **human reference** and a skill **index**. Agents load each `polylith-migrate-*/SKILL.md` independently via the skill loader; this README is **not** auto-loaded with any skill. Anything an agent must know to act has to live in the relevant `SKILL.md` itself, not here.
 
 This directory contains skills for migrating **non-Polylith Python projects** into a Polylith workspace. They cooperate via two artifacts under `migration/<PROJECT>/`:
 
-- `state.md` — a flat `KEY=value` file. Canonical schema lives in [`migrate-discover/SKILL.md`](./migrate-discover/SKILL.md).
+- `state.md` — a flat `KEY=value` file. Canonical schema lives in [`polylith-migrate-discover/SKILL.md`](./polylith-migrate-discover/SKILL.md).
 - `manifest.md` — a human-readable structural inventory of the source project.
 
 ---
@@ -28,21 +28,21 @@ This directory contains skills for migrating **non-Polylith Python projects** in
 Load the orchestrator and let it drive the rest:
 
 ```
-Load the `migrate-orchestrator` skill and migrate `projects/<project-name>`.
+Load the `polylith-migrate-orchestrator` skill and migrate `projects/<project-name>`.
 ```
 
 The orchestrator will:
 1. Ask the user for explicit confirmation.
 2. Establish a git safety net (dedicated branch + per-phase commits).
 3. Load and execute each phase skill in order, verifying after each.
 
-> **Why every sub-skill says "do not load directly".** Each `migrate-<phase>` skill's `description:` starts with a redirect to `migrate-orchestrator`. This is intentional: it makes the orchestrator the only valid entry point regardless of which sub-skill the agent's fuzzy-match initially favours. The sub-skills depend on state (`migration/<PROJECT>/state.md`) and a git safety net that only the orchestrator sets up.
+> **Why every sub-skill says "do not load directly".** Each `polylith-migrate-<phase>` skill's `description:` starts with a redirect to `polylith-migrate-orchestrator`. This is intentional: it makes the orchestrator the only valid entry point regardless of which sub-skill the agent's fuzzy-match initially favours. The sub-skills depend on state (`migration/<PROJECT>/state.md`) and a git safety net that only the orchestrator sets up.
 
 ---
 
 ## Downstream installation
 
-When this skill set is installed into another Polylith workspace (e.g. via a skills package), the in-skill `[ENTRY POINT]` / `[Internal sub-skill of migrate-orchestrator …]` markers in each `description:` are the primary routing signal — they ship with the package.
+When this skill set is installed into another Polylith workspace (e.g. via a skills package), the in-skill `[ENTRY POINT]` / `[Internal sub-skill of polylith-migrate-orchestrator …]` markers in each `description:` are the primary routing signal — they ship with the package.
 
 For an extra-strong signal, downstream consumers should add the following snippet to their own repo-level `AGENTS.md` (or equivalent agent-routing file). It is **not** required — the in-skill markers are usually sufficient — but it removes any ambiguity for agents that read `AGENTS.md` before scanning skill descriptions.
 
@@ -51,10 +51,10 @@ For an extra-strong signal, downstream consumers should add the following snippe
 
 When the user asks to migrate a non-Polylith Python project to Polylith
 (e.g. "migrate `projects/<name>` to Polylith"), load the
-`migrate-orchestrator` skill first and let it drive the workflow.
+`polylith-migrate-orchestrator` skill first and let it drive the workflow.
 
-Never load `migrate-discover`, `migrate-extract-to-base`, or any other
-`migrate-*` sub-skill directly — they are phases the orchestrator
+Never load `polylith-migrate-discover`, `polylith-migrate-extract-to-base`, or any other
+`polylith-migrate-*` sub-skill directly — they are phases the orchestrator
 invokes in order, with per-phase verification and git checkpoints
 between them.
 ```
@@ -64,7 +64,7 @@ between them.
 ## Workflow at a glance
 
 The **authoritative** phase order, numbering, and dependencies live in
-[`migrate-orchestrator/SKILL.md`](./migrate-orchestrator/SKILL.md) — it is the
+[`polylith-migrate-orchestrator/SKILL.md`](./polylith-migrate-orchestrator/SKILL.md) — it is the
 **single source of truth**. This README intentionally does **not** repeat the
 table, to avoid drift (sub-skills must not hardcode phase numbers either; they
 reference `<N>` from the orchestrator table).
@@ -78,14 +78,14 @@ At a glance, the flow is:
 > isolate-shared-and-project-logic → distribute-wiring → split-component-internals →
 > refactor-tests → definition-of-done**
 
-### Optional skills (triggered during `migrate-discover`)
+### Optional skills (triggered during `polylith-migrate-discover`)
 
 | Skill                                                                                           | Purpose                                                                                              | Trigger / dependency                                                              |
 |-------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------|
-| [`migrate-convert-linter`](./migrate-convert-linter/SKILL.md)                                   | Align the project's linter/formatter with the **workspace's** configured tool.                      | `CONVERT_LINTER=yes` in `state.md`. Runs between `migrate-discover` and `migrate-analyze-imports`. |
-| [`migrate-convert-type-checker`](./migrate-convert-type-checker/SKILL.md)                       | Align the project's type checker with the **workspace's** configured tool.                          | `CONVERT_TYPE_CHECKER=yes` in `state.md`. Runs between `migrate-discover` and `migrate-analyze-imports`. |
-| [`migrate-convert-package-manager`](./migrate-convert-package-manager/SKILL.md)                 | Convert the project's `pyproject.toml` to uv workspaces. **Opinionated about uv** — only run when the workspace itself uses uv. | `CONVERT_PACKAGE_MANAGER=yes` in `state.md`. Runs between `migrate-discover` and `migrate-analyze-imports`. |
-| [`migrate-dedupe`](./migrate-dedupe/SKILL.md)                                                   | Identify and apply controlled deduplication discovered during refactoring.                          | User approval. Runs after `migrate-split-big-component` or `migrate-extract-standalone-modules`. |
+| [`polylith-migrate-convert-linter`](./polylith-migrate-convert-linter/SKILL.md)                                   | Align the project's linter/formatter with the **workspace's** configured tool.                      | `CONVERT_LINTER=yes` in `state.md`. Runs between `polylith-migrate-discover` and `polylith-migrate-analyze-imports`. |
+| [`polylith-migrate-convert-type-checker`](./polylith-migrate-convert-type-checker/SKILL.md)                       | Align the project's type checker with the **workspace's** configured tool.                          | `CONVERT_TYPE_CHECKER=yes` in `state.md`. Runs between `polylith-migrate-discover` and `polylith-migrate-analyze-imports`. |
+| [`polylith-migrate-convert-package-manager`](./polylith-migrate-convert-package-manager/SKILL.md)                 | Convert the project's `pyproject.toml` to uv workspaces. **Opinionated about uv** — only run when the workspace itself uses uv. | `CONVERT_PACKAGE_MANAGER=yes` in `state.md`. Runs between `polylith-migrate-discover` and `polylith-migrate-analyze-imports`. |
+| [`polylith-migrate-dedupe`](./polylith-migrate-dedupe/SKILL.md)                                                   | Identify and apply controlled deduplication discovered during refactoring.                          | User approval. Runs after `polylith-migrate-split-big-component` or `polylith-migrate-extract-standalone-modules`. |
 
 ---
 
@@ -95,17 +95,17 @@ These skills overlap in vocabulary but address different scopes. Use this matrix
 
 | Skill                                       | Scope                                          | Trigger                                                                   |
 |---------------------------------------------|------------------------------------------------|---------------------------------------------------------------------------|
-| `migrate-split-big-component`               | Within one project; component → multiple components. | The temporary big component (from `migrate-isolate-base-and-big-component`) is too large. |
-| `migrate-extract-standalone-modules`        | Within one project; pulls foundational modules out of the residual. | Residual still contains `consts.py`/`exceptions.py`/`models.py`.  |
-| `migrate-split-component-internals`         | Within one already-extracted shared component; `core.py` → multiple files. | A component's `core.py` mixes multiple domains internally.      |
-| `migrate-isolate-shared-and-project-logic`  | Cross-project; separate shared vs project-specific in components used by ≥ 2 projects. | Migrating a 2nd+ project that overlaps with an already-extracted one. |
+| `polylith-migrate-split-big-component`               | Within one project; component → multiple components. | The temporary big component (from `polylith-migrate-isolate-base-and-big-component`) is too large. |
+| `polylith-migrate-extract-standalone-modules`        | Within one project; pulls foundational modules out of the residual. | Residual still contains `consts.py`/`exceptions.py`/`models.py`.  |
+| `polylith-migrate-split-component-internals`         | Within one already-extracted shared component; `core.py` → multiple files. | A component's `core.py` mixes multiple domains internally.      |
+| `polylith-migrate-isolate-shared-and-project-logic`  | Cross-project; separate shared vs project-specific in components used by ≥ 2 projects. | Migrating a 2nd+ project that overlaps with an already-extracted one. |
 
-> 💡 In a fresh migration of a single project, you usually run `migrate-split-big-component` → `migrate-extract-standalone-modules` → `migrate-split-component-internals`, and skip `migrate-isolate-shared-and-project-logic` until a second project is migrated.
+> 💡 In a fresh migration of a single project, you usually run `polylith-migrate-split-big-component` → `polylith-migrate-extract-standalone-modules` → `polylith-migrate-split-component-internals`, and skip `polylith-migrate-isolate-shared-and-project-logic` until a second project is migrated.
 
 ---
 
 ## Files in this directory
 
 - `README.md` — this file (human reference + index).
-- `migrate-orchestrator/SKILL.md` — entry point; defines the phase order and the git safety net.
-- `migrate-<phase>/SKILL.md` — one per phase referenced in the orchestrator table.
+- `polylith-migrate-orchestrator/SKILL.md` — entry point; defines the phase order and the git safety net.
+- `polylith-migrate-<phase>/SKILL.md` — one per phase referenced in the orchestrator table.

…project/migrate-analyze-imports/SKILL.md …olylith-migrate-analyze-imports/SKILL.md.agents/skills/polylith/migrate-project/migrate-analyze-imports/SKILL.md renamed to .agents/skills/polylith/migrate-project/polylith-migrate-analyze-imports/SKILL.md .agents/skills/polylith/migrate-project/migrate-analyze-imports/SKILL.md renamed to .agents/skills/polylith/migrate-project/polylith-migrate-analyze-imports/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: migrate-analyze-imports
-description: "[Internal sub-skill of `migrate-orchestrator`. Do not load directly — load `migrate-orchestrator` first, which drives all phases.] Analyze the project's import graph to find how the original namespace is referenced, choose the namespace-rewrite strategy (shim vs shimless), detect circular imports, and list symbols exported by the original namespace."
+name: polylith-migrate-analyze-imports
+description: "[Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Analyze the project's import graph to find how the original namespace is referenced, choose the namespace-rewrite strategy (shim vs shimless), detect circular imports, and list symbols exported by the original namespace."
 ---
 
-# Skill: migrate-analyze-imports
+# Skill: polylith-migrate-analyze-imports
 
 ## Goal
 Analyze the project's import graph to:
@@ -13,7 +13,7 @@ Analyze the project's import graph to:
 4. Detect potential circular imports.
 
 This drives the namespace rewrite (phase 4) and, when `SHIM_STRATEGY=shim`, the
-shim sub-track (phase 4b). See the `migrate-orchestrator` table for phase numbers.
+shim sub-track (phase 4b). See the `polylith-migrate-orchestrator` table for phase numbers.
 
 ## Inputs
 - Project name (from `migration/<project-name>/state.md`)
@@ -95,5 +95,5 @@ SHIM_STRATEGY=<shim|shimless>
 git add migration/${PROJECT}/import_analysis.md migration/${PROJECT}/state.md
 git commit -m "migrate(${PROJECT}): phase <N> — analyze-imports"
 ```
-> `<N>` is this phase's number from the `migrate-orchestrator` table (the single
+> `<N>` is this phase's number from the `polylith-migrate-orchestrator` table (the single
 > source of truth) — do not hardcode it.

…migrate-automate-import-updates/SKILL.md …migrate-automate-import-updates/SKILL.md.agents/skills/polylith/migrate-project/migrate-automate-import-updates/SKILL.md renamed to .agents/skills/polylith/migrate-project/polylith-migrate-automate-import-updates/SKILL.md .agents/skills/polylith/migrate-project/migrate-automate-import-updates/SKILL.md renamed to .agents/skills/polylith/migrate-project/polylith-migrate-automate-import-updates/SKILL.md

@@ -1,21 +1,21 @@
 ---
-name: migrate-automate-import-updates
-description: "[Internal sub-skill of `migrate-orchestrator`. Do not load directly — load `migrate-orchestrator` first, which drives all phases.] Update imports in the new base location to reference the new namespace instead of the original namespace."
+name: polylith-migrate-automate-import-updates
+description: "[Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Update imports in the new base location to reference the new namespace instead of the original namespace."
 ---
 
-# Skill: migrate-automate-import-updates
+# Skill: polylith-migrate-automate-import-updates
 
 ## Goal
 Update imports to reference the new namespace instead of the original namespace, ensuring that the codebase remains functional after the namespace migration.
 
-> **Scope depends on `SHIM_STRATEGY`** (set by `migrate-analyze-imports`):
+> **Scope depends on `SHIM_STRATEGY`** (set by `polylith-migrate-analyze-imports`):
 > - `shim`: rewrite imports **in the new base location only** — external consumers keep
 >   using the original namespace via the shim (phase 4b).
 > - `shimless`: rewrite **every** reference to the original namespace — base internals,
 >   entrypoints / run-scripts, infra (e.g. `alembic/env.py`), and tests — so nothing
 >   imports the old namespace and no shim is needed.
 >
-> Cover **all three reference forms** (see `migrate-analyze-imports`): dotted
+> Cover **all three reference forms** (see `polylith-migrate-analyze-imports`): dotted
 > `from <ns>.<sub> import …`, bare-submodule `from <ns> import <sub>` (incl. multi-name
 > and **mixed** lines), and quoted string paths (`mock.patch("<ns>.x.Y")`, logging
 > dict-config). A naive "`from <ns>.`" replace silently misses the bare and quoted forms.
@@ -26,7 +26,7 @@ Update imports to reference the new namespace instead of the original namespace,
 > names — far more reliably than ad-hoc edits across dozens of files. Keep it as plain
 > functions (no classes), run it over `bases/`, `components/`, `test/`, and the project
 > dir, then verify by grepping for any residual `<ns>` reference. The same helper is
-> reusable for the component-extraction rewrites in `migrate-split-big-component`.
+> reusable for the component-extraction rewrites in `polylith-migrate-split-big-component`.
 
 ## Inputs
 - Project name (from `migration/<project-name>/state.md`)
@@ -73,4 +73,4 @@ git add bases/${TARGET_TOP_NS}/${INITIAL_BASE_NAME}/
 git add migration/${PROJECT}/import_updates.md
 git commit -m "migrate(${PROJECT}): phase <N> — automate-import-updates"
 ```
-> `<N>` is this phase's number from the `migrate-orchestrator` table (the single source of truth) — do not hardcode it.
+> `<N>` is this phase's number from the `polylith-migrate-orchestrator` table (the single source of truth) — do not hardcode it.