[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DHVA2398CA7RARKMZ9AMYZ":3,"skill-same:01M6DHVA2398CA7RARKMZ9AMYZ":109},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":65,"commitSha":66,"skillDirectory":67,"forksCount":68,"repositoryHtmlUrl":69,"repositoryHomepageUrl":6,"ownerHtmlUrl":70,"ownerBlogUrl":6,"ownerDescription":71,"updatedAt":72,"install":73,"resources":86},"01M6DHVA2398CA7RARKMZ9AMYZ","clean-architecture",null,"Use when designing layered architectures, separating concerns across boundaries, implementing ports and adapters, or when business logic is leaking into frameworks and the codebase feels tangled. Triggers on: \"의존성 규칙\", \"레이어 아키텍처\".","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\u002Fclean-architecture\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"architecture","clean architecture","clean","use","triggers","service","logic","across","frameworks","thinking","do","design","business","ports","tool","how","sse","web","implement","MCP","2026-11-10 10:12:30",false,"---\nname: clean-architecture\ndescription: >-\n  Use when designing layered architectures, separating concerns across\n  boundaries, implementing ports and adapters, or when business logic is leaking\n  into frameworks and the codebase feels tangled. Triggers on: \"의존성 규칙\", \"레이어\n  아키텍처\".\nlicense: MIT\nmetadata:\n  version: \"1.0.0\"\nscenarios:\n  - \"design a clean architecture for this service\"\n  - \"my business logic is leaking into the web layer\"\n  - \"how do I implement ports and adapters?\"\n  - \"클린 아키텍처 적용해줘\"\n  - \"의존성이 잘못된 방향으로 흘러가고 있어\"\n  - \"비즈니스 로직이 컨트롤러에 너무 많이 들어가 있어\"\ncompatibility:\n  recommended:\n    - think-tool\n    - sequential-thinking\n  optional:\n    - mcp-reasoner\n  remote_mcp_note: >-\n    think-tool이 있으면 의존성 방향 위반과 경계 설계 트레이드오프 분석이 더 정확해집니다.\n    Claude 설정 → MCP Servers에서 remote SSE 엔드포인트를 추가하세요.\n---\n\n## Standing Mandates\n\n- NEVER add a port, layer, or interface \"for flexibility\". One adapter keeps the seam concrete; a port needs a second\n  real adapter or a test fake you actually use. (Scar: single-implementation interfaces everywhere make a CRUD service\n  five files per change.)\n- NEVER score from impressions. Every point off the score cites a violating import (`file:line`, direction) you read. (An impression-based 6\u002F10 cannot be recounted or argued with.)\n- A fact you were not shown (module layout, which layer a class sits in) is `[확인 필요: ○○]`, never inferred; a score resting on one is `provisional`.\n- Goal: the score recounts to the listed violations, and step 5 is checked (rule tests run with no framework import) or marked `[확인 필요]`.\n\n# Clean Architecture Framework\n\nKeep the rules that earn the business its money free of imports from the tools that deliver them: web stack, datastore, messaging.\n\n**Not for** code-level naming and function size (`develop:clean-code`), bounded contexts and aggregates\n(`develop:domain-driven-design`), topology and deployment (`develop:architecture-designer`), ranking refactor targets\nin a live repo (`develop:architecture-review`), or simple scripts and prototypes.\n\n## Process\n\n1. **Assess current state** — Read the imports; list dependency rule violations; score 0–10\n2. **Draw concentric circles** — innermost Entities, then Use Cases, then Interface Adapters, outermost Frameworks\u002FDrivers\n3. **Identify violations** — Find import arrows pointing outward; list them\n4. **Apply Dependency Inversion** — Define interfaces in inner circles; implementations in outer circles\n5. **Validate** — Confirm business logic tests run with no framework imports\n\n### Seam Discipline (before step 4 adds a port)\n\n- **Deletion test**: delete the module in your head. Complexity vanishes → it was a pass-through; remove it. Complexity reappears across callers → it earns its place.\n- **Adapter rule**: one adapter → keep it concrete; the seam is hypothetical. A second adapter (real, or a test fake you actually need) → introduce the port.\n- **The interface is the test surface**: tests cross the same seam callers do. If a test must reach past it, the module is the wrong shape.\n\n## Scoring\n\nRate 0–10. A 10 means every business rule can be exercised in a test with nothing else running.\n\n## The Clean Architecture Framework\n\n### 1. Dependency Rule and the Rings\n\nImports run toward the middle only. A class in an inner ring has no knowledge that any outer ring exists.\n\n| Context | Pattern | Example |\n|---------|---------|---------|\n| Layer direction | The inner ring declares the contract; the outer ring fulfils it | `UserRepository` declared with the use cases; `PostgresUserRepository` lives in adapters |\n| Data crossing | Plain data holders travel between rings; persistence-mapped objects stay outside | Use case answers with a `UserResponse`, never the table-mapped class |\n| Framework isolation | Put framework calls behind your own interface | `EmailSender` interface hides whether you use SendGrid or SES |\n| Database independence | A repository hides how data is stored | rules call `repo.save(user)` and never see SQL |\n\nSee: [references\u002Fdependency-direction.md](references\u002Fdependency-direction.md)\n\n### 2. Entities and Use Cases\n\n- **Entities** hold the rules that apply company-wide and import no framework\n- **Use Cases** hold rules specific to one application operation, drive the entities, take a request model in and hand a response model back\n\n| Context | Pattern | Example |\n|---------|---------|---------|\n| Entity design | Encapsulate rules with no framework dependencies | `Order.calculateTotal()` knows nothing about HTTP |\n| Use Case boundary | Declare an input port and an output port | `CreateOrderInput` interface; `CreateOrderOutput` interface |\n| Request\u002FResponse | Dumb value objects carry input and output | `CreateOrderRequest { items, customerId }`, free of persistence types |\n| Single responsibility | A class per application operation | `PlaceOrder`, `CancelOrder`, `RefundOrder` kept apart |\n\nSee: [references\u002Fuse-cases-and-adapters.md](references\u002Fuse-cases-and-adapters.md)\n\n### 3. Adapters and Frameworks\n\nAdapters translate between the use cases' data shapes and whatever the outside world speaks. Frameworks sit in the outermost ring.\n\n| Context | Pattern | Example |\n|---------|---------|---------|\n| Controller | Turns an incoming call into the use case's input | `OrderController.create(req)` assembles a `CreateOrderRequest` |\n| Presenter | Shapes the use case's answer for display | `OrderPresenter.present(response)` prepares the JSON payload |\n| Gateway | Implements repository interface using a specific DB | `SqlOrderRepository implements OrderRepository` |\n| Plugin architecture | Main component wires dependencies at startup | `main()` instantiates concrete classes and injects them |\n\nSee: [references\u002Fuse-cases-and-adapters.md](references\u002Fuse-cases-and-adapters.md)\n\n### 4. Component Principles\n\n- **REP**: what ships as one unit should also be reusable as one unit\n- **CCP**: group classes that a single kind of change will touch\n- **ADP**: the module graph stays free of loops\n- **SDP**: point dependencies at the modules that change less\n\nSee: [references\u002Fcomponents-and-solid.md](references\u002Fcomponents-and-solid.md)\n\n### 5. SOLID Principles\n\nSRP, OCP, LSP, ISP, DIP, with traps and checks in the reference. Typical DIP break: `OrderService` imports `StripeClient` directly.\n\nSee: [references\u002Fcomponents-and-solid.md](references\u002Fcomponents-and-solid.md)\n\n### 6. Boundary Strength and Humble Objects\n\n- **Full boundary**: one interface per direction (input port plus output port)\n- **Partial boundary**: strategy or facade pattern\n- **Humble Object**: split behavior at a boundary — testable logic separate from hard-to-test infrastructure\n\nSee: [references\u002Fboundary-strength.md](references\u002Fboundary-strength.md)\n\n## Quick Diagnostic\n\nAny \"no\" is a violation row: rule tests need neither datastore nor server · every import points inward · the datastore\ncan change with the rules untouched · use cases ignore how requests arrive · the framework stays in the outer ring.\n\n## Output Template\n\n```\n## Clean architecture — \u003Cservice or path>\n\nScore: \u003Cn>\u002F10 — \u003Cone line citing the violations below>\nViolations: \u003C# · importer → imported (file:line) · direction> ...\nPlan: \u003Cinterface to extract \u002F class to move, per violation #>\nDiagram: before\u002Fafter (Mermaid or ASCII)\n\n\u003Cv> violations · \u003Cp> ports proposed · \u003Cu> facts [확인 필요]\n```\n\n## What Claude Does \u002F What You Do\n\n| Claude | You |\n|--------|-----|\n| Draws the concentric circle diagram | Decide which violations to fix now |\n| Identifies dependency rule violations | Confirm business rules and domain entities |\n| Defines interface contracts at each boundary | Implement concrete classes in outer circles |\n| Writes Use Case input\u002Foutput DTOs | Wire dependencies in Main\u002Fcomposition root |\n\n## Reference Files\n\n- [dependency-direction.md](references\u002Fdependency-direction.md)\n- [use-cases-and-adapters.md](references\u002Fuse-cases-and-adapters.md)\n- [components-and-solid.md](references\u002Fcomponents-and-solid.md)\n- [boundary-strength.md](references\u002Fboundary-strength.md)\n\n## Related Skills\n\n- `develop:architecture-review` — rank which tangled modules to deepen first, from git history\n- `develop:clean-code` — code-level quality within each layer\n- `develop:domain-driven-design` — domain modeling and bounded contexts\n- `develop:architecture-designer` — structural and deployment-level decisions\n","## Standing Mandates\n\n- NEVER add a port, layer, or interface \"for flexibility\". One adapter keeps the seam concrete; a port needs a second\n  real adapter or a test fake you actually use. (Scar: single-implementation interfaces everywhere make a CRUD service\n  five files per change.)\n- NEVER score from impressions. Every point off the score cites a violating import (`file:line`, direction) you read. (An impression-based 6\u002F10 cannot be recounted or argued with.)\n- A fact you were not shown (module layout, which layer a class sits in) is `[확인 필요: ○○]`, never inferred; a score resting on one is `provisional`.\n- Goal: the score recounts to the listed violations, and step 5 is checked (rule tests run with no framework import) or marked `[확인 필요]`.\n\n# Clean Architecture Framework\n\nKeep the rules that earn the business its money free of imports from the tools that deliver them: web stack, datastore, messaging.\n\n**Not for** code-level naming and function size (`develop:clean-code`), bounded contexts and aggregates\n(`develop:domain-driven-design`), topology and deployment (`develop:architecture-designer`), ranking refactor targets\nin a live repo (`develop:architecture-review`), or simple scripts and prototypes.\n\n## Process\n\n1. **Assess current state** — Read the imports; list dependency rule violations; score 0–10\n2. **Draw concentric circles** — innermost Entities, then Use Cases, then Interface Adapters, outermost Frameworks\u002FDrivers\n3. **Identify violations** — Find import arrows pointing outward; list them\n4. **Apply Dependency Inversion** — Define interfaces in inner circles; implementations in outer circles\n5. **Validate** — Confirm business logic tests run with no framework imports\n\n### Seam Discipline (before step 4 adds a port)\n\n- **Deletion test**: delete the module in your head. Complexity vanishes → it was a pass-through; remove it. Complexity reappears across callers → it earns its place.\n- **Adapter rule**: one adapter → keep it concrete; the seam is hypothetical. A second adapter (real, or a test fake you actually need) → introduce the port.\n- **The interface is the test surface**: tests cross the same seam callers do. If a test must reach past it, the module is the wrong shape.\n\n## Scoring\n\nRate 0–10. A 10 means every business rule can be exercised in a test with nothing else running.\n\n## The Clean Architecture Framework\n\n### 1. Dependency Rule and the Rings\n\nImports run toward the middle only. A class in an inner ring has no knowledge that any outer ring exists.\n\n| Context | Pattern | Example |\n|---------|---------|---------|\n| Layer direction | The inner ring declares the contract; the outer ring fulfils it | `UserRepository` declared with the use cases; `PostgresUserRepository` lives in adapters |\n| Data crossing | Plain data holders travel between rings; persistence-mapped objects stay outside | Use case answers with a `UserResponse`, never the table-mapped class |\n| Framework isolation | Put framework calls behind your own interface | `EmailSender` interface hides whether you use SendGrid or SES |\n| Database independence | A repository hides how data is stored | rules call `repo.save(user)` and never see SQL |\n\nSee: [references\u002Fdependency-direction.md](references\u002Fdependency-direction.md)\n\n### 2. Entities and Use Cases\n\n- **Entities** hold the rules that apply company-wide and import no framework\n- **Use Cases** hold rules specific to one application operation, drive the entities, take a request model in and hand a response model back\n\n| Context | Pattern | Example |\n|---------|---------|---------|\n| Entity design | Encapsulate rules with no framework dependencies | `Order.calculateTotal()` knows nothing about HTTP |\n| Use Case boundary | Declare an input port and an output port | `CreateOrderInput` interface; `CreateOrderOutput` interface |\n| Request\u002FResponse | Dumb value objects carry input and output | `CreateOrderRequest { items, customerId }`, free of persistence types |\n| Single responsibility | A class per application operation | `PlaceOrder`, `CancelOrder`, `RefundOrder` kept apart |\n\nSee: [references\u002Fuse-cases-and-adapters.md](references\u002Fuse-cases-and-adapters.md)\n\n### 3. Adapters and Frameworks\n\nAdapters translate between the use cases' data shapes and whatever the outside world speaks. Frameworks sit in the outermost ring.\n\n| Context | Pattern | Example |\n|---------|---------|---------|\n| Controller | Turns an incoming call into the use case's input | `OrderController.create(req)` assembles a `CreateOrderRequest` |\n| Presenter | Shapes the use case's answer for display | `OrderPresenter.present(response)` prepares the JSON payload |\n| Gateway | Implements repository interface using a specific DB | `SqlOrderRepository implements OrderRepository` |\n| Plugin architecture | Main component wires dependencies at startup | `main()` instantiates concrete classes and injects them |\n\nSee: [references\u002Fuse-cases-and-adapters.md](references\u002Fuse-cases-and-adapters.md)\n\n### 4. Component Principles\n\n- **REP**: what ships as one unit should also be reusable as one unit\n- **CCP**: group classes that a single kind of change will touch\n- **ADP**: the module graph stays free of loops\n- **SDP**: point dependencies at the modules that change less\n\nSee: [references\u002Fcomponents-and-solid.md](references\u002Fcomponents-and-solid.md)\n\n### 5. SOLID Principles\n\nSRP, OCP, LSP, ISP, DIP, with traps and checks in the reference. Typical DIP break: `OrderService` imports `StripeClient` directly.\n\nSee: [references\u002Fcomponents-and-solid.md](references\u002Fcomponents-and-solid.md)\n\n### 6. Boundary Strength and Humble Objects\n\n- **Full boundary**: one interface per direction (input port plus output port)\n- **Partial boundary**: strategy or facade pattern\n- **Humble Object**: split behavior at a boundary — testable logic separate from hard-to-test infrastructure\n\nSee: [references\u002Fboundary-strength.md](references\u002Fboundary-strength.md)\n\n## Quick Diagnostic\n\nAny \"no\" is a violation row: rule tests need neither datastore nor server · every import points inward · the datastore\ncan change with the rules untouched · use cases ignore how requests arrive · the framework stays in the outer ring.\n\n## Output Template\n\n```\n## Clean architecture — \u003Cservice or path>\n\nScore: \u003Cn>\u002F10 — \u003Cone line citing the violations below>\nViolations: \u003C# · importer → imported (file:line) · direction> ...\nPlan: \u003Cinterface to extract \u002F class to move, per violation #>\nDiagram: before\u002Fafter (Mermaid or ASCII)\n\n\u003Cv> violations · \u003Cp> ports proposed · \u003Cu> facts [확인 필요]\n```\n\n## What Claude Does \u002F What You Do\n\n| Claude | You |\n|--------|-----|\n| Draws the concentric circle diagram | Decide which violations to fix now |\n| Identifies dependency rule violations | Confirm business rules and domain entities |\n| Defines interface contracts at each boundary | Implement concrete classes in outer circles |\n| Writes Use Case input\u002Foutput DTOs | Wire dependencies in Main\u002Fcomposition root |\n\n## Reference Files\n\n- [dependency-direction.md](references\u002Fdependency-direction.md)\n- [use-cases-and-adapters.md](references\u002Fuse-cases-and-adapters.md)\n- [components-and-solid.md](references\u002Fcomponents-and-solid.md)\n- [boundary-strength.md](references\u002Fboundary-strength.md)\n\n## Related Skills\n\n- `develop:architecture-review` — rank which tangled modules to deepen first, from git history\n- `develop:clean-code` — code-level quality within each layer\n- `develop:domain-driven-design` — domain modeling and bounded contexts\n- `develop:architecture-designer` — structural and deployment-level decisions\n",{"name":5,"license":15,"metadata":49,"scenarios":51,"description":7,"compatibility":58},{"version":50},"1.0.0",[52,53,54,55,56,57],"design a clean architecture for this service","my business logic is leaking into the web layer","how do I implement ports and adapters?","클린 아키텍처 적용해줘","의존성이 잘못된 방향으로 흘러가고 있어","비즈니스 로직이 컨트롤러에 너무 많이 들어가 있어",{"optional":59,"recommended":61,"remote_mcp_note":64},[60],"mcp-reasoner",[62,63],"think-tool","sequential-thinking","think-tool이 있으면 의존성 방향 위반과 경계 설계 트레이드오프 분석이 더 정확해집니다. Claude 설정 → MCP Servers에서 remote SSE 엔드포인트를 추가하세요.","main","cdb89e1460a1035ae4d122ee0b33344216b2cbfe","develop\u002Fskills\u002Fclean-architecture",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":74,"prompt":84,"zipAvailable":85},[75,78,81],{"tool":76,"command":77},"npx","npx skills add newkayak12\u002Fclaude-skills --skill clean-architecture",{"tool":79,"command":80},"bunx","bunx skills add newkayak12\u002Fclaude-skills --skill clean-architecture",{"tool":82,"command":83},"pnpm","pnpm dlx skills add newkayak12\u002Fclaude-skills --skill clean-architecture","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fclean-architecture\u002FSKILL.md",true,[87,93,97,101,105],{"path":88,"resourceType":89,"resourceTypeDesc":90,"sizeBytes":91,"sourceHtmlUrl":92},"agents\u002Fopenai.yaml","REFERENCE","参考文档",128,"https:\u002F\u002Fgithub.com\u002Fnexuslinkproductions\u002Fyuri-os\u002Fblob\u002Fmain\u002Fskills\u002Fusing-git-worktrees\u002Fagents\u002Fopenai.yaml",{"path":94,"resourceType":89,"resourceTypeDesc":90,"sizeBytes":95,"sourceHtmlUrl":96},"references\u002Fboundary-strength.md",4458,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fclean-architecture\u002Freferences\u002Fboundary-strength.md",{"path":98,"resourceType":89,"resourceTypeDesc":90,"sizeBytes":99,"sourceHtmlUrl":100},"references\u002Fcomponents-and-solid.md",4123,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fclean-architecture\u002Freferences\u002Fcomponents-and-solid.md",{"path":102,"resourceType":89,"resourceTypeDesc":90,"sizeBytes":103,"sourceHtmlUrl":104},"references\u002Fdependency-direction.md",5071,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fclean-architecture\u002Freferences\u002Fdependency-direction.md",{"path":106,"resourceType":89,"resourceTypeDesc":90,"sizeBytes":107,"sourceHtmlUrl":108},"references\u002Fuse-cases-and-adapters.md",5189,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fclean-architecture\u002Freferences\u002Fuse-cases-and-adapters.md",[110,131,156,178,206,225],{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":116,"publishedAt":44},"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",[],[112,41,24,117,118,119,120,121,122,38,123,27,124,125,126,127,28,128,129,130],"mermaid","browser","cache","redis","api","b-tree","page","er","postgres","query","layout","as","chart","SVG",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":141,"publishedAt":44},"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",[137,140],{"categoryNo":138,"categoryName":139,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[142,143,144,145,43,146,147,148,149,40,150,151,38,152,153,27,154,33,155,28],"test","master","test master","testing","writing","unit tests","development","qa","test plan","plan","analyze","coverage","only","tests",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":163,"publishedAt":44},"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",[162],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[164,165,166,43,167,168,38,169,27,170,171,172,173,174,175,33,176,177,155,28],"sre","engineer","sre engineer","observability","SET","fix","reliability","slo","sli","burn-rate","alert","up","call","define",{"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":193,"publishedAt":44},"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",[184,187,188],{"categoryNo":185,"categoryName":186,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":189,"categoryName":190,"taxonomyType":191,"taxonomyTypeDesc":192},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[194,195,35,43,146,196,197,198,199,40,38,200,201,202,27,203,165,204,126,205],"sql","sql pro","oracle","boot","code","database","explain","spring","strategy","schema","functions","optimizer",{"skillNo":207,"name":208,"nameZh":6,"description":209,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":210,"categories":211,"keywords":217,"publishedAt":44},"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",[212,213,214],{"categoryNo":185,"categoryName":186,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":215,"categoryName":216,"taxonomyType":191,"taxonomyTypeDesc":192},"01JBSEEDCAT000000000000030","开发工程师",[197,218,201,165,219,43,24,198,220,199,221,121,222,38,223,27,126,224,205,28],"spring boot","spring boot engineer","authentication","java","configure","kotlin","caching",{"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":232,"publishedAt":44},"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",[231],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[233,234,148,235,236,43,42,237,238,239,40,38,240,27,241,34,33,242,243,28],"spec","spec driven development","spec driven","driven","tasks","acceptance","first","write","think","acceptance criteria","feature"]