Skill: auto-port custom columns to plugin packages

[andreatgretel]

Problem

Custom columns (@custom_column_generator) are convenient for local/notebook use but hit a hard wall when users need serialization - the generator function serializes to just its __name__, so configs can't round-trip through YAML/JSON. The recommended path is to rewrite as a plugin, but the transformation is mechanical and the boilerplate is easy to get wrong.

Proposal

Add a /port-to-plugin Claude Code skill (.agents/skills/) that takes a Python file containing one or more @custom_column_generator functions and scaffolds a complete, installable plugin package.

Transformation mapping

Custom column	Plugin
@custom_column_generator(required_columns=..., side_effect_columns=...)	required_columns / side_effect_columns properties on config class
generator_params: BaseModel fields	Promoted to config class fields
model_aliases decorator arg	Config field + resource_provider.model_registry access in impl
Function body with row param	ColumnGeneratorCellByCell.generate()
Function body with df param	ColumnGeneratorFullColumn.generate()
GenerationStrategy choice	Base class selection

Output structure

Given /port-to-plugin path/to/my_workflow.py:

data-designer-<name>-plugin/
  src/<package_name>/
    __init__.py
    config.py        # SingleColumnConfig subclass with Literal discriminator
    impl.py          # ColumnGenerator{CellByCell,FullColumn} subclass
    plugin.py        # Plugin() registration object
  pyproject.toml     # Entry point under data_designer.plugins

Scope

• Single custom column per invocation (v1), multi-column bundling as a follow-up
• Rewrites models parameter access to self.resource_provider.model_registry
• Flattens generator_params into config fields
• Uses docs/plugins/example.md and tests_e2e/.../plugins/column_generator/ as scaffolding templates

Why a skill and not a CLI command

The transformation requires understanding intent (naming the discriminator, choosing config field types, handling edge cases in function bodies). An LLM-backed skill can make judgment calls that a rigid code generator can't, while the plugin structure is constrained enough that the output is verifiable.

Acceptance criteria

• Skill file at .agents/skills/port-to-plugin/
• Handles cell-by-cell and full-column strategies
• Handles generator_params flattening
• Handles models parameter rewriting
• Generated plugin installs and passes data_designer.plugins entry point discovery
• Includes a test scaffold

[andreatgretel]

Programmatic vs LLM-backed approach

After some analysis, the core transformation is mechanical enough for a programmatic CLI using ast:

What ast can handle:

• Parse @custom_column_generator decorators and extract required_columns, side_effect_columns, model_aliases
• Detect strategy from first param name (row -> ColumnGeneratorCellByCell, df -> ColumnGeneratorFullColumn)
• Extract generator_params fields via Pydantic model_fields
• Derive names: my_generator -> MyGeneratorConfig, "my-generator" discriminator, data-designer-my-generator-plugin package
• Scaffold the full package structure from templates

What needs judgment (LLM or manual):

• Rewriting models["alias"] access to self.resource_provider.model_registry
• Transplanting the function body into a generate(self, ...) method with correct self.config references
• Resolving closures, captured state, and import hoisting
• Choosing good names when the function name is generic

Suggested approach: start with a programmatic CLI (data-designer port-to-plugin my_workflow.py) that scaffolds the package and drops the function body in with # TODO markers for manual fixups. Then layer a Claude Code skill on top that can do the full rewrite. The CLI covers the 80% case and is usable without any LLM tooling.