[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PF4K2TYGR5DQZ1NZPJ0YF7":3,"skill-same:01M6PF4K2TYGR5DQZ1NZPJ0YF7":91},{"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":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":72},"01M6PF4K2TYGR5DQZ1NZPJ0YF7","conducting-chaos-engineering",null,"This skill enables Claude to design and execute chaos engineering experiments to test system resilience. It is used when the user requests help with failure injection, latency simulation, resource exhaustion testing, or resilience validation. The skill is triggered by discussions of chaos experiments (GameDays), failure injection strategies, resilience testing, and validation of recovery mechanisms like circuit breakers and retry logic. It leverages tools like Chaos Mesh, Gremlin, Toxiproxy, and AWS FIS to simulate real-world failures and assess system behavior.","sandraschi\u002Fdocumentation-mcp","sandraschi","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F34750307?v=4","01M6C42H9WE5EC9CK3N5RGZP8S","Sandra Schipal","01M6PE1X2FZP8KR5GANPPFTHA8",2,"MIT","https:\u002F\u002Fgithub.com\u002Fsandraschi\u002Fdocumentation-mcp\u002Fblob\u002Fmaster\u002Fdocs\u002Fnot-mcp-related\u002Fclaude-skills\u002Ftemp\u002Fcode-plugins\u002Fplugins\u002Ftesting\u002Fchaos-engineering-toolkit\u002Fskills\u002Fchaos-engineering-toolkit\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"chaos","engineering","Conducting Chaos Engineering","chaos engineering","system","toxiproxy","circuit","retry","latency","strategies","world","testing","simulation","injection","Tools","gremlin","resilience","experiments","mesh","design","2026-11-10 10:12:30",false,"---\nname: conducting-chaos-engineering\ndescription: |\n  This skill enables Claude to design and execute chaos engineering experiments to test system resilience. It is used when the user requests help with failure injection, latency simulation, resource exhaustion testing, or resilience validation. The skill is triggered by discussions of chaos experiments (GameDays), failure injection strategies, resilience testing, and validation of recovery mechanisms like circuit breakers and retry logic. It leverages tools like Chaos Mesh, Gremlin, Toxiproxy, and AWS FIS to simulate real-world failures and assess system behavior.\n---\n\n## Overview\n\nThis skill empowers Claude to act as a chaos engineering specialist, guiding users through the process of designing and implementing controlled failure scenarios to identify weaknesses and improve the robustness of their systems. It facilitates the creation of chaos experiments to validate system resilience and recovery mechanisms.\n\n## How It Works\n\n1. **Experiment Design**: Claude helps define the scope, target system, and failure scenarios for the chaos experiment based on the user's objectives.\n2. **Tool Selection**: Claude recommends appropriate chaos engineering tools (e.g., Chaos Mesh, Gremlin, Toxiproxy, AWS FIS) based on the target environment and desired failure types.\n3. **Execution and Monitoring**: Claude assists with configuring and executing the chaos experiment, while monitoring key metrics to observe system behavior under stress.\n4. **Analysis and Recommendations**: Claude analyzes the results of the experiment, identifies vulnerabilities, and provides recommendations for improving system resilience.\n\n## When to Use This Skill\n\nThis skill activates when you need to:\n- Design a chaos experiment to test the resilience of a specific service or application.\n- Implement failure injection strategies to simulate real-world outages.\n- Validate the effectiveness of circuit breakers and retry mechanisms.\n- Analyze system behavior under stress and identify potential vulnerabilities.\n\n## Examples\n\n### Example 1: Database Failover Testing\n\nUser request: \"Help me design a chaos experiment to test our database failover process.\"\n\nThe skill will:\n1. Design a chaos experiment involving simulated database failures and automated failover.\n2. Recommend using Chaos Mesh for Kubernetes environments or AWS FIS for AWS-hosted databases.\n\n### Example 2: API Latency Simulation\n\nUser request: \"Create a latency injection test for our API gateway to simulate network congestion.\"\n\nThe skill will:\n1. Design a latency injection test using Toxiproxy to introduce delays in API requests.\n2. Monitor API response times and error rates to assess the impact of latency.\n\n## Best Practices\n\n- **Define Clear Objectives**: Clearly define the goals of the chaos experiment and the specific system behavior you want to test.\n- **Start Small**: Begin with small-scale experiments and gradually increase the scope and intensity of the failures.\n- **Automate and Monitor**: Automate the execution and monitoring of chaos experiments to ensure repeatability and accurate data collection.\n\n## Integration\n\nThis skill integrates with various chaos engineering tools, allowing Claude to orchestrate failure injection, latency simulation, and resource exhaustion testing across different environments. It can also be used in conjunction with monitoring tools to track system behavior and identify potential vulnerabilities.\n","## Overview\n\nThis skill empowers Claude to act as a chaos engineering specialist, guiding users through the process of designing and implementing controlled failure scenarios to identify weaknesses and improve the robustness of their systems. It facilitates the creation of chaos experiments to validate system resilience and recovery mechanisms.\n\n## How It Works\n\n1. **Experiment Design**: Claude helps define the scope, target system, and failure scenarios for the chaos experiment based on the user's objectives.\n2. **Tool Selection**: Claude recommends appropriate chaos engineering tools (e.g., Chaos Mesh, Gremlin, Toxiproxy, AWS FIS) based on the target environment and desired failure types.\n3. **Execution and Monitoring**: Claude assists with configuring and executing the chaos experiment, while monitoring key metrics to observe system behavior under stress.\n4. **Analysis and Recommendations**: Claude analyzes the results of the experiment, identifies vulnerabilities, and provides recommendations for improving system resilience.\n\n## When to Use This Skill\n\nThis skill activates when you need to:\n- Design a chaos experiment to test the resilience of a specific service or application.\n- Implement failure injection strategies to simulate real-world outages.\n- Validate the effectiveness of circuit breakers and retry mechanisms.\n- Analyze system behavior under stress and identify potential vulnerabilities.\n\n## Examples\n\n### Example 1: Database Failover Testing\n\nUser request: \"Help me design a chaos experiment to test our database failover process.\"\n\nThe skill will:\n1. Design a chaos experiment involving simulated database failures and automated failover.\n2. Recommend using Chaos Mesh for Kubernetes environments or AWS FIS for AWS-hosted databases.\n\n### Example 2: API Latency Simulation\n\nUser request: \"Create a latency injection test for our API gateway to simulate network congestion.\"\n\nThe skill will:\n1. Design a latency injection test using Toxiproxy to introduce delays in API requests.\n2. Monitor API response times and error rates to assess the impact of latency.\n\n## Best Practices\n\n- **Define Clear Objectives**: Clearly define the goals of the chaos experiment and the specific system behavior you want to test.\n- **Start Small**: Begin with small-scale experiments and gradually increase the scope and intensity of the failures.\n- **Automate and Monitor**: Automate the execution and monitoring of chaos experiments to ensure repeatability and accurate data collection.\n\n## Integration\n\nThis skill integrates with various chaos engineering tools, allowing Claude to orchestrate failure injection, latency simulation, and resource exhaustion testing across different environments. It can also be used in conjunction with monitoring tools to track system behavior and identify potential vulnerabilities.\n",{"name":5,"description":7},"master","be156301b65e301887f327d08190ed4f17ba08d2","docs\u002Fnot-mcp-related\u002Fclaude-skills\u002Ftemp\u002Fcode-plugins\u002Fplugins\u002Ftesting\u002Fchaos-engineering-toolkit\u002Fskills\u002Fchaos-engineering-toolkit",0,"https:\u002F\u002Fgithub.com\u002Fsandraschi\u002Fdocumentation-mcp","https:\u002F\u002Fgithub.com\u002Fsandraschi","2026-11-14 11:02:49",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add sandraschi\u002Fdocumentation-mcp --skill conducting-chaos-engineering",{"tool":65,"command":66},"bunx","bunx skills add sandraschi\u002Fdocumentation-mcp --skill conducting-chaos-engineering",{"tool":68,"command":69},"pnpm","pnpm dlx skills add sandraschi\u002Fdocumentation-mcp --skill conducting-chaos-engineering","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsandraschi\u002Fdocumentation-mcp\u002Fblob\u002Fmaster\u002Fdocs\u002Fnot-mcp-related\u002Fclaude-skills\u002Ftemp\u002Fcode-plugins\u002Fplugins\u002Ftesting\u002Fchaos-engineering-toolkit\u002Fskills\u002Fchaos-engineering-toolkit\u002FSKILL.md",true,[73,79,85],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"assets\u002FREADME.md","ASSET","资产文件",425,"https:\u002F\u002Fgithub.com\u002Fsandraschi\u002Fdocumentation-mcp\u002Fblob\u002Fmaster\u002Fdocs\u002Fnot-mcp-related\u002Fclaude-skills\u002Ftemp\u002Fcode-plugins\u002Fplugins\u002Ftesting\u002Fchaos-engineering-toolkit\u002Fskills\u002Fchaos-engineering-toolkit\u002Fassets\u002FREADME.md",{"path":80,"resourceType":81,"resourceTypeDesc":82,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002FREADME.md","REFERENCE","参考文档",419,"https:\u002F\u002Fgithub.com\u002Fsandraschi\u002Fdocumentation-mcp\u002Fblob\u002Fmaster\u002Fdocs\u002Fnot-mcp-related\u002Fclaude-skills\u002Ftemp\u002Fcode-plugins\u002Fplugins\u002Ftesting\u002Fchaos-engineering-toolkit\u002Fskills\u002Fchaos-engineering-toolkit\u002Freferences\u002FREADME.md",{"path":86,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":89,"sourceHtmlUrl":90},"scripts\u002FREADME.md","SCRIPT","脚本",444,"https:\u002F\u002Fgithub.com\u002Fsandraschi\u002Fdocumentation-mcp\u002Fblob\u002Fmaster\u002Fdocs\u002Fnot-mcp-related\u002Fclaude-skills\u002Ftemp\u002Fcode-plugins\u002Fplugins\u002Ftesting\u002Fchaos-engineering-toolkit\u002Fskills\u002Fchaos-engineering-toolkit\u002Fscripts\u002FREADME.md",[92,115,142,152,175,201],{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":102,"publishedAt":47},"01M6PFAWAHEJJCKKVNXEWNK87W","Docs Research","Use MCP Central Docs server to search, ask, and retrieve documentation (FastMCP, standards, packaging).","https:\u002F\u002Fgithub.com\u002Fsandraschi\u002Fdocumentation-mcp\u002Fblob\u002Fmaster\u002Fsrc\u002Fdocs_mcp\u002Fskills\u002Fdocs-research\u002FSKILL.md",[98,101],{"categoryNo":99,"categoryName":100,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[103,104,105,106,107,108,109,110,111,112,113,114],"docs research","docs","research","standards","use","packaging","ask","server","search","fastmcp","documentation","MCP",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":121,"publishedAt":47},"01M6PFAN4DAENMY574Q7Q3CB3H","wrappee-drift","Read-only, single-repo audit of a repo's tool coverage against the software it wraps (its current real API\u002Fdocs, not training-data memory) and against comparable\u002Fcompeting wrappers. Trigger when the user says \"wrappee drift\" followed by a repo name, \"capability audit\" followed by a repo name, or asks whether a repo is missing features the wrapped software or a competitor now has. Always scoped to one named repo per invocation -- never trigger this fleet-wide or unprompted; that is explicitly against the SOP. Do NOT trigger for internal fleet-standard compliance (that is drift-scan) or strategic worth\u002Farchive decisions (that is quality-check) -- this is specifically about the gap between the repo's tool list and the wrapped software's\u002Fcompetitors' actual current capabilities.","https:\u002F\u002Fgithub.com\u002Fsandraschi\u002Fdocumentation-mcp\u002Fblob\u002Fmaster\u002Fdocs\u002Fskills\u002Fwrappee-drift\u002FSKILL.md",[],[122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141],"drift","wrappee drift","api","data","audit","capabilities","training","memory","features","repo audit","competitors","fleet","now","software","tool list","only","never","coverage","list","read",{"skillNo":143,"name":144,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":151,"publishedAt":47},"01M6PFADA3X031SK3W3T6X0N6H","modules","https:\u002F\u002Fgithub.com\u002Fsandraschi\u002Fdocumentation-mcp\u002Fblob\u002Fmaster\u002Fdocs\u002Fskills\u002Fwindsurf-mcp-standards\u002Fmodules\u002FSKILL.md",[147,150],{"categoryNo":148,"categoryName":149,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[144],{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":160,"publishedAt":47},"01M6PFA8YA029N68TW0X31FB1W","mcp-standards","Use when developing MCP servers to access comprehensive standards for scaffolding, packaging, sampling, documentation, testing, error handling, monitoring, and CI\u002FCD workflows.","https:\u002F\u002Fgithub.com\u002Fsandraschi\u002Fdocumentation-mcp\u002Fblob\u002Fmaster\u002Fdocs\u002Fskills\u002Fwindsurf-mcp-standards\u002FSKILL.md",[158,159],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[161,114,106,107,162,163,164,165,166,167,168,169,170,171,172,173,113,174,38,108],"mcp standards","monitoring","sampling","scaffolding","servers","cd","error","for","CI\u002FCD","access","ci","mcp servers","error handling","workflows",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":183,"publishedAt":47},"01M6PFA1XX344WX57B0DJZY94Q","webapp-cua-test","Run the pre-Tauri CUA click-through test (real browser, dev stack, OCR \"Connected\" wait, sidebar nav walk) for a fleet MCP server repo under D:\\Dev\\repos. Trigger when the user says \"cua webapp test\" or \"webapp clickthrough\" followed by a repo name, asks for an e2e click-through of a webapp, or asks whether a webapp boots and connects in a real browser. Not for the installed NSIS app (that is the nsis-build skill \u002F cua-nsis-test) and not for DOM assertions (Playwright), and not for hunting fake data or dead buttons (fakefind).","https:\u002F\u002Fgithub.com\u002Fsandraschi\u002Fdocumentation-mcp\u002Fblob\u002Fmaster\u002Fdocs\u002Fskills\u002Fwebapp-cua-test\u002FSKILL.md",[181,182],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[184,185,186,187,188,114,189,190,191,168,192,193,194,195,196,197,198,199,110,200],"webapp","test","webapp cua test","playwright","mcp server","dev","dom","assertions","trigger","click","app","tauri","repo","stack","e2e","ocr","browser",{"skillNo":202,"name":203,"nameZh":6,"description":204,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":205,"categories":206,"keywords":208,"publishedAt":47},"01M6PF9WYF6NWJR7WVN38TT0WH","ship","Final release gate for a fleet MCP server repo under D:\\Dev\\repos -- run all quality gates, build the release artifact, verify it, commit, push, and cut a GitHub release. Trigger this whenever the user says \"ship it\", \"ship\" followed by a repo name, \"release\" followed by a repo name, or asks to finalize and publish work that's already been done in a repo. This is the terminal step after assfix\u002Fnsis-build, not a substitute for them -- if the repo hasn't been assessed recently, say so before shipping rather than shipping blind.","https:\u002F\u002Fgithub.com\u002Fsandraschi\u002Fdocumentation-mcp\u002Fblob\u002Fmaster\u002Fdocs\u002Fskills\u002Fship\u002FSKILL.md",[207],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[203,196,168,192,209,210,211,212,213,214,215,110,216,189,217,218,219,188,220,114],"gates","ship it","artifact","done","say","work","publish","push","shipping","quality gates","commit","github"]