From payloadcms-skills
Designs Payload CMS collections from source CMS data samples via interactive analysis, iteration, and proposes migration strategies from WordPress, Contentful, Strapi, Sanity, Webflow.
npx claudepluginhub joshuarweaver/cascade-data-storage --plugin payloadcms-skillsThis skill uses the workspace's default tool permissions.
Interactive workflow to design Payload collections from source CMS data. Config-first approach: establish the data structure through conversation before any data import.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Interactive workflow to design Payload collections from source CMS data. Config-first approach: establish the data structure through conversation before any data import.
Start
↓
Ask for data sample
↓
Analyze data shape
↓
Propose collection config
↓
User reviews ──────────────┐
│ │
├─ changes needed ───→ Adjust config ──→ (back to User reviews)
│
└─ looks good ───→ Config confirmed
↓
More collections? ──────┐
│ │
├─ yes ──→ (back to Ask for data sample)
│
└─ no ───→ All collections confirmed
↓
Discuss migration approach
↓
Done
When user provides data (JSON, CSV, or describes their schema):
Present a Payload collection config based on analysis:
// Example output format
export const Posts: CollectionConfig = {
slug: 'posts',
fields: [
{ name: 'title', type: 'text', required: true },
{ name: 'content', type: 'richText' },
{ name: 'author', type: 'relationship', relationTo: 'users' },
// ...
],
}
Explain your reasoning for each field choice. When something could go multiple ways (group vs JSON, text vs textarea, select vs relationship), ask rather than assume.
Work through uncertainties: required fields, hasMany relationships, rich text vs HTML, custom timestamps vs built-in. Continue until the user confirms the config.
After each confirmation, ask:
"Are there other content types we should create collections for?"
If yes, loop back to Phase 1 with new data sample.
Common related collections to prompt for:
Only after ALL collections are confirmed, discuss data import:
Offer to generate a seed script or walk through manual import.
Throughout the process, watch for these:
This is the most common migration mistake. Data that looks static often needs to be dynamic.
When you see repeated string values (categories, tags, types, statuses):
{ "category": "Technology" }
{ "category": "News" }
{ "category": "Technology" }
Don't assume it's a select field. Ask:
"I see
categoryhas values like 'Technology', 'News'. Should this be:
- A select field with fixed options (values won't change)
- A relationship to a Categories collection (users can add/edit/remove categories later)"
Default to relationship for anything that looks like:
Use select only for:
If creating a relationship, remember to add the related collection (Categories, Tags, etc.) to the migration plan.
| Issue | How to Handle |
|---|---|
| User provides partial data | Ask for more samples, especially edge cases |
| Unclear relationships | Ask user to describe how content types connect |
| Rich text ambiguity | Clarify: Lexical editor, Slate, or store raw HTML |
| Missing media collection | Always confirm upload collection exists before referencing |
| Overly complex nested data | Consider flattening or using blocks instead of deep groups |