[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CPAC3BXKVWG2DKQ3F9P2RE":3,"skill-same:01M6CPAC3BXKVWG2DKQ3F9P2RE":81},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":37,"commitSha":38,"skillDirectory":39,"forksCount":40,"repositoryHtmlUrl":41,"repositoryHomepageUrl":42,"ownerHtmlUrl":43,"ownerBlogUrl":44,"ownerDescription":45,"updatedAt":46,"install":47,"resources":60},"01M6CPAC3BXKVWG2DKQ3F9P2RE","convex-migration-helper",null,"Plans Convex schema and data migrations with widen-migrate-narrow and @convex-dev\u002Fmigrations. Use for breaking schema changes, backfills, table reshaping, or zero-downtime rollouts.","bholmesdev\u002Fhubble.md","bholmesdev","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F51384119?v=4","01M6CP8SJ3N9W8FYVCGV41QT3G","Ben Holmes","01M6CP8SP3A84K1TFMVS8BEBDW",1524,"MIT","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002Fpackages\u002Fsync-backend\u002F.agents\u002Fskills\u002Fconvex-migration-helper\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31],"convex migration helper","convex","migration","migration helper","dev","ZeRO","data","migrate","table","use","schema","rollouts","migrations","2026-11-10 10:12:30",false,"---\nname: convex-migration-helper\ndescription:\n  Plans Convex schema and data migrations with widen-migrate-narrow and\n  @convex-dev\u002Fmigrations. Use for breaking schema changes, backfills, table\n  reshaping, or zero-downtime rollouts.\n---\n\n# Convex Migration Helper\n\nSafely migrate Convex schemas and data when making breaking changes.\n\n## When to Use\n\n- Adding new required fields to existing tables\n- Changing field types or structure\n- Splitting or merging tables\n- Renaming or deleting fields\n- Migrating from nested to relational data\n\n## When Not to Use\n\n- Greenfield schema with no existing data in production or dev\n- Adding optional fields that do not need backfilling\n- Adding new tables with no existing data to migrate\n- Adding or removing indexes with no correctness concern\n- Questions about Convex schema design without a migration need\n\n## Key Concepts\n\n### Schema Validation Drives the Workflow\n\nConvex will not let you deploy a schema that does not match the data at rest.\nThis is the fundamental constraint that shapes every migration:\n\n- You cannot add a required field if existing documents don't have it\n- You cannot change a field's type if existing documents have the old type\n- You cannot remove a field from the schema if existing documents still have it\n\nThis means migrations follow a predictable pattern: **widen the schema, migrate\nthe data, narrow the schema**.\n\n### Online Migrations\n\nConvex migrations run online, meaning the app continues serving requests while\ndata is updated asynchronously in batches. During the migration window, your\ncode must handle both old and new data formats.\n\n### Prefer New Fields Over Changing Types\n\nWhen changing the shape of data, create a new field rather than modifying an\nexisting one. This makes the transition safer and easier to roll back.\n\n### Don't Delete Data\n\nUnless you are certain, prefer deprecating fields over deleting them. Mark the\nfield as `v.optional` and add a code comment explaining it is deprecated and why\nit existed.\n\n## Safe Changes (No Migration Needed)\n\n### Adding Optional Field\n\n```typescript\n\u002F\u002F Before\nusers: defineTable({\n  name: v.string(),\n});\n\n\u002F\u002F After - safe, new field is optional\nusers: defineTable({\n  name: v.string(),\n  bio: v.optional(v.string()),\n});\n```\n\n### Adding New Table\n\n```typescript\nposts: defineTable({\n  userId: v.id(\"users\"),\n  title: v.string(),\n}).index(\"by_user\", [\"userId\"]);\n```\n\n### Adding Index\n\n```typescript\nusers: defineTable({\n  name: v.string(),\n  email: v.string(),\n}).index(\"by_email\", [\"email\"]);\n```\n\n## Breaking Changes: The Deployment Workflow\n\nEvery breaking migration follows the same multi-deploy pattern:\n\n**Deploy 1 - Widen the schema:**\n\n1. Update schema to allow both old and new formats (e.g., add optional new\n   field)\n2. Update code to handle both formats when reading\n3. Update code to write the new format for new documents\n4. Deploy\n\n**Between deploys - Migrate data:**\n\n5. Run migration to backfill existing documents\n6. Verify all documents are migrated\n\n**Deploy 2 - Narrow the schema:**\n\n7. Update schema to require the new format only\n8. Remove code that handles the old format\n9. Deploy\n\n## Using the Migrations Component\n\nFor any non-trivial migration, use the\n[`@convex-dev\u002Fmigrations`](https:\u002F\u002Fwww.convex.dev\u002Fcomponents\u002Fmigrations)\ncomponent. It handles batching, cursor-based pagination, state tracking, resume\nfrom failure, dry runs, and progress monitoring.\n\nSee `references\u002Fmigrations-component.md` for installation, setup, defining and\nrunning migrations, dry runs, status monitoring, and configuration options.\n\n## Common Migration Patterns\n\nSee `references\u002Fmigration-patterns.md` for complete patterns with code examples\ncovering:\n\n- Adding a required field\n- Deleting a field\n- Changing a field type\n- Splitting nested data into a separate table\n- Cleaning up orphaned documents\n- Zero-downtime strategies (dual write, dual read)\n- Small table shortcut (single internalMutation without the component)\n- Verifying a migration is complete\n\n## Common Pitfalls\n\n1. **Making a field required before migrating data**: Convex rejects the deploy\n   because existing documents lack the field. Always widen the schema first.\n2. **Using `.collect()` on large tables**: Hits transaction limits or causes\n   timeouts. Use the migrations component for proper batched pagination.\n   `.collect()` is only safe for tables you know are small.\n3. **Not writing the new format before migrating**: Documents created during the\n   migration window will be missed, leaving unmigrated data after the migration\n   \"completes.\"\n4. **Skipping the dry run**: Use `dryRun: true` to validate migration logic\n   before committing changes to production data. Catches bugs before they touch\n   real documents.\n5. **Deleting fields prematurely**: Prefer deprecating with `v.optional` and a\n   comment. Only delete after you are confident the data is no longer needed and\n   no code references it.\n6. **Using crons for migration batches**: The migrations component handles\n   batching via recursive scheduling internally. Crons require manual cleanup\n   and an extra deploy to remove.\n\n## Migration Checklist\n\n- [ ] Identify the breaking change and plan the multi-deploy workflow\n- [ ] Update schema to allow both old and new formats\n- [ ] Update code to handle both formats when reading\n- [ ] Update code to write the new format for new documents\n- [ ] Deploy widened schema and updated code\n- [ ] Define migration using the `@convex-dev\u002Fmigrations` component\n- [ ] Test with `dryRun: true`\n- [ ] Run migration and monitor status\n- [ ] Verify all documents are migrated\n- [ ] Update schema to require new format only\n- [ ] Clean up code that handled old format\n- [ ] Deploy final schema and code\n- [ ] Remove migration code once confirmed stable\n","# Convex Migration Helper\n\nSafely migrate Convex schemas and data when making breaking changes.\n\n## When to Use\n\n- Adding new required fields to existing tables\n- Changing field types or structure\n- Splitting or merging tables\n- Renaming or deleting fields\n- Migrating from nested to relational data\n\n## When Not to Use\n\n- Greenfield schema with no existing data in production or dev\n- Adding optional fields that do not need backfilling\n- Adding new tables with no existing data to migrate\n- Adding or removing indexes with no correctness concern\n- Questions about Convex schema design without a migration need\n\n## Key Concepts\n\n### Schema Validation Drives the Workflow\n\nConvex will not let you deploy a schema that does not match the data at rest.\nThis is the fundamental constraint that shapes every migration:\n\n- You cannot add a required field if existing documents don't have it\n- You cannot change a field's type if existing documents have the old type\n- You cannot remove a field from the schema if existing documents still have it\n\nThis means migrations follow a predictable pattern: **widen the schema, migrate\nthe data, narrow the schema**.\n\n### Online Migrations\n\nConvex migrations run online, meaning the app continues serving requests while\ndata is updated asynchronously in batches. During the migration window, your\ncode must handle both old and new data formats.\n\n### Prefer New Fields Over Changing Types\n\nWhen changing the shape of data, create a new field rather than modifying an\nexisting one. This makes the transition safer and easier to roll back.\n\n### Don't Delete Data\n\nUnless you are certain, prefer deprecating fields over deleting them. Mark the\nfield as `v.optional` and add a code comment explaining it is deprecated and why\nit existed.\n\n## Safe Changes (No Migration Needed)\n\n### Adding Optional Field\n\n```typescript\n\u002F\u002F Before\nusers: defineTable({\n  name: v.string(),\n});\n\n\u002F\u002F After - safe, new field is optional\nusers: defineTable({\n  name: v.string(),\n  bio: v.optional(v.string()),\n});\n```\n\n### Adding New Table\n\n```typescript\nposts: defineTable({\n  userId: v.id(\"users\"),\n  title: v.string(),\n}).index(\"by_user\", [\"userId\"]);\n```\n\n### Adding Index\n\n```typescript\nusers: defineTable({\n  name: v.string(),\n  email: v.string(),\n}).index(\"by_email\", [\"email\"]);\n```\n\n## Breaking Changes: The Deployment Workflow\n\nEvery breaking migration follows the same multi-deploy pattern:\n\n**Deploy 1 - Widen the schema:**\n\n1. Update schema to allow both old and new formats (e.g., add optional new\n   field)\n2. Update code to handle both formats when reading\n3. Update code to write the new format for new documents\n4. Deploy\n\n**Between deploys - Migrate data:**\n\n5. Run migration to backfill existing documents\n6. Verify all documents are migrated\n\n**Deploy 2 - Narrow the schema:**\n\n7. Update schema to require the new format only\n8. Remove code that handles the old format\n9. Deploy\n\n## Using the Migrations Component\n\nFor any non-trivial migration, use the\n[`@convex-dev\u002Fmigrations`](https:\u002F\u002Fwww.convex.dev\u002Fcomponents\u002Fmigrations)\ncomponent. It handles batching, cursor-based pagination, state tracking, resume\nfrom failure, dry runs, and progress monitoring.\n\nSee `references\u002Fmigrations-component.md` for installation, setup, defining and\nrunning migrations, dry runs, status monitoring, and configuration options.\n\n## Common Migration Patterns\n\nSee `references\u002Fmigration-patterns.md` for complete patterns with code examples\ncovering:\n\n- Adding a required field\n- Deleting a field\n- Changing a field type\n- Splitting nested data into a separate table\n- Cleaning up orphaned documents\n- Zero-downtime strategies (dual write, dual read)\n- Small table shortcut (single internalMutation without the component)\n- Verifying a migration is complete\n\n## Common Pitfalls\n\n1. **Making a field required before migrating data**: Convex rejects the deploy\n   because existing documents lack the field. Always widen the schema first.\n2. **Using `.collect()` on large tables**: Hits transaction limits or causes\n   timeouts. Use the migrations component for proper batched pagination.\n   `.collect()` is only safe for tables you know are small.\n3. **Not writing the new format before migrating**: Documents created during the\n   migration window will be missed, leaving unmigrated data after the migration\n   \"completes.\"\n4. **Skipping the dry run**: Use `dryRun: true` to validate migration logic\n   before committing changes to production data. Catches bugs before they touch\n   real documents.\n5. **Deleting fields prematurely**: Prefer deprecating with `v.optional` and a\n   comment. Only delete after you are confident the data is no longer needed and\n   no code references it.\n6. **Using crons for migration batches**: The migrations component handles\n   batching via recursive scheduling internally. Crons require manual cleanup\n   and an extra deploy to remove.\n\n## Migration Checklist\n\n- [ ] Identify the breaking change and plan the multi-deploy workflow\n- [ ] Update schema to allow both old and new formats\n- [ ] Update code to handle both formats when reading\n- [ ] Update code to write the new format for new documents\n- [ ] Deploy widened schema and updated code\n- [ ] Define migration using the `@convex-dev\u002Fmigrations` component\n- [ ] Test with `dryRun: true`\n- [ ] Run migration and monitor status\n- [ ] Verify all documents are migrated\n- [ ] Update schema to require new format only\n- [ ] Clean up code that handled old format\n- [ ] Deploy final schema and code\n- [ ] Remove migration code once confirmed stable\n",{"name":5,"description":7},"main","c85ef9e48f9e108d9ce4646bd27a1171f1b5f6ca","packages\u002Fsync-backend\u002F.agents\u002Fskills\u002Fconvex-migration-helper",99,"https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md","https:\u002F\u002Fhubble.md","https:\u002F\u002Fgithub.com\u002Fbholmesdev","https:\u002F\u002Fbholmes.dev","Web developer, teacher, whiteboardist. Building the next terminal @warpdotdev ","2026-11-06 02:02:39",{"source":8,"skillName":5,"commands":48,"prompt":58,"zipAvailable":59},[49,52,55],{"tool":50,"command":51},"npx","npx skills add bholmesdev\u002Fhubble.md --skill convex-migration-helper",{"tool":53,"command":54},"bunx","bunx skills add bholmesdev\u002Fhubble.md --skill convex-migration-helper",{"tool":56,"command":57},"pnpm","pnpm dlx skills add bholmesdev\u002Fhubble.md --skill convex-migration-helper","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002Fpackages\u002Fsync-backend\u002F.agents\u002Fskills\u002Fconvex-migration-helper\u002FSKILL.md",true,[61,67,73,77],{"path":62,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":65,"sourceHtmlUrl":66},"agents\u002Fopenai.yaml","REFERENCE","参考文档",472,"https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002Fpackages\u002Fsync-backend\u002F.agents\u002Fskills\u002Fconvex-migration-helper\u002Fagents\u002Fopenai.yaml",{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"assets\u002Ficon.svg","ASSET","资产文件",386,"https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002Fpackages\u002Fsync-backend\u002F.agents\u002Fskills\u002Fconvex-migration-helper\u002Fassets\u002Ficon.svg",{"path":74,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Fmigration-patterns.md",6188,"https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002Fpackages\u002Fsync-backend\u002F.agents\u002Fskills\u002Fconvex-migration-helper\u002Freferences\u002Fmigration-patterns.md",{"path":78,"resourceType":63,"resourceTypeDesc":64,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fmigrations-component.md",4124,"https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002Fpackages\u002Fsync-backend\u002F.agents\u002Fskills\u002Fconvex-migration-helper\u002Freferences\u002Fmigrations-component.md",[82,101,118,138,158,183],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":93,"publishedAt":32},"01M6PQAVS5DTTVEV9VA313YSYM","review-markdown-comments","Reply to, resolve, or reopen Hubble review comments stored as CriticMarkup in Markdown files. Use when asked to address a Hubble review comment.","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Freview-markdown-comments\u002FSKILL.md",[88],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",[94,95,96,97,98,99,100,28],"review markdown comments","comments","review","markdown","as","files","reply",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":32},"01M6PQAH29FCQB6921Y94CA8F4","merge-risk","Use when assessing the risk of merging a PR","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmerge-risk\u002FSKILL.md",[],[108,109,110,111,112,113,114,115,116,117,28,37],"merge","risk","merge risk","github","blob","pr","https","engineering","true","matt pocock",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":128,"publishedAt":32},"01M6PQA0ADFHMANPW4KRAV7EA6","embed-html-app","Embed a Hubble HTML App inline inside a Markdown File using an iframe block. Use when an app should be viewed in the context of a document.","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fembed-html-app\u002FSKILL.md",[124,125],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},{"categoryNo":126,"categoryName":127,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000009","前端开发",[129,130,131,132,133,134,97,135,28,136,137],"html","app","embed","embed html app","inline","file","context","document","block",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":144,"publishedAt":32},"01M6PQ9WQM5HF4QQ1J750346NY","edit-diagram","Create or edit a Hubble diagram: a .tldr file Hubble opens in its built-in tldraw canvas. With this skill installed, any diagram, canvas, whiteboard, or .tldr file is a Hubble diagram: use this skill instead of tldraw-offline, unless the user names the tldraw offline app or the file is a .tldraw archive.","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fedit-diagram\u002FSKILL.md",[],[145,146,147,28,148,149,150,151,134,152,153,154,155,130,156,157],"edit diagram","edit","diagram","whiteboard","canvas","create","offline","tldraw offline","archive","tldr","user","tldraw","with",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":168,"publishedAt":32},"01M6PQ9JKMF9ZDQWNVSA38VCTT","create-html-app","Create or update a Hubble HTML App: a folder-local .html file Hubble runs as a self-contained interactive UI, with Alpine, Tailwind, Hubble theme tokens, and the injected hubble runtime API.","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcreate-html-app\u002FSKILL.md",[164,165],{"categoryNo":126,"categoryName":127,"taxonomyType":91,"taxonomyTypeDesc":92},{"categoryNo":166,"categoryName":167,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000010","后端与接口",[169,130,129,150,170,171,172,173,174,175,176,177,178,179,134,180,98,181,157,182],"create html app","ui","theme tokens","runtime","tokens","local","self","interactive","Tailwind","api","alpine","update","theme","folder",{"skillNo":184,"name":20,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":188,"publishedAt":32},"01M6CPAR6ECFN9P9H1S4XWDCB1","Routes general Convex requests to the right project skill. Use when the user asks which Convex skill to use or gives an underspecified Convex app task.","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002Fpackages\u002Fsync-backend\u002F.agents\u002Fskills\u002Fconvex\u002FSKILL.md",[],[20,189,190,191,28,155],"task","general","project skill"]