Skip to content
skillsafebeta
← Report library
Purpose / Development

Deprecation And Migration Skill Security Audit

What the author says it does (original text)

Manages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when migrating a database schema in production, such as renaming or dropping a column without downtime (expand/contract). Use when deciding whether to maintain or sunset existing code.

Independent security check

Security risks found

Files checked
1
Risks found
4
Could it run dangerous commands?Looks for programs run straight after downloading, remote control of your computer, and hidden commands.Risks found: 1
Medium risk

The example runs an npx command with no pinned version or verified source

Source references: 2
What we found

The migration-notice template tells users to run `npx migrate-check` without a version, publisher, source, or integrity check. If the package is not already local, `npx` may download and execute it from the configured registry. This is an example rather than automatic execution, but an agent could copy it into a real migration procedure.

Why this matters

If the registry, package-name resolution, or package is compromised, the downloaded code could access project files and environment variables available to the current user.

Legitimate use of this code

`npx migrate-check` is an example inside a deprecation-notice template, not code that runs automatically, and the source does not establish that this package exists. The risk arises only if an agent or user copies the placeholder into a real workflow, where `npx` may download and execute an unpinned package. A user can require verification of the package identity plus a fixed version and registry source before use.

This assessment concerns the code and conditions shown, not proof that harm has occurred.
SKILL.md:88In the instructionsOpen original file
### Migration Guide1. Replace `import { client } from 'old-service'` with `import { client } from 'new-service'`2. Update configuration (see examples below)3. Run the migration verification script: `npx migrate-check````
Show 1 other places
SKILL.md:77In the instructionsOpen original file
### Step 2: Announce and Document```markdown## Deprecation Notice: OldService
Could it expose your files or keys?Looks for uploads of files containing passwords or keys, and keys written directly in the code.Risks found: 1
Medium risk

The contract phase deletes an old production column and its data

Source references: 3
What we found

The worked example ultimately says to stop writing and drop the old column. Separate deployments and checks for old references reduce compatibility risk, but dropping a column remains destructive. The rule that every migration has a down path does not itself ensure that deleted data can be restored.

Why this matters

If backfill is incomplete, dual-written values diverge, or an undiscovered reader remains, the drop can cause production data loss and application failures. Without a pre-drop data snapshot, reversing the schema cannot reconstruct the old values.

The production database example explicitly ends by dropping the old column, which removes its data. Phasing, dual writes, backfilling, and a separate deployment reduce compatibility and rollout risk, but the required “down path” does not explain how deleted data would be restored. A user can require database-owner approval, proof of no remaining readers, and a restore-tested backup or archive, or restrict the agent to preparing—but not executing—the contract step.

SKILL.md:177In the instructionsOpen original file
1. **Expand.** Add `full_name` as nullable. Deploy. (Old code ignores it; nothing breaks.)2. **Dual-write.** App writes both `name` and `full_name` on every insert/update. Deploy.3. **Backfill.** Copy `name → full_name` for existing rows, in batches, so you don't lock the table.4. **Switch reads.** Point the app at `full_name`, keep writing both. Deploy and bake.5. **Contract.** Stop writing `name`, then — in a *separate, later* deploy — drop the column.
Show 2 other places
SKILL.md:185In the instructionsOpen original file
**Rules:**- **Additive first, destructive last and alone.** Adds (new nullable column, new table, new index) are safe in any deploy; drops and renames get their own deploy *after* no code references the old shape.- **Every migration has a tested down path.** A migration you can't reverse is a deploy you can't roll back. Write and run the `down` before merging.- **Backfill in batches, off the hot path.** A single `UPDATE` over millions of rows locks the table; chunk it and throttle.- **Build large indexes without blocking writes** (e.g. Postgres `CREATE INDEX CONCURRENTLY`).
SKILL.md:166In the instructionsOpen original file
A schema change is the riskiest migration because the data is the one thing you cannot roll back by reverting a deploy. The failure mode is coupling the schema change to the code change: rename a column in the same release that starts using the new name, and during the rollout window — when old and new code run at once — one of them is querying a column that doesn't exist. The fix is to **never change a column in place**. Migrate in additive phases so old and new code are both valid at every step.
Could it delete files or keep running?Looks for broad file deletion, disk overwrites, and programs set to start automatically.Risks found: 1
Medium risk

A mistaken completion decision could permanently remove project assets

Source references: 4
What we found

After migration, the guide instructs removal of old code plus associated tests, documentation, and configuration. It does require all consumers to be migrated and active usage to be zero, but it does not require human approval, a backup, a retention period, or recoverable deletion. Metrics or dependency analysis can miss hidden consumers.

Why this matters

Still-needed code or configuration could be removed, while tests and operational documentation disappear at the same time, causing build failures, outages, or difficult recovery.

The guide explicitly calls for deleting old code, tests, documentation, and configuration, so missed consumers could cause asset loss or regressions. Requiring all consumers to be migrated and zero active usage materially reduces the risk, but there is no requirement for human approval, backup, or recoverable deletion. A user can restrict the agent to producing a cleanup list or patch and require owner confirmation, version-control recovery, and rollback checks before removal.

SKILL.md:110In the instructionsOpen original file
Only after all consumers have migrated:```1. Verify zero active usage (metrics, logs, dependency analysis)2. Remove the code3. Remove associated tests, documentation, and configuration4. Remove the deprecation notices5. Celebrate — removing code is an achievement
Show 3 other places
SKILL.md:96In the instructionsOpen original file
Migrate consumers one at a time, not all at once. For each consumer:```1. Identify all touchpoints with the deprecated system2. Update to use the replacement3. Verify behavior matches (tests, integration checks)4. Remove references to the old system5. Confirm no regressions```
SKILL.md:108In the instructionsOpen original file
### Step 4: Remove the Old SystemOnly after all consumers have migrated:```1. Verify zero active usage (metrics, logs, dependency analysis)2. Remove the code3. Remove associated tests, documentation, and configuration4. Remove the deprecation notices5. Celebrate — removing code is an achievement```
SKILL.md:235In the instructionsOpen original file
- [ ] Replacement is production-proven and covers all critical use cases- [ ] Migration guide exists with concrete steps and examples- [ ] All active consumers have been migrated (verified by metrics/logs)- [ ] Old code, tests, documentation, and configuration are fully removed- [ ] No references to the deprecated system remain in the codebase- [ ] Deprecation notices are removed (they served their purpose)
Could it bypass safety checks?Looks for skipped website security checks, excessive file access, or actions that skip your approval.Risks found: 1
Low risk

The install command does not pin a dependency version

Source references: 3
What we found

The installation command does not specify dependency versions. The same command may download different code later, so what you install can differ from what was checked.

Why this matters

A later install may download different code even though the command and this report have not changed.

Legitimate use of this code

This appears inside a fictional Markdown deprecation-notice example. `migrate-check` is a placeholder name, not an installation step or an actual dependency of the Skill. It is unpinned, so copying it into a real migration could let `npx` fetch and run registry code. A user can ask that placeholders be clearly marked and that real guides use a trusted source and fixed version. These lines do not show that the Skill itself installs the package.

This assessment concerns the code and conditions shown, not proof that harm has occurred.
SKILL.md:91In the instructionsOpen original file
2. Update configuration (see examples below)3. Run the migration verification script: `npx migrate-check````
Show 2 other places
SKILL.md:79In the instructionsOpen original file
```markdown## Deprecation Notice: OldService
SKILL.md:88In the instructionsOpen original file
### Migration Guide1. Replace `import { client } from 'old-service'` with `import { client } from 'new-service'`2. Update configuration (see examples below)3. Run the migration verification script: `npx migrate-check````
Could it mislead the AI or hide text?Checks the skill instructions for requests to ignore you, influence the report, or hide text in invisible characters.No risks found
Could it change links or payment recipients without asking?Looks for forced referral or payment changes combined with instructions to hide the change.No risks found

Inside this skill

8 instruction sections

This Skill is a procedural guide for deprecation and migration. Its stated scope includes replacing old systems, sunsetting features, deleting dead code, and changing production database schemas. The provided source contains only Markdown, with no accompanying scripts or installation configuration to audit.

View source
SKILL.md:2In the instructionsOpen original file
---name: deprecation-and-migrationdescription: Manages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when migrating a database schema in production, such as renaming or dropping a column without downtime (expand/contract). Use when deciding whether to maintain or sunset existing code.---

The guide generally requires a working replacement, incremental consumer migration, and behavior verification before removing the old system. It also calls for confirming zero active usage through metrics, logs, and dependency analysis.

View source
SKILL.md:96In the instructionsOpen original file
Migrate consumers one at a time, not all at once. For each consumer:```1. Identify all touchpoints with the deprecated system2. Update to use the replacement3. Verify behavior matches (tests, integration checks)4. Remove references to the old system5. Confirm no regressions```
SKILL.md:108In the instructionsOpen original file
### Step 4: Remove the Old SystemOnly after all consumers have migrated:```1. Verify zero active usage (metrics, logs, dependency analysis)2. Remove the code3. Remove associated tests, documentation, and configuration4. Remove the deprecation notices

For databases, the guide recommends an expand–migrate–contract sequence: add and backfill a new column, switch reads, and delete the old column in a separate deployment. It also recommends batched backfills to avoid long table locks.

View source
SKILL.md:177In the instructionsOpen original file
1. **Expand.** Add `full_name` as nullable. Deploy. (Old code ignores it; nothing breaks.)2. **Dual-write.** App writes both `name` and `full_name` on every insert/update. Deploy.3. **Backfill.** Copy `name → full_name` for existing rows, in batches, so you don't lock the table.4. **Switch reads.** Point the app at `full_name`, keep writing both. Deploy and bake.5. **Contract.** Stop writing `name`, then — in a *separate, later* deploy — drop the column.
Start here · InstructionsSKILL.md
deprecation-and-migration
Lines connect the instruction file to its sections, not an observed execution order. Select a section to read the source. 3 more sections are available in the original file.
Files and check records1 files

Coverage and gaps

Content covered in each file

These are the source ranges included in this check, not a guarantee that every issue has been resolved.

  • SKILL.mdFull text included

This report is for the version above. We read the available code and instructions without running the skill or checking extra packages it installs. This is not a promise of safety: a different version or setup may behave differently.

  • SKILL.mdInstructions

Operations mentioned in code and instructions

Install extra software packages
SKILL.md:91In the instructionsOpen original file
2. Update configuration (see examples below)3. Run the migration verification script: `npx migrate-check````
Lines read
248
File checksum (to compare versions)
c1e33cc702c9512154261bfc7387c5b4854d2b69be1e43a9f3045b667d1b062b