[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DHVEGJ1V7DH6WMW0D2XS44":3,"skill-same:01M6DHVEGJ1V7DH6WMW0D2XS44":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":34,"publishedAt":55,"linkOnly":56,"markdownContent":57,"markdownBody":58,"frontMatter":59,"refName":75,"commitSha":76,"skillDirectory":77,"forksCount":78,"repositoryHtmlUrl":79,"repositoryHomepageUrl":6,"ownerHtmlUrl":80,"ownerBlogUrl":6,"ownerDescription":81,"updatedAt":82,"install":83,"resources":96},"01M6DHVEGJ1V7DH6WMW0D2XS44","clean-code",null,"Use when a diff, branch or PR needs review or a gate verdict, code needs refactoring, or a requirement needs implementing cleanly. Triggers: \"코드 리뷰\", \"이 브랜치 리뷰해줘\", \"PR 리뷰\", \"리팩토링\", \"어떻게 구현해?\", \"review this branch\", \"code review\".","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-code\u002FSKILL.md",[18,23,26,31],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":32,"categoryName":33,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000031","产品经理",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"clean","code","clean code","how","long","triggers","acceptance criteria","thinking","diff","use","branch","tool","code review","sse","acceptance","quality gate","pr","implement","review","MCP","2026-11-10 10:12:30",false,"---\nname: clean-code\ndescription: >-\n  Use when a diff, branch or PR needs review or a gate verdict, code needs refactoring, or a\n  requirement needs implementing cleanly. Triggers: \"코드 리뷰\", \"이 브랜치 리뷰해줘\", \"PR 리뷰\",\n  \"리팩토링\", \"어떻게 구현해?\", \"review this branch\", \"code review\".\nlicense: MIT\nmetadata:\n  version: \"2.1.0\"\nscenarios:\n  - \"quality gate: does this diff meet the acceptance criteria?\"\n  - \"refactor this function — it's too long\"\n  - \"how should I implement this requirement cleanly?\"\n  - \"이 PR 품질 게이트 통과 가능한지 봐줘\"\n  - \"이 코드 리팩토링해줘\"\n  - \"이 요구사항 어떻게 구현하면 깔끔할까?\"\ncompatibility:\n  recommended:\n    - think-tool\n  optional:\n    - sequential-thinking\n  remote_mcp_note: >-\n    think-tool이 있으면 코드 스멜 탐지와 리팩토링 우선순위 판단이 더 정확해집니다.\n    Claude 설정 → MCP Servers에서 remote SSE 엔드포인트를 추가하세요.\n---\n\n# Clean Code\n\nCode that communicates intent, minimizes surprises, and welcomes change — judged in gate\nmode, written in implement mode, against the same six dimensions.\n\n## Mode Map\n\nPick the mode from the stage you were called in and the output the caller asks for.\n\n| Mode | Chosen when | Interactive | Headless (teams \u002F harness stage) |\n|------|-------------|-------------|----------------------------------|\n| **Gate \u002F review** | stage is `gate`, `review` or `critique`; asked to judge or review a diff; or the required output asks for a verdict (`accept`, `pass`, `verified`) | Findings table + verdict, before\u002Fafter snippets for each fix | Judge only; fill the caller's verdict fields per Process G5; edit nothing; ask nothing |\n| **Implement** | stage is `implement`; asked how to build a stated requirement; or the required output asks for `changed_files` | Present the ordered steps, then write the code if asked | Follow the steps and edit the files; return what the caller asks (e.g. `changed_files`, `checks`); ask nothing |\n\n- A refactor request is implement mode with \"behaviour unchanged\" as the requirement: pin\n  current behaviour with tests (step I2), then restructure.\n- A caller's required output always overrides this skill's Output Template. When nobody\n  can answer, an open point becomes a recorded assumption, never a question.\n\n## When to Use \u002F When Not to Use\n\n| Use | Skip |\n|-----|------|\n| Quality gate or PR review of a diff | Architectural layer decisions (use clean-architecture) |\n| Refactoring legacy code | Domain modeling (use domain-driven-design) |\n| Implementing a stated requirement others will maintain | Performance optimization (profile first) |\n| Naming variables, functions, classes | Infrastructure or deployment config |\n\n## The Six Dimensions\n\nNames · Functions · Comments & formatting · Error handling · Unit tests · Smells. Patterns,\nexamples and the quick diagnostic: [references\u002Freview-framework.md](references\u002Freview-framework.md).\nSeverity rubric and worked examples of both modes: [references\u002Fmodes.md](references\u002Fmodes.md).\n\n## Process\n\n### Gate \u002F review mode\n\n1. **G1 Fix the bar.** List the acceptance items you judge against (from the caller, the\n   PR, or the request). None supplied → blocking is reserved for correctness defects; say so.\n   Interactive with no caller acceptance: look up the spec the change claims — issue refs in\n   commit messages (Closes\u002FFixes #N, ticket keys), a spec\u002Fplan path the user names, a docs\u002F\n   file matching the issue number or branch name. Read it; its items become the acceptance\n   list and its out-of-scope lines count too. None found or the ref dangles → say so in the\n   output and continue as above; never ask. Caller-supplied acceptance or headless: skip the\n   lookup, read nothing beyond the diff.\n2. **G2 Read the diff, dimension by dimension.** For each of the six dimensions, check the\n   changed lines and the code they call. Read every comment the change added: one that\n   states behaviour the code does not have is a finding. Run any check you can run (tests,\n   linters) and keep what it printed.\n3. **G3 Record findings.** One row per defect: `file:line`, dimension, severity\n   (blocking \u002F major \u002F minor — rubric in references\u002Fmodes.md), verdict `fail`, the\n   acceptance item it threatens (required when blocking), and the concrete fix. A dimension\n   checked clean gets one `pass` row with its line range. Unclear intent → a finding\n   `assumption: … — what would settle it`, blocking if an acceptance item turns on it.\n   Scope finding: a changed behaviour no spec item asks for, or one the spec puts out of\n   scope — quote the spec line; blocking if the spec explicitly excludes it, major otherwise.\n4. **G4 Verdict.** FAIL iff any blocking finding; otherwise PASS, majors and minors listed.\n   A 0–10 score is never the verdict.\n5. **G5 Map onto the caller's contract** when one is given (teams `gate`: `accept`,\n   `match_pct`, `checks`, `gaps`, `observations`, `reason`):\n   - each blocking finding → one `gaps[]` entry\n     `\"\u003Cid> \u003Cfile>:\u003Cline> — \u003Cseverity> — threatens \u003Cacceptance> — \u003Cfix>\"`;\n   - each major\u002Fminor finding → one `observations[]` entry in the same shape;\n   - `accept: false` iff any blocking finding;\n   - every other required field is still filled as the caller defines it — `match_pct`\n     (0–100, share of acceptance met), `checks` (what you ran or read → what it showed),\n     `reason`, `evidence`. Dropping the 0–10 score is not a reason to drop or zero them.\n6. **G6 Interactive only:** add before\u002Fafter snippets for each fix; give a 0–10 score only\n   if asked (rubric in references\u002Freview-framework.md).\n\n### Implement mode\n\nEach step names what it leaves in the tree. Worked example: references\u002Fmodes.md.\n\n1. **I1 Pin the requirement.** List the behaviours, the acceptance items and the error\n   cases. Ambiguity → write the assumption into the handoff. *Leaves:* case list +\n   assumptions (handoff \u002F notes).\n2. **I2 Cases first.** Derive cases with expected results (`develop:test-master` reference\n   mode) and write the test file FIRST, before any implementation file — even when no test\n   runner is available here; the test file is still the first artifact. Where a runner\n   applies, run them and watch them fail for the predicted reason\n   (`develop:test-driven-development`); otherwise leave the RED proof to the test stage.\n   *Leaves:* test file path + test names, RED output (or \"not run\").\n3. **I3 Structure.** Decide the file\u002Fmodule and the public surface — only what the\n   requirement names is exported; one responsibility per module. *Leaves:* paths + exported\n   symbols.\n4. **I4 Names.** Domain words from the requirement; predicates for booleans; named\n   constants for every literal with meaning. *Leaves:* symbol names.\n5. **I5 Function boundaries.** One thing per function, one level of abstraction, under ~20\n   lines, ≤3 parameters, no flag arguments, guard clauses for errors. *Leaves:* function list.\n6. **I6 Error handling.** Typed errors carrying context; no null returns, no empty catch,\n   no silent default; wrap third-party calls. *Leaves:* error type(s) + a test asserting each.\n7. **I7 GREEN, then tidy.** Make the tests pass; remove duplication, magic numbers and\n   \"what\" comments. *Leaves:* passing test output.\n8. **I8 Self-gate.** Run gate mode G2–G4 over your own diff; fix every blocking and major\n   finding. *Leaves:* no blocking findings.\n\nIn an implement **stage** these steps are how you do the work: edit the files, then return\nthe caller's shape (`changed_files` = files you actually changed, `checks` = test output).\nReturning the steps instead of the code is a failed stage.\n\n## Output Template\n\nUsed when no caller fixes the output shape (inside a contract, Process G5 \u002F the implement\nstage note apply instead).\n\n**Gate \u002F review**\n\n| ID | file:line | Dimension | Severity | Verdict | Threatens | Fix |\n|----|-----------|-----------|----------|---------|-----------|-----|\n| F1 | path:line | errors | blocking | fail | A2 … | … |\n| P1 | path:start-end | names | — | pass | — | — |\n\nVerdict: PASS | FAIL — `\u003Cn>` blocking (`\u003Cids>`); assumptions: `\u003Clist or none>`.\n\n**Implement**\n\n| # | Step | What to do | Leaves in tree (path \u002F symbol \u002F test) | Check |\n|---|------|------------|----------------------------------------|-------|\n| I1 | Pin requirement | … | … | every acceptance item has a case |\n\nThen: files changed, test command → output.\n\n## What Claude Does \u002F What You Do\n\n| Claude | You |\n|--------|-----|\n| **Gate, headless:** judges the diff, records findings with file:line, fills the caller's verdict fields; asks nothing | — |\n| **Gate, interactive:** same findings + verdict, before\u002Fafter snippets, a score only if asked | Share the diff and acceptance; confirm business intent behind code flagged `assumption` |\n| **Implement, headless:** follows I1–I8, edits files, returns `changed_files` + checks; asks nothing | — |\n| **Implement, interactive:** presents the steps, then writes the code and tests | State the requirement; approve the steps; merge after review |\n\n## Reference Files\n\n- [review-framework.md](references\u002Freview-framework.md) — six dimensions, quick diagnostic, optional score\n- [modes.md](references\u002Fmodes.md) — severity rubric, finding\u002Fgaps examples, implement walkthrough\n- [naming-conventions.md](references\u002Fnaming-conventions.md)\n- [functions-and-methods.md](references\u002Ffunctions-and-methods.md)\n- [comments-formatting.md](references\u002Fcomments-formatting.md)\n- [error-handling.md](references\u002Ferror-handling.md)\n- [testing-principles.md](references\u002Ftesting-principles.md)\n- [code-smells.md](references\u002Fcode-smells.md)\n\n## Related Skills\n\n- `develop:test-master` — case lists with expected results (reference mode) for step I2\n- `develop:test-driven-development` — the RED proof for step I2\n- `develop:clean-architecture` — architectural layer structure and dependency rule\n- `develop:domain-driven-design` — domain modeling and ubiquitous language\n","# Clean Code\n\nCode that communicates intent, minimizes surprises, and welcomes change — judged in gate\nmode, written in implement mode, against the same six dimensions.\n\n## Mode Map\n\nPick the mode from the stage you were called in and the output the caller asks for.\n\n| Mode | Chosen when | Interactive | Headless (teams \u002F harness stage) |\n|------|-------------|-------------|----------------------------------|\n| **Gate \u002F review** | stage is `gate`, `review` or `critique`; asked to judge or review a diff; or the required output asks for a verdict (`accept`, `pass`, `verified`) | Findings table + verdict, before\u002Fafter snippets for each fix | Judge only; fill the caller's verdict fields per Process G5; edit nothing; ask nothing |\n| **Implement** | stage is `implement`; asked how to build a stated requirement; or the required output asks for `changed_files` | Present the ordered steps, then write the code if asked | Follow the steps and edit the files; return what the caller asks (e.g. `changed_files`, `checks`); ask nothing |\n\n- A refactor request is implement mode with \"behaviour unchanged\" as the requirement: pin\n  current behaviour with tests (step I2), then restructure.\n- A caller's required output always overrides this skill's Output Template. When nobody\n  can answer, an open point becomes a recorded assumption, never a question.\n\n## When to Use \u002F When Not to Use\n\n| Use | Skip |\n|-----|------|\n| Quality gate or PR review of a diff | Architectural layer decisions (use clean-architecture) |\n| Refactoring legacy code | Domain modeling (use domain-driven-design) |\n| Implementing a stated requirement others will maintain | Performance optimization (profile first) |\n| Naming variables, functions, classes | Infrastructure or deployment config |\n\n## The Six Dimensions\n\nNames · Functions · Comments & formatting · Error handling · Unit tests · Smells. Patterns,\nexamples and the quick diagnostic: [references\u002Freview-framework.md](references\u002Freview-framework.md).\nSeverity rubric and worked examples of both modes: [references\u002Fmodes.md](references\u002Fmodes.md).\n\n## Process\n\n### Gate \u002F review mode\n\n1. **G1 Fix the bar.** List the acceptance items you judge against (from the caller, the\n   PR, or the request). None supplied → blocking is reserved for correctness defects; say so.\n   Interactive with no caller acceptance: look up the spec the change claims — issue refs in\n   commit messages (Closes\u002FFixes #N, ticket keys), a spec\u002Fplan path the user names, a docs\u002F\n   file matching the issue number or branch name. Read it; its items become the acceptance\n   list and its out-of-scope lines count too. None found or the ref dangles → say so in the\n   output and continue as above; never ask. Caller-supplied acceptance or headless: skip the\n   lookup, read nothing beyond the diff.\n2. **G2 Read the diff, dimension by dimension.** For each of the six dimensions, check the\n   changed lines and the code they call. Read every comment the change added: one that\n   states behaviour the code does not have is a finding. Run any check you can run (tests,\n   linters) and keep what it printed.\n3. **G3 Record findings.** One row per defect: `file:line`, dimension, severity\n   (blocking \u002F major \u002F minor — rubric in references\u002Fmodes.md), verdict `fail`, the\n   acceptance item it threatens (required when blocking), and the concrete fix. A dimension\n   checked clean gets one `pass` row with its line range. Unclear intent → a finding\n   `assumption: … — what would settle it`, blocking if an acceptance item turns on it.\n   Scope finding: a changed behaviour no spec item asks for, or one the spec puts out of\n   scope — quote the spec line; blocking if the spec explicitly excludes it, major otherwise.\n4. **G4 Verdict.** FAIL iff any blocking finding; otherwise PASS, majors and minors listed.\n   A 0–10 score is never the verdict.\n5. **G5 Map onto the caller's contract** when one is given (teams `gate`: `accept`,\n   `match_pct`, `checks`, `gaps`, `observations`, `reason`):\n   - each blocking finding → one `gaps[]` entry\n     `\"\u003Cid> \u003Cfile>:\u003Cline> — \u003Cseverity> — threatens \u003Cacceptance> — \u003Cfix>\"`;\n   - each major\u002Fminor finding → one `observations[]` entry in the same shape;\n   - `accept: false` iff any blocking finding;\n   - every other required field is still filled as the caller defines it — `match_pct`\n     (0–100, share of acceptance met), `checks` (what you ran or read → what it showed),\n     `reason`, `evidence`. Dropping the 0–10 score is not a reason to drop or zero them.\n6. **G6 Interactive only:** add before\u002Fafter snippets for each fix; give a 0–10 score only\n   if asked (rubric in references\u002Freview-framework.md).\n\n### Implement mode\n\nEach step names what it leaves in the tree. Worked example: references\u002Fmodes.md.\n\n1. **I1 Pin the requirement.** List the behaviours, the acceptance items and the error\n   cases. Ambiguity → write the assumption into the handoff. *Leaves:* case list +\n   assumptions (handoff \u002F notes).\n2. **I2 Cases first.** Derive cases with expected results (`develop:test-master` reference\n   mode) and write the test file FIRST, before any implementation file — even when no test\n   runner is available here; the test file is still the first artifact. Where a runner\n   applies, run them and watch them fail for the predicted reason\n   (`develop:test-driven-development`); otherwise leave the RED proof to the test stage.\n   *Leaves:* test file path + test names, RED output (or \"not run\").\n3. **I3 Structure.** Decide the file\u002Fmodule and the public surface — only what the\n   requirement names is exported; one responsibility per module. *Leaves:* paths + exported\n   symbols.\n4. **I4 Names.** Domain words from the requirement; predicates for booleans; named\n   constants for every literal with meaning. *Leaves:* symbol names.\n5. **I5 Function boundaries.** One thing per function, one level of abstraction, under ~20\n   lines, ≤3 parameters, no flag arguments, guard clauses for errors. *Leaves:* function list.\n6. **I6 Error handling.** Typed errors carrying context; no null returns, no empty catch,\n   no silent default; wrap third-party calls. *Leaves:* error type(s) + a test asserting each.\n7. **I7 GREEN, then tidy.** Make the tests pass; remove duplication, magic numbers and\n   \"what\" comments. *Leaves:* passing test output.\n8. **I8 Self-gate.** Run gate mode G2–G4 over your own diff; fix every blocking and major\n   finding. *Leaves:* no blocking findings.\n\nIn an implement **stage** these steps are how you do the work: edit the files, then return\nthe caller's shape (`changed_files` = files you actually changed, `checks` = test output).\nReturning the steps instead of the code is a failed stage.\n\n## Output Template\n\nUsed when no caller fixes the output shape (inside a contract, Process G5 \u002F the implement\nstage note apply instead).\n\n**Gate \u002F review**\n\n| ID | file:line | Dimension | Severity | Verdict | Threatens | Fix |\n|----|-----------|-----------|----------|---------|-----------|-----|\n| F1 | path:line | errors | blocking | fail | A2 … | … |\n| P1 | path:start-end | names | — | pass | — | — |\n\nVerdict: PASS | FAIL — `\u003Cn>` blocking (`\u003Cids>`); assumptions: `\u003Clist or none>`.\n\n**Implement**\n\n| # | Step | What to do | Leaves in tree (path \u002F symbol \u002F test) | Check |\n|---|------|------------|----------------------------------------|-------|\n| I1 | Pin requirement | … | … | every acceptance item has a case |\n\nThen: files changed, test command → output.\n\n## What Claude Does \u002F What You Do\n\n| Claude | You |\n|--------|-----|\n| **Gate, headless:** judges the diff, records findings with file:line, fills the caller's verdict fields; asks nothing | — |\n| **Gate, interactive:** same findings + verdict, before\u002Fafter snippets, a score only if asked | Share the diff and acceptance; confirm business intent behind code flagged `assumption` |\n| **Implement, headless:** follows I1–I8, edits files, returns `changed_files` + checks; asks nothing | — |\n| **Implement, interactive:** presents the steps, then writes the code and tests | State the requirement; approve the steps; merge after review |\n\n## Reference Files\n\n- [review-framework.md](references\u002Freview-framework.md) — six dimensions, quick diagnostic, optional score\n- [modes.md](references\u002Fmodes.md) — severity rubric, finding\u002Fgaps examples, implement walkthrough\n- [naming-conventions.md](references\u002Fnaming-conventions.md)\n- [functions-and-methods.md](references\u002Ffunctions-and-methods.md)\n- [comments-formatting.md](references\u002Fcomments-formatting.md)\n- [error-handling.md](references\u002Ferror-handling.md)\n- [testing-principles.md](references\u002Ftesting-principles.md)\n- [code-smells.md](references\u002Fcode-smells.md)\n\n## Related Skills\n\n- `develop:test-master` — case lists with expected results (reference mode) for step I2\n- `develop:test-driven-development` — the RED proof for step I2\n- `develop:clean-architecture` — architectural layer structure and dependency rule\n- `develop:domain-driven-design` — domain modeling and ubiquitous language\n",{"name":5,"license":15,"metadata":60,"scenarios":62,"description":7,"compatibility":69},{"version":61},"2.1.0",[63,64,65,66,67,68],"quality gate: does this diff meet the acceptance criteria?","refactor this function — it's too long","how should I implement this requirement cleanly?","이 PR 품질 게이트 통과 가능한지 봐줘","이 코드 리팩토링해줘","이 요구사항 어떻게 구현하면 깔끔할까?",{"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\u002Fclean-code",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":84,"prompt":94,"zipAvailable":95},[85,88,91],{"tool":86,"command":87},"npx","npx skills add newkayak12\u002Fclaude-skills --skill clean-code",{"tool":89,"command":90},"bunx","bunx skills add newkayak12\u002Fclaude-skills --skill clean-code",{"tool":92,"command":93},"pnpm","pnpm dlx skills add newkayak12\u002Fclaude-skills --skill clean-code","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fclean-code\u002FSKILL.md",true,[97,103,107,111,115,119,123,127],{"path":98,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Fcode-smells.md","REFERENCE","参考文档",3634,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fclean-code\u002Freferences\u002Fcode-smells.md",{"path":104,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":105,"sourceHtmlUrl":106},"references\u002Fcomments-formatting.md",3067,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fclean-code\u002Freferences\u002Fcomments-formatting.md",{"path":108,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":109,"sourceHtmlUrl":110},"references\u002Ferror-handling.md",3723,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fclean-code\u002Freferences\u002Ferror-handling.md",{"path":112,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":113,"sourceHtmlUrl":114},"references\u002Ffunctions-and-methods.md",3431,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fclean-code\u002Freferences\u002Ffunctions-and-methods.md",{"path":116,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":117,"sourceHtmlUrl":118},"references\u002Fmodes.md",5825,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fclean-code\u002Freferences\u002Fmodes.md",{"path":120,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":121,"sourceHtmlUrl":122},"references\u002Fnaming-conventions.md",2944,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fclean-code\u002Freferences\u002Fnaming-conventions.md",{"path":124,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":125,"sourceHtmlUrl":126},"references\u002Freview-framework.md",4329,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fclean-code\u002Freferences\u002Freview-framework.md",{"path":128,"resourceType":99,"resourceTypeDesc":100,"sizeBytes":129,"sourceHtmlUrl":130},"references\u002Ftesting-principles.md",3659,"https:\u002F\u002Fgithub.com\u002Fnewkayak12\u002Fclaude-skills\u002Fblob\u002Fmain\u002Fdevelop\u002Fskills\u002Fclean-code\u002Freferences\u002Ftesting-principles.md",[132,155,180,202,228,245],{"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":55},"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,140,141,142,143,144,145,146,46,147,44,148,149,150,151,40,152,153,154],"web","architecture","mermaid","browser","cache","redis","api","b-tree","page","er","postgres","query","layout","as","chart","SVG",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":165,"publishedAt":55},"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",[161,164],{"categoryNo":162,"categoryName":163,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[166,167,168,169,54,170,171,172,173,48,174,175,46,176,177,44,178,42,179,40],"test","master","test master","testing","writing","unit tests","development","qa","test plan","plan","analyze","coverage","only","tests",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":187,"publishedAt":55},"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",[186],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[188,189,190,54,191,192,46,193,44,194,195,196,197,198,199,42,200,201,179,40],"sre","engineer","sre engineer","observability","SET","fix","reliability","slo","sli","burn-rate","alert","up","call","define",{"skillNo":203,"name":204,"nameZh":6,"description":205,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":206,"categories":207,"keywords":215,"publishedAt":55},"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",[208,211,212],{"categoryNo":209,"categoryName":210,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":213,"categoryName":214,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000033","数据分析师",[216,217,218,54,170,219,220,36,221,48,46,222,223,224,44,225,189,226,150,227],"sql","sql pro","design","oracle","boot","database","explain","spring","strategy","schema","functions","optimizer",{"skillNo":229,"name":230,"nameZh":6,"description":231,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":232,"categories":233,"keywords":237,"publishedAt":55},"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",[234,235,236],{"categoryNo":209,"categoryName":210,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},[220,238,223,189,239,54,140,36,240,221,241,145,242,46,243,44,150,244,227,40],"spring boot","spring boot engineer","authentication","java","configure","kotlin","caching",{"skillNo":246,"name":247,"nameZh":6,"description":248,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":249,"categories":250,"keywords":252,"publishedAt":55},"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",[251],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[253,254,172,255,256,54,52,257,49,258,48,46,259,44,260,261,42,41,262,40],"spec","spec driven development","spec driven","driven","tasks","first","write","think","do","feature"]