[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DHTWP13BMAH6Y5TTVPMQ5R":3,"skill-same:01M6DHTWP13BMAH6Y5TTVPMQ5R":131},{"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":29,"publishedAt":50,"linkOnly":51,"markdownContent":52,"markdownBody":53,"frontMatter":54,"refName":75,"commitSha":76,"skillDirectory":77,"forksCount":78,"repositoryHtmlUrl":79,"repositoryHomepageUrl":6,"ownerHtmlUrl":80,"ownerBlogUrl":6,"ownerDescription":81,"updatedAt":82,"install":83,"resources":96},"01M6DHTWP13BMAH6Y5TTVPMQ5R","chaos-engineer",null,"Use when you want to test whether a system survives real failures. Triggers on: \"장애 주입 테스트\", \"game day 준비\", \"pod 죽여보고 싶어\", \"chaos experiment\", \"kill a pod in staging\", \"simulate zone outage\". Not for active incidents.","newkayak12\u002Fclaude-skills","newkayak12","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F74722411?v=4","01M6DHQRSHSVM4F2EJACTMC766","Sanghyeon Kim","01M6DHQRX6XQ0XKTD3QB8CGFM9",3,"MIT","https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fchaos-engineer\u002FSKILL.md",[18,23,26],{"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与智能体开发",[30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49],"chaos engineer","chaos","engineer","chaos experiment","experiment docs","triggers","thinking","litmus","sre","use","design","tool","system","exercise","blast radius","code","architecture","mesh","kubernetes","MCP","2026-11-10 10:12:30",false,"---\nname: chaos-engineer\ndescription: >-\n  Use when you want to test whether a system survives real failures. Triggers on: \"장애 주입 테스트\", \"game day 준비\", \"pod\n  죽여보고 싶어\", \"chaos experiment\", \"kill a pod in staging\", \"simulate zone outage\". Not for active incidents.\nscenarios:\n  - \"I want to run a chaos experiment on our Kubernetes cluster to test pod failure resilience\"\n  - \"Help me plan a game day exercise to test our system's failure tolerance\"\n  - \"Design a blast-radius-controlled fault injection for our microservices\"\n  - \"카오스 테스트로 시스템 복원력을 검증하고 싶어\"\n  - \"게임 데이 실험 설계를 도와줘\"\n  - \"스테이징에서 pod 하나 죽여보고 싶은데 어떻게 안전하게 해?\"\ncompatibility:\n  recommended:\n    - think-tool\n  optional:\n    - sequential-thinking\n  remote_mcp_note: >-\n    think-tool이 있으면 실험 설계 시 블라스트 반경과 안전 제어를 더 체계적으로 평가합니다.\n    Claude 설정 → MCP Servers에서 remote SSE 엔드포인트를 추가하세요.\nlicense: MIT\nmetadata:\n  version: \"1.1.0\"\n  area: resilience\n  keywords: fault injection, game day, blast radius, steady-state hypothesis, Chaos Mesh, Litmus\n  kind: specialist\n  produces: experiment docs and injection code\n  see-also: sre-engineer, architecture-designer, circuit-breaker-tuner\n---\n\n## Standing Mandates\n\n- NEVER design an experiment without a steady-state metric that is live now. With no observability, a failure test only\n  causes damage and proves nothing; if there is none, stop and say so.\n- NEVER inject before the abort path is written and the user has rehearsed it. A fault with no scripted way back turns\n  an experiment into an incident.\n- NEVER widen the blast radius in the same run. Start at the narrowest scope; widen only after the previous size\n  confirmed the hypothesis, otherwise a failure cannot be traced to one cause.\n- NEVER inject two faults in one run: the result could not say which one broke the system.\n- NEVER invent a missing fact (dependencies, current SLO, existing breakers). Mark `[확인 필요: ○○]`; an experiment\n  built on a guessed topology tests the guess.\n- Goal: every experiment has a hypothesis, a live steady-state metric, a scope, an abort trigger and a scripted abort of\n  30 s or less; the closing tally recounts to the experiment sheets.\n\n# Chaos Engineer\n\n**Not for** an active incident (`develop:incident-response-playbook`), SLO or alert setup (`develop:sre-engineer`),\nor tuning the breaker itself (`develop:circuit-breaker-tuner`).\n\n## Process\n\n1. **System analysis** — chart components, dependencies, user-critical paths, how each can fail. Read the repo,\n   manifests and dashboards first. Confirm metrics collection (Prometheus, Datadog or similar) is live, and measure the\n   steady state until it is stable before anything is injected.\n2. **Experiment design** — hypothesis, normal-behaviour metrics, how far the fault may reach (narrowest scope first),\n   what stops it, one fault per run. Fill `references\u002Fexperiment-design.md`. `pod-kill` is irreversible: cap\n   `value`\u002Fselector and write the manual recovery first; reversible = `pod-failure` + `duration`\n   (`references\u002Fkubernetes-chaos.md`).\n3. **Execute** — user runs it; inject under observation with the scripted way back (30 s or less, rehearsed) at hand.\n   Production: breakers, flags or canary isolation already in place, or stay in staging.\n4. **Learn** — record what was found, fix weaknesses, close monitoring gaps; every run ends with a write-up and one or\n   more tracked fixes (`references\u002Fpost-mortem.md`).\n5. **Automate** — put recurring experiments into the delivery pipeline.\n6. **Recount** — count experiments, the ones with all five fields, and the findings; fix the tally if the sheets differ.\n\n## Output Template\n\n```\n## Experiment — \u003Ctitle> (\u003Cenv>)\n\nHypothesis: \u003Cwhen X fails, Y stays within Z>\nSteady state: \u003Cmetric, normal range, live? yes\u002Fno>\nScope: \u003Crung> · Abort trigger: \u003Ccondition> · Abort script: \u003Ccommand> (\u003Cs> s)\nInjection: \u003Cmanifest or script>\nResult: confirmed \u002F refuted \u002F aborted — \u003Cmetric reading>\nFixes: \u003Ctracked item, owner>\nGaps: [확인 필요: ○○] ...\n\n\u003Cn> experiments · \u003Cc> confirmed · \u003Cr> refuted · \u003Ca> aborted · \u003Cg> gaps\n```\n\n## What Claude Does \u002F What You Do\n\n| Claude | You |\n|--------|-----|\n| Drafts hypothesis and steady-state definition | Confirm the hypothesis reflects real business risk |\n| Generates Litmus, toxiproxy, or Chaos Monkey config | Run experiments in your environment |\n| Designs blast radius controls | Verify blast radius is acceptable before starting |\n| Writes rollback scripts | Test rollback works before the experiment begins |\n| Templates the learning summary | Fill in actual findings and assign follow-up tickets |\n\n## Reference Guide\n\n| Need | File | Open when |\n|------|------|-----------|\n| Experiment sheet | `references\u002Fexperiment-design.md` | writing the claim, scope rungs, abort triggers |\n| Host and cloud faults | `references\u002Finfrastructure-chaos.md` | network, dependency, resource, zone, DNS, certificate faults |\n| Cluster faults | `references\u002Fkubernetes-chaos.md` | pod, node, partition, autoscaling faults, Chaos Mesh pod-kill example |\n| Tooling | `references\u002Fchaos-tools.md` | picking a tool, random-kill scripts, pipeline gates, toxiproxy |\n| Game days | `references\u002Fgame-days.md` | running a supervised session |\n| Write-up | `references\u002Fpost-mortem.md` | report after a game day or real incident |\n\n## Related Skills\n\n- `develop:sre-engineer` — SLO definition, error budgets, alerting\n- `develop:incident-response-playbook` — when the failure is real and active\n- `develop:architecture-designer` — resilience pattern design for distributed systems\n- `develop:circuit-breaker-tuner` — configure failure thresholds before running chaos experiments\n","## Standing Mandates\n\n- NEVER design an experiment without a steady-state metric that is live now. With no observability, a failure test only\n  causes damage and proves nothing; if there is none, stop and say so.\n- NEVER inject before the abort path is written and the user has rehearsed it. A fault with no scripted way back turns\n  an experiment into an incident.\n- NEVER widen the blast radius in the same run. Start at the narrowest scope; widen only after the previous size\n  confirmed the hypothesis, otherwise a failure cannot be traced to one cause.\n- NEVER inject two faults in one run: the result could not say which one broke the system.\n- NEVER invent a missing fact (dependencies, current SLO, existing breakers). Mark `[확인 필요: ○○]`; an experiment\n  built on a guessed topology tests the guess.\n- Goal: every experiment has a hypothesis, a live steady-state metric, a scope, an abort trigger and a scripted abort of\n  30 s or less; the closing tally recounts to the experiment sheets.\n\n# Chaos Engineer\n\n**Not for** an active incident (`develop:incident-response-playbook`), SLO or alert setup (`develop:sre-engineer`),\nor tuning the breaker itself (`develop:circuit-breaker-tuner`).\n\n## Process\n\n1. **System analysis** — chart components, dependencies, user-critical paths, how each can fail. Read the repo,\n   manifests and dashboards first. Confirm metrics collection (Prometheus, Datadog or similar) is live, and measure the\n   steady state until it is stable before anything is injected.\n2. **Experiment design** — hypothesis, normal-behaviour metrics, how far the fault may reach (narrowest scope first),\n   what stops it, one fault per run. Fill `references\u002Fexperiment-design.md`. `pod-kill` is irreversible: cap\n   `value`\u002Fselector and write the manual recovery first; reversible = `pod-failure` + `duration`\n   (`references\u002Fkubernetes-chaos.md`).\n3. **Execute** — user runs it; inject under observation with the scripted way back (30 s or less, rehearsed) at hand.\n   Production: breakers, flags or canary isolation already in place, or stay in staging.\n4. **Learn** — record what was found, fix weaknesses, close monitoring gaps; every run ends with a write-up and one or\n   more tracked fixes (`references\u002Fpost-mortem.md`).\n5. **Automate** — put recurring experiments into the delivery pipeline.\n6. **Recount** — count experiments, the ones with all five fields, and the findings; fix the tally if the sheets differ.\n\n## Output Template\n\n```\n## Experiment — \u003Ctitle> (\u003Cenv>)\n\nHypothesis: \u003Cwhen X fails, Y stays within Z>\nSteady state: \u003Cmetric, normal range, live? yes\u002Fno>\nScope: \u003Crung> · Abort trigger: \u003Ccondition> · Abort script: \u003Ccommand> (\u003Cs> s)\nInjection: \u003Cmanifest or script>\nResult: confirmed \u002F refuted \u002F aborted — \u003Cmetric reading>\nFixes: \u003Ctracked item, owner>\nGaps: [확인 필요: ○○] ...\n\n\u003Cn> experiments · \u003Cc> confirmed · \u003Cr> refuted · \u003Ca> aborted · \u003Cg> gaps\n```\n\n## What Claude Does \u002F What You Do\n\n| Claude | You |\n|--------|-----|\n| Drafts hypothesis and steady-state definition | Confirm the hypothesis reflects real business risk |\n| Generates Litmus, toxiproxy, or Chaos Monkey config | Run experiments in your environment |\n| Designs blast radius controls | Verify blast radius is acceptable before starting |\n| Writes rollback scripts | Test rollback works before the experiment begins |\n| Templates the learning summary | Fill in actual findings and assign follow-up tickets |\n\n## Reference Guide\n\n| Need | File | Open when |\n|------|------|-----------|\n| Experiment sheet | `references\u002Fexperiment-design.md` | writing the claim, scope rungs, abort triggers |\n| Host and cloud faults | `references\u002Finfrastructure-chaos.md` | network, dependency, resource, zone, DNS, certificate faults |\n| Cluster faults | `references\u002Fkubernetes-chaos.md` | pod, node, partition, autoscaling faults, Chaos Mesh pod-kill example |\n| Tooling | `references\u002Fchaos-tools.md` | picking a tool, random-kill scripts, pipeline gates, toxiproxy |\n| Game days | `references\u002Fgame-days.md` | running a supervised session |\n| Write-up | `references\u002Fpost-mortem.md` | report after a game day or real incident |\n\n## Related Skills\n\n- `develop:sre-engineer` — SLO definition, error budgets, alerting\n- `develop:incident-response-playbook` — when the failure is real and active\n- `develop:architecture-designer` — resilience pattern design for distributed systems\n- `develop:circuit-breaker-tuner` — configure failure thresholds before running chaos experiments\n",{"name":5,"license":15,"metadata":55,"scenarios":62,"description":7,"compatibility":69},{"area":56,"kind":57,"version":58,"keywords":59,"produces":60,"see-also":61},"resilience","specialist","1.1.0","fault injection, game day, blast radius, steady-state hypothesis, Chaos Mesh, Litmus","experiment docs and injection code","sre-engineer, architecture-designer, circuit-breaker-tuner",[63,64,65,66,67,68],"I want to run a chaos experiment on our Kubernetes cluster to test pod failure resilience","Help me plan a game day exercise to test our system's failure tolerance","Design a blast-radius-controlled fault injection for our microservices","카오스 테스트로 시스템 복원력을 검증하고 싶어","게임 데이 실험 설계를 도와줘","스테이징에서 pod 하나 죽여보고 싶은데 어떻게 안전하게 해?",{"optional":70,"recommended":72,"remote_mcp_note":74},[71],"sequential-thinking",[73],"think-tool","think-tool이 있으면 실험 설계 시 블라스트 반경과 안전 제어를 더 체계적으로 평가합니다. Claude 설정 → MCP Servers에서 remote SSE 엔드포인트를 추가하세요.","main","cdb89e1460a1035ae4d122ee0b33344216b2cbfe","develop\u002Fskills\u002Fchaos-engineer",1,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills","https:\u002F\u002Fgithub.com\u002Fnewkayak12","그냥 하는 사람\r\n","2026-11-12 14:05:10",{"source":8,"skillName":5,"commands":84,"prompt":94,"zipAvailable":95},[85,88,91],{"tool":86,"command":87},"npx","npx skills add newkayak12\u002Fclaude-skills --skill chaos-engineer",{"tool":89,"command":90},"bunx","bunx skills add newkayak12\u002Fclaude-skills --skill chaos-engineer",{"tool":92,"command":93},"pnpm","pnpm dlx skills add newkayak12\u002Fclaude-skills --skill chaos-engineer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fchaos-engineer\u002FSKILL.md",true,[97,103,107,111,115,119,123,127],{"path":98,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":101,"sourceHtmlUrl":102},"agents\u002Fchaos-executor.md","REFERENCE","参考文档",1825,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fchaos-engineer\u002Fagents\u002Fchaos-executor.md",{"path":104,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":105,"sourceHtmlUrl":106},"agents\u002Fexperiment-designer.md",1699,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fchaos-engineer\u002Fagents\u002Fexperiment-designer.md",{"path":108,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":109,"sourceHtmlUrl":110},"references\u002Fchaos-tools.md",1789,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fchaos-engineer\u002Freferences\u002Fchaos-tools.md",{"path":112,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":113,"sourceHtmlUrl":114},"references\u002Fexperiment-design.md",2382,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fchaos-engineer\u002Freferences\u002Fexperiment-design.md",{"path":116,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":117,"sourceHtmlUrl":118},"references\u002Fgame-days.md",1932,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fchaos-engineer\u002Freferences\u002Fgame-days.md",{"path":120,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":121,"sourceHtmlUrl":122},"references\u002Finfrastructure-chaos.md",2934,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fchaos-engineer\u002Freferences\u002Finfrastructure-chaos.md",{"path":124,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":125,"sourceHtmlUrl":126},"references\u002Fkubernetes-chaos.md",3207,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fchaos-engineer\u002Freferences\u002Fkubernetes-chaos.md",{"path":128,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":129,"sourceHtmlUrl":130},"references\u002Fpost-mortem.md",1326,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fchaos-engineer\u002Freferences\u002Fpost-mortem.md",[132,154,178,198,225,244],{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":50},"01M6DJ9KATAGNQ28QRQWG32PNG","diagram","Use when something must be drawn as a checked figure, not Mermaid: page layout, B-tree, lock timeline, ER, benchmark chart, architecture, sequence. SVG + PNG. Triggers: \"도식화해줘\", \"그림으로 그려줘\", \"책에 넣을 그림\", \"시퀀스 다이어그램\", \"draw this as a figure\".","https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fwrite\u002Fskills\u002Fdiagram\u002FSKILL.md",[],[134,139,46,140,141,142,143,144,145,41,146,39,147,148,149,150,35,151,152,153],"web","mermaid","browser","cache","redis","api","b-tree","page","er","postgres","query","layout","as","chart","SVG",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":162,"publishedAt":50},"01M6DJ0RNQFTMCJFZ0F90TKV6X","test-master","Use when writing, improving, or auditing tests, or writing case specs with expected results from a spec. Triggers: \"테스트 작성\", \"테스트 케이스 작성\", \"test case writing\", \"단위 테스트\", \"커버리지 분석\", \"test plan\", \"defect report\".","https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Ftest-master\u002FSKILL.md",[160,161],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[163,164,165,166,49,167,168,169,170,171,172,173,41,174,175,39,176,36,177,35],"test","master","test master","testing","writing","unit tests","development","qa","sse","test plan","plan","analyze","coverage","only","tests",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":185,"publishedAt":50},"01M6DJ0HNBTK0C266899VBY25J","sre-engineer","Use when setting up production reliability practices. Triggers on: \"SLO 정하고 싶어\", \"에러 버짓\", \"알람 피로\", \"반복 작업(toil) 줄이기\", \"golden signals dashboard\", \"burn-rate alert\". Not for active incidents or chaos tests.","https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fsre-engineer\u002FSKILL.md",[184],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[38,32,186,49,187,188,41,189,39,190,191,192,193,194,195,36,196,197,177,35],"sre engineer","observability","SET","fix","reliability","slo","sli","burn-rate","alert","up","call","define",{"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":213,"publishedAt":50},"01M6DJ0D2M8JP3K67HF3EPWRXC","sql-pro","Use when someone needs help writing or rewriting SQL — authoring complex joins, CTEs, window functions, or recursive queries — or designing a schema from scratch, normalizing an existing one, or migrating queries between database dialects.","https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fsql-pro\u002FSKILL.md",[204,207,208],{"categoryNo":205,"categoryName":206,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":209,"categoryName":210,"taxonomyType":211,"taxonomyTypeDesc":212},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[214,215,40,49,167,216,217,45,218,171,41,219,220,221,39,222,32,223,149,224],"sql","sql pro","oracle","boot","database","explain","spring","strategy","schema","functions","optimizer",{"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":236,"publishedAt":50},"01M6DJ07ZKVJXBHFF6F1KE8SF9","spring-boot-engineer","Use when building or extending a Spring Boot 3.x Java backend — REST, Spring Security, JPA, WebFlux, Actuator. Triggers on: \"Spring Boot API\", \"스프링 시큐리티 설정\", \"JPA 연동\". Not for service decomposition or query tuning.","https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fspring-boot-engineer\u002FSKILL.md",[231,232,233],{"categoryNo":205,"categoryName":206,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":234,"categoryName":235,"taxonomyType":211,"taxonomyTypeDesc":212},"01JBSEEDCAT000000000000030","开发工程师",[217,237,220,32,238,49,46,45,239,218,240,144,241,41,242,39,149,243,224,35],"spring boot","spring boot engineer","authentication","java","configure","kotlin","caching",{"skillNo":245,"name":246,"nameZh":6,"description":247,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":248,"categories":249,"keywords":251,"publishedAt":50},"01M6DJ036MK4ESPPFEY6WY8FWZ","spec-driven-development","Use when a feature should be specified before it is coded — stories, acceptance criteria, tasks, a per-criterion check. Triggers: \"스펙 먼저\", \"명세부터 쓰고 구현\", \"수용 기준 먼저\", \"spec first\", \"spec-driven development\".","https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fspec-driven-development\u002FSKILL.md",[250],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[252,253,169,254,255,49,256,257,258,259,171,41,260,39,261,262,36,263,264,35],"spec","spec driven development","spec driven","driven","implement","tasks","acceptance","first","write","think","do","acceptance criteria","feature"]