[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6RBAH5WCD2MR686WN81M30S":3,"skill-same:01M6RBAH5WCD2MR686WN81M30S":112},{"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":34,"publishedAt":55,"linkOnly":56,"markdownContent":57,"markdownBody":58,"frontMatter":59,"refName":68,"commitSha":69,"skillDirectory":70,"forksCount":71,"repositoryHtmlUrl":72,"repositoryHomepageUrl":6,"ownerHtmlUrl":73,"ownerBlogUrl":74,"ownerDescription":6,"updatedAt":75,"install":76,"resources":89},"01M6RBAH5WCD2MR686WN81M30S","chaos-engineer",null,"Designs chaos experiments, creates failure injection frameworks, and facilitates game day exercises for distributed systems — producing runbooks, experiment manifests, rollback procedures, and post-mortem templates. Use when designing chaos experiments, implementing failure injection frameworks, or conducting game day exercises. Invoke for chaos experiments, resilience testing, blast radius control, game days, antifragile systems, fault injection, Chaos Monkey, Litmus Chaos.","PIXARTSeu\u002FSynapse","PIXARTSeu","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F274446381?v=4","01M6RB4XPN9YBZCRY4FVN9PJCT","Pixarts ","01M6RB4XTF8G9KHQEMC21FGDKD",12,"MIT","https:\u002F\u002Fgithub.com\u002FPIXARTSeu\u002FSynapse\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fchaos-engineer\u002FSKILL.md",[18,23,26,29],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"chaos engineer","chaos","engineer","experiment","when","invoke","post-mortem","implementing","manifests","runbooks","testing","litmus","sre","chaos experiment","chaos engineering","game","injection","code","resilience","experiments","2026-11-10 10:12:30",false,"---\nname: chaos-engineer\ndescription: Designs chaos experiments, creates failure injection frameworks, and facilitates game day exercises for distributed systems — producing runbooks, experiment manifests, rollback procedures, and post-mortem templates. Use when designing chaos experiments, implementing failure injection frameworks, or conducting game day exercises. Invoke for chaos experiments, resilience testing, blast radius control, game days, antifragile systems, fault injection, Chaos Monkey, Litmus Chaos.\nlicense: MIT\nmetadata:\n  author: https:\u002F\u002Fgithub.com\u002FJeffallan\n  version: \"1.1.0\"\n  domain: devops\n  triggers: chaos engineering, resilience testing, failure injection, game day, blast radius, chaos experiment, fault injection, Chaos Monkey, Litmus Chaos, antifragile\n  role: specialist\n  scope: implementation\n  output-format: code\n  related-skills: sre-engineer, devops-engineer, kubernetes-specialist\n---\n\n# Chaos Engineer\n\n## When to Use This Skill\n\n- Designing and executing chaos experiments\n- Implementing failure injection frameworks (Chaos Monkey, Litmus, etc.)\n- Planning and conducting game day exercises\n- Building blast radius controls and safety mechanisms\n- Setting up continuous chaos testing in CI\u002FCD\n- Improving system resilience based on experiment findings\n\n## Core Workflow\n\n1. **System Analysis** - Map architecture, dependencies, critical paths, and failure modes\n2. **Experiment Design** - Define hypothesis, steady state, blast radius, and safety controls\n3. **Execute Chaos** - Run controlled experiments with monitoring and quick rollback\n4. **Learn & Improve** - Document findings, implement fixes, enhance monitoring\n5. **Automate** - Integrate chaos testing into CI\u002FCD for continuous resilience\n\n## Reference Guide\n\nLoad detailed guidance based on context:\n\n| Topic | Reference | Load When |\n|-------|-----------|-----------|\n| Experiments | `references\u002Fexperiment-design.md` | Designing hypothesis, blast radius, rollback |\n| Infrastructure | `references\u002Finfrastructure-chaos.md` | Server, network, zone, region failures |\n| Kubernetes | `references\u002Fkubernetes-chaos.md` | Pod, node, Litmus, chaos mesh experiments |\n| Tools & Automation | `references\u002Fchaos-tools.md` | Chaos Monkey, Gremlin, Pumba, CI\u002FCD integration |\n| Game Days | `references\u002Fgame-days.md` | Planning, executing, learning from game days |\n\n## Safety Checklist\n\nNon-obvious constraints that must be enforced on every experiment:\n\n- **Steady state first** — define and verify baseline metrics before injecting any failure\n- **Blast radius cap** — start with the smallest possible impact scope; expand only after validation\n- **Automated rollback ≤ 30 seconds** — abort path must be scripted and tested before the experiment begins\n- **Single variable** — change only one failure condition at a time until behaviour is well understood\n- **No production without safety nets** — customer-facing environments require circuit breakers, feature flags, or canary isolation\n- **Close the loop** — every experiment must produce a written learning summary and at least one tracked improvement\n\n## Output Templates\n\nWhen implementing chaos engineering, provide:\n1. Experiment design document (hypothesis, metrics, blast radius)\n2. Implementation code (failure injection scripts\u002Fmanifests)\n3. Monitoring setup and alert configuration\n4. Rollback procedures and safety controls\n5. Learning summary and improvement recommendations\n\n## Concrete Example: Pod Failure Experiment (Litmus Chaos)\n\nThe following shows a complete experiment — from hypothesis to rollback — using Litmus Chaos on Kubernetes.\n\n### Step 1 — Define steady state and apply the experiment\n\n```bash\n# Verify baseline: p99 latency \u003C 200ms, error rate \u003C 0.1%\nkubectl get deploy my-service -n production\nkubectl top pods -n production -l app=my-service\n```\n\n### Step 2 — Create and apply a Litmus ChaosEngine manifest\n\n```yaml\n# chaos-pod-delete.yaml\napiVersion: litmuschaos.io\u002Fv1alpha1\nkind: ChaosEngine\nmetadata:\n  name: my-service-pod-delete\n  namespace: production\nspec:\n  appinfo:\n    appns: production\n    applabel: \"app=my-service\"\n    appkind: deployment\n  # Limit blast radius: only 1 replica at a time\n  engineState: active\n  chaosServiceAccount: litmus-admin\n  experiments:\n    - name: pod-delete\n      spec:\n        components:\n          env:\n            - name: TOTAL_CHAOS_DURATION\n              value: \"60\"          # seconds\n            - name: CHAOS_INTERVAL\n              value: \"20\"          # delete one pod every 20s\n            - name: FORCE\n              value: \"false\"\n            - name: PODS_AFFECTED_PERC\n              value: \"33\"          # max 33% of replicas affected\n```\n\n```bash\n# Apply the experiment\nkubectl apply -f chaos-pod-delete.yaml\n\n# Watch experiment status\nkubectl describe chaosengine my-service-pod-delete -n production\nkubectl get chaosresult my-service-pod-delete-pod-delete -n production -w\n```\n\n### Step 3 — Monitor during the experiment\n\n```bash\n# Tail application logs for errors\nkubectl logs -l app=my-service -n production --since=2m -f\n\n# Check ChaosResult verdict when complete\nkubectl get chaosresult my-service-pod-delete-pod-delete \\\n  -n production -o jsonpath='{.status.experimentStatus.verdict}'\n```\n\n### Step 4 — Rollback \u002F abort if steady state is violated\n\n```bash\n# Immediately stop the experiment\nkubectl patch chaosengine my-service-pod-delete \\\n  -n production --type merge -p '{\"spec\":{\"engineState\":\"stop\"}}'\n\n# Confirm all pods are healthy\nkubectl rollout status deployment\u002Fmy-service -n production\n```\n\n## Concrete Example: Network Latency with toxiproxy\n\n```bash\n# Install toxiproxy CLI\nbrew install toxiproxy   # macOS; use the binary release on Linux\n\n# Start toxiproxy server (runs alongside your service)\ntoxiproxy-server &\n\n# Create a proxy for your downstream dependency\ntoxiproxy-cli create -l 0.0.0.0:22222 -u downstream-db:5432 db-proxy\n\n# Inject 300ms latency with 10% jitter — blast radius: this proxy only\ntoxiproxy-cli toxic add db-proxy -t latency -a latency=300 -a jitter=30\n\n# Run your load test \u002F observe metrics here ...\n\n# Remove the toxic to restore normal behaviour\ntoxiproxy-cli toxic remove db-proxy -n latency_downstream\n```\n\n## Concrete Example: Chaos Monkey (Spinnaker \u002F standalone)\n\n```bash\n# chaos-monkey-config.yml — restrict to a single ASG\ndeployment:\n  enabled: true\n  regionIndependence: false\nchaos:\n  enabled: true\n  meanTimeBetweenKillsInWorkDays: 2\n  minTimeBetweenKillsInWorkDays: 1\n  grouping: APP           # kill one instance per app, not per cluster\n  exceptions:\n    - account: production\n      region: us-east-1\n      detail: \"*-canary\"  # never kill canary instances\n\n# Apply and trigger a manual kill for testing\nchaos-monkey --app my-service --account staging --dry-run false\n```\n","# Chaos Engineer\n\n## When to Use This Skill\n\n- Designing and executing chaos experiments\n- Implementing failure injection frameworks (Chaos Monkey, Litmus, etc.)\n- Planning and conducting game day exercises\n- Building blast radius controls and safety mechanisms\n- Setting up continuous chaos testing in CI\u002FCD\n- Improving system resilience based on experiment findings\n\n## Core Workflow\n\n1. **System Analysis** - Map architecture, dependencies, critical paths, and failure modes\n2. **Experiment Design** - Define hypothesis, steady state, blast radius, and safety controls\n3. **Execute Chaos** - Run controlled experiments with monitoring and quick rollback\n4. **Learn & Improve** - Document findings, implement fixes, enhance monitoring\n5. **Automate** - Integrate chaos testing into CI\u002FCD for continuous resilience\n\n## Reference Guide\n\nLoad detailed guidance based on context:\n\n| Topic | Reference | Load When |\n|-------|-----------|-----------|\n| Experiments | `references\u002Fexperiment-design.md` | Designing hypothesis, blast radius, rollback |\n| Infrastructure | `references\u002Finfrastructure-chaos.md` | Server, network, zone, region failures |\n| Kubernetes | `references\u002Fkubernetes-chaos.md` | Pod, node, Litmus, chaos mesh experiments |\n| Tools & Automation | `references\u002Fchaos-tools.md` | Chaos Monkey, Gremlin, Pumba, CI\u002FCD integration |\n| Game Days | `references\u002Fgame-days.md` | Planning, executing, learning from game days |\n\n## Safety Checklist\n\nNon-obvious constraints that must be enforced on every experiment:\n\n- **Steady state first** — define and verify baseline metrics before injecting any failure\n- **Blast radius cap** — start with the smallest possible impact scope; expand only after validation\n- **Automated rollback ≤ 30 seconds** — abort path must be scripted and tested before the experiment begins\n- **Single variable** — change only one failure condition at a time until behaviour is well understood\n- **No production without safety nets** — customer-facing environments require circuit breakers, feature flags, or canary isolation\n- **Close the loop** — every experiment must produce a written learning summary and at least one tracked improvement\n\n## Output Templates\n\nWhen implementing chaos engineering, provide:\n1. Experiment design document (hypothesis, metrics, blast radius)\n2. Implementation code (failure injection scripts\u002Fmanifests)\n3. Monitoring setup and alert configuration\n4. Rollback procedures and safety controls\n5. Learning summary and improvement recommendations\n\n## Concrete Example: Pod Failure Experiment (Litmus Chaos)\n\nThe following shows a complete experiment — from hypothesis to rollback — using Litmus Chaos on Kubernetes.\n\n### Step 1 — Define steady state and apply the experiment\n\n```bash\n# Verify baseline: p99 latency \u003C 200ms, error rate \u003C 0.1%\nkubectl get deploy my-service -n production\nkubectl top pods -n production -l app=my-service\n```\n\n### Step 2 — Create and apply a Litmus ChaosEngine manifest\n\n```yaml\n# chaos-pod-delete.yaml\napiVersion: litmuschaos.io\u002Fv1alpha1\nkind: ChaosEngine\nmetadata:\n  name: my-service-pod-delete\n  namespace: production\nspec:\n  appinfo:\n    appns: production\n    applabel: \"app=my-service\"\n    appkind: deployment\n  # Limit blast radius: only 1 replica at a time\n  engineState: active\n  chaosServiceAccount: litmus-admin\n  experiments:\n    - name: pod-delete\n      spec:\n        components:\n          env:\n            - name: TOTAL_CHAOS_DURATION\n              value: \"60\"          # seconds\n            - name: CHAOS_INTERVAL\n              value: \"20\"          # delete one pod every 20s\n            - name: FORCE\n              value: \"false\"\n            - name: PODS_AFFECTED_PERC\n              value: \"33\"          # max 33% of replicas affected\n```\n\n```bash\n# Apply the experiment\nkubectl apply -f chaos-pod-delete.yaml\n\n# Watch experiment status\nkubectl describe chaosengine my-service-pod-delete -n production\nkubectl get chaosresult my-service-pod-delete-pod-delete -n production -w\n```\n\n### Step 3 — Monitor during the experiment\n\n```bash\n# Tail application logs for errors\nkubectl logs -l app=my-service -n production --since=2m -f\n\n# Check ChaosResult verdict when complete\nkubectl get chaosresult my-service-pod-delete-pod-delete \\\n  -n production -o jsonpath='{.status.experimentStatus.verdict}'\n```\n\n### Step 4 — Rollback \u002F abort if steady state is violated\n\n```bash\n# Immediately stop the experiment\nkubectl patch chaosengine my-service-pod-delete \\\n  -n production --type merge -p '{\"spec\":{\"engineState\":\"stop\"}}'\n\n# Confirm all pods are healthy\nkubectl rollout status deployment\u002Fmy-service -n production\n```\n\n## Concrete Example: Network Latency with toxiproxy\n\n```bash\n# Install toxiproxy CLI\nbrew install toxiproxy   # macOS; use the binary release on Linux\n\n# Start toxiproxy server (runs alongside your service)\ntoxiproxy-server &\n\n# Create a proxy for your downstream dependency\ntoxiproxy-cli create -l 0.0.0.0:22222 -u downstream-db:5432 db-proxy\n\n# Inject 300ms latency with 10% jitter — blast radius: this proxy only\ntoxiproxy-cli toxic add db-proxy -t latency -a latency=300 -a jitter=30\n\n# Run your load test \u002F observe metrics here ...\n\n# Remove the toxic to restore normal behaviour\ntoxiproxy-cli toxic remove db-proxy -n latency_downstream\n```\n\n## Concrete Example: Chaos Monkey (Spinnaker \u002F standalone)\n\n```bash\n# chaos-monkey-config.yml — restrict to a single ASG\ndeployment:\n  enabled: true\n  regionIndependence: false\nchaos:\n  enabled: true\n  meanTimeBetweenKillsInWorkDays: 2\n  minTimeBetweenKillsInWorkDays: 1\n  grouping: APP           # kill one instance per app, not per cluster\n  exceptions:\n    - account: production\n      region: us-east-1\n      detail: \"*-canary\"  # never kill canary instances\n\n# Apply and trigger a manual kill for testing\nchaos-monkey --app my-service --account staging --dry-run false\n```\n",{"name":5,"license":15,"metadata":60,"description":7},{"role":61,"scope":62,"author":63,"domain":64,"version":65,"triggers":66,"output-format":52,"related-skills":67},"specialist","implementation","https:\u002F\u002Fgithub.com\u002FJeffallan","devops","1.1.0","chaos engineering, resilience testing, failure injection, game day, blast radius, chaos experiment, fault injection, Chaos Monkey, Litmus Chaos, antifragile","sre-engineer, devops-engineer, kubernetes-specialist","main","c19c0bc0a04d25a849ce749fe88250e688f06437",".agents\u002Fskills\u002Fchaos-engineer",1,"https:\u002F\u002Fgithub.com\u002FPIXARTSeu\u002FSynapse","https:\u002F\u002Fgithub.com\u002FPIXARTSeu","https:\u002F\u002Fpixarts.eu\u002F","2026-09-24 06:30:45",{"source":8,"skillName":5,"commands":77,"prompt":87,"zipAvailable":88},[78,81,84],{"tool":79,"command":80},"npx","npx skills add PIXARTSeu\u002FSynapse --skill chaos-engineer",{"tool":82,"command":83},"bunx","bunx skills add PIXARTSeu\u002FSynapse --skill chaos-engineer",{"tool":85,"command":86},"pnpm","pnpm dlx skills add PIXARTSeu\u002FSynapse --skill chaos-engineer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FPIXARTSeu\u002FSynapse\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fchaos-engineer\u002FSKILL.md",true,[90,96,100,104,108],{"path":91,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002Fchaos-tools.md","REFERENCE","参考文档",14217,"https:\u002F\u002Fgithub.com\u002FPIXARTSeu\u002FSynapse\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fchaos-engineer\u002Freferences\u002Fchaos-tools.md",{"path":97,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Fexperiment-design.md",7031,"https:\u002F\u002Fgithub.com\u002FPIXARTSeu\u002FSynapse\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fchaos-engineer\u002Freferences\u002Fexperiment-design.md",{"path":101,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":102,"sourceHtmlUrl":103},"references\u002Fgame-days.md",12355,"https:\u002F\u002Fgithub.com\u002FPIXARTSeu\u002FSynapse\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fchaos-engineer\u002Freferences\u002Fgame-days.md",{"path":105,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":106,"sourceHtmlUrl":107},"references\u002Finfrastructure-chaos.md",10035,"https:\u002F\u002Fgithub.com\u002FPIXARTSeu\u002FSynapse\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fchaos-engineer\u002Freferences\u002Finfrastructure-chaos.md",{"path":109,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":110,"sourceHtmlUrl":111},"references\u002Fkubernetes-chaos.md",10785,"https:\u002F\u002Fgithub.com\u002FPIXARTSeu\u002FSynapse\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fchaos-engineer\u002Freferences\u002Fkubernetes-chaos.md",[113,142,149,176,198,225],{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":123,"publishedAt":55},"01M6X0ECZKGP44NP2JW588B9RG","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\u002FPIXARTSeu\u002FSynapse\u002Fblob\u002Fmain\u002Fskills\u002Fvercel-react-best-practices\u002FSKILL.md",[119,122],{"categoryNo":120,"categoryName":121,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},[124,125,126,127,128,129,130,131,132,133,134,52,135,136,137,138,139,140,141,39],"react","vercel react best practices","best practices","react best practices","vercel","writing","performance","components","react components","guidelines","tasks","Optimization","data","refactoring","patterns","next","triggers","data fetching",{"skillNo":143,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":148,"publishedAt":55},"01M6X05WCVH879XKZEAQ15PHQX","https:\u002F\u002Fgithub.com\u002FPIXARTSeu\u002FSynapse\u002Fblob\u002Fmain\u002Fpackages\u002Fcodegraph\u002Fdata\u002Fskill\u002Fvercel-react-best-practices\u002FSKILL.md",[146,147],{"categoryNo":120,"categoryName":121,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},[124,125,126,127,128,129,130,131,132,133,134,52,135,136,137,138,139,140,141,39],{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":159,"publishedAt":55},"01M6WZ286AR2SYE9GZYVW0CNYG","wordpress-pro","Develops custom WordPress themes and plugins, creates and registers Gutenberg blocks and block patterns, configures WooCommerce stores, implements WordPress REST API endpoints, applies security hardening (nonces, sanitization, escaping, capability checks), and optimizes performance through caching and query tuning. Use when building WordPress themes, writing plugins, customizing Gutenberg blocks, extending WooCommerce, working with ACF, using the WordPress REST API, applying hooks and filters, or improving WordPress performance and security.","https:\u002F\u002Fgithub.com\u002FPIXARTSeu\u002FSynapse\u002Fblob\u002Fmain\u002Fpackages\u002Fcodegraph\u002Fdata\u002Flifecycle-skills\u002Fwordpress-pro\u002FSKILL.md",[155,158],{"categoryNo":156,"categoryName":157,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},[160,161,162,129,163,130,52,164,165,166,167,168,169,170,171,172,173,174,175,39],"wordpress","wordpress pro","pro","security","tuning","api","laravel","reviewer","hooks","filters","expert","query","woocommerce","caching","themes","sanitization",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":184,"publishedAt":55},"01M6WZ1ZVG6PJ4PVN9RTK0BX7Z","websocket-engineer","Use when building real-time communication systems with WebSockets or Socket.IO. Invoke for bidirectional messaging, horizontal scaling with Redis, presence tracking, room management.","https:\u002F\u002Fgithub.com\u002FPIXARTSeu\u002FSynapse\u002Fblob\u002Fmain\u002Fpackages\u002Fcodegraph\u002Fdata\u002Flifecycle-skills\u002Fwebsocket-engineer\u002FSKILL.md",[182,183],{"categoryNo":156,"categoryName":157,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},[185,37,186,187,52,188,189,165,167,190,170,191,192,193,194,195,196,197,40,39],"websocket","websocket engineer","architecture","messaging","monitoring","fastapi","time","scaling","io","communication systems","presence","updates","socket",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":207,"publishedAt":55},"01M6WZ1G86ZR73H0WNM6CGNRGF","vue-expert","Builds Vue 3 components with Composition API patterns, configures Nuxt 3 SSR\u002FSSG projects, sets up Pinia stores, scaffolds Quasar\u002FCapacitor mobile apps, implements PWA features, and optimises Vite builds. Use when creating Vue 3 applications with Composition API, writing reusable composables, managing state with Pinia, building hybrid mobile apps with Quasar or Capacitor, configuring service workers, or tuning Vite configuration and TypeScript integration.","https:\u002F\u002Fgithub.com\u002FPIXARTSeu\u002FSynapse\u002Fblob\u002Fmain\u002Fpackages\u002Fcodegraph\u002Fdata\u002Flifecycle-skills\u002Fvue-expert\u002FSKILL.md",[204,205,206],{"categoryNo":120,"categoryName":121,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":156,"categoryName":157,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},[208,170,209,210,129,211,131,212,213,214,215,216,217,218,219,220,221,222,223,224],"vue","vue expert","frontend","typescript","config","applications","Composition","projects","pinia","use","router","workers","mobile","reusable","worker","apps","hybrid",{"skillNo":226,"name":227,"nameZh":6,"description":228,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":229,"categories":230,"keywords":233,"publishedAt":55},"01M6WZ1AP3GFCBAMD712X8KRP7","vue-expert-js","Creates Vue 3 components, builds vanilla JS composables, configures Vite projects, and sets up routing and state management using JavaScript only — no TypeScript. Generates JSDoc-typed code with @typedef, @param, and @returns annotations for full type coverage without a TS compiler. Use when building Vue 3 applications with JavaScript only (no TypeScript), when projects require JSDoc-based type hints, when migrating from Vue 2 Options API to Composition API in JS, or when teams prefer vanilla JavaScript, .mjs modules, or need quick prototypes without TypeScript setup.","https:\u002F\u002Fgithub.com\u002FPIXARTSeu\u002FSynapse\u002Fblob\u002Fmain\u002Fpackages\u002Fcodegraph\u002Fdata\u002Flifecycle-skills\u002Fvue-expert-js\u002FSKILL.md",[231,232],{"categoryNo":120,"categoryName":121,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},[208,234,170,235,209,210,211,131,52,165,214,215,236,237,238,239,240,241,242,39],"js","vue expert js","coverage","only","up","modules","options","jsdoc","quick"]