cc-session-tools 3.3.0__tar.gz → 3.3.2__tar.gz

{cc_session_tools-3.3.0/src/cc_session_tools.egg-info → cc_session_tools-3.3.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: cc-session-tools
-Version: 3.3.0
+Version: 3.3.2
 Summary: Claude Code session management CLI tools (ccd, ccr, ccs, claude-code-usage, ccst) and hook library (hooks package)
 Author: raffishquartan
 License: MIT License

{cc_session_tools-3.3.0 → cc_session_tools-3.3.2}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "cc-session-tools"
-version = "3.3.0"
+version = "3.3.2"
 description = "Claude Code session management CLI tools (ccd, ccr, ccs, claude-code-usage, ccst) and hook library (hooks package)"
 readme = "README.md"
 license = { file = "LICENSE" }

{cc_session_tools-3.3.0 → cc_session_tools-3.3.2}/src/cc_session_tools/lib/pdata/classify.py

@@ -8,7 +8,7 @@ apart by a generic scan; guessing wrong here would silently bake a per-project
 judgement call into shared tooling, which this plan must not do (see the
 per-project inventory doc, not this module, for those calls). Every markdown/
 text/unknown-extension file defaults to folder-owned; a human (via the
-pm-project-init skill) reviews the printed report and flips individual entries
+pm-pdata-do-init skill) reviews the printed report and flips individual entries
 to db-owned with an explicit record_group/strategy.
 """
 from __future__ import annotations

{cc_session_tools-3.3.0 → cc_session_tools-3.3.2}/src/cc_session_tools/lib/pdata/cutover.py

@@ -14,7 +14,7 @@ from cc_session_tools.lib.pdata.manifest import ManifestEntry
 def _pointer_file_content(*, project: str, entry: ManifestEntry) -> str:
     """Generic pointer content (spec pdata/init-pointer-files): the record_group now
     holding this file's data, its field/schema table, and an example query — plus,
-    when the entry carries preface_text (set by hand per pm-project-init's
+    when the entry carries preface_text (set by hand per pm-pdata-do-init's
     garbled-CSV-header fix recipe), that text verbatim under its own heading."""
     lines = [
         f"# {Path(entry.path).name} — migrated to pdata",

{cc_session_tools-3.3.0 → cc_session_tools-3.3.2}/src/cc_session_tools/lib/pdata/importers.py

@@ -89,7 +89,7 @@ def import_json_array_rows(project_root: Path, entry: ManifestEntry) -> list[Imp
     path = project_root / entry.path
     created_at = _mtime(path)
     data: Any = json.loads(path.read_text(encoding="utf-8"))
-    # A hand-edited manifest entry (pm-project-init Step 4 instructs editing this
+    # A hand-edited manifest entry (pm-pdata-do-init Step 4 instructs editing this
     # file directly) can assign 'json-array-rows' to a file whose actual JSON
     # shape isn't an array of objects. Validate the shape here and raise
     # ValueError — the exact exception type write()'s per-entry

{cc_session_tools-3.3.0 → cc_session_tools-3.3.2}/src/cc_session_tools/lib/pdata/init_service.py

@@ -136,7 +136,7 @@ def _render_report(m: Manifest) -> str:
                 lines.append(
                     "    ⚠ worth double-checking — these field names read as sentence "
                     "fragments, not column names; this file's header may not be what it "
-                    "looks like (see pm-project-init's garbled-CSV-header caveat)"
+                    "looks like (see pm-pdata-do-init's garbled-CSV-header caveat)"
                 )
     lines.append(
         "Review/override entries in the proposal file listed below before running --write."

{cc_session_tools-3.3.0 → cc_session_tools-3.3.2}/src/cc_session_tools/lib/pdata/manifest.py

@@ -44,7 +44,7 @@ class ManifestEntry:
     # --write skips any entry that already carries one instead of re-importing it
     # (spec pdata/init-write-idempotency). None for an entry never yet migrated.
     migrated_at: str | None = None
-    # Hand-set during review (pm-project-init's garbled-CSV-header fix recipe):
+    # Hand-set during review (pm-pdata-do-init's garbled-CSV-header fix recipe):
     # header/provenance text stripped from the source file before migration,
     # preserved verbatim here so cutover.archive_entries can carry it into the
     # entry's pointer file (spec pdata/init-pointer-files). None when not applicable.
@@ -95,7 +95,7 @@ def load(path: Path) -> Manifest:
     """Raises ValueError (never a raw KeyError/TypeError/AttributeError) for any
     malformed proposal file — a missing "project"/"entries" key, an "entries" that
     isn't a list, an entry that isn't an object, or an entry with an unexpected
-    field shape. This is a real hand-edit surface (pm-project-init Step 4
+    field shape. This is a real hand-edit surface (pm-pdata-do-init Step 4
     instructs editing this file directly), so a shape error here must reach
     _cmd_pdata_init's `except (FileNotFoundError, ValueError)` and dry_run's
     `except ValueError` and produce the documented exit-2 validation error instead

{cc_session_tools-3.3.0 → cc_session_tools-3.3.2}/src/cc_session_tools/lib/pdata/resolve.py

@@ -8,7 +8,7 @@ overwrite (that is rehydrate.py's job for the clean fast-forward case; this modu
 
 Never auto-merges, never silently keeps one side and discards the other — every record surfaced
 here needs an explicit choice from the caller (ultimately Chris, via the CLI/skill), matching the
-existing `pm-pdata-conflict-resolution` skill's single-file-conflict framing exactly. Every
+existing `pm-pdata-resolve-conflicts` skill's single-file-conflict framing exactly. Every
 record: `apply_resolution` is all-or-nothing over the whole diff, for the reasons in its own
 docstring.
 
@@ -342,7 +342,7 @@ def _apply_resolution(
             f"record_id(s) {collisions}: id collision (the same id was independently assigned to "
             f"two unrelated records) — not resolvable as a local/dump choice, since either pick "
             f"would discard one side's real record; needs a manual, out-of-band fix (see the "
-            f"pm-pdata-conflict-resolution skill, point 4)"
+            f"pm-pdata-resolve-conflicts skill, point 4)"
         )
 
     group_mismatches = sorted(rid for rid, rd in by_id.items() if rd.group_mismatch)
@@ -351,7 +351,7 @@ def _apply_resolution(
             f"record_id(s) {group_mismatches}: group mismatch (same id and created_at, but the "
             f"two sides disagree on record_group) — not resolvable as a local/dump choice. "
             f"Compare each side's content/file_path before assuming a rename is safe (see the "
-            f"pm-pdata-conflict-resolution skill, point 5, for why it may instead be a "
+            f"pm-pdata-resolve-conflicts skill, point 5, for why it may instead be a "
             f"same-second id collision), then retry"
         )
 

{cc_session_tools-3.3.0 → cc_session_tools-3.3.2}/src/cc_session_tools/lib/pdata/service.py

@@ -310,7 +310,7 @@ def update_record(
     content and fields are independent — updating fields never re-serializes content, and vice
     versa. This is deliberate (it's what lets a --field-only update skip resending content), not
     a gap: a record group whose content is designed to mirror its fields is the caller's own
-    duplication to keep in sync, on every write, by passing both. See pm-pdata-schema-design
+    duplication to keep in sync, on every write, by passing both. See pm-pdata-design-schema
     SKILL.md's "content and extension fields are never auto-synced" section."""
     if content is None and file_path is None and not fields:
         raise ValueError(

{cc_session_tools-3.3.0/src/cc_session_tools/skills/pm-pdata-schema-design → cc_session_tools-3.3.2/src/cc_session_tools/skills/pm-pdata-design-schema}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: pm-pdata-schema-design
+name: pm-pdata-design-schema
 description: Use before writing a genuinely new kind of structured data into any project's ccst pdata store - deciding whether it fits an existing record_group, needs a brand-new group, and whether that group needs an extension table or free-text content suffices. Triggers on "I need to track a new kind of record", "what record_group should this be", "does this need an extension table", "add a new field to ccst pdata", or any session about to call `ccst pdata add`/`schema add-field` for a record shape it hasn't used before. Prevents lazy catch-all groups (`notes`/`misc`) that silently recreate the EAV undifferentiated-bucket problem the schema deliberately rejected.
 ---
 

{cc_session_tools-3.3.0 → cc_session_tools-3.3.2}/src/cc_session_tools/skills/pm-pdata-do-audit-and-prepare-to-migrate/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: pm-pdata-do-audit-and-prepare-to-migrate
-description: Full consistency/completeness audit of a project's central and recordkeeping files - OneDrive sync-conflict cleanup, cross-checking every index/register/log against what it claims to describe, and a pdata-migration readiness pass. Ends by writing a readiness manifest file that feeds `ccst pdata init` (via `pm-project-init`) - the tool-native migration mechanism - and, only for the narrow record shapes it can't express, the deprecated `pm-pdata-do-migrate` fallback. Triggers on "review all my central files", "audit the project files", "check everything is up to date and consistent", "get this project ready for pdata", "/pm-pdata-do-audit-and-prepare-to-migrate", or any request for a thorough review/health-check of a project's index/log/register files (as opposed to a single-session wrap-up, which is pm-update-central-files). Especially relevant when a project is scheduled to migrate to pdata - this audit is the recommended prerequisite pass, since a schema design should not be built against files that still have unresolved sync-conflict duplicates or known dangling rows.
+description: Full consistency/completeness audit of a project's central and recordkeeping files - OneDrive sync-conflict cleanup, cross-checking every index/register/log against what it claims to describe, and a pdata-migration readiness pass. Ends by writing a readiness manifest file that feeds `ccst pdata init` (via `pm-pdata-do-init`) - the tool-native migration mechanism - and, only for the narrow record shapes it can't express, the deprecated `pm-pdata-do-manual-migration` fallback. Triggers on "review all my central files", "audit the project files", "check everything is up to date and consistent", "get this project ready for pdata", "/pm-pdata-do-audit-and-prepare-to-migrate", or any request for a thorough review/health-check of a project's index/log/register files (as opposed to a single-session wrap-up, which is pm-update-central-files). Especially relevant when a project is scheduled to migrate to pdata - this audit is the recommended prerequisite pass, since a schema design should not be built against files that still have unresolved sync-conflict duplicates or known dangling rows.
 ---
 
 # Audit central files
 
 > **This audit feeds `ccst pdata init`, not a manual migration.** The readiness manifest this
 > skill produces (Phase 5) is a pre-flight pass for `ccst pdata init` (driven by the
-> `pm-project-init` skill) - the tool-native, default migration mechanism. `pm-pdata-do-migrate`
+> `pm-pdata-do-init` skill) - the tool-native, default migration mechanism. `pm-pdata-do-manual-migration`
 > is a deprecated fallback for record shapes `ccst pdata init` genuinely can't express; it is not
 > the default next step after this audit.
 
@@ -121,7 +121,7 @@ Give the user a single reviewable delete script for every confirmed-safe deletio
 ## Phase 4: pdata-readiness pass
 
 Compile a dedicated `pdata-readiness-notes.md` (or equivalent) listing, file by file, every
-blocker a future `pm-pdata-schema-design` session would hit if it tried to design a schema
+blocker a future `pm-pdata-design-schema` session would hit if it tried to design a schema
 against the file as it currently stands:
 
 - Inconsistent separator/delimiter use within one logical column.
@@ -137,10 +137,10 @@ against the file as it currently stands:
   means something different from a genuinely blank one).
 
 This file is deliberately NOT a migration plan - it's a findings list for whoever runs the actual
-`pm-pdata-schema-design` session next, so that work isn't designed against a still-messy
+`pm-pdata-design-schema` session next, so that work isn't designed against a still-messy
 substrate.
 
-## Phase 5: write the readiness manifest (for `ccst pdata init`/`pm-project-init` to consume)
+## Phase 5: write the readiness manifest (for `ccst pdata init`/`pm-pdata-do-init` to consume)
 
 Once the audit reaches a settled state (per your own stopping rule - typically two consecutive
 clean verification rounds, or a documented pragmatic stop), write one machine-and-human-readable
@@ -151,8 +151,8 @@ otherwise the project's own top-level docs location. Its existence and location
 recorded in the project's own instructions file (`CLAUDE.md`/`AGENTS.md`/equivalent) so a future
 session doesn't have to search for it.
 
-The manifest must have, in this order, so a `pm-project-init` session running `ccst pdata init`
-(or, for the narrow record shapes it can't express, the deprecated `pm-pdata-do-migrate`
+The manifest must have, in this order, so a `pm-pdata-do-init` session running `ccst pdata init`
+(or, for the narrow record shapes it can't express, the deprecated `pm-pdata-do-manual-migration`
 fallback) can parse it deterministically:
 
 1. **Header**: audit date, session/agent identifier, and an explicit "STALE IF" note - state the
@@ -161,8 +161,8 @@ fallback) can parse it deterministically:
 2. **File inventory**: every central/index/recordkeeping file the audit covered, with: full path,
    row/entry count, last-verified-clean date, and its role (`index`, `register`, `log`,
    `narrative`, `derived-artefact`).
-3. **Per-file migration blockers**, in the exact shape `pm-pdata-schema-design` and
-   `pm-project-init` expect to consume - this is the same content this skill's own Phase 4
+3. **Per-file migration blockers**, in the exact shape `pm-pdata-design-schema` and
+   `pm-pdata-do-init` expect to consume - this is the same content this skill's own Phase 4
    already produces, just formalised into the manifest rather than a standalone prose report:
    inconsistent separators, unstable/non-existent natural keys, mixed date formats, multi-schema
    single files, machine-specific paths, null-value conventions that aren't real nulls.

{cc_session_tools-3.3.0/src/cc_session_tools/skills/pm-project-init → cc_session_tools-3.3.2/src/cc_session_tools/skills/pm-pdata-do-init}/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: pm-project-init
-description: Use when initializing a brand-new project's ccst pdata store, or migrating an existing ~/cc/<project>'s informally-accumulated flat files into it - drives `ccst pdata init` and applies judgement reviewing its classification report (spec §3's folder-owned/db-owned framework), since the tool's own defaults are deliberately conservative and need a human decision on every ambiguous file. Triggers - "migrate <project> to pdata", "run pdata init for <project>", "set up the data store for <project>", "/pm-project-init". Do NOT use for ccst pdata verify, per-record-group schema design (pm-pdata-schema-design), or version-conflict reconciliation (pm-pdata-conflict-resolution) - those are separate skills.
+name: pm-pdata-do-init
+description: Use when initializing a brand-new project's ccst pdata store, or migrating an existing ~/cc/<project>'s informally-accumulated flat files into it - drives `ccst pdata init` and applies judgement reviewing its classification report (spec §3's folder-owned/db-owned framework), since the tool's own defaults are deliberately conservative and need a human decision on every ambiguous file. Triggers - "migrate <project> to pdata", "run pdata init for <project>", "set up the data store for <project>", "/pm-pdata-do-init". Do NOT use for ccst pdata verify, per-record-group schema design (pm-pdata-design-schema), or version-conflict reconciliation (pm-pdata-resolve-conflicts) - those are separate skills.
 ---
 
-# pm-project-init
+# pm-pdata-do-init
 
 Drives `ccst pdata init` (spec §7) end to end and applies the judgement the tool itself
 deliberately does not: `ccst pdata init`'s automatic classifier only proposes CSV/JSON files as

{cc_session_tools-3.3.0/src/cc_session_tools/skills/pm-pdata-do-migrate → cc_session_tools-3.3.2/src/cc_session_tools/skills/pm-pdata-do-manual-migration}/SKILL.md

@@ -1,12 +1,12 @@
 ---
-name: pm-pdata-do-migrate
-description: Execute a project's actual migration from flat central/index files to a ccst pdata record store - build a migration plan, adversarially verify the plan itself, present it for the user's confirmation, then execute it and write a results file. Consumes the readiness manifest pm-pdata-do-audit-and-prepare-to-migrate produces if one exists, but always explores the project independently too, so it works even without that manifest. Triggers on "migrate this project to pdata", "run the pdata migration", "/pm-pdata-do-migrate", or any request to actually move a project's CSV/index/log files into pdata (as opposed to just auditing readiness, which is pm-pdata-do-audit-and-prepare-to-migrate, or designing the target schema in the abstract, which is pm-pdata-schema-design).
+name: pm-pdata-do-manual-migration
+description: Execute a project's actual migration from flat central/index files to a ccst pdata record store - build a migration plan, adversarially verify the plan itself, present it for the user's confirmation, then execute it and write a results file. Consumes the readiness manifest pm-pdata-do-audit-and-prepare-to-migrate produces if one exists, but always explores the project independently too, so it works even without that manifest. Triggers on "migrate this project to pdata", "run the pdata migration", "/pm-pdata-do-manual-migration", or any request to actually move a project's CSV/index/log files into pdata (as opposed to just auditing readiness, which is pm-pdata-do-audit-and-prepare-to-migrate, or designing the target schema in the abstract, which is pm-pdata-design-schema).
 ---
 
-# Migrate a project to pdata
+# Manually migrate a project to pdata (deprecated fallback)
 
 > **Deprecated fallback — `ccst pdata init` is the standard mechanism.** `ccst pdata init`
-> (driven by the `pm-project-init` skill) is the tool-native migration mechanism: classification,
+> (driven by the `pm-pdata-do-init` skill) is the tool-native migration mechanism: classification,
 > a human-reviewable manifest, backup, verify, atomic cutover, and shipped post-write doc/skill-
 > update prompts. It is the default choice wherever it is available, and this skill is superseded
 > by it for any file `ccst pdata init`'s classifier can already handle (a normal CSV/JSON file
@@ -25,9 +25,9 @@ description: Execute a project's actual migration from flat central/index files
 
 - `pm-pdata-do-audit-and-prepare-to-migrate` - readiness audit. Finds and fixes problems in the CURRENT flat files.
   Produces a readiness manifest. Does not touch pdata at all.
-- `pm-pdata-schema-design` - designs the TARGET record-group schema in the abstract (field names,
+- `pm-pdata-design-schema` - designs the TARGET record-group schema in the abstract (field names,
   types, groupings) before any data moves.
-- `pm-pdata-do-migrate` (this skill) - takes whatever schema exists (designed via the skill above,
+- `pm-pdata-do-manual-migration` (this skill) - takes whatever schema exists (designed via the skill above,
   or designed inline as part of this skill's own plan if no separate design session happened) and
   actually moves the data: `ccst pdata add`/`batch` calls, verification, and a results record.
 
@@ -59,7 +59,7 @@ audit pass would.
 
 ## Step 2: design or confirm the target schema
 
-For each central file being migrated, decide (or confirm, if `pm-pdata-schema-design` already
+For each central file being migrated, decide (or confirm, if `pm-pdata-design-schema` already
 ran):
 
 - **Record group name** - typically the file's own conceptual name (`correspondence-log`,

{cc_session_tools-3.3.0/src/cc_session_tools/skills/pm-pdata-conflict-resolution → cc_session_tools-3.3.2/src/cc_session_tools/skills/pm-pdata-resolve-conflicts}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: pm-pdata-conflict-resolution
+name: pm-pdata-resolve-conflicts
 description: Use immediately when `ccst pdata update` or `ccst pdata delete` exits 3 (a version conflict) - takes the CLI's current-vs-attempted diff and presents it to Chris for reconciliation, per spec §6.2's "the session asks Chris how to reconcile" contract. Also use when `ccst pdata resolve` reports a cross-machine fork (a `.pdata-db-dump` conflict between two laptops), or phrasing like "pdata update conflict", "version conflict on a record", "someone else already updated this row", "sync conflict", "pdata fork between machines". Never auto-retries, never silently picks a side, never discards either version.
 ---
 

{cc_session_tools-3.3.0 → cc_session_tools-3.3.2}/src/cc_session_tools/skills/pm-project-layout-reference/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: pm-project-layout-reference
-description: Canonical reference for ~/cc/<project>'s optional folder conventions (correspondence/, meetings-and-calls/, analysis/, workstreams/, workstreams-archived/) and the assessment criteria for using them - which folders a given project needs, when correspondence/ should nest by year, and how a workstream moves from active to archived. Read this before setting up a new project's folders, before reorganising an existing project's layout, or before deciding whether a project's correspondence/ needs splitting. Reference-only - does not perform any reorganisation itself; for an actual flat-to-nested split once you've decided one is needed, see `ccst pdata reorganize`. Triggers - "how should this project be organised", "should correspondence/ be split", "archive this workstream", "/pm-project-layout-reference". Do NOT use for the pdata data-store migration itself (pm-project-init) or per-record-group schema design (pm-pdata-schema-design) - those are separate skills; this one is about folder-owned content and structure, not the data store.
+description: Canonical reference for ~/cc/<project>'s optional folder conventions (correspondence/, meetings-and-calls/, analysis/, workstreams/, workstreams-archived/) and the assessment criteria for using them - which folders a given project needs, when correspondence/ should nest by year, and how a workstream moves from active to archived. Read this before setting up a new project's folders, before reorganising an existing project's layout, or before deciding whether a project's correspondence/ needs splitting. Reference-only - does not perform any reorganisation itself; for an actual flat-to-nested split once you've decided one is needed, see `ccst pdata reorganize`. Triggers - "how should this project be organised", "should correspondence/ be split", "archive this workstream", "/pm-project-layout-reference". Do NOT use for the pdata data-store migration itself (pm-pdata-do-init) or per-record-group schema design (pm-pdata-design-schema) - those are separate skills; this one is about folder-owned content and structure, not the data store.
 ---
 
 # pm-project-layout-reference
@@ -64,7 +64,7 @@ These criteria apply to any of the folders above, not just `correspondence/`:
 
 These five folders hold folder-owned content by definition - genuinely file-shaped material
 (attachments, PDFs, `.eml` originals) that isn't a good fit for becoming pdata rows. A project
-being pdata-migrated (see `pm-project-init`) says nothing about whether it also has any of these
+being pdata-migrated (see `pm-pdata-do-init`) says nothing about whether it also has any of these
 five folders, and vice versa - they're orthogonal. `home` is the concrete example: it's
 pdata-migrated (its structured data now lives in SQLite) and still has a live `correspondence/`
 folder full of `.md`+`.pdf` pairs, untouched by the migration, sitting right next to its `data/`

{cc_session_tools-3.3.0 → cc_session_tools-3.3.2/src/cc_session_tools.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: cc-session-tools
-Version: 3.3.0
+Version: 3.3.2
 Summary: Claude Code session management CLI tools (ccd, ccr, ccs, claude-code-usage, ccst) and hook library (hooks package)
 Author: raffishquartan
 License: MIT License

{cc_session_tools-3.3.0 → cc_session_tools-3.3.2}/src/cc_session_tools.egg-info/SOURCES.txt

@@ -123,11 +123,11 @@ src/cc_session_tools/skills/move-session/SKILL.md
 src/cc_session_tools/skills/move-session/hooks/sessionstart-pending-rename.sh
 src/cc_session_tools/skills/move-session/scripts/cc_session_rules.py
 src/cc_session_tools/skills/move-session/scripts/move_session.py
-src/cc_session_tools/skills/pm-pdata-conflict-resolution/SKILL.md
+src/cc_session_tools/skills/pm-pdata-design-schema/SKILL.md
 src/cc_session_tools/skills/pm-pdata-do-audit-and-prepare-to-migrate/SKILL.md
-src/cc_session_tools/skills/pm-pdata-do-migrate/SKILL.md
-src/cc_session_tools/skills/pm-pdata-schema-design/SKILL.md
-src/cc_session_tools/skills/pm-project-init/SKILL.md
+src/cc_session_tools/skills/pm-pdata-do-init/SKILL.md
+src/cc_session_tools/skills/pm-pdata-do-manual-migration/SKILL.md
+src/cc_session_tools/skills/pm-pdata-resolve-conflicts/SKILL.md
 src/cc_session_tools/skills/pm-project-layout-reference/SKILL.md
 src/cc_session_tools/skills/pm-update-central-files/SKILL.md
 src/cc_session_tools/skills/reduce-persistent-context/CALIBRATION.md

{cc_session_tools-3.3.0 → cc_session_tools-3.3.2}/tests/test_ccst_bundle_discovery.py

@@ -140,17 +140,18 @@ def test_bundled_prompts_are_no_longer_placeholders():
         assert "PLACEHOLDER" not in text
 
 
-def test_pm_pdata_audit_and_migrate_are_bundled_skills():
-    """pm-pdata-do-audit-and-prepare-to-migrate and pm-pdata-do-migrate (renamed from
-    pm-pdata-audit/pm-pdata-migrate in 3.1.0 for clarity) were built directly under
-    ~/.claude/skills/ in an earlier session - moved into this repo's bundled skills/ so
-    ccst skills install / install-everything provision them on every machine, not just the
-    one they were authored on. No registry to update - _discover_skills is a directory scan
-    (any subdir with a SKILL.md), so this test is really asserting the directories/files
+def test_pm_pdata_audit_and_manual_migration_are_bundled_skills():
+    """pm-pdata-do-audit-and-prepare-to-migrate and pm-pdata-do-manual-migration (renamed from
+    pm-pdata-audit/pm-pdata-migrate in 3.1.0, then pm-pdata-do-migrate renamed again to
+    pm-pdata-do-manual-migration for clarity once it became a deprecated fallback) were built
+    directly under ~/.claude/skills/ in an earlier session - moved into this repo's bundled
+    skills/ so ccst skills install / install-everything provision them on every machine, not
+    just the one they were authored on. No registry to update - _discover_skills is a directory
+    scan (any subdir with a SKILL.md), so this test is really asserting the directories/files
     exist and are named correctly."""
     discovered = {p.name for p in ccst._discover_skills(ccst._discover_source_dir())}
     assert "pm-pdata-do-audit-and-prepare-to-migrate" in discovered
-    assert "pm-pdata-do-migrate" in discovered
+    assert "pm-pdata-do-manual-migration" in discovered
 
 
 def test_compact_smart_is_a_bundled_skill():