field-mapping-safety

Validates field mappings, enum mappings, and data synchronization logic during refactoring.

1.0k|109|Updated Jan 4, 2026
One-click install
npx skills add https://github.com/doccker/cc-use-exp --skill field-mapping-safety
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: field-mapping-safety
Source: https://github.com/doccker/cc-use-exp/tree/main/.cursor/skills/field-mapping-safety
Command: npx skills add https://github.com/doccker/cc-use-exp --skill field-mapping-safety

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Refactoring often breaks field mappings silently: TypeScript type checks pass while wrong dataIndex values, incomplete enum maps, or sync overwrites cause runtime failures like "Invalid Date", blank cells, or lost user edits. This Skill prevents field-name guessing and ensures mappings match the original code's actual behavior.

Core Features & Use Cases

  • Field Name Verification: Enforces checking original code (e.g., via git show) and backend API responses instead of inferring field names from type definitions, catching subtle differences like changedAt vs createdAt.
  • Enum Mapping Completeness: Provides checklists to verify every enum value, spelling, color, and text is preserved during refactoring of typeMap or statusMap.
  • Sync Overwrite Protection: Implements a last-sync-value pattern so external data synchronization (ERP, CRM imports) never clears target fields on null source values or overwrites manual user adjustments.
  • Use Case: When refactoring a table component with 10 operation-type enum values, use this Skill to compare against the original code and confirm no enum entries, rowKey fields, or date renderers were broken.

Quick Start

Ask the AI to review your refactored table columns and enum mappings against the original code using the field-mapping-safety checklist before committing.

Frequently Asked Questions about field-mapping-safety

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I avoid breaking field mappings when refactoring table columns?

Check the original code's actual dataIndex usage with git show rather than inferring from type definitions. Prefer required fields over optional ones, and watch for similar names like changedAt vs createdAt that TypeScript cannot distinguish at runtime.

Why does my refactored table show Invalid Date or undefined values?

This happens when the dataIndex points to an optional or nonexistent field that passes type checking but is undefined at runtime. Verify the backend API's actual response fields and add defensive rendering that handles null values.

How do I prevent data sync from overwriting user edits?

Use the last-sync-value pattern: store the value set during the previous sync in a mapping table, and only overwrite if the current target value still equals it. If the user changed the field, skip the update and log the decision.

Does TypeScript type checking catch wrong field names in dataIndex?

No. If the wrong field exists in the type definition as optional, TypeScript passes while runtime rendering fails. Type checking is necessary but not sufficient; runtime testing and comparison against original code are required.

When should enum mappings be verified during refactoring?

Verify enum mappings whenever refactoring typeMap or statusMap objects. Compare each value against the original code for completeness, spelling (UPLOAD vs Upload), and consistent colors and text, since missing entries render as blank or default tags.