​
Directory Layout

my-workflow/
├─ codemod.yaml
├─ workflow.yaml
├─ scripts/
└─ rules/
The folder—called a workflow package—is the root when you run npx codemod workflow run -w ./my-workflow/.
You can combine types in a single package. The scripts/ and rules/ folders are conventional, not required—use any paths and reference them from workflow.yaml.
A workflow package is a directory containing your workflow.yaml and any scripts, rules, or assets referenced by your workflow.
  • When you run 
    npx codemod workflow run -w ./my-workflow/
    the directory is used as the root for all relative paths.
  • You can also run a workflow directly from a file: 
    npx codemod workflow run -w workflow.yaml

​
Workflow File

workflow.yaml
version: "1"
state:
  schema: []
templates: []
nodes: []
See Building workflows for a deep dive into nodes, steps, params, strategy, and examples.

​
codemod.yaml fields

These are the fields you define when scaffolding a new codemod (based on the actual CLI template and prompts):
​
schema_version
string
default:"1.0"
required
Codemod workflow schema version.
​
name
string
required
Codemod package name (unique within scope).Example:
  • remove-console-logs
  • Optionally, you can add organization/project scopes: @scope/remove-console-logs.
​
version
string
default:"0.1.0"
required
Semantic version of the package.
​
description
string
required
Brief description of what the codemod does.
​
author
string
required
Author name and email, e.g., Jane Doe <jane@example.com>.
​
license
string
default:"MIT"
required
License identifier (SPDX), e.g., MIT.
​
workflow
string
default:"workflow.yaml"
required
Relative path to your workflow file.
​
category
string
default:"migration"
Category for the codemod.
​
targets.languages
string[]
Languages targeted by this codemod (selected language during codemod init; editable later).
​
keywords
string[]
Search keywords for discovery.Example: keywords: ["transformation", "migration"]
​
registry.access
string
default:"public"
Access controls who can run/use the codemod (once they can see it).
  • public: Anyone can run the codemod.
  • private: Only the owner can run the codemod.
  • pro: Only Pro plan users can run the codemod.
Access applies on top of visibility. For example, visibility: public with access: pro shows the package publicly, but only Pro users can run it.
​
registry.visibility
string
default:"public"
Visibility controls who can see the package in the Registry (search, listings, and UI).
  • public: Everyone can see the package in the Registry.
  • private: Only the owner can see the package.
  • org: Members of the package’s organization scope can see the package.
  • user: Visible only to the publishing user (user-scoped visibility).
During scaffolding, the CLI sets public/private based on —private. You can change to any supported value above when publishing.
Example:
codemod.yaml
schema_version: "1.0"

name: "my-awesome-codemod"
version: "0.1.0"
description: "Transform legacy patterns to modern syntax"
author: "Your Name <you@example.com>"
license: "MIT"
workflow: "workflow.yaml"
category: "migration"

targets:
  languages: ["typescript"]

keywords: ["transformation", "migration"]

registry:
  access: "public"
  visibility: "public"