[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DXWCW8GVQ4S21F533MH466":3,"skill-same:01M6DXWCW8GVQ4S21F533MH466":70},{"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":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":56,"install":57,"resources":69},"01M6DXWCW8GVQ4S21F533MH466","code-quality-lens",null,"Code quality review lens for evaluating design principles, error handling, complexity, testability, and maintainability. Used by review orchestrators — not invoked directly.","atomicinnovation\u002Faccelerator","atomicinnovation","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F65866524?v=4","01M6DXP513JV585FN2QPNR6079","Atomic","01M6DXP55MPK99YVZ2HGMEN991",34,"MIT","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Fcode-quality-lens\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"code quality","code","quality","lens","code quality lens","maintainability","code quality review","for","true","principles","error","testability","false","design","quality review","design principles","complexity","error handling","review","2026-11-10 10:12:30",false,"---\nname: code-quality-lens\ndescription: Code quality review lens for evaluating design principles, error\n  handling, complexity, testability, and maintainability. Used by review\n  orchestrators — not invoked directly.\nuser-invocable: false\ndisable-model-invocation: true\n---\n\n# Code Quality Lens\n\nReview as the next developer who will maintain this code in six months.\n\n## Core Responsibilities\n\n1. **Evaluate Code Complexity, Readability, and Design Principles**\n\n- Assess cyclomatic and cognitive complexity\n- Check for deep nesting, long methods or functions\n- Verify meaningful naming and self-documenting code\n- Evaluate use of guard clauses over nesting\n- Check SOLID principles adherence\n- Evaluate DRY, KISS, and YAGNI adherence\n- Assess design pattern fitness — right pattern for the problem, not\n  over-engineered\n- Check functional purity where applicable (immutability, pure functions,\n  composition, effect management)\n- Evaluate composition over inheritance\n\n2. **Assess Testability and Maintainability**\n\n- Evaluate whether components are designed for testability (dependency\n  injection, interface abstractions)\n- Assess whether designs support independent component testing\n- Check that complexity is proportional to requirements\n- Verify the design considers long-term maintainability\n- Will the next developer understand this code in six months?\n\nNote: Testability as a *code design property* is assessed here. The specific\ntesting strategy and coverage (test pyramid, edge cases, mock strategy) is\nassessed by the test-coverage lens.\n\n3. **Review Error Handling, Observability, and Code Smells**\n\n- Check appropriate error categorisation and propagation strategy (recoverable\n  vs fatal, user-facing vs internal)\n- Verify no swallowed exceptions\n- Identify specific error types vs generic catch-alls\n- Evaluate structured logging provisions with appropriate levels\n- Assess metrics collection and correlation\u002Ftracing for async flows\n- Identify code smells: god objects, feature envy, primitive obsession, flag\n  arguments, data clumps, dead code\n\n## Key Evaluation Questions\n\n**Readability and complexity** (always applicable):\n- **Complexity**: If this function's requirements changed, how many places\n  would need to change? (Watch for: cyclomatic complexity > 10, nesting\n  depth > 3, functions > 50 lines, cognitive complexity that forces\n  re-reading.)\n- **Readability**: Will the next developer understand this code in six months\n  without the original author's context? (Watch for: unclear naming, missing\n  guard clauses, large unfocused units, hidden side effects.)\n- **Code smells**: If I removed this code, what would break — and if the\n  answer is \"nothing\", why is it here? (Watch for: god objects, feature envy,\n  primitive obsession, flag arguments, data clumps, dead code.)\n\n**Design principles** (when the change introduces new classes, interfaces, or\nabstractions):\n- **Design principles**: If this class or module took on one more\n  responsibility, where would it go — and would that feel natural or forced?\n  (Watch for: SRP violations, rigid hierarchies, missing dependency inversion,\n  interface pollution.)\n\n**Error handling and observability** (when the change includes error paths,\ncatch blocks, or logging statements):\n- **Error handling**: If this error occurred in production at 3am, would the\n  error message and stack trace lead you to the root cause? (Watch for:\n  swallowed exceptions, generic messages, missing context, unlogged error\n  paths.)\n- **Observability**: If this code misbehaved in production, would you be able\n  to diagnose the issue from logs and traces alone? (Watch for: missing\n  structured logging, absent correlation IDs, no metrics for key operations.)\n\n**Testability** (always applicable):\n- **Testability**: Can this component be tested in isolation without standing\n  up the entire system? (Watch for: hard-coded dependencies, missing injection\n  points, tightly coupled collaborators.)\n\n## Important Guidelines\n\n- **Explore the codebase** for existing quality patterns and conventions\n- **Be pragmatic** — focus on issues that will cause real maintenance pain,\n  not style nitpicks\n- **Rate confidence** on each finding — distinguish definite issues from\n  potential concerns\n- **Evaluate proportionally** — a simple utility doesn't need the same rigour\n  as a core domain component\n- **Consider readability** — will the next developer understand this code in\n  six months?\n- **Check testability early** — designs that are hard to test are usually hard\n  to maintain\n\n## What NOT to Do\n\n- Don't review architecture, security, performance, standards, test\n  coverage, usability, documentation, database, correctness, compatibility,\n  portability, or safety — those are other lenses\n- Don't assess algorithmic efficiency, caching strategy, or concurrency\n  efficiency — that is the performance lens\n- Don't assess logical correctness (invariant preservation, boundary\n  conditions, state validity) — that is the correctness lens. This lens\n  focuses on *maintainability* — readability, design principles, error\n  handling patterns\n- Don't nitpick style preferences that don't affect maintainability\n- Don't insist on patterns or principles where simplicity serves better\n- Don't penalise pragmatic shortcuts that are explicitly acknowledged\n- Don't recommend adding complexity in the name of \"best practices\"\n- Don't assess the testing strategy (test pyramid, edge cases, mock strategy)\n  — that is the test coverage lens\n\nRemember: You're evaluating whether the code is a pleasure to maintain —\nreadable, testable, and simply designed. The best code quality is the simplest\ndesign that meets the requirements and can evolve gracefully.\n","# Code Quality Lens\n\nReview as the next developer who will maintain this code in six months.\n\n## Core Responsibilities\n\n1. **Evaluate Code Complexity, Readability, and Design Principles**\n\n- Assess cyclomatic and cognitive complexity\n- Check for deep nesting, long methods or functions\n- Verify meaningful naming and self-documenting code\n- Evaluate use of guard clauses over nesting\n- Check SOLID principles adherence\n- Evaluate DRY, KISS, and YAGNI adherence\n- Assess design pattern fitness — right pattern for the problem, not\n  over-engineered\n- Check functional purity where applicable (immutability, pure functions,\n  composition, effect management)\n- Evaluate composition over inheritance\n\n2. **Assess Testability and Maintainability**\n\n- Evaluate whether components are designed for testability (dependency\n  injection, interface abstractions)\n- Assess whether designs support independent component testing\n- Check that complexity is proportional to requirements\n- Verify the design considers long-term maintainability\n- Will the next developer understand this code in six months?\n\nNote: Testability as a *code design property* is assessed here. The specific\ntesting strategy and coverage (test pyramid, edge cases, mock strategy) is\nassessed by the test-coverage lens.\n\n3. **Review Error Handling, Observability, and Code Smells**\n\n- Check appropriate error categorisation and propagation strategy (recoverable\n  vs fatal, user-facing vs internal)\n- Verify no swallowed exceptions\n- Identify specific error types vs generic catch-alls\n- Evaluate structured logging provisions with appropriate levels\n- Assess metrics collection and correlation\u002Ftracing for async flows\n- Identify code smells: god objects, feature envy, primitive obsession, flag\n  arguments, data clumps, dead code\n\n## Key Evaluation Questions\n\n**Readability and complexity** (always applicable):\n- **Complexity**: If this function's requirements changed, how many places\n  would need to change? (Watch for: cyclomatic complexity > 10, nesting\n  depth > 3, functions > 50 lines, cognitive complexity that forces\n  re-reading.)\n- **Readability**: Will the next developer understand this code in six months\n  without the original author's context? (Watch for: unclear naming, missing\n  guard clauses, large unfocused units, hidden side effects.)\n- **Code smells**: If I removed this code, what would break — and if the\n  answer is \"nothing\", why is it here? (Watch for: god objects, feature envy,\n  primitive obsession, flag arguments, data clumps, dead code.)\n\n**Design principles** (when the change introduces new classes, interfaces, or\nabstractions):\n- **Design principles**: If this class or module took on one more\n  responsibility, where would it go — and would that feel natural or forced?\n  (Watch for: SRP violations, rigid hierarchies, missing dependency inversion,\n  interface pollution.)\n\n**Error handling and observability** (when the change includes error paths,\ncatch blocks, or logging statements):\n- **Error handling**: If this error occurred in production at 3am, would the\n  error message and stack trace lead you to the root cause? (Watch for:\n  swallowed exceptions, generic messages, missing context, unlogged error\n  paths.)\n- **Observability**: If this code misbehaved in production, would you be able\n  to diagnose the issue from logs and traces alone? (Watch for: missing\n  structured logging, absent correlation IDs, no metrics for key operations.)\n\n**Testability** (always applicable):\n- **Testability**: Can this component be tested in isolation without standing\n  up the entire system? (Watch for: hard-coded dependencies, missing injection\n  points, tightly coupled collaborators.)\n\n## Important Guidelines\n\n- **Explore the codebase** for existing quality patterns and conventions\n- **Be pragmatic** — focus on issues that will cause real maintenance pain,\n  not style nitpicks\n- **Rate confidence** on each finding — distinguish definite issues from\n  potential concerns\n- **Evaluate proportionally** — a simple utility doesn't need the same rigour\n  as a core domain component\n- **Consider readability** — will the next developer understand this code in\n  six months?\n- **Check testability early** — designs that are hard to test are usually hard\n  to maintain\n\n## What NOT to Do\n\n- Don't review architecture, security, performance, standards, test\n  coverage, usability, documentation, database, correctness, compatibility,\n  portability, or safety — those are other lenses\n- Don't assess algorithmic efficiency, caching strategy, or concurrency\n  efficiency — that is the performance lens\n- Don't assess logical correctness (invariant preservation, boundary\n  conditions, state validity) — that is the correctness lens. This lens\n  focuses on *maintainability* — readability, design principles, error\n  handling patterns\n- Don't nitpick style preferences that don't affect maintainability\n- Don't insist on patterns or principles where simplicity serves better\n- Don't penalise pragmatic shortcuts that are explicitly acknowledged\n- Don't recommend adding complexity in the name of \"best practices\"\n- Don't assess the testing strategy (test pyramid, edge cases, mock strategy)\n  — that is the test coverage lens\n\nRemember: You're evaluating whether the code is a pleasure to maintain —\nreadable, testable, and simply designed. The best code quality is the simplest\ndesign that meets the requirements and can evolve gracefully.\n",{"name":5,"description":7,"user-invocable":44,"disable-model-invocation":48},true,"main","007b2dd695b63c2f097cdc40e54229b6e8b4596a","skills\u002Freview\u002Flenses\u002Fcode-quality-lens",3,"https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator","https:\u002F\u002Fgo-atomic.io","https:\u002F\u002Fgithub.com\u002Fatomicinnovation","2026-11-15 03:43:02",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":48},[59,62,65],{"tool":60,"command":61},"npx","npx skills add atomicinnovation\u002Faccelerator --skill code-quality-lens",{"tool":63,"command":64},"bunx","bunx skills add atomicinnovation\u002Faccelerator --skill code-quality-lens",{"tool":66,"command":67},"pnpm","pnpm dlx skills add atomicinnovation\u002Faccelerator --skill code-quality-lens","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Freview\u002Flenses\u002Fcode-quality-lens\u002FSKILL.md",[],[71,103,128,150,165,190],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":85,"publishedAt":43},"01M70S7PFGVATJREBFEGPJB718","explore-pr","Build an interactive, design-first and picture-first exploration page for a pull request — its architecture, abstractions and design decisions drawn as diagrams, a guided tour in reading order with code as the evidence, an attention map of where the risk sits, a ledger of its riskiest operations, prior review findings re-checked against the code, and simulations specific to the PR — with the reviewer's verdicts and notes saved. Use when the user wants to explore, understand or review a large pull request or its design, asks for a review page, walkthrough or visual explanation of a PR, or is struggling to review a big change.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fexplore-pr\u002FSKILL.md",[77,82],{"categoryNo":78,"categoryName":79,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":83,"categoryName":84,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000032","设计师",[86,87,88,89,90,91,92,93,37,94,95,96,97,98,25,99,100,42,101,102],"explore pr","explore","pr","diagrams","exploration","re","review findings","walkthrough","map","when","number","URL","Bash","architecture","reviewer","notes","change",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":43},"01M6DY04WBTMFV96JMBP5ZXVFX","update-work-item","Update fields (status, priority, tags, parent, etc.) of an existing work item. Use to transition status, change priority, manage tags, or edit any frontmatter field. No transition enforcement — arbitrary changes are allowed.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fupdate-work-item\u002FSKILL.md",[],[110,111,112,113,114,115,116,98,102,117,118,119,120,121,122,123,124,125,126,127],"work","update","update work item","work item","enforcement","manage","use","config","edit","validate","status","transition","frontmatter","Existing","tags","changes","fields","op",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":43},"01M6DY0106CF15CYEJHZM14GBZ","sync-work-items","Reconcile local work items in meta\u002Fwork\u002F with the active remote tracker named by work.integration. Use when the user wants to sync, push, or pull work items to or from Jira or Linear, preview what a sync would change, or reconcile divergent local and remote state.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fsync-work-items\u002FSKILL.md",[],[110,135,136,137,138,139,140,98,141,102,142,143,144,145,146,147,148,117,149,122,95],"sync","sync work items","promote","Meta","local","only","preview","active","tracker","max","jira","remote","create","adopt","reconcile",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":156,"publishedAt":43},"01M6HNF86984S4XK21Q26VZA21","sync-work-items-recovery","Recovery procedures for work sync failures that need a person — terminal rows, refused pending pushes and refused orders. Read by sync-work-items — not invoked directly.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fsync-work-items-recovery\u002FSKILL.md",[],[157,110,158,135,136,159,31,160,161,162,32,36,163,164],"sync work items recovery","recovery","work-items","terminal","read","person","orders","pending",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":174,"publishedAt":43},"01M6DXZWH7PR72VCEXSSD4XNK4","stress-test-work-item","Interactively stress-test a work item by grilling the user on scope, assumptions, acceptance criteria, edge cases, and dependencies to surface issues, gaps, and flawed assumptions before implementation is planned.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Fstress-test-work-item\u002FSKILL.md",[171],{"categoryNo":172,"categoryName":173,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000008","测试与质量",[175,176,110,177,113,178,179,180,181,182,183,98,184,185,117,119,186,187,188,96,189,122],"stress test","test","stress test work item","stress","scope","issues","edge","stress-test","acceptance","acceptance criteria","dependencies","implementation","grilling","user","gaps",{"skillNo":191,"name":192,"nameZh":6,"description":193,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":194,"categories":195,"keywords":196,"publishedAt":43},"01M6DXZRQWHTWV1G9PTTHCGGYA","review-work-item","Review a work item through multiple quality lenses and collaboratively iterate based on findings. Use when the user wants to evaluate a work item before implementation or escalation.","https:\u002F\u002Fgithub.com\u002Fatomicinnovation\u002Faccelerator\u002Fblob\u002Fmain\u002Fskills\u002Fwork\u002Freview-work-item\u002FSKILL.md",[],[42,110,197,113,198,199,116,98,200,26,117,119,186,188,201,95,202,203,122,204],"review work item","review work","escalation","file","metadata","iterate","evaluate","path"]