/codemod-generator

name: codemod-generator
description: "Generate tested jscodeshift/postcss codemods for design system migrations: token renames, prop renames or removals, import paths, component swaps. Triggers: codemod, migration script, rename this prop everywhere. Deprecation planning: deprecation-process. Release notes: change-communication."
allowed-tools: Read, Write, Grep, Glob, Bash(cat:*), Bash(find:*), Bash(head:*), Bash(ls:*), Bash(node:*), Bash(sort:*), Bash(tail:*), Bash(wc:*), Bash(npx tsc:*), Bash(npx jscodeshift:*), Bash(npx jest:*), Bash(npx vitest:*)
references:
  - ../../knowledge-notes/component-governance.md
  - ../../knowledge-notes/design-to-code-contract.md
  - ../../knowledge-notes/output-discipline.md

Codemod Generator

A skill for producing automated code transformation scripts that apply design system changes across consuming codebases. When a token is renamed, a component API changes, or an import path moves, this skill generates the script that makes the change everywhere — safely, consistently, and with a dry-run option.

**Output type:** File creation. This skill produces executable transformation scripts (JavaScript/TypeScript) and documentation. It does not apply the transformations to the team's code — it generates scripts that teams run in their own codebases. Where you can execute commands, it does run the tests and a dry run (Step 5b).

---

Before you begin: verify references

Confirm that every path in this skill's frontmatter `references:` exists relative to this SKILL.md. If any is missing, stop: the install is incomplete, usually because a flattening installer (for example `npx skills install`) dropped the repo-root `knowledge-notes/` directory. Tell the user to reinstall by a method in `1-INSTALL.md` and run `verify-install.sh` from the install root. Proceed without the references only if the user explicitly says to, and then say in the output that it was produced without the pack's reference material.

Why this exists

A design system change without a migration path is a breaking promise, and the manual find-and-replace is where upgrade debt accumulates until teams stop upgrading. A codemod does the mechanical part deterministically across every file. This skill generates the script and its tests; the deprecation plan and the migration guide stay with `deprecation-process` and `change-communication`.

---

Configuration

If `.ds-ops-config.yml` exists, follow the configuration-and-recurring knowledge note (`../../knowledge-notes/configuration-and-recurring.md`). This skill reads:

codemods:
  language: "typescript"              # typescript, javascript, or both
  transform_engine: "jscodeshift"     # jscodeshift, ts-morph, or custom
  output_directory: "codemods/"
  test_framework: "jest"              # jest or vitest for codemod tests
  style_dictionary_format: false      # If tokens use Style Dictionary format
  css_custom_properties: true         # If tokens are consumed as CSS custom properties

If no configuration exists, use these defaults:

• Language: TypeScript
• Transform engine: jscodeshift
• Output directory: `codemods/`
• Test framework: jest

---

Codemod types

This skill generates five types of codemods:

Type 1: Token rename

Renames a design token across all consuming files.

**Scope:** CSS custom properties, JavaScript/TypeScript token imports, Sass variables, style objects, className references, and template-literal CSS in styled-components and Emotion (`css\`...\``, `styled.div\`...\``), which is where most CSS-in-JS token references live.

**Example input:**

Rename: color.brand.primary → color.action.primary
Affects: CSS custom properties (--color-brand-primary → --color-action-primary)
         JS token imports (tokens.color.brand.primary → tokens.color.action.primary)
         Sass variables ($color-brand-primary → $color-action-primary)

Type 2: Component prop rename

Renames a component prop across all usage sites.

**Example input:**

Component: Button
Rename prop: type → variant
Value mapping: type="primary" → variant="primary" (no value change)

Type 3: Component prop removal

Removes a deprecated prop with a safe fallback or migration.

**Example input:**

Component: Button
Remove prop: disableRipple
Migration: Delete the attribute (the ripple effect has been removed from the system).
If the value is dynamic (disableRipple={flag}), leave it and add a TODO comment,
since removing it may drop logic the consumer relies on.

Type 4: Import path update

Updates import paths when packages are restructured.

**Example input:**

Old: import { Button } from '@myds/components'
New: import { Button } from '@myds/react/Button'

Type 5: Component replacement

Replaces one component with another, mapping props.

**Example input:**

Replace: DatePicker → DatePickerNext
Prop mapping:
  - value → selectedDate
  - onChange → onDateChange
  - format → dateFormat (default: "yyyy-MM-dd")
  - minDate → min
  - maxDate → max
Removed props: locale (now uses system locale)
New required props: none

---

Step 0: Determine the codemod type

From the user's request, determine:

1. **What is changing?** Token name, prop name, import path, or component replacement 2. **What are the before and after states?** Exact old and new values 3. **What is the scope?** CSS, JS/TS, Sass, all of the above 4. **Are there edge cases?** Conditional logic, dynamic values, spread props 5. **Is there a value mapping?** Or is it a straight rename

If the request is unclear on any of these, ask before generating. A codemod that transforms the wrong thing is worse than no codemod at all.

---

Step 1: Generate the transform script

**Pick the engine for the change.** jscodeshift for syntactic changes (renames, attribute edits, import paths), which is most of them. ts-morph when the transform needs type information, for example renaming a prop only on components whose props extend a given inte