[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MDR4JV1K6GM4PBYQVQ7TD":3,"skill-same:01M71MDR4JV1K6GM4PBYQVQ7TD":71},{"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":23,"publishedAt":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":51,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M71MDR4JV1K6GM4PBYQVQ7TD","clickhousectl-cloud-deploy",null,"Use when a user wants to deploy ClickHouse to the cloud, go to production, use ClickHouse Cloud, host a managed ClickHouse service, or migrate from a local ClickHouse setup to ClickHouse Cloud.","iDorgham\u002FWorkspace-Factory","iDorgham","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F136521493?v=4","01M6CNGBDAHE4ARW3YJEF4X2FD","Dorgham","01M71E8H3CXZ7DJX59MTM9JEB2",1,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Fskills\u002Fofficial_clickhouse_clickhousectl_cloud_deploy\u002Fskill.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"cloud deploy","clickhousectl cloud deploy","cloud","deploy","clickhouse","managed","local","host","use","when","migrate","Production","go","service","setup","user","2026-11-10 10:56:23",false,"---\nname: clickhousectl-cloud-deploy\ndescription: Use when a user wants to deploy ClickHouse to the cloud, go to production, use ClickHouse Cloud, host a managed ClickHouse service, or migrate from a local ClickHouse setup to ClickHouse Cloud.\nlicense: Apache-2.0\nmetadata:\n  author: ClickHouse Inc\n  version: \"0.1.0\"\n---\n\n# Deploy to ClickHouse Cloud\n\nThis skill walks through deploying to ClickHouse Cloud using `clickhousectl`. It covers account setup, CLI authentication, service creation, schema migration, and connecting your application. Follow these steps in order.\n\n## When to Apply\n\nUse this skill when the user wants to:\n- Deploy their ClickHouse application to production\n- Host ClickHouse as a managed cloud service\n- Migrate from a local ClickHouse setup to ClickHouse Cloud\n- Create a ClickHouse Cloud service\n- Set up ClickHouse Cloud for the first time\n\n---\n\n## Step 1: Sign up for ClickHouse Cloud\n\nBefore using any cloud commands, the user needs a ClickHouse Cloud account.\n\n**Ask the user:** \"Do you already have a ClickHouse Cloud account?\"\n\n**If they do not have an account**, explain:\n\n> ClickHouse Cloud is a fully managed service that runs ClickHouse for you — no infrastructure to maintain, automatic scaling, backups, and upgrades included. There's a free trial so you can get started without a credit card.\n>\n> To create an account, go to: **https:\u002F\u002Fclickhouse.cloud**\n>\n> Sign up with your email, Google, or GitHub account. Once you're in the console, let me know and we'll continue with the next step.\n\n**Wait for the user to confirm** they have signed up or already have an account before proceeding.\n\n---\n\n## Step 2: Authenticate the CLI\n\nFirst, ensure `clickhousectl` is installed. Check with:\n\n```bash\nwhich clickhousectl\n```\n\nIf not found, install it:\n\n```bash\ncurl -fsSL https:\u002F\u002Fclickhouse.com\u002Fcli | sh\n```\n\nNow authenticate. There are two options — choose based on the situation:\n\n> **Important: OAuth login is read-only.** Browser login (Option A) grants read-only access — you can list organizations, services, and query existing services, but you **cannot** create, modify, or delete services. Any destructive or mutating cloud operation (service creation, deletion, scaling, etc.) **requires API key authentication** (Option B). If this workflow involves creating or changing cloud resources, you must use Option B.\n\n### Option A: Browser login (read-only access)\n\nUse this when a human is available to open a browser and you only need to inspect existing cloud resources (list orgs, list services, query data). It uses OAuth device flow — no API keys needed.\n\nInstruct the user to run:\n\n```bash\nclickhousectl cloud login\n```\n\nThis prints a URL and a code. The user opens the URL in their browser, confirms the code, and logs in with their ClickHouse Cloud account. The CLI automatically receives credentials once the browser flow completes.\n\nThis is sufficient for steps that only read data (e.g., `cloud org list`, `cloud service get`, `cloud service client`). For any step that creates or modifies resources, switch to API key auth.\n\n### Option B: API key auth (required for destructive actions)\n\n**Use this option when creating, modifying, or deleting cloud resources** (e.g., `cloud service create`, `cloud service delete`). Also use this for headless\u002FCI environments where no browser is available. Both `--api-key` and `--api-secret` are **required** — if the user provides one without the other, tell them both are needed.\n\n```bash\nclickhousectl cloud login --api-key \u003Ckey> --api-secret \u003Csecret>\n```\n\nIf the user doesn't have API keys yet, guide them to create one:\n\n> In the ClickHouse Cloud console:\n> 1. Click the **gear icon** (Settings) in the left sidebar\n> 2. Go to **API Keys**\n> 3. Click **Create API Key**\n> 4. Give it a name (e.g., \"cli\") and select the **Admin** role\n> 5. Click **Generate API Key**\n> 6. **Copy both the Key ID and the Key Secret** — the secret is only shown once\n\n---\n\n**To verify authentication works:**\n\n```bash\nclickhousectl cloud org list\n```\n\nThis should return the user's organization.\n\n---\n\n## Step 3: Create a cloud service\n\n> **Requires API key auth.** Service creation is a mutating operation. If you authenticated with browser login (Option A) in Step 2, you must re-authenticate with API key auth (Option B) before proceeding.\n\nCreate a new ClickHouse Cloud service:\n\n```bash\nclickhousectl cloud service create --name \u003Cservice-name>\n```\n\n**The output includes the service ID and default user password** — note it for subsequent commands.\n\n**Wait for the service to be ready.** After creation, the service takes a moment to provision. Check its status:\n\n```bash\nclickhousectl cloud service get \u003Cservice-id>\n```\nYou can grep the \"state\" field to see if it is \"running\".\n\n---\n\n## Step 4: Migrate schemas\n\nIf the user has local table definitions (e.g., from using the `clickhousectl-local-dev` skill), migrate them to the cloud service.\n\nUse `cloud service client` to run queries against the cloud service — it looks up the endpoint, port, and TLS settings automatically. You just need the service name (or `--id`) and the password from step 3.\n\n**Read the local schema files** from `clickhouse\u002Ftables\u002F` and apply each one to the cloud service:\n\n```bash\nclickhousectl cloud service client --name \u003Cservice-name> \\\n  --queries-file clickhouse\u002Ftables\u002F\u003Ctable>.sql\n```\n\nApply them in dependency order — tables referenced by materialized views should be created first.\n\n**Also apply materialized views** if they exist:\n\n```bash\nclickhousectl cloud service client --name \u003Cservice-name> \\\n  --queries-file clickhouse\u002Fmaterialized_views\u002F\u003Cview>.sql\n```\n\nThe `--user` flag defaults to `default`. If the user has a different database user, pass `--user \u003Cusername>`.\n\n---\n\n## Step 5: Verify the deployment\n\nConnect to the cloud service and confirm tables exist:\n\n```bash\nclickhousectl cloud service client --name \u003Cservice-name> --query \"SHOW TABLES\"\n```\n\nRun a test query to confirm the schema is correct:\n\n```bash\nclickhousectl cloud service client --name \u003Cservice-name> --query \"DESCRIBE TABLE \u003Ctable-name>\"\n```\n\n---\n\n## Step 6: Update application config\n\nRetrieve the service endpoint for the user's application config:\n\n```bash\nclickhousectl cloud service get \u003Cservice-id>\n```\n\nProvide the user with the connection details:\n\n- **Host:** from the service `get` output\n- **Port:** `8443` for HTTPS \u002F `9440` for native TLS\n- **User:** `default`\n- **Password:** the password from step 3 (service creation)\n- **SSL\u002FTLS:** required (always enabled on Cloud)\n\n**Example connection strings** (adapt to the user's language\u002Fframework):\n\n**Python (clickhouse-connect):**\n```python\nimport clickhouse_connect\n\nclient = clickhouse_connect.get_client(\n    host='\u003Ccloud-host>',\n    port=8443,\n    username='default',\n    password='\u003Cpassword>',\n    secure=True\n)\n```\n\n**Node.js (@clickhouse\u002Fclient):**\n```javascript\nimport { createClient } from '@clickhouse\u002Fclient'\n\nconst client = createClient({\n  url: 'https:\u002F\u002F\u003Ccloud-host>:8443',\n  username: 'default',\n  password: '\u003Cpassword>',\n})\n```\n\n**Go (clickhouse-go):**\n```go\nconn, err := clickhouse.Open(&clickhouse.Options{\n    Addr: []string{\"\u003Ccloud-host>:9440\"},\n    Auth: clickhouse.Auth{\n        Username: \"default\",\n        Password: \"\u003Cpassword>\",\n    },\n    TLS: &tls.Config{},\n})\n```\n\nSuggest the user store the password in an environment variable or secrets manager rather than hardcoding it.\n\nSuggest the user should not use the default user in production. A user should be created just for their app.","# Deploy to ClickHouse Cloud\n\nThis skill walks through deploying to ClickHouse Cloud using `clickhousectl`. It covers account setup, CLI authentication, service creation, schema migration, and connecting your application. Follow these steps in order.\n\n## When to Apply\n\nUse this skill when the user wants to:\n- Deploy their ClickHouse application to production\n- Host ClickHouse as a managed cloud service\n- Migrate from a local ClickHouse setup to ClickHouse Cloud\n- Create a ClickHouse Cloud service\n- Set up ClickHouse Cloud for the first time\n\n---\n\n## Step 1: Sign up for ClickHouse Cloud\n\nBefore using any cloud commands, the user needs a ClickHouse Cloud account.\n\n**Ask the user:** \"Do you already have a ClickHouse Cloud account?\"\n\n**If they do not have an account**, explain:\n\n> ClickHouse Cloud is a fully managed service that runs ClickHouse for you — no infrastructure to maintain, automatic scaling, backups, and upgrades included. There's a free trial so you can get started without a credit card.\n>\n> To create an account, go to: **https:\u002F\u002Fclickhouse.cloud**\n>\n> Sign up with your email, Google, or GitHub account. Once you're in the console, let me know and we'll continue with the next step.\n\n**Wait for the user to confirm** they have signed up or already have an account before proceeding.\n\n---\n\n## Step 2: Authenticate the CLI\n\nFirst, ensure `clickhousectl` is installed. Check with:\n\n```bash\nwhich clickhousectl\n```\n\nIf not found, install it:\n\n```bash\ncurl -fsSL https:\u002F\u002Fclickhouse.com\u002Fcli | sh\n```\n\nNow authenticate. There are two options — choose based on the situation:\n\n> **Important: OAuth login is read-only.** Browser login (Option A) grants read-only access — you can list organizations, services, and query existing services, but you **cannot** create, modify, or delete services. Any destructive or mutating cloud operation (service creation, deletion, scaling, etc.) **requires API key authentication** (Option B). If this workflow involves creating or changing cloud resources, you must use Option B.\n\n### Option A: Browser login (read-only access)\n\nUse this when a human is available to open a browser and you only need to inspect existing cloud resources (list orgs, list services, query data). It uses OAuth device flow — no API keys needed.\n\nInstruct the user to run:\n\n```bash\nclickhousectl cloud login\n```\n\nThis prints a URL and a code. The user opens the URL in their browser, confirms the code, and logs in with their ClickHouse Cloud account. The CLI automatically receives credentials once the browser flow completes.\n\nThis is sufficient for steps that only read data (e.g., `cloud org list`, `cloud service get`, `cloud service client`). For any step that creates or modifies resources, switch to API key auth.\n\n### Option B: API key auth (required for destructive actions)\n\n**Use this option when creating, modifying, or deleting cloud resources** (e.g., `cloud service create`, `cloud service delete`). Also use this for headless\u002FCI environments where no browser is available. Both `--api-key` and `--api-secret` are **required** — if the user provides one without the other, tell them both are needed.\n\n```bash\nclickhousectl cloud login --api-key \u003Ckey> --api-secret \u003Csecret>\n```\n\nIf the user doesn't have API keys yet, guide them to create one:\n\n> In the ClickHouse Cloud console:\n> 1. Click the **gear icon** (Settings) in the left sidebar\n> 2. Go to **API Keys**\n> 3. Click **Create API Key**\n> 4. Give it a name (e.g., \"cli\") and select the **Admin** role\n> 5. Click **Generate API Key**\n> 6. **Copy both the Key ID and the Key Secret** — the secret is only shown once\n\n---\n\n**To verify authentication works:**\n\n```bash\nclickhousectl cloud org list\n```\n\nThis should return the user's organization.\n\n---\n\n## Step 3: Create a cloud service\n\n> **Requires API key auth.** Service creation is a mutating operation. If you authenticated with browser login (Option A) in Step 2, you must re-authenticate with API key auth (Option B) before proceeding.\n\nCreate a new ClickHouse Cloud service:\n\n```bash\nclickhousectl cloud service create --name \u003Cservice-name>\n```\n\n**The output includes the service ID and default user password** — note it for subsequent commands.\n\n**Wait for the service to be ready.** After creation, the service takes a moment to provision. Check its status:\n\n```bash\nclickhousectl cloud service get \u003Cservice-id>\n```\nYou can grep the \"state\" field to see if it is \"running\".\n\n---\n\n## Step 4: Migrate schemas\n\nIf the user has local table definitions (e.g., from using the `clickhousectl-local-dev` skill), migrate them to the cloud service.\n\nUse `cloud service client` to run queries against the cloud service — it looks up the endpoint, port, and TLS settings automatically. You just need the service name (or `--id`) and the password from step 3.\n\n**Read the local schema files** from `clickhouse\u002Ftables\u002F` and apply each one to the cloud service:\n\n```bash\nclickhousectl cloud service client --name \u003Cservice-name> \\\n  --queries-file clickhouse\u002Ftables\u002F\u003Ctable>.sql\n```\n\nApply them in dependency order — tables referenced by materialized views should be created first.\n\n**Also apply materialized views** if they exist:\n\n```bash\nclickhousectl cloud service client --name \u003Cservice-name> \\\n  --queries-file clickhouse\u002Fmaterialized_views\u002F\u003Cview>.sql\n```\n\nThe `--user` flag defaults to `default`. If the user has a different database user, pass `--user \u003Cusername>`.\n\n---\n\n## Step 5: Verify the deployment\n\nConnect to the cloud service and confirm tables exist:\n\n```bash\nclickhousectl cloud service client --name \u003Cservice-name> --query \"SHOW TABLES\"\n```\n\nRun a test query to confirm the schema is correct:\n\n```bash\nclickhousectl cloud service client --name \u003Cservice-name> --query \"DESCRIBE TABLE \u003Ctable-name>\"\n```\n\n---\n\n## Step 6: Update application config\n\nRetrieve the service endpoint for the user's application config:\n\n```bash\nclickhousectl cloud service get \u003Cservice-id>\n```\n\nProvide the user with the connection details:\n\n- **Host:** from the service `get` output\n- **Port:** `8443` for HTTPS \u002F `9440` for native TLS\n- **User:** `default`\n- **Password:** the password from step 3 (service creation)\n- **SSL\u002FTLS:** required (always enabled on Cloud)\n\n**Example connection strings** (adapt to the user's language\u002Fframework):\n\n**Python (clickhouse-connect):**\n```python\nimport clickhouse_connect\n\nclient = clickhouse_connect.get_client(\n    host='\u003Ccloud-host>',\n    port=8443,\n    username='default',\n    password='\u003Cpassword>',\n    secure=True\n)\n```\n\n**Node.js (@clickhouse\u002Fclient):**\n```javascript\nimport { createClient } from '@clickhouse\u002Fclient'\n\nconst client = createClient({\n  url: 'https:\u002F\u002F\u003Ccloud-host>:8443',\n  username: 'default',\n  password: '\u003Cpassword>',\n})\n```\n\n**Go (clickhouse-go):**\n```go\nconn, err := clickhouse.Open(&clickhouse.Options{\n    Addr: []string{\"\u003Ccloud-host>:9440\"},\n    Auth: clickhouse.Auth{\n        Username: \"default\",\n        Password: \"\u003Cpassword>\",\n    },\n    TLS: &tls.Config{},\n})\n```\n\nSuggest the user store the password in an environment variable or secrets manager rather than hardcoding it.\n\nSuggest the user should not use the default user in production. A user should be created just for their app.",{"name":5,"license":15,"metadata":45,"description":7},{"author":46,"version":47},"ClickHouse Inc","0.1.0","master","c2e410e11df4d80d885e0ecf0583ef3c926df736","factory\u002Flibrary\u002Fskills\u002Fofficial_clickhouse_clickhousectl_cloud_deploy",0,"https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory","https:\u002F\u002Fgithub.com\u002FiDorgham","Dorgham.me","hey I'm Dorgham \r\nI code, I create, and AI codes back. \r\nMaybe we can give AI the chance!! now we begin. 🚀🤖\r\n... . . . git commit -m \"Hello, Future\" ","2026-05-04 18:39:09",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add iDorgham\u002FWorkspace-Factory --skill clickhousectl-cloud-deploy",{"tool":63,"command":64},"bunx","bunx skills add iDorgham\u002FWorkspace-Factory --skill clickhousectl-cloud-deploy",{"tool":66,"command":67},"pnpm","pnpm dlx skills add iDorgham\u002FWorkspace-Factory --skill clickhousectl-cloud-deploy","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Fskills\u002Fofficial_clickhouse_clickhousectl_cloud_deploy\u002Fskill.md",true,[],[72,103,126,148,167,190],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":76,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":82,"publishedAt":102},"01M71P8WVBMB2X3D24R0YT0B0E","vercel-react-view-transitions","Guide for implementing smooth, native-feeling animations using React's View Transition API (`\u003CViewTransition>` component, `addTransitionType`, and CSS view transition pseudo-elements). Use this skill whenever the user wants to add page transitions, animate route changes, create shared element animations, animate enter\u002Fexit of components, animate list reorder, implement directional (forward\u002Fback) navigation animations, or integrate view transitions in Next.js. Also use when the user mentions view transitions, `startViewTransition`, `ViewTransition`, transition types, or asks about animating between UI states in React without third-party animation libraries.","MIT","https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Fskills\u002Fofficial_vercel_labs_react_view_transitions\u002Fskill.md",[79],{"categoryNo":80,"categoryName":81,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[83,84,85,86,87,88,89,90,91,92,93,94,95,96,33,97,98,99,100,101],"react","vercel react view transitions","view","react view transitions","vercel","transitions","shared","back","Animation","css","types","states","element","implementing","components","api","route","create","libraries","2026-11-10 13:02:02",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":76,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":110,"publishedAt":102},"01M71P8TDGHZ289TSAC5VTG2EW","vercel-react-native-skills","React Native and Expo best practices for building performant mobile apps. Use when building React Native components, optimizing list performance, implementing animations, or working with native modules. Triggers on tasks involving React Native, Expo, mobile performance, or native platform APIs.","https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Fskills\u002Fofficial_vercel_labs_react_native_skills\u002Fskill.md",[109],{"categoryNo":80,"categoryName":81,"taxonomyType":21,"taxonomyTypeDesc":22},[83,111,112,87,113,114,115,116,96,117,33,118,97,119,120,121,122,123,124,125],"react native","native","vercel react native skills","react native skills","modules","performance","apps","tasks","mobile","expo","list","mobile performance","platform","animations","for",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":76,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":133,"publishedAt":102},"01M71P8QK4JF5BYRGYDDGPZQG9","vercel-react-best-practices","React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React\u002FNext.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.","https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Fskills\u002Fofficial_vercel_labs_react_best_practices\u002Fskill.md",[132],{"categoryNo":80,"categoryName":81,"taxonomyType":21,"taxonomyTypeDesc":22},[83,134,135,87,136,116,137,33,138,118,97,139,140,141,142,143,144,145,146,147],"react best practices","vercel react best practices","best practices","writing","code","data fetching","react components","next","refactoring","data","patterns","Optimization","guidelines","triggers",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":76,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":155,"publishedAt":102},"01M71P8HVEA70K5N6ZVJCG2ED3","vercel-composition-patterns","React composition patterns that scale. Use when refactoring components with boolean prop proliferation, building flexible component libraries, or designing reusable APIs. Triggers on tasks involving compound components, render props, context providers, or component architecture. Includes React 19 API changes.","https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Fskills\u002Fofficial_vercel_labs_composition_patterns\u002Fskill.md",[154],{"categoryNo":80,"categoryName":81,"taxonomyType":21,"taxonomyTypeDesc":22},[156,87,157,144,158,159,160,161,147,162,163,32,33,164,118,97,165,166,98,83],"Composition","composition patterns","vercel composition patterns","react composition patterns","react 19","render","boolean","component architecture","reusable","architecture","react composition",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":76,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":176,"publishedAt":102},"01M71P60XXKKP222ZFJRG7R373","supabase-postgres-best-practices","Postgres performance optimization and best practices from Supabase. Use this skill when writing, reviewing, or optimizing Postgres queries, schema designs, or database configurations.","https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Fskills\u002Fofficial_supabase_supabase_postgres_best_practices\u002Fskill.md",[173],{"categoryNo":174,"categoryName":175,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[177,178,179,180,136,181,182,183,125,145,116,184,185,137,186,32,187,188,189,33],"postgres best practices","supabase","postgres","supabase postgres best practices","categories","postgres performance","advanced","correct","schema","impact","Rules","critical","database",{"skillNo":191,"name":192,"nameZh":6,"description":193,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":76,"licenseFileUrl":6,"sourceHtmlUrl":194,"categories":195,"keywords":197,"publishedAt":40},"01M71P2ZCEJD0PKC458YTP1FJW","portable-text-serialization","Render and serialize Portable Text to React, Svelte, Vue, Astro, HTML, Markdown, and plain text. Use when implementing Portable Text rendering in any frontend framework, building custom serializers for non-standard block types, converting Portable Text to HTML strings server-side, converting Portable Text to Markdown, extracting plain text from Portable Text, or troubleshooting rendering issues with marks, blocks, lists, or custom types.","https:\u002F\u002Fgithub.com\u002FiDorgham\u002FWorkspace-Factory\u002Fblob\u002Fmaster\u002Ffactory\u002Flibrary\u002Fskills\u002Fofficial_sanity_io_portable_text_serialization\u002Fskill.md",[196],{"categoryNo":80,"categoryName":81,"taxonomyType":21,"taxonomyTypeDesc":22},[198,199,200,201,202,93,203,161,204,96,205,206,33,83,207,208,209,210,211,212],"text","portable text serialization","portable","serialization","extracting","strings","issues","frontend","svelte","sanity","astro","server","markdown","rendering","vue"]