[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DJ0RNQFTMCJFZ0F90TKV6X":3,"skill-same:01M6DJ0RNQFTMCJFZ0F90TKV6X":140},{"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":72,"commitSha":73,"skillDirectory":74,"forksCount":75,"repositoryHtmlUrl":76,"repositoryHomepageUrl":6,"ownerHtmlUrl":77,"ownerBlogUrl":6,"ownerDescription":78,"updatedAt":79,"install":80,"resources":93},"01M6DJ0RNQFTMCJFZ0F90TKV6X","test-master",null,"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\".","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\u002Ftest-master\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],"test","test master","master","tool","triggers","tests","thinking","only","use","coverage","analyze","testing","plan","test plan","sse","qa","development","unit tests","writing","MCP","2026-11-10 10:12:30",false,"---\nname: test-master\ndescription: >-\n  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\".\nlicense: MIT\nmetadata:\n  version: \"1.2.0\"\n  domain: quality\n  role: specialist\n  scope: testing\n  output-format: report\n  related-skills: test-driven-development, flaky-test-analyzer\nscenarios:\n  - \"write unit tests for this service\"\n  - \"analyze test coverage\"\n  - \"write the test cases for this spec to qa\u002Fcases.md (cases only)\"\n  - \"이 코드에 테스트 추가해줘\"\n  - \"테스트 커버리지 분석해줘\"\n  - \"이 기능 명세로 테스트 케이스만 뽑아서 파일로 써줘\"\ncompatibility:\n  recommended:\n    - think-tool\n  optional:\n    - sequential-thinking\n    - mcp-reasoner\n  remote_mcp_note: >-\n    think-tool이 있으면 플레이키 실패 원인 추론과 커버리지 갭 분석이 더 정확해집니다.\n    Claude 설정 → MCP Servers에서 remote SSE 엔드포인트를 추가하세요.\n---\n\n## Standing Mandates\n\n- NEVER write a test whose expected value you took from the code under test. Derive it from the spec or acceptance; read code only for names. (Scar: expectations copied from the implementation pass by construction and pin its bugs.)\n- NEVER assert truthiness or non-null where an exact value exists, and never cover only the success side — each behavior gets a happy and an error\u002Fedge\u002Fboundary case.\n- NEVER report a percentage, a pass, or a result you did not run (Reference mode runs nothing). A missing fact is `[확인 필요]` under Assumptions, not a guess.\n- NEVER rerun a failing test until it passes; sort it as assertion miss or flakiness and hand flakiness to `flaky-test-analyzer`.\n- Goal: every acceptance item maps to at least one case with a concrete expected result, or to a Not-covered reason — Reference mode stops at the case file, Full mode stops when the targets are met or the gap is named.\n\n# Test Master\n\nTests and case specs from a spec: write, improve, audit, report.\n\n**Not for** red-green-refactor discipline (`test-driven-development`), one intermittent failure (`flaky-test-analyzer`), multi-step HTTP flows against a live server (`scenario-director`), or a code review.\n\n## Modes\n\n| | Full (interactive) | Reference (headless) |\n|---|---|---|\n| When | A person asks for tests, a plan, or an audit | A pipeline step consults this skill (teams qa `cases`, clean-code implement's tests-first step), or \"cases only\" \u002F nobody can answer |\n| Steps | 1 → 5 | 1, 2, then 3R; stop |\n| Writes | test code, results, report | one case-spec file at the caller's path ([case-spec.md](references\u002Fcase-spec.md)) |\n| Runs tests \u002F coverage | yes | no |\n| Asks the user | scope and edge cases | never — open points go under Assumptions |\n\nUnsure → Reference mode. If the caller defines its own return shape, write the case file at its path and return that shape.\n\n## Process\n\nWith sequential-thinking, complete steps 1 and 2 as separate steps before any test code.\n\n1. **Define scope** — what is under test, which testing types apply (Reference: work from the acceptance, not the implementation).\n2. **Create strategy** — how functional, performance, security apply.\n\n3R. **Reference: write case specs, then stop** — per [case-spec.md](references\u002Fcase-spec.md): id, behavior, level, precondition\u002Finput, expected result, acceptance covered; a coverage map from every acceptance to its cases; unresolved points as Assumptions. No test code, no runs, no questions.\n\n3. **Write tests** (Full) — exact assertions, doubles for external dependencies, one plain-sentence title per behavior, no run-order coupling, no production data.\n4. **Execute** — run; on failure sort real miss vs environment\u002Fflakiness and fix the cause. With think-tool, trace the failure chain before diagnosing.\n5. **Report** — findings with severity and a concrete fix each; check coverage targets and name any gap.\n\n## Reference Guide\n\n| Subject | File | Open When |\n|---|---|---|\n| Unit | `references\u002Funit-testing.md` | JUnit\u002FMockK idioms, doubles, parametrized boundaries |\n| Integration | `references\u002Fintegration-testing.md` | Spring slices, Testcontainers |\n| E2E | `references\u002Fe2e-testing.md` | Picking journeys; stable browser tests |\n| Load | `references\u002Fperformance-testing.md` | k6 load, stress, spike, soak |\n| Security | `references\u002Fsecurity-testing.md` | Auth and input-validation checklist |\n| Reporting | `references\u002Ftest-reports.md` | Report layout, finding, severity |\n| QA practice | `references\u002Fqa-methodology.md` | Plans, design techniques, defects, gates |\n| Automation | `references\u002Fautomation.md` | Structure, CI layout |\n| Test-first | `references\u002Ftdd-cycle.md` | Red-green-refactor, bug-fix flow |\n| Smells | `references\u002Ftest-smells.md` | Mock misuse, brittle or hollow tests |\n| Case spec | `references\u002Fcase-spec.md` | Reference mode file shape |\n\n## Output Template\n\n**Full mode:**\n\n```\n## Test report — \u003Cscope>\nVerdict: \u003Ctargets met | N gaps>  ·  Cases: 14 (9 happy, 5 error\u002Fedge)  ·  Run: 14 passed, 0 failed\nCoverage: line 84% \u002F branch 71% (target 80\u002F70) · uncovered: \u003Cfile:range>\nFindings: 1 Critical, 0 High, 2 Medium, 1 Low\n| # | Severity | Finding | Fix |\n```\n\n**Reference mode** — one file at the caller's path: `Status: specified, not run`; case table `id | behavior | kind | level | precondition \u002F input | expected result | acceptance covered`; Coverage (acceptance → case ids); Assumptions; Not covered. Closing line: `Cases: N · acceptance covered: X\u002FY · Not covered: Z · Assumptions: W`. Every row has a concrete expected result; no run results.\n\n## What Claude Does \u002F What You Do\n\n| Claude | You |\n|--------|-----|\n| Writes scaffolding, assertions, plan structure; finds coverage gaps | Confirm scope and edge cases; validate the tests match business intent |\n| Suggests mocking strategies | Run the tests, share failure output, wire CI |\n| Reference: writes the case file from the acceptance, records assumptions instead of asking | Nothing during the step — the next step executes the cases and overturns a wrong assumption |\n\n## Related Skills\n\n- `develop:test-driven-development` — red-green-refactor; turns Reference-mode cases into failing tests\n- `develop:scenario-director` — multi-step HTTP scenario specs + catalog\n- `develop:flaky-test-analyzer` — intermittent failures\n- `develop:clean-code` — test code quality and readability\n","## Standing Mandates\n\n- NEVER write a test whose expected value you took from the code under test. Derive it from the spec or acceptance; read code only for names. (Scar: expectations copied from the implementation pass by construction and pin its bugs.)\n- NEVER assert truthiness or non-null where an exact value exists, and never cover only the success side — each behavior gets a happy and an error\u002Fedge\u002Fboundary case.\n- NEVER report a percentage, a pass, or a result you did not run (Reference mode runs nothing). A missing fact is `[확인 필요]` under Assumptions, not a guess.\n- NEVER rerun a failing test until it passes; sort it as assertion miss or flakiness and hand flakiness to `flaky-test-analyzer`.\n- Goal: every acceptance item maps to at least one case with a concrete expected result, or to a Not-covered reason — Reference mode stops at the case file, Full mode stops when the targets are met or the gap is named.\n\n# Test Master\n\nTests and case specs from a spec: write, improve, audit, report.\n\n**Not for** red-green-refactor discipline (`test-driven-development`), one intermittent failure (`flaky-test-analyzer`), multi-step HTTP flows against a live server (`scenario-director`), or a code review.\n\n## Modes\n\n| | Full (interactive) | Reference (headless) |\n|---|---|---|\n| When | A person asks for tests, a plan, or an audit | A pipeline step consults this skill (teams qa `cases`, clean-code implement's tests-first step), or \"cases only\" \u002F nobody can answer |\n| Steps | 1 → 5 | 1, 2, then 3R; stop |\n| Writes | test code, results, report | one case-spec file at the caller's path ([case-spec.md](references\u002Fcase-spec.md)) |\n| Runs tests \u002F coverage | yes | no |\n| Asks the user | scope and edge cases | never — open points go under Assumptions |\n\nUnsure → Reference mode. If the caller defines its own return shape, write the case file at its path and return that shape.\n\n## Process\n\nWith sequential-thinking, complete steps 1 and 2 as separate steps before any test code.\n\n1. **Define scope** — what is under test, which testing types apply (Reference: work from the acceptance, not the implementation).\n2. **Create strategy** — how functional, performance, security apply.\n\n3R. **Reference: write case specs, then stop** — per [case-spec.md](references\u002Fcase-spec.md): id, behavior, level, precondition\u002Finput, expected result, acceptance covered; a coverage map from every acceptance to its cases; unresolved points as Assumptions. No test code, no runs, no questions.\n\n3. **Write tests** (Full) — exact assertions, doubles for external dependencies, one plain-sentence title per behavior, no run-order coupling, no production data.\n4. **Execute** — run; on failure sort real miss vs environment\u002Fflakiness and fix the cause. With think-tool, trace the failure chain before diagnosing.\n5. **Report** — findings with severity and a concrete fix each; check coverage targets and name any gap.\n\n## Reference Guide\n\n| Subject | File | Open When |\n|---|---|---|\n| Unit | `references\u002Funit-testing.md` | JUnit\u002FMockK idioms, doubles, parametrized boundaries |\n| Integration | `references\u002Fintegration-testing.md` | Spring slices, Testcontainers |\n| E2E | `references\u002Fe2e-testing.md` | Picking journeys; stable browser tests |\n| Load | `references\u002Fperformance-testing.md` | k6 load, stress, spike, soak |\n| Security | `references\u002Fsecurity-testing.md` | Auth and input-validation checklist |\n| Reporting | `references\u002Ftest-reports.md` | Report layout, finding, severity |\n| QA practice | `references\u002Fqa-methodology.md` | Plans, design techniques, defects, gates |\n| Automation | `references\u002Fautomation.md` | Structure, CI layout |\n| Test-first | `references\u002Ftdd-cycle.md` | Red-green-refactor, bug-fix flow |\n| Smells | `references\u002Ftest-smells.md` | Mock misuse, brittle or hollow tests |\n| Case spec | `references\u002Fcase-spec.md` | Reference mode file shape |\n\n## Output Template\n\n**Full mode:**\n\n```\n## Test report — \u003Cscope>\nVerdict: \u003Ctargets met | N gaps>  ·  Cases: 14 (9 happy, 5 error\u002Fedge)  ·  Run: 14 passed, 0 failed\nCoverage: line 84% \u002F branch 71% (target 80\u002F70) · uncovered: \u003Cfile:range>\nFindings: 1 Critical, 0 High, 2 Medium, 1 Low\n| # | Severity | Finding | Fix |\n```\n\n**Reference mode** — one file at the caller's path: `Status: specified, not run`; case table `id | behavior | kind | level | precondition \u002F input | expected result | acceptance covered`; Coverage (acceptance → case ids); Assumptions; Not covered. Closing line: `Cases: N · acceptance covered: X\u002FY · Not covered: Z · Assumptions: W`. Every row has a concrete expected result; no run results.\n\n## What Claude Does \u002F What You Do\n\n| Claude | You |\n|--------|-----|\n| Writes scaffolding, assertions, plan structure; finds coverage gaps | Confirm scope and edge cases; validate the tests match business intent |\n| Suggests mocking strategies | Run the tests, share failure output, wire CI |\n| Reference: writes the case file from the acceptance, records assumptions instead of asking | Nothing during the step — the next step executes the cases and overturns a wrong assumption |\n\n## Related Skills\n\n- `develop:test-driven-development` — red-green-refactor; turns Reference-mode cases into failing tests\n- `develop:scenario-director` — multi-step HTTP scenario specs + catalog\n- `develop:flaky-test-analyzer` — intermittent failures\n- `develop:clean-code` — test code quality and readability\n",{"name":5,"license":15,"metadata":52,"scenarios":58,"description":7,"compatibility":65},{"role":53,"scope":38,"domain":54,"version":55,"output-format":56,"related-skills":57},"specialist","quality","1.2.0","report","test-driven-development, flaky-test-analyzer",[59,60,61,62,63,64],"write unit tests for this service","analyze test coverage","write the test cases for this spec to qa\u002Fcases.md (cases only)","이 코드에 테스트 추가해줘","테스트 커버리지 분석해줘","이 기능 명세로 테스트 케이스만 뽑아서 파일로 써줘",{"optional":66,"recommended":69,"remote_mcp_note":71},[67,68],"sequential-thinking","mcp-reasoner",[70],"think-tool","think-tool이 있으면 플레이키 실패 원인 추론과 커버리지 갭 분석이 더 정확해집니다. Claude 설정 → MCP Servers에서 remote SSE 엔드포인트를 추가하세요.","main","cdb89e1460a1035ae4d122ee0b33344216b2cbfe","develop\u002Fskills\u002Ftest-master",1,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills","https:\u002F\u002Fgithub.com\u002Fnewkayak12","그냥 하는 사람\r\n","2026-11-13 23:10:20",{"source":8,"skillName":5,"commands":81,"prompt":91,"zipAvailable":92},[82,85,88],{"tool":83,"command":84},"npx","npx skills add newkayak12\u002Fclaude-skills --skill test-master",{"tool":86,"command":87},"bunx","bunx skills add newkayak12\u002Fclaude-skills --skill test-master",{"tool":89,"command":90},"pnpm","pnpm dlx skills add newkayak12\u002Fclaude-skills --skill test-master","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Ftest-master\u002FSKILL.md",true,[94,100,104,108,112,116,120,124,128,132,136],{"path":95,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Fautomation.md","REFERENCE","参考文档",2734,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Ftest-master\u002Freferences\u002Fautomation.md",{"path":101,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":102,"sourceHtmlUrl":103},"references\u002Fcase-spec.md",3188,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Ftest-master\u002Freferences\u002Fcase-spec.md",{"path":105,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":106,"sourceHtmlUrl":107},"references\u002Fe2e-testing.md",2228,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Ftest-master\u002Freferences\u002Fe2e-testing.md",{"path":109,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":110,"sourceHtmlUrl":111},"references\u002Fintegration-testing.md",2926,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Ftest-master\u002Freferences\u002Fintegration-testing.md",{"path":113,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":114,"sourceHtmlUrl":115},"references\u002Fperformance-testing.md",2208,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Ftest-master\u002Freferences\u002Fperformance-testing.md",{"path":117,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":118,"sourceHtmlUrl":119},"references\u002Fqa-methodology.md",3339,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Ftest-master\u002Freferences\u002Fqa-methodology.md",{"path":121,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":122,"sourceHtmlUrl":123},"references\u002Fsecurity-testing.md",2337,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Ftest-master\u002Freferences\u002Fsecurity-testing.md",{"path":125,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":126,"sourceHtmlUrl":127},"references\u002Ftdd-cycle.md",2047,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Ftest-master\u002Freferences\u002Ftdd-cycle.md",{"path":129,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":130,"sourceHtmlUrl":131},"references\u002Ftest-reports.md",1802,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Ftest-master\u002Freferences\u002Ftest-reports.md",{"path":133,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":134,"sourceHtmlUrl":135},"references\u002Ftest-smells.md",2430,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Ftest-master\u002Freferences\u002Ftest-smells.md",{"path":137,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":138,"sourceHtmlUrl":139},"references\u002Funit-testing.md",2875,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Ftest-master\u002Freferences\u002Funit-testing.md",[141,164,186,215,234,255],{"skillNo":142,"name":143,"nameZh":6,"description":144,"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":147,"publishedAt":47},"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",[],[143,148,149,150,151,152,153,154,155,30,156,35,157,158,159,160,31,161,162,163],"web","architecture","mermaid","browser","cache","redis","api","b-tree","page","er","postgres","query","layout","as","chart","SVG",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":171,"publishedAt":47},"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",[170],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[172,173,174,46,175,176,30,177,35,178,179,180,181,182,183,33,184,185,32,31],"sre","engineer","sre engineer","observability","SET","fix","reliability","slo","sli","burn-rate","alert","up","call","define",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":201,"publishedAt":47},"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",[192,195,196],{"categoryNo":193,"categoryName":194,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":197,"categoryName":198,"taxonomyType":199,"taxonomyTypeDesc":200},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[202,203,204,46,45,205,206,207,208,41,30,209,210,211,35,212,173,213,159,214],"sql","sql pro","design","oracle","boot","code","database","explain","spring","strategy","schema","functions","optimizer",{"skillNo":216,"name":217,"nameZh":6,"description":218,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":219,"categories":220,"keywords":226,"publishedAt":47},"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",[221,222,223],{"categoryNo":193,"categoryName":194,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":224,"categoryName":225,"taxonomyType":199,"taxonomyTypeDesc":200},"01JBSEEDCAT000000000000030","开发工程师",[206,227,210,173,228,46,149,207,229,208,230,154,231,30,232,35,159,233,214,31],"spring boot","spring boot engineer","authentication","java","configure","kotlin","caching",{"skillNo":235,"name":236,"nameZh":6,"description":237,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":238,"categories":239,"keywords":241,"publishedAt":47},"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",[240],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[242,243,43,244,245,46,246,247,248,249,41,30,250,35,251,252,33,253,254,31],"spec","spec driven development","spec driven","driven","implement","tasks","acceptance","first","write","think","do","acceptance criteria","feature",{"skillNo":256,"name":257,"nameZh":6,"description":258,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":259,"categories":260,"keywords":263,"publishedAt":47},"01M6DHYFTQSA9RQ6YXNDHF0N4J","like-my-code","Use when a repo's code style must become written policy — harness conventions (coding.md, boundaries.md) backed by repo evidence. Triggers: \"내 코드 스타일로 컨벤션 뽑아줘\", \"이 레포 스타일을 정책으로\", \"like my code\", \"extract conventions from this repo\".","https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Flike-my-code\u002FSKILL.md",[261,262],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":224,"categoryName":225,"taxonomyType":199,"taxonomyTypeDesc":200},[207,264,46,265,266,267,154,41,30,268,269,270,271,35,272,251,273,31,274],"like my code","policy","code style","harness","coding","work","repo","extract","evidence","conventions","style"]