/codemod-generator

name: codemod-generator
description: "Generate codemods (automated code transformation scripts) for design system migrations — token renames, component API changes, prop deprecations, and import path updates. Produces ready-to-run jscodeshift or custom AST transform scripts that safely apply changes across consuming codebases. Trigger when someone says: generate a codemod, automate this migration, write a transform script, bulk rename tokens, auto-migrate components, jscodeshift for this change, create a migration script, update all imports, rename this prop everywhere, or anything about automating code changes across consumers of a design system. Do NOT trigger for planning the deprecation process — use deprecation-process for that. Do NOT trigger for writing release notes about a change — use change-communication for that."
references:
  - ../../knowledge-notes/component-governance.md
  - ../../knowledge-notes/design-to-code-contract.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 execute the transformations — it generates scripts that teams run in their own codebases.

---

Why this exists

A design system change without a migration path is a breaking promise. When you rename `color.brand.primary` to `color.action.primary`, every consumer who uses that token has to find and replace it — manually, across every file, hoping they do not miss one. When you change a `Button` prop from `type` to `variant`, every consuming team has to grep their codebase, update every instance, and test every page.

This manual work is where migration debt accumulates. Teams delay adopting the new version because the upgrade cost is too high. The system fragments — some teams on v3, some on v4, some on a custom fork they stopped updating two versions ago.

Codemods fix this by automating the mechanical part of migration. A codemod is a script that reads source code, applies a specific transformation, and writes the result — safely, deterministically, and across thousands of files in seconds.

This skill generates those scripts. It does not replace the deprecation plan or the migration guide — those are context-heavy, human-judgment outputs. It replaces the mechanical labour of applying the changes.

---

Configuration

Check for `.ds-ops-config.yml` in the project root:

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.

**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: isLoading
Migration: Replace <Button isLoading> with <Button loading>

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

For jscodeshift transforms (JavaScript/TypeScript)

Each codemod is a single file following the jscodeshift API:

/**
 * Codemod: [description]
 * Generated by Design System Ops — codemod-generator
 *
 * Usage:
 *   npx jscodeshift --transform codemods/[name].js --extensions=tsx,ts,jsx,js src/
 *
 * Dry run (preview changes without writing):
 *   npx jscodeshift --transform codemods/[name].js --dry