[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71PASSZY800C0RPEARBS918":3,"skill-same:01M71PASSZY800C0RPEARBS918":82},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":15,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":59,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M71PASSZY800C0RPEARBS918","write-query",null,"Write optimized SQL for your dialect with best practices. Use when translating a natural-language data need into SQL, building a multi-CTE query with joins and aggregations, optimizing a query against a large partitioned table, or getting dialect-specific syntax for Snowflake, BigQuery, Postgres, etc.","monoes\u002Fmonomind","monoes","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F276744696?v=4","01M71KWF37AJ2NJBP3KWBVSDGT","01M71KWF4CSF8ADH0M6HA09VD2",23,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"write","write query","query","data","plugins","syntax","https","sql","github","work","multi","with","natural-language","best practices","when","use","knowledge","snowflake","for","postgres","2026-11-10 13:02:02",false,"---\nname: write-query\ndescription: \"Write optimized SQL for your dialect with best practices. Use when translating a natural-language data need into SQL, building a multi-CTE query with joins and aggregations, optimizing a query against a large partitioned table, or getting dialect-specific syntax for Snowflake, BigQuery, Postgres, etc.\"\ntags: []\ntools: []\nlicense: Apache-2.0\nsource: https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins\nsource_path: \"data\u002Fskills\u002Fwrite-query\"\nsource_commit: 8444efcd48f7012f09797778a36a33e73d0861f4\n---\n# \u002Fwrite-query - Write Optimized SQL\n\n> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](..\u002F..\u002FCONNECTORS.md).\n\nWrite a SQL query from a natural language description, optimized for your specific SQL dialect and following best practices.\n\n## Usage\n\n```\n\u002Fwrite-query \u003Cdescription of what data you need>\n```\n\n## Workflow\n\n### 1. Understand the Request\n\nParse the user's description to identify:\n\n- **Output columns**: What fields should the result include?\n- **Filters**: What conditions limit the data (time ranges, segments, statuses)?\n- **Aggregations**: Are there GROUP BY operations, counts, sums, averages?\n- **Joins**: Does this require combining multiple tables?\n- **Ordering**: How should results be sorted?\n- **Limits**: Is there a top-N or sample requirement?\n\n### 2. Determine SQL Dialect\n\nIf the user's SQL dialect is not already known, ask which they use:\n\n- **PostgreSQL** (including Aurora, RDS, Supabase, Neon)\n- **Snowflake**\n- **BigQuery** (Google Cloud)\n- **Redshift** (Amazon)\n- **Databricks SQL**\n- **MySQL** (including Aurora MySQL, PlanetScale)\n- **SQL Server** (Microsoft)\n- **DuckDB**\n- **SQLite**\n- **Other** (ask for specifics)\n\nRemember the dialect for future queries in the same session.\n\n### 3. Discover Schema (If Warehouse Connected)\n\nIf a data warehouse MCP server is connected:\n\n1. Search for relevant tables based on the user's description\n2. Inspect column names, types, and relationships\n3. Check for partitioning or clustering keys that affect performance\n4. Look for pre-built views or materialized views that might simplify the query\n\n### 4. Write the Query\n\nFollow these best practices:\n\n**Structure:**\n- Use CTEs (WITH clauses) for readability when queries have multiple logical steps\n- One CTE per logical transformation or data source\n- Name CTEs descriptively (e.g., `daily_signups`, `active_users`, `revenue_by_product`)\n\n**Performance:**\n- Never use `SELECT *` in production queries -- specify only needed columns\n- Filter early (push WHERE clauses as close to the base tables as possible)\n- Use partition filters when available (especially date partitions)\n- Prefer `EXISTS` over `IN` for subqueries with large result sets\n- Use appropriate JOIN types (don't use LEFT JOIN when INNER JOIN is correct)\n- Avoid correlated subqueries when a JOIN or window function works\n- Be mindful of exploding joins (many-to-many)\n\n**Readability:**\n- Add comments explaining the \"why\" for non-obvious logic\n- Use consistent indentation and formatting\n- Alias tables with meaningful short names (not just `a`, `b`, `c`)\n- Put each major clause on its own line\n\n**Dialect-specific optimizations:**\n- Apply dialect-specific syntax and functions (see `sql-queries` skill for details)\n- Use dialect-appropriate date functions, string functions, and window syntax\n- Note any dialect-specific performance features (e.g., Snowflake clustering, BigQuery partitioning)\n\n### 5. Present the Query\n\nProvide:\n\n1. **The complete query** in a SQL code block with syntax highlighting\n2. **Brief explanation** of what each CTE or section does\n3. **Performance notes** if relevant (expected cost, partition usage, potential bottlenecks)\n4. **Modification suggestions** -- how to adjust for common variations (different time range, different granularity, additional filters)\n\n### 6. Offer to Execute\n\nIf a data warehouse is connected, offer to run the query and analyze the results. If the user wants to run it themselves, the query is ready to copy-paste.\n\n## Examples\n\n**Simple aggregation:**\n```\n\u002Fwrite-query Count of orders by status for the last 30 days\n```\n\n**Complex analysis:**\n```\n\u002Fwrite-query Cohort retention analysis -- group users by their signup month, then show what percentage are still active (had at least one event) at 1, 3, 6, and 12 months after signup\n```\n\n**Performance-critical:**\n```\n\u002Fwrite-query We have a 500M row events table partitioned by date. Find the top 100 users by event count in the last 7 days with their most recent event type.\n```\n\n## Tips\n\n- Mention your SQL dialect upfront to get the right syntax immediately\n- If you know the table names, include them -- otherwise Claude will help you find them\n- Specify if you need the query to be idempotent (safe to re-run) or one-time\n- For recurring queries, mention if it should be parameterized for date ranges\n","# \u002Fwrite-query - Write Optimized SQL\n\n> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](..\u002F..\u002FCONNECTORS.md).\n\nWrite a SQL query from a natural language description, optimized for your specific SQL dialect and following best practices.\n\n## Usage\n\n```\n\u002Fwrite-query \u003Cdescription of what data you need>\n```\n\n## Workflow\n\n### 1. Understand the Request\n\nParse the user's description to identify:\n\n- **Output columns**: What fields should the result include?\n- **Filters**: What conditions limit the data (time ranges, segments, statuses)?\n- **Aggregations**: Are there GROUP BY operations, counts, sums, averages?\n- **Joins**: Does this require combining multiple tables?\n- **Ordering**: How should results be sorted?\n- **Limits**: Is there a top-N or sample requirement?\n\n### 2. Determine SQL Dialect\n\nIf the user's SQL dialect is not already known, ask which they use:\n\n- **PostgreSQL** (including Aurora, RDS, Supabase, Neon)\n- **Snowflake**\n- **BigQuery** (Google Cloud)\n- **Redshift** (Amazon)\n- **Databricks SQL**\n- **MySQL** (including Aurora MySQL, PlanetScale)\n- **SQL Server** (Microsoft)\n- **DuckDB**\n- **SQLite**\n- **Other** (ask for specifics)\n\nRemember the dialect for future queries in the same session.\n\n### 3. Discover Schema (If Warehouse Connected)\n\nIf a data warehouse MCP server is connected:\n\n1. Search for relevant tables based on the user's description\n2. Inspect column names, types, and relationships\n3. Check for partitioning or clustering keys that affect performance\n4. Look for pre-built views or materialized views that might simplify the query\n\n### 4. Write the Query\n\nFollow these best practices:\n\n**Structure:**\n- Use CTEs (WITH clauses) for readability when queries have multiple logical steps\n- One CTE per logical transformation or data source\n- Name CTEs descriptively (e.g., `daily_signups`, `active_users`, `revenue_by_product`)\n\n**Performance:**\n- Never use `SELECT *` in production queries -- specify only needed columns\n- Filter early (push WHERE clauses as close to the base tables as possible)\n- Use partition filters when available (especially date partitions)\n- Prefer `EXISTS` over `IN` for subqueries with large result sets\n- Use appropriate JOIN types (don't use LEFT JOIN when INNER JOIN is correct)\n- Avoid correlated subqueries when a JOIN or window function works\n- Be mindful of exploding joins (many-to-many)\n\n**Readability:**\n- Add comments explaining the \"why\" for non-obvious logic\n- Use consistent indentation and formatting\n- Alias tables with meaningful short names (not just `a`, `b`, `c`)\n- Put each major clause on its own line\n\n**Dialect-specific optimizations:**\n- Apply dialect-specific syntax and functions (see `sql-queries` skill for details)\n- Use dialect-appropriate date functions, string functions, and window syntax\n- Note any dialect-specific performance features (e.g., Snowflake clustering, BigQuery partitioning)\n\n### 5. Present the Query\n\nProvide:\n\n1. **The complete query** in a SQL code block with syntax highlighting\n2. **Brief explanation** of what each CTE or section does\n3. **Performance notes** if relevant (expected cost, partition usage, potential bottlenecks)\n4. **Modification suggestions** -- how to adjust for common variations (different time range, different granularity, additional filters)\n\n### 6. Offer to Execute\n\nIf a data warehouse is connected, offer to run the query and analyze the results. If the user wants to run it themselves, the query is ready to copy-paste.\n\n## Examples\n\n**Simple aggregation:**\n```\n\u002Fwrite-query Count of orders by status for the last 30 days\n```\n\n**Complex analysis:**\n```\n\u002Fwrite-query Cohort retention analysis -- group users by their signup month, then show what percentage are still active (had at least one event) at 1, 3, 6, and 12 months after signup\n```\n\n**Performance-critical:**\n```\n\u002Fwrite-query We have a 500M row events table partitioned by date. Find the top 100 users by event count in the last 7 days with their most recent event type.\n```\n\n## Tips\n\n- Mention your SQL dialect upfront to get the right syntax immediately\n- If you know the table names, include them -- otherwise Claude will help you find them\n- Specify if you need the query to be idempotent (safe to re-run) or one-time\n- For recurring queries, mention if it should be parameterized for date ranges\n",{"name":5,"tags":49,"tools":50,"source":51,"license":14,"description":7,"source_path":52,"source_commit":53},[],[],"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fknowledge-work-plugins","data\u002Fskills\u002Fwrite-query","8444efcd48f7012f09797778a36a33e73d0861f4","main","f7cd4595d0f8959822163e14f9787117765c931a","packages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query",2,"https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind","https:\u002F\u002Fmonoes.github.io\u002Fmonomind\u002F","https:\u002F\u002Fgithub.com\u002Fmonoes","https:\u002F\u002Fmonoes.me","2026-11-10 01:53:48",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add monoes\u002Fmonomind --skill write-query",{"tool":69,"command":70},"bunx","bunx skills add monoes\u002Fmonomind --skill write-query",{"tool":72,"command":73},"pnpm","pnpm dlx skills add monoes\u002Fmonomind --skill write-query","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-query\u002FSKILL.md",true,[77],{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":15},"LICENSE.txt","LICENSE","许可证",11607,[83,108,141,166,193,215],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":44},"01M71PB3SHWKMNJM6MD65VX8D6","zk-steward","Org role guidance for a ZK steward: engineer zero-knowledge proof systems with circuit design, SNARK vs STARK choice and security review. This is zero-knowledge cryptography, not Zettelkasten note-taking.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fzk-steward\u002FSKILL.md",[],[90,91,92,93,94,95,96,40,97,26,98,99,100,101,102,103,104,105,106,107],"zk","zk steward","steward","zero-knowledge","engineer","choice","design","impact","snark","review","monomind","security review","stark","zettelkasten","cryptography","security","org","blockchain",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":112,"licenseFileUrl":113,"sourceHtmlUrl":114,"categories":115,"keywords":124,"publishedAt":44},"01M71PB18SDG28WBKPKJNB814K","writing-plans","Use when you have a spec or requirements for a multi-step coding task and must write an implementation plan before touching code. Produces bite-sized TDD tasks with exact file paths, code and commands for an engineer with zero context.","MIT","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwriting-plans\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwriting-plans\u002FSKILL.md",[116,121],{"categoryNo":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000036","内容创作者",[125,126,127,94,128,129,38,130,26,131,132,133,134,24,135,136,137,138,139,140],"writing","writing plans","plans","superpowers","implementation plan","you","code","tasks","plan","product","commands","paths","suggest","coding","context","ZeRO",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":145,"sourceHtmlUrl":146,"categories":147,"keywords":151,"publishedAt":44},"01M71PAXFM488X9ARXK0T04TF5","write-spec","Write a feature spec or PRD from a problem statement or feature idea. Use when turning a vague idea or user request into a structured document, scoping a feature with goals and non-goals, defining success metrics and acceptance criteria, or breaking a big ask into a phased spec.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fwrite-spec\u002FSKILL.md",[148],{"categoryNo":149,"categoryName":150,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理",[24,152,153,154,155,40,156,38,157,158,33,134,159,160,161,162,163,164,39,165],"write spec","spec","user request","problem","acceptance","ask","vague","request","scoping","idea","metrics","feature","problem statement","document",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":178,"publishedAt":44},"01M71PAPTX0T3PF6ETFVR96SJJ","workflow-automation","Org role guidance for workflow automation: build and maintain CI\u002FCD definitions in GitHub Actions or equivalent: triggers, jobs, matrices, caching. Covers path filters, dependency caching, parallel jobs, timeouts and fail-fast ordering.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworkflow-automation\u002FSKILL.md",[172,175],{"categoryNo":173,"categoryName":174,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":176,"categoryName":177,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000023","Skill与智能体开发",[179,180,181,182,42,183,184,185,186,97,187,188,189,26,100,32,190,191,192,30],"Workflow Automation","automation","workflow","parallel","actions","ci","triggers","github actions","maintain","filters","caching","build","dependency","devops",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":200,"publishedAt":44},"01M71PAM19Z1XTV9NPCFSE2MY8","workflow-architect","Org role guidance for a workflow architect: map full workflow trees for systems, user journeys and agents, covering every branch and failure. Covers discovering workflows from code, handoff contracts, timeouts, recovery paths and observable state.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworkflow-architect\u002FSKILL.md",[199],{"categoryNo":176,"categoryName":177,"taxonomyType":119,"taxonomyTypeDesc":120},[181,201,202,203,204,205,206,42,207,208,131,209,210,211,100,32,212,213,30,214],"workflow architect","architect","trees","user journeys","branch","planning","map","workflows","architecture","state","leadership","recovery","operations","systems",{"skillNo":216,"name":217,"nameZh":6,"description":218,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":219,"categories":220,"keywords":221,"publishedAt":44},"01M71PAHFJHG641X0RR432KB3G","worker-specialist","Org role guidance for a worker specialist: execute one assigned, well-scoped task with precision and report status honestly at real milestones. Covers confirming done-criteria first, surfacing blockers immediately and sharing intermediate results with peers.","https:\u002F\u002Fgithub.com\u002Fmonoes\u002Fmonomind\u002Fblob\u002Fmain\u002Fpackages\u002F@monomind\u002Fcli\u002Forg-skills\u002Fworker-specialist\u002FSKILL.md",[],[222,223,224,42,225,226,227,228,229,230,35,231,100,32,232,213,233,234,235,30],"worker","worker specialist","specialist","scoped","milestones","done","one","coordination","task","first","results","report status","sharing","at"]