[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CPAF390J8XPHMHMN4QRPGX":3,"skill-same:01M6CPAF390J8XPHMHMN4QRPGX":85},{"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":28,"linkOnly":29,"markdownContent":30,"markdownBody":31,"frontMatter":32,"refName":33,"commitSha":34,"skillDirectory":35,"forksCount":36,"repositoryHtmlUrl":37,"repositoryHomepageUrl":38,"ownerHtmlUrl":39,"ownerBlogUrl":40,"ownerDescription":41,"updatedAt":42,"install":43,"resources":56},"01M6CPAF390J8XPHMHMN4QRPGX","convex-performance-audit",null,"Audits Convex performance for reads, subscriptions, write contention, and function limits. Use for slow features, insights findings, OCC conflicts, or read amplification.","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-performance-audit\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27],"convex performance audit","convex","performance","audit","read","write","use","subscriptions","conflicts","2026-11-10 10:12:30",false,"---\nname: convex-performance-audit\ndescription:\n  Audits Convex performance for reads, subscriptions, write contention, and\n  function limits. Use for slow features, insights findings, OCC conflicts, or\n  read amplification.\n---\n\n# Convex Performance Audit\n\nDiagnose and fix performance problems in Convex applications, one problem class\nat a time.\n\n## When to Use\n\n- A Convex page or feature feels slow or expensive\n- `npx convex insights --details` reports high bytes read, documents read, or\n  OCC conflicts\n- Low-freshness read paths are using reactivity where point-in-time reads would\n  do\n- OCC conflict errors or excessive mutation retries\n- High subscription count or slow UI updates\n- Functions approaching execution or transaction limits\n- The same performance pattern needs fixing across sibling functions\n\n## When Not to Use\n\n- Initial Convex setup, auth setup, or component extraction\n- Pure schema migrations with no performance goal\n- One-off micro-optimizations without a user-visible or deployment-visible\n  problem\n\n## Guardrails\n\n- Prefer simpler code when scale is small, traffic is modest, or the available\n  signals are weak\n- Do not recommend digest tables, document splitting, fetch-strategy changes, or\n  migration-heavy rollouts unless there is a measured signal, a clearly\n  unbounded path, or a known hot read\u002Fwrite path\n- In Convex, a simple scan on a small table is often acceptable. Do not invent\n  structural work just because a pattern is not ideal at large scale\n\n## First Step: Gather Signals\n\nStart with the strongest signal available:\n\n1. If deployment Health insights are already available from the user or the\n   current context, treat them as a first-class source of performance signals.\n2. If CLI insights are available, run `npx convex insights --details`. Use\n   `--prod`, `--preview-name`, or `--deployment-name` when needed.\n   - If the local repo's Convex CLI is too old to support `insights`, try\n     `npx -y convex@latest insights --details` before giving up.\n3. If the repo already uses `convex-doctor`, you may treat its findings as\n   hints. Do not require it, and do not treat it as the source of truth.\n4. If runtime signals are unavailable, audit from code anyway, but keep the\n   guardrails above in mind. Lack of insights is not proof of health, but it is\n   also not proof that a large refactor is warranted.\n\n## Signal Routing\n\nAfter gathering signals, identify the problem class and read the matching\nreference file.\n\n| Signal                                                         | Reference                                 |\n| -------------------------------------------------------------- | ----------------------------------------- |\n| High bytes or documents read, JS filtering, unnecessary joins  | `references\u002Fhot-path-rules.md`            |\n| OCC conflict errors, write contention, mutation retries        | `references\u002Focc-conflicts.md`             |\n| High subscription count, slow UI updates, excessive re-renders | `references\u002Fsubscription-cost.md`         |\n| Function timeouts, transaction size errors, large payloads     | `references\u002Ffunction-budget.md`           |\n| General \"it's slow\" with no specific signal                    | Start with `references\u002Fhot-path-rules.md` |\n\nMultiple problem classes can overlap. Read the most relevant reference first,\nthen check the others if symptoms remain.\n\n## Escalate Larger Fixes\n\nIf the likely fix is invasive, cross-cutting, or migration-heavy, stop and\npresent options before editing.\n\nExamples:\n\n- introducing digest or summary tables across multiple flows\n- splitting documents to isolate frequently-updated fields\n- reworking pagination or fetch strategy across several screens\n- switching to a new index or denormalized field that needs migration-safe\n  rollout\n\nWhen correctness depends on handling old and new states during a rollout,\nconsult `skills\u002Fconvex-migration-helper\u002FSKILL.md` for the migration workflow.\n\n## Workflow\n\n### 1. Scope the problem\n\nPick one concrete user flow from the actual project. Look at the codebase,\nclient pages, and API surface to find the flow that matches the symptom.\n\nWrite down:\n\n- entrypoint functions\n- client callsites using `useQuery`, `usePaginatedQuery`, or `useMutation`\n- tables read\n- tables written\n- whether the path is high-read, high-write, or both\n\n### 2. Trace the full read and write set\n\nFor each function in the path:\n\n1. Trace every `ctx.db.get()` and `ctx.db.query()`\n2. Trace every `ctx.db.patch()`, `ctx.db.replace()`, and `ctx.db.insert()`\n3. Note foreign-key lookups, JS-side filtering, and full-document reads\n4. Identify all sibling functions touching the same tables\n5. Identify reactive stats, aggregates, or widgets rendered on the same page\n\nIn Convex, every extra read increases transaction work, and every write can\ninvalidate reactive subscribers. Treat read amplification and invalidation\namplification as first-class problems.\n\n### 3. Apply fixes from the relevant reference\n\nRead the reference file matching your problem class. Each reference includes\nspecific patterns, code examples, and a recommended fix order.\n\nDo not stop at the single function named by an insight. Trace sibling readers\nand writers touching the same tables.\n\n### 4. Fix sibling functions together\n\nWhen one function touching a table has a performance bug, audit sibling\nfunctions for the same pattern.\n\nAfter finding one problem, inspect both sibling readers and sibling writers for\nthe same table family, including companion digest or summary tables.\n\nExamples:\n\n- If one list query switches from full docs to a digest table, inspect the other\n  list queries for that table\n- If one mutation isolates a frequently-updated field or splits a hot document,\n  inspect the other writers to the same table\n- If one read path needs a migration-safe rollout for an unbackfilled field,\n  inspect sibling reads for the same rollout risk\n\nDo not leave one path fixed and another path on the old pattern unless there is\na clear product reason.\n\n### 5. Verify before finishing\n\nConfirm all of these:\n\n1. Results are the same as before, no dropped records\n2. Eliminated reads or writes are no longer in the path where expected\n3. Fallback behavior works when denormalized or indexed fields are missing\n4. Frequently-updated fields are isolated from widely-read documents where\n   needed\n5. Every relevant sibling reader and writer was inspected, not just the original\n   function\n\n## Reference Files\n\n- `references\u002Fhot-path-rules.md` - Read amplification, invalidation,\n  denormalization, indexes, digest tables\n- `references\u002Focc-conflicts.md` - Write contention, OCC resolution, hot document\n  splitting\n- `references\u002Fsubscription-cost.md` - Reactive query cost, subscription\n  granularity, point-in-time reads\n- `references\u002Ffunction-budget.md` - Execution limits, transaction size, large\n  documents, payload size\n\nAlso check the official\n[Convex Best Practices](https:\u002F\u002Fdocs.convex.dev\u002Funderstanding\u002Fbest-practices\u002F)\npage for additional patterns covering argument validation, access control, and\ncode organization that may surface during the audit.\n\n## Checklist\n\n- [ ] Gathered signals from insights, dashboard, or code audit\n- [ ] Identified the problem class and read the matching reference\n- [ ] Scoped one concrete user flow or function path\n- [ ] Traced every read and write in that path\n- [ ] Identified sibling functions touching the same tables\n- [ ] Applied fixes from the reference, following the recommended fix order\n- [ ] Fixed sibling functions consistently\n- [ ] Verified behavior and confirmed no regressions\n","# Convex Performance Audit\n\nDiagnose and fix performance problems in Convex applications, one problem class\nat a time.\n\n## When to Use\n\n- A Convex page or feature feels slow or expensive\n- `npx convex insights --details` reports high bytes read, documents read, or\n  OCC conflicts\n- Low-freshness read paths are using reactivity where point-in-time reads would\n  do\n- OCC conflict errors or excessive mutation retries\n- High subscription count or slow UI updates\n- Functions approaching execution or transaction limits\n- The same performance pattern needs fixing across sibling functions\n\n## When Not to Use\n\n- Initial Convex setup, auth setup, or component extraction\n- Pure schema migrations with no performance goal\n- One-off micro-optimizations without a user-visible or deployment-visible\n  problem\n\n## Guardrails\n\n- Prefer simpler code when scale is small, traffic is modest, or the available\n  signals are weak\n- Do not recommend digest tables, document splitting, fetch-strategy changes, or\n  migration-heavy rollouts unless there is a measured signal, a clearly\n  unbounded path, or a known hot read\u002Fwrite path\n- In Convex, a simple scan on a small table is often acceptable. Do not invent\n  structural work just because a pattern is not ideal at large scale\n\n## First Step: Gather Signals\n\nStart with the strongest signal available:\n\n1. If deployment Health insights are already available from the user or the\n   current context, treat them as a first-class source of performance signals.\n2. If CLI insights are available, run `npx convex insights --details`. Use\n   `--prod`, `--preview-name`, or `--deployment-name` when needed.\n   - If the local repo's Convex CLI is too old to support `insights`, try\n     `npx -y convex@latest insights --details` before giving up.\n3. If the repo already uses `convex-doctor`, you may treat its findings as\n   hints. Do not require it, and do not treat it as the source of truth.\n4. If runtime signals are unavailable, audit from code anyway, but keep the\n   guardrails above in mind. Lack of insights is not proof of health, but it is\n   also not proof that a large refactor is warranted.\n\n## Signal Routing\n\nAfter gathering signals, identify the problem class and read the matching\nreference file.\n\n| Signal                                                         | Reference                                 |\n| -------------------------------------------------------------- | ----------------------------------------- |\n| High bytes or documents read, JS filtering, unnecessary joins  | `references\u002Fhot-path-rules.md`            |\n| OCC conflict errors, write contention, mutation retries        | `references\u002Focc-conflicts.md`             |\n| High subscription count, slow UI updates, excessive re-renders | `references\u002Fsubscription-cost.md`         |\n| Function timeouts, transaction size errors, large payloads     | `references\u002Ffunction-budget.md`           |\n| General \"it's slow\" with no specific signal                    | Start with `references\u002Fhot-path-rules.md` |\n\nMultiple problem classes can overlap. Read the most relevant reference first,\nthen check the others if symptoms remain.\n\n## Escalate Larger Fixes\n\nIf the likely fix is invasive, cross-cutting, or migration-heavy, stop and\npresent options before editing.\n\nExamples:\n\n- introducing digest or summary tables across multiple flows\n- splitting documents to isolate frequently-updated fields\n- reworking pagination or fetch strategy across several screens\n- switching to a new index or denormalized field that needs migration-safe\n  rollout\n\nWhen correctness depends on handling old and new states during a rollout,\nconsult `skills\u002Fconvex-migration-helper\u002FSKILL.md` for the migration workflow.\n\n## Workflow\n\n### 1. Scope the problem\n\nPick one concrete user flow from the actual project. Look at the codebase,\nclient pages, and API surface to find the flow that matches the symptom.\n\nWrite down:\n\n- entrypoint functions\n- client callsites using `useQuery`, `usePaginatedQuery`, or `useMutation`\n- tables read\n- tables written\n- whether the path is high-read, high-write, or both\n\n### 2. Trace the full read and write set\n\nFor each function in the path:\n\n1. Trace every `ctx.db.get()` and `ctx.db.query()`\n2. Trace every `ctx.db.patch()`, `ctx.db.replace()`, and `ctx.db.insert()`\n3. Note foreign-key lookups, JS-side filtering, and full-document reads\n4. Identify all sibling functions touching the same tables\n5. Identify reactive stats, aggregates, or widgets rendered on the same page\n\nIn Convex, every extra read increases transaction work, and every write can\ninvalidate reactive subscribers. Treat read amplification and invalidation\namplification as first-class problems.\n\n### 3. Apply fixes from the relevant reference\n\nRead the reference file matching your problem class. Each reference includes\nspecific patterns, code examples, and a recommended fix order.\n\nDo not stop at the single function named by an insight. Trace sibling readers\nand writers touching the same tables.\n\n### 4. Fix sibling functions together\n\nWhen one function touching a table has a performance bug, audit sibling\nfunctions for the same pattern.\n\nAfter finding one problem, inspect both sibling readers and sibling writers for\nthe same table family, including companion digest or summary tables.\n\nExamples:\n\n- If one list query switches from full docs to a digest table, inspect the other\n  list queries for that table\n- If one mutation isolates a frequently-updated field or splits a hot document,\n  inspect the other writers to the same table\n- If one read path needs a migration-safe rollout for an unbackfilled field,\n  inspect sibling reads for the same rollout risk\n\nDo not leave one path fixed and another path on the old pattern unless there is\na clear product reason.\n\n### 5. Verify before finishing\n\nConfirm all of these:\n\n1. Results are the same as before, no dropped records\n2. Eliminated reads or writes are no longer in the path where expected\n3. Fallback behavior works when denormalized or indexed fields are missing\n4. Frequently-updated fields are isolated from widely-read documents where\n   needed\n5. Every relevant sibling reader and writer was inspected, not just the original\n   function\n\n## Reference Files\n\n- `references\u002Fhot-path-rules.md` - Read amplification, invalidation,\n  denormalization, indexes, digest tables\n- `references\u002Focc-conflicts.md` - Write contention, OCC resolution, hot document\n  splitting\n- `references\u002Fsubscription-cost.md` - Reactive query cost, subscription\n  granularity, point-in-time reads\n- `references\u002Ffunction-budget.md` - Execution limits, transaction size, large\n  documents, payload size\n\nAlso check the official\n[Convex Best Practices](https:\u002F\u002Fdocs.convex.dev\u002Funderstanding\u002Fbest-practices\u002F)\npage for additional patterns covering argument validation, access control, and\ncode organization that may surface during the audit.\n\n## Checklist\n\n- [ ] Gathered signals from insights, dashboard, or code audit\n- [ ] Identified the problem class and read the matching reference\n- [ ] Scoped one concrete user flow or function path\n- [ ] Traced every read and write in that path\n- [ ] Identified sibling functions touching the same tables\n- [ ] Applied fixes from the reference, following the recommended fix order\n- [ ] Fixed sibling functions consistently\n- [ ] Verified behavior and confirmed no regressions\n",{"name":5,"description":7},"main","c85ef9e48f9e108d9ce4646bd27a1171f1b5f6ca","packages\u002Fsync-backend\u002F.agents\u002Fskills\u002Fconvex-performance-audit",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":44,"prompt":54,"zipAvailable":55},[45,48,51],{"tool":46,"command":47},"npx","npx skills add bholmesdev\u002Fhubble.md --skill convex-performance-audit",{"tool":49,"command":50},"bunx","bunx skills add bholmesdev\u002Fhubble.md --skill convex-performance-audit",{"tool":52,"command":53},"pnpm","pnpm dlx skills add bholmesdev\u002Fhubble.md --skill convex-performance-audit","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002Fpackages\u002Fsync-backend\u002F.agents\u002Fskills\u002Fconvex-performance-audit\u002FSKILL.md",true,[57,63,69,73,77,81],{"path":58,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":61,"sourceHtmlUrl":62},"agents\u002Fopenai.yaml","REFERENCE","参考文档",518,"https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002Fpackages\u002Fsync-backend\u002F.agents\u002Fskills\u002Fconvex-performance-audit\u002Fagents\u002Fopenai.yaml",{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"assets\u002Ficon.svg","ASSET","资产文件",490,"https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002Fpackages\u002Fsync-backend\u002F.agents\u002Fskills\u002Fconvex-performance-audit\u002Fassets\u002Ficon.svg",{"path":70,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Ffunction-budget.md",7916,"https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002Fpackages\u002Fsync-backend\u002F.agents\u002Fskills\u002Fconvex-performance-audit\u002Freferences\u002Ffunction-budget.md",{"path":74,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Fhot-path-rules.md",11059,"https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002Fpackages\u002Fsync-backend\u002F.agents\u002Fskills\u002Fconvex-performance-audit\u002Freferences\u002Fhot-path-rules.md",{"path":78,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Focc-conflicts.md",4544,"https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002Fpackages\u002Fsync-backend\u002F.agents\u002Fskills\u002Fconvex-performance-audit\u002Freferences\u002Focc-conflicts.md",{"path":82,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002Fsubscription-cost.md",9839,"https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002Fpackages\u002Fsync-backend\u002F.agents\u002Fskills\u002Fconvex-performance-audit\u002Freferences\u002Fsubscription-cost.md",[86,105,122,142,162,187],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":97,"publishedAt":28},"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",[92],{"categoryNo":93,"categoryName":94,"taxonomyType":95,"taxonomyTypeDesc":96},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",[98,99,100,101,102,103,104,25],"review markdown comments","comments","review","markdown","as","files","reply",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":28},"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",[],[112,113,114,115,116,117,118,119,120,121,25,33],"merge","risk","merge risk","github","blob","pr","https","engineering","true","matt pocock",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":132,"publishedAt":28},"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",[128,129],{"categoryNo":93,"categoryName":94,"taxonomyType":95,"taxonomyTypeDesc":96},{"categoryNo":130,"categoryName":131,"taxonomyType":95,"taxonomyTypeDesc":96},"01JBSEEDCAT000000000000009","前端开发",[133,134,135,136,137,138,101,139,25,140,141],"html","app","embed","embed html app","inline","file","context","document","block",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":28},"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",[],[149,150,151,25,152,153,154,155,138,156,157,158,159,134,160,161],"edit diagram","edit","diagram","whiteboard","canvas","create","offline","tldraw offline","archive","tldr","user","tldraw","with",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":172,"publishedAt":28},"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",[168,169],{"categoryNo":130,"categoryName":131,"taxonomyType":95,"taxonomyTypeDesc":96},{"categoryNo":170,"categoryName":171,"taxonomyType":95,"taxonomyTypeDesc":96},"01JBSEEDCAT000000000000010","后端与接口",[173,134,133,154,174,175,176,177,178,179,180,181,182,183,138,184,102,185,161,186],"create html app","ui","theme tokens","runtime","tokens","local","self","interactive","Tailwind","api","alpine","update","theme","folder",{"skillNo":188,"name":20,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":192,"publishedAt":28},"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,193,194,195,25,159],"task","general","project skill"]