[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6H4Z652MHSMDPFDJ0XJH5K9":3,"skill-same:01M6H4Z652MHSMDPFDJ0XJH5K9":104},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":6,"ownerHtmlUrl":58,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":59,"install":60,"resources":73},"01M6H4Z652MHSMDPFDJ0XJH5K9","modeling-nosql-data",null,"Build use when you need to work with NoSQL data modeling.\nThis skill provides NoSQL database design with comprehensive guidance and automation.\nTrigger with phrases like \"model NoSQL data\", \"design document structure\",\nor \"optimize NoSQL schema\".","micsapp\u002Fmicstec-skills","micsapp","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F82411001?v=4","01M6GWCFQ6D3PV8EHNY62NN5VW","01M6GWCFVE1PA5HG0DKC7AMFJ3",4,"MIT","https:\u002F\u002Fgithub.com\u002Fmicsapp\u002Fmicstec-skills\u002Fblob\u002Fmaster\u002Fclaude-code\u002Fplugins-plus-skills\u002Fplugins\u002Fdatabase\u002Fnosql-data-modeler\u002Fskills\u002Fmodeling-nosql-data\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"modeling","data","nosql","Modeling NoSQL Data","use","you","with","trigger","io","structure","document","schema","design","model","Bash","mysql","database","code","data modeling","automation","2026-11-10 10:12:30",false,"---\nname: modeling-nosql-data\ndescription: |\n  Build use when you need to work with NoSQL data modeling.\n  This skill provides NoSQL database design with comprehensive guidance and automation.\n  Trigger with phrases like \"model NoSQL data\", \"design document structure\",\n  or \"optimize NoSQL schema\".\n\nallowed-tools: Read, Write, Edit, Grep, Glob, Bash(psql:*), Bash(mysql:*), Bash(mongosh:*)\nversion: 1.0.0\nauthor: Jeremy Longshore \u003Cjeremy@intentsolutions.io>\nlicense: MIT\ncompatible-with: claude-code, codex, openclaw\n---\n# NoSQL Data Modeler\n\n## Overview\n\nDesign data models for NoSQL databases including MongoDB (document), DynamoDB (key-value\u002Fwide-column), Redis (key-value), and Cassandra (wide-column). Unlike relational modeling where normalization drives design, NoSQL modeling starts from access patterns and query requirements, then shapes the data to serve those patterns efficiently.\n\n## Prerequisites\n\n- `mongosh`, `aws dynamodb` CLI, `redis-cli`, or `cqlsh` installed depending on target database\n- Documented list of application access patterns (read\u002Fwrite queries the application performs)\n- Expected data volumes (document count, average document size, growth rate)\n- Read\u002Fwrite ratio and latency requirements for each access pattern\n- Understanding of consistency requirements (strong vs. eventual consistency)\n\n## Instructions\n\n1. Catalog all application access patterns as a table with columns: pattern name, query description, frequency (queries\u002Fsec), latency requirement, and data fields accessed. This drives every modeling decision.\n\n2. For MongoDB document modeling, apply the embedding vs. referencing decision framework:\n   - **Embed** when: data is always accessed together, child data has no independent lifecycle, cardinality is bounded (1:few), and updates are infrequent.\n   - **Reference** when: data has independent access patterns, cardinality is unbounded (1:many\u002Fmany:many), child documents are large, or data is shared across parents.\n\n3. Design document schemas that match query patterns. If the application needs \"all orders for a customer with line items,\" embed line items inside the order document. If the application needs \"all products across all orders,\" use references to a products collection.\n\n4. For DynamoDB, design the partition key and sort key to support the primary access pattern with a single-table design. Use composite sort keys (e.g., `ORDER#2024-01-15#12345`) for hierarchical data. Plan GSIs (Global Secondary Indexes) for secondary access patterns, keeping total GSI count under 5.\n\n5. Evaluate denormalization trade-offs: duplicating data across documents reduces read latency but increases write complexity and storage. Denormalize data that changes rarely (user names, product categories) but reference data that changes frequently (prices, inventory counts).\n\n6. Handle one-to-many relationships by choosing between embedding (small arrays), child referencing (parent stores child IDs), or parent referencing (child stores parent ID). For unbounded one-to-many, always use parent referencing to avoid document size limits (16MB in MongoDB).\n\n7. Model many-to-many relationships using an array of references in each document or a dedicated junction collection. For DynamoDB, use adjacency list patterns with inverted GSIs.\n\n8. Plan for schema evolution by using schema versioning fields (`schemaVersion: 2`), writing migration scripts that update documents in batches, and ensuring application code handles both old and new document shapes during rollout.\n\n9. Validate the model against access patterns by running sample queries with `explain()` in MongoDB or examining consumed capacity units in DynamoDB. Verify that primary access patterns require only single-partition reads.\n\n10. Document the final data model with sample documents, index definitions, and the access pattern mapping that justifies each modeling decision.\n\n## Output\n\n- **Data model diagrams** showing document\u002Fcollection structure, embedded vs. referenced relationships\n- **Sample documents** in JSON format for each collection\u002Ftable with realistic data\n- **Index definitions** including compound indexes, partial indexes, and TTL indexes\n- **Access pattern mapping** table linking each query to its supporting collection and index\n- **Migration scripts** for evolving schemas from existing relational models to NoSQL\n\n## Error Handling\n\n| Error | Cause | Solution |\n|-------|-------|---------|\n| Document exceeds 16MB size limit (MongoDB) | Unbounded array growth from embedding too many child documents | Switch from embedding to referencing; use the bucket pattern to chunk large arrays into fixed-size sub-documents |\n| Hot partition in DynamoDB | Partition key with low cardinality causes uneven distribution | Add a random suffix or use a composite key; distribute writes across partitions with write sharding |\n| High read latency on referenced documents | Too many round trips to resolve references (N+1 query problem) | Denormalize frequently accessed reference data; use `$lookup` aggregation for server-side joins; batch reference resolution |\n| Inconsistent denormalized data | Write to source succeeds but denormalized copies not updated | Implement change streams (MongoDB) or DynamoDB Streams to propagate updates; use transactional writes where supported |\n| Query requires full collection scan | Missing index on query filter fields | Create compound indexes matching query predicates and sort order; use `explain()` to verify index usage |\n\n## Examples\n\n**E-commerce product catalog in MongoDB**: Products embed variant arrays (size, color, price) since variants are always accessed with the product. Reviews reference the product by ID since reviews are accessed independently and grow unboundedly. A compound index on `{category: 1, price: 1}` supports filtered browsing.\n\n**Social media feed in DynamoDB single-table design**: Partition key is `USER#userId`, sort key is `POST#timestamp` for user timeline queries. A GSI with partition key `HASHTAG#tag` and sort key `timestamp` supports hashtag feeds. User profile data uses sort key `PROFILE` on the same partition.\n\n**IoT sensor data in Cassandra**: Partition key is `sensor_id`, clustering column is `timestamp DESC`. Each partition holds one sensor's readings, ordered by time. TTL of 90 days automatically expires old readings. Materialized views support queries by location and sensor type.\n\n## Resources\n\n- MongoDB data modeling patterns: https:\u002F\u002Fwww.mongodb.com\u002Fdocs\u002Fmanual\u002Fdata-modeling\u002F\n- DynamoDB single-table design: https:\u002F\u002Fdocs.aws.amazon.com\u002Famazondynamodb\u002Flatest\u002Fdeveloperguide\u002Fbp-modeling-nosql.html\n- Cassandra data modeling guide: https:\u002F\u002Fcassandra.apache.org\u002Fdoc\u002Flatest\u002Fcassandra\u002Fdata_modeling\u002F\n- Redis data structures: https:\u002F\u002Fredis.io\u002Fdocs\u002Fdata-types\u002F\n- NoSQL design patterns catalog: https:\u002F\u002Fwww.mongodb.com\u002Fdocs\u002Fmanual\u002Fapplications\u002Fdata-models\u002F","# NoSQL Data Modeler\n\n## Overview\n\nDesign data models for NoSQL databases including MongoDB (document), DynamoDB (key-value\u002Fwide-column), Redis (key-value), and Cassandra (wide-column). Unlike relational modeling where normalization drives design, NoSQL modeling starts from access patterns and query requirements, then shapes the data to serve those patterns efficiently.\n\n## Prerequisites\n\n- `mongosh`, `aws dynamodb` CLI, `redis-cli`, or `cqlsh` installed depending on target database\n- Documented list of application access patterns (read\u002Fwrite queries the application performs)\n- Expected data volumes (document count, average document size, growth rate)\n- Read\u002Fwrite ratio and latency requirements for each access pattern\n- Understanding of consistency requirements (strong vs. eventual consistency)\n\n## Instructions\n\n1. Catalog all application access patterns as a table with columns: pattern name, query description, frequency (queries\u002Fsec), latency requirement, and data fields accessed. This drives every modeling decision.\n\n2. For MongoDB document modeling, apply the embedding vs. referencing decision framework:\n   - **Embed** when: data is always accessed together, child data has no independent lifecycle, cardinality is bounded (1:few), and updates are infrequent.\n   - **Reference** when: data has independent access patterns, cardinality is unbounded (1:many\u002Fmany:many), child documents are large, or data is shared across parents.\n\n3. Design document schemas that match query patterns. If the application needs \"all orders for a customer with line items,\" embed line items inside the order document. If the application needs \"all products across all orders,\" use references to a products collection.\n\n4. For DynamoDB, design the partition key and sort key to support the primary access pattern with a single-table design. Use composite sort keys (e.g., `ORDER#2024-01-15#12345`) for hierarchical data. Plan GSIs (Global Secondary Indexes) for secondary access patterns, keeping total GSI count under 5.\n\n5. Evaluate denormalization trade-offs: duplicating data across documents reduces read latency but increases write complexity and storage. Denormalize data that changes rarely (user names, product categories) but reference data that changes frequently (prices, inventory counts).\n\n6. Handle one-to-many relationships by choosing between embedding (small arrays), child referencing (parent stores child IDs), or parent referencing (child stores parent ID). For unbounded one-to-many, always use parent referencing to avoid document size limits (16MB in MongoDB).\n\n7. Model many-to-many relationships using an array of references in each document or a dedicated junction collection. For DynamoDB, use adjacency list patterns with inverted GSIs.\n\n8. Plan for schema evolution by using schema versioning fields (`schemaVersion: 2`), writing migration scripts that update documents in batches, and ensuring application code handles both old and new document shapes during rollout.\n\n9. Validate the model against access patterns by running sample queries with `explain()` in MongoDB or examining consumed capacity units in DynamoDB. Verify that primary access patterns require only single-partition reads.\n\n10. Document the final data model with sample documents, index definitions, and the access pattern mapping that justifies each modeling decision.\n\n## Output\n\n- **Data model diagrams** showing document\u002Fcollection structure, embedded vs. referenced relationships\n- **Sample documents** in JSON format for each collection\u002Ftable with realistic data\n- **Index definitions** including compound indexes, partial indexes, and TTL indexes\n- **Access pattern mapping** table linking each query to its supporting collection and index\n- **Migration scripts** for evolving schemas from existing relational models to NoSQL\n\n## Error Handling\n\n| Error | Cause | Solution |\n|-------|-------|---------|\n| Document exceeds 16MB size limit (MongoDB) | Unbounded array growth from embedding too many child documents | Switch from embedding to referencing; use the bucket pattern to chunk large arrays into fixed-size sub-documents |\n| Hot partition in DynamoDB | Partition key with low cardinality causes uneven distribution | Add a random suffix or use a composite key; distribute writes across partitions with write sharding |\n| High read latency on referenced documents | Too many round trips to resolve references (N+1 query problem) | Denormalize frequently accessed reference data; use `$lookup` aggregation for server-side joins; batch reference resolution |\n| Inconsistent denormalized data | Write to source succeeds but denormalized copies not updated | Implement change streams (MongoDB) or DynamoDB Streams to propagate updates; use transactional writes where supported |\n| Query requires full collection scan | Missing index on query filter fields | Create compound indexes matching query predicates and sort order; use `explain()` to verify index usage |\n\n## Examples\n\n**E-commerce product catalog in MongoDB**: Products embed variant arrays (size, color, price) since variants are always accessed with the product. Reviews reference the product by ID since reviews are accessed independently and grow unboundedly. A compound index on `{category: 1, price: 1}` supports filtered browsing.\n\n**Social media feed in DynamoDB single-table design**: Partition key is `USER#userId`, sort key is `POST#timestamp` for user timeline queries. A GSI with partition key `HASHTAG#tag` and sort key `timestamp` supports hashtag feeds. User profile data uses sort key `PROFILE` on the same partition.\n\n**IoT sensor data in Cassandra**: Partition key is `sensor_id`, clustering column is `timestamp DESC`. Each partition holds one sensor's readings, ordered by time. TTL of 90 days automatically expires old readings. Materialized views support queries by location and sensor type.\n\n## Resources\n\n- MongoDB data modeling patterns: https:\u002F\u002Fwww.mongodb.com\u002Fdocs\u002Fmanual\u002Fdata-modeling\u002F\n- DynamoDB single-table design: https:\u002F\u002Fdocs.aws.amazon.com\u002Famazondynamodb\u002Flatest\u002Fdeveloperguide\u002Fbp-modeling-nosql.html\n- Cassandra data modeling guide: https:\u002F\u002Fcassandra.apache.org\u002Fdoc\u002Flatest\u002Fcassandra\u002Fdata_modeling\u002F\n- Redis data structures: https:\u002F\u002Fredis.io\u002Fdocs\u002Fdata-types\u002F\n- NoSQL design patterns catalog: https:\u002F\u002Fwww.mongodb.com\u002Fdocs\u002Fmanual\u002Fapplications\u002Fdata-models\u002F",{"name":5,"author":48,"license":14,"version":49,"description":50,"allowed-tools":51,"compatible-with":52},"Jeremy Longshore \u003Cjeremy@intentsolutions.io>","1.0.0","Build use when you need to work with NoSQL data modeling.\nThis skill provides NoSQL database design with comprehensive guidance and automation.\nTrigger with phrases like \"model NoSQL data\", \"design document structure\",\nor \"optimize NoSQL schema\".\n","Read, Write, Edit, Grep, Glob, Bash(psql:*), Bash(mysql:*), Bash(mongosh:*)","claude-code, codex, openclaw","master","3f5d983eb4ef375b749adcd6b07ec03bd82ae8a8","claude-code\u002Fplugins-plus-skills\u002Fplugins\u002Fdatabase\u002Fnosql-data-modeler\u002Fskills\u002Fmodeling-nosql-data",0,"https:\u002F\u002Fgithub.com\u002Fmicsapp\u002Fmicstec-skills","https:\u002F\u002Fgithub.com\u002Fmicsapp","2026-03-20 11:24:18",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add micsapp\u002Fmicstec-skills --skill modeling-nosql-data",{"tool":66,"command":67},"bunx","bunx skills add micsapp\u002Fmicstec-skills --skill modeling-nosql-data",{"tool":69,"command":70},"pnpm","pnpm dlx skills add micsapp\u002Fmicstec-skills --skill modeling-nosql-data","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicsapp\u002Fmicstec-skills\u002Fblob\u002Fmaster\u002Fclaude-code\u002Fplugins-plus-skills\u002Fplugins\u002Fdatabase\u002Fnosql-data-modeler\u002Fskills\u002Fmodeling-nosql-data\u002FSKILL.md",true,[74,80,86,92,96,100],{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"assets\u002FREADME.md","ASSET","资产文件",320,"https:\u002F\u002Fgithub.com\u002Fmicsapp\u002Fmicstec-skills\u002Fblob\u002Fmaster\u002Fclaude-code\u002Fplugins-plus-skills\u002Fplugins\u002Fdatabase\u002Fnosql-data-modeler\u002Fskills\u002Fmodeling-nosql-data\u002Fassets\u002FREADME.md",{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002FREADME.md","REFERENCE","参考文档",62,"https:\u002F\u002Fgithub.com\u002Fmicsapp\u002Fmicstec-skills\u002Fblob\u002Fmaster\u002Fclaude-code\u002Fplugins-plus-skills\u002Fplugins\u002Fdatabase\u002Fnosql-data-modeler\u002Fskills\u002Fmodeling-nosql-data\u002Freferences\u002FREADME.md",{"path":87,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"scripts\u002Fgenerate_sample_data.py","SCRIPT","脚本",11665,"https:\u002F\u002Fgithub.com\u002Fmicsapp\u002Fmicstec-skills\u002Fblob\u002Fmaster\u002Fclaude-code\u002Fplugins-plus-skills\u002Fplugins\u002Fdatabase\u002Fnosql-data-modeler\u002Fskills\u002Fmodeling-nosql-data\u002Fscripts\u002Fgenerate_sample_data.py",{"path":93,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":94,"sourceHtmlUrl":95},"scripts\u002Fmigrate_schema.py",14143,"https:\u002F\u002Fgithub.com\u002Fmicsapp\u002Fmicstec-skills\u002Fblob\u002Fmaster\u002Fclaude-code\u002Fplugins-plus-skills\u002Fplugins\u002Fdatabase\u002Fnosql-data-modeler\u002Fskills\u002Fmodeling-nosql-data\u002Fscripts\u002Fmigrate_schema.py",{"path":97,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":98,"sourceHtmlUrl":99},"scripts\u002FREADME.md",367,"https:\u002F\u002Fgithub.com\u002Fmicsapp\u002Fmicstec-skills\u002Fblob\u002Fmaster\u002Fclaude-code\u002Fplugins-plus-skills\u002Fplugins\u002Fdatabase\u002Fnosql-data-modeler\u002Fskills\u002Fmodeling-nosql-data\u002Fscripts\u002FREADME.md",{"path":101,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":102,"sourceHtmlUrl":103},"scripts\u002Fvalidate_schema.py",15589,"https:\u002F\u002Fgithub.com\u002Fmicsapp\u002Fmicstec-skills\u002Fblob\u002Fmaster\u002Fclaude-code\u002Fplugins-plus-skills\u002Fplugins\u002Fdatabase\u002Fnosql-data-modeler\u002Fskills\u002Fmodeling-nosql-data\u002Fscripts\u002Fvalidate_schema.py",[105,140,169,189,209,234],{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":119,"publishedAt":43},"01M6HBTJ02FXBFG9NYEHHYAP52","azure-apim-architecture","Analyzes and explains Azure API Management architecture decisions for enterprise API marketplace implementations using VNet Internal mode, Front Door, hybrid authentication, and multi-environment strategies. Use when discussing APIM component selection, network topology, cost optimization, or comparing alternatives like workspaces vs instances, VNet Internal vs External mode, or Front Door vs Application Gateway.","https:\u002F\u002Fgithub.com\u002Fmicsapp\u002Fmicstec-skills\u002Fblob\u002Fmaster\u002Fcopilot-cli\u002Fcopilot-agent-skills\u002F.github\u002Fskills\u002Fazure-apim-architecture\u002FSKILL.md",[111,116],{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":117,"categoryName":118,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000030","开发工程师",[120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139],"architecture","azure","azure apim architecture","component","authentication","gateway","topology","Optimization","network","api","team","environment","multi-environment","workspaces","instances","selection","strategies","azure api management","mode","for",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":154,"publishedAt":43},"01M6HBT7J4H082JEEA670B3EQ9","apiops-deployment","Guides deployment of Azure API Management infrastructure using Infrastructure as Code (Bicep\u002FTerraform), CI\u002FCD pipelines (GitHub Actions\u002FAzure DevOps), and APIOps workflows. Use when deploying APIM, creating pipelines, or implementing dev→test→prod promotion strategies.","https:\u002F\u002Fgithub.com\u002Fmicsapp\u002Fmicstec-skills\u002Fblob\u002Fmaster\u002Fcopilot-cli\u002Fcopilot-agent-skills\u002F.github\u002Fskills\u002Fapiops-deployment\u002FSKILL.md",[146,147,150,153],{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},{"categoryNo":148,"categoryName":149,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":151,"categoryName":152,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":117,"categoryName":118,"taxonomyType":20,"taxonomyTypeDesc":21},[155,156,157,158,121,159,40,160,161,162,163,164,129,130,136,165,166,137,167,168],"deployment","apiops deployment","workflows","azure devops","infrastructure","infrastructure as code","actions","ci","github actions","github-actions","as","guides","CI\u002FCD","implementing",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":176,"publishedAt":43},"01M6HBT2HEA23THNE9E00GYQBE","apim-policy-authoring","Creates production-ready Azure API Management policy XML for authentication (OAuth 2.0, JWT validation, subscription keys), rate limiting, CORS configuration, error handling, and API transformations. Use when implementing API security, access control, or request\u002Fresponse processing logic.","https:\u002F\u002Fgithub.com\u002Fmicsapp\u002Fmicstec-skills\u002Fblob\u002Fmaster\u002Fcopilot-cli\u002Fcopilot-agent-skills\u002F.github\u002Fskills\u002Fapim-policy-authoring\u002FSKILL.md",[175],{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},[177,178,179,180,121,124,129,130,181,27,182,183,184,185,186,137,187,188,168,139],"policy","authoring","apim policy authoring","security","access","ready","api security","Access Control","error","processing","cors configuration","production-ready",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":197,"publishedAt":43},"01M6HBSY65SB29J9WE9KYD0K6T","api-security-review","Reviews Azure API Management configurations for security vulnerabilities, OWASP API Security Top 10 compliance, VNet Internal mode validation, Private Link verification, and Azure Security Benchmark alignment. Use when performing security audits, pre-deployment validation, or compliance reviews.","https:\u002F\u002Fgithub.com\u002Fmicsapp\u002Fmicstec-skills\u002Fblob\u002Fmaster\u002Fcopilot-cli\u002Fcopilot-agent-skills\u002F.github\u002Fskills\u002Fapi-security-review\u002FSKILL.md",[195,196],{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},{"categoryNo":117,"categoryName":118,"taxonomyType":20,"taxonomyTypeDesc":21},[198,180,199,129,183,200,121,155,201,202,203,204,130,205,137,206,207,208,138,139],"review","security review","api security review","benchmark","verification","owasp","owasp-api","alignment","azure security","reviews","top",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":215,"publishedAt":43},"01M6HBSRW4PDFE6K4F8JYPZQ05","jira-cli","Interact with Jira from the command line to create, list, view, edit, and transition issues, manage sprints and epics, and perform common Jira workflows. Use when the user asks about Jira tasks, tickets, issues, sprints, or needs to manage project work items.","https:\u002F\u002Fgithub.com\u002Fmicsapp\u002Fmicstec-skills\u002Fblob\u002Fmaster\u002Fcopilot-cli\u002Fawesome-copilot-agents\u002Fskills\u002Fjira-cli\u002FSKILL.md",[],[216,217,218,157,219,220,221,222,129,223,224,225,226,227,228,229,230,231,232,233],"cli","jira","jira cli","init","tasks","create","issues","common","work","command","edit","list","view","project","project work","token","line","sprints",{"skillNo":235,"name":236,"nameZh":6,"description":237,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":238,"categories":239,"keywords":240,"publishedAt":43},"01M6HBSNS3JHMW603G47TWE31H","calculator","Performs arbitrary-precision arithmetic calculations including addition, subtraction, multiplication, division, and exponents. Use when the user asks to calculate, compute, or evaluate math expressions, or when precise decimal arithmetic is needed to avoid floating-point errors.","https:\u002F\u002Fgithub.com\u002Fmicsapp\u002Fmicstec-skills\u002Fblob\u002Fmaster\u002Fcopilot-cli\u002Fawesome-copilot-agents\u002Fskills\u002Fcalculator\u002FSKILL.md",[],[236,241,242,243,244,245,246,27,247,248],"npm","js","calculate","node","math","user","compute","errors"]