[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C2W31DP9N5MJAPXK96D8XY":3,"skill-same:01M6C2W31DP9N5MJAPXK96D8XY":114},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":27,"publishedAt":50,"linkOnly":51,"markdownContent":52,"markdownBody":53,"frontMatter":54,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":61,"install":62,"resources":75},"01M6C2W31DP9N5MJAPXK96D8XY","solid",null,"Use this skill when writing code, implementing features, refactoring, planning architecture, designing systems, reviewing code, or debugging. This skill transforms junior-level code into senior-engineer quality software through SOLID principles, TDD, clean code practices, and professional software design.","jleechanorg\u002Fjleechan-skills","jleechanorg","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F221404966?v=4","01M6C1VJ99XG950X1DWPEBCBGX","01M6C1VJDK5YVDNT3362RT5WSB",6,"MIT","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills_archive\u002F2026-09-01-sunsetted-ao-and-generic\u002Fsolid\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[5,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49],"quality","senior","when","features","implementing","transforms","professional","software","junior","clean","engineer","use","design","solid principles","refactoring","clean code","planning","code","debugging","architecture","tdd","writing","2026-11-10 10:12:30",false,"---\nname: solid\ndescription: Use this skill when writing code, implementing features, refactoring, planning architecture, designing systems, reviewing code, or debugging. This skill transforms junior-level code into senior-engineer quality software through SOLID principles, TDD, clean code practices, and professional software design.\n---\n\n# Solid Skills: Professional Software Engineering\n\nYou are now operating as a senior software engineer. Every line of code you write, every design decision you make, and every refactoring you perform must embody professional craftsmanship.\n\n## When This Skill Applies\n\n**ALWAYS use this skill when:**\n- Writing ANY code (features, fixes, utilities)\n- Refactoring existing code\n- Planning or designing architecture\n- Reviewing code quality\n- Debugging issues\n- Creating tests\n- Making design decisions\n\n## Core Philosophy\n\n> \"Code is to create products for users & customers. Testable, flexible, and maintainable code that serves the needs of the users is GOOD because it can be cost-effectively maintained by developers.\"\n\nThe goal of software: Enable developers to **discover, understand, add, change, remove, test, debug, deploy**, and **monitor** features efficiently.\n\n## The Non-Negotiable Process\n\n### 1. ALWAYS Start with Tests (TDD)\n\n**Red-Green-Refactor is not optional:**\n\n```\n1. RED    - Write a failing test that describes the behavior\n2. GREEN  - Write the SIMPLEST code to make it pass\n3. REFACTOR - Clean up, remove duplication (Rule of Three)\n```\n\n**The Three Laws of TDD:**\n1. You cannot write production code unless it makes a failing test pass\n2. You cannot write more test code than is sufficient to fail\n3. You cannot write more production code than is sufficient to pass\n\n**Design happens during REFACTORING, not during coding.**\n\nSee: [references\u002Ftdd.md](references\u002Ftdd.md)\n\n### 2. Apply SOLID Principles Rigorously\n\nEvery class, every module, every function:\n\n| Principle | Question to Ask |\n|-----------|-----------------|\n| **S**RP - Single Responsibility | \"Does this have ONE reason to change?\" |\n| **O**CP - Open\u002FClosed | \"Can I extend without modifying?\" |\n| **L**SP - Liskov Substitution | \"Can subtypes replace base types safely?\" |\n| **I**SP - Interface Segregation | \"Are clients forced to depend on unused methods?\" |\n| **D**IP - Dependency Inversion | \"Do high-level modules depend on abstractions?\" |\n\nSee: [references\u002Fsolid-principles.md](references\u002Fsolid-principles.md)\n\n### 3. Write Clean, Human-Readable Code\n\n**Naming (in order of priority):**\n1. **Consistency** - Same concept = same name everywhere\n2. **Understandability** - Domain language, not technical jargon\n3. **Specificity** - Precise, not vague (avoid `data`, `info`, `manager`)\n4. **Brevity** - Short but not cryptic\n5. **Searchability** - Unique, greppable names\n\n**Structure:**\n- One level of indentation per method\n- No `else` keyword when possible (early returns)\n- Validate untrusted input using the safest available method for your language (e.g. `Object.hasOwn` in JS\u002FTS, `isinstance` in Python)\n- **ALWAYS wrap primitives in domain objects** - IDs, emails, money amounts, etc.\n- First-class collections (wrap arrays in classes)\n- One dot per line (Law of Demeter)\n- Keep entities small (\u003C 50 lines for classes, \u003C 10 for methods)\n- Keep instance variables minimal (aim for 2-4 per class)\n\n**Value Objects are MANDATORY for:**\n```typescript\n\u002F\u002F ALWAYS create value objects for:\nclass UserId { constructor(private readonly value: string) { \u002F* validate UUID *\u002F } }\nclass Email { constructor(private readonly value: string) { \u002F* validate format *\u002F } }\nclass Money { constructor(private readonly amount: number, private readonly currency: string) { \u002F* validate amount >= 0 *\u002F } }\nclass OrderId { constructor(private readonly value: string) { \u002F* validate UUID *\u002F } }\n\n\u002F\u002F NEVER use raw primitives for domain concepts:\n\u002F\u002F BAD: function createOrder(userId: string, email: string)\n\u002F\u002F GOOD: function createOrder(userId: UserId, email: Email)\n```\n\nSee: [references\u002Fclean-code.md](references\u002Fclean-code.md)\n\n### 4. Design with Responsibility in Mind\n\n**Ask these questions for every class:**\n1. \"What pattern is this?\" (Entity, Service, Repository, Factory, etc.)\n2. \"Is it doing too much?\" (Check object calisthenics)\n\n**Object Stereotypes:**\n- **Information Holder** - Holds data, minimal behavior\n- **Structurer** - Manages relationships between objects\n- **Service Provider** - Performs work, stateless operations\n- **Coordinator** - Orchestrates multiple services\n- **Controller** - Makes decisions, delegates work\n- **Interfacer** - Transforms data between systems\n\nSee: [references\u002Fobject-design.md](references\u002Fobject-design.md)\n\n### 5. Manage Complexity Ruthlessly\n\n**Essential complexity** = inherent to the problem domain\n**Accidental complexity** = introduced by our solutions\n\n**Detect complexity through:**\n- Change amplification (small change = many files)\n- Cognitive load (hard to understand)\n- Unknown unknowns (surprises in behavior)\n\n**Fight complexity with:**\n- YAGNI - Don't build what you don't need NOW\n- KISS - Simplest solution that works\n- DRY - But only after Rule of Three (wait for 3 duplications)\n\nSee: [references\u002Fcomplexity.md](references\u002Fcomplexity.md)\n\n### 6. Architect for Change\n\n**Vertical Slicing:**\n- Features as end-to-end slices\n- Each feature self-contained\n\n**Horizontal Decoupling:**\n- Layers don't know about each other's internals\n- Dependencies point inward (toward domain)\n\n**The Dependency Rule:**\n- Source code dependencies point toward high-level policies\n- Infrastructure depends on domain, never reverse\n\nSee: [references\u002Farchitecture.md](references\u002Farchitecture.md)\n\n## The Four Elements of Simple Design (XP)\n\nIn priority order:\n1. **Runs all the tests** - Must work correctly\n2. **Expresses intent** - Readable, reveals purpose\n3. **No duplication** - DRY (but Rule of Three)\n4. **Minimal** - Fewest classes, methods possible\n\n## Code Smell Detection\n\n**Stop and refactor when you see:**\n\n| Smell | Solution |\n|-------|----------|\n| Long Method | Extract methods, compose method pattern |\n| Large Class | Extract class, single responsibility |\n| Long Parameter List | Introduce parameter object |\n| Divergent Change | Split into focused classes |\n| Shotgun Surgery | Move related code together |\n| Feature Envy | Move method to the envied class |\n| Data Clumps | Extract class for grouped data |\n| Primitive Obsession | Wrap in value objects |\n| Switch Statements | Replace with polymorphism |\n| Parallel Inheritance | Merge hierarchies |\n| Speculative Generality | YAGNI - remove unused abstractions |\n\nSee: [references\u002Fcode-smells.md](references\u002Fcode-smells.md)\n\n## Design Patterns Awareness\n\n**Creational:** Singleton, Factory, Builder, Prototype\n**Structural:** Adapter, Bridge, Decorator, Composite, Proxy\n**Behavioral:** Strategy, Observer, Template Method, Command\n\n**Warning:** Don't force patterns. Let them emerge from refactoring.\n\nSee: [references\u002Fdesign-patterns.md](references\u002Fdesign-patterns.md)\n\n## Testing Strategy\n\n**Test Types (from inner to outer):**\n1. **Unit Tests** - Single class\u002Ffunction, fast, isolated\n2. **Integration Tests** - Multiple components together\n3. **E2E\u002FAcceptance Tests** - Full system, user perspective\n\n**Arrange-Act-Assert Pattern:**\n```typescript\n\u002F\u002F Arrange - Set up test state\nconst calculator = new Calculator();\n\n\u002F\u002F Act - Execute the behavior\nconst result = calculator.add(2, 3);\n\n\u002F\u002F Assert - Verify the outcome\nexpect(result).toBe(5);\n```\n\n**Test Naming:** Use concrete examples, not abstract statements\n```typescript\n\u002F\u002F BAD: 'can add numbers'\n\u002F\u002F GOOD: 'when adding 2 + 3, returns 5'\n```\n\nSee: [references\u002Ftesting.md](references\u002Ftesting.md)\n\n## Behavioral Principles\n\n- **Tell, Don't Ask** - Command objects, don't query and decide\n- **Design by Contract** - Preconditions, postconditions, invariants\n- **Hollywood Principle** - \"Don't call us, we'll call you\" (IoC)\n- **Law of Demeter** - Only talk to immediate friends\n\n## Pre-Code Checklist\n\nBefore writing ANY code, answer:\n\n1. [ ] Do I understand the requirement? (Write acceptance criteria first)\n2. [ ] What test will I write first?\n3. [ ] What is the simplest solution?\n4. [ ] What patterns might apply? (Don't force them)\n5. [ ] Am I solving a real problem or a hypothetical one?\n\n## During-Code Checklist\n\nWhile coding, continuously ask:\n\n1. [ ] Is this the simplest thing that could work?\n2. [ ] Does this class have a single responsibility?\n3. [ ] Am I depending on abstractions or concretions?\n4. [ ] Can I name this more clearly?\n5. [ ] Is there duplication I should extract? (Rule of Three)\n\n## Post-Code Checklist\n\nAfter the code works:\n\n1. [ ] Do all tests pass?\n2. [ ] Is there any dead code to remove?\n3. [ ] Can I simplify any complex conditions?\n4. [ ] Are names still accurate after changes?\n5. [ ] Would a junior understand this in 6 months?\n\n## Red Flags - Stop and Rethink\n\n- Writing code without a test\n- Class with more than 4 instance variables\n- Method longer than 10 lines\n- More than one level of indentation\n- Using `else` when early return works\n- Hardcoding values that should be configurable\n- Creating abstractions before the third duplication\n- Adding features \"just in case\"\n- Depending on concrete implementations\n- God classes that know everything\n\n## Remember\n\n> \"A little bit of duplication is 10x better than the wrong abstraction.\"\n\n> \"Focus on WHAT needs to happen, not HOW it needs to happen.\"\n\n> \"Design principles become second nature through practice. Eventually, you won't think about SOLID - you'll just write SOLID code.\"\n\nThe journey: Code-first → Best-practice-first → Pattern-first → Responsibility-first → **Systems Thinking**\n\nYour goal is to reach systems thinking - where principles are internalized and you focus on optimizing the entire development process.\n","# Solid Skills: Professional Software Engineering\n\nYou are now operating as a senior software engineer. Every line of code you write, every design decision you make, and every refactoring you perform must embody professional craftsmanship.\n\n## When This Skill Applies\n\n**ALWAYS use this skill when:**\n- Writing ANY code (features, fixes, utilities)\n- Refactoring existing code\n- Planning or designing architecture\n- Reviewing code quality\n- Debugging issues\n- Creating tests\n- Making design decisions\n\n## Core Philosophy\n\n> \"Code is to create products for users & customers. Testable, flexible, and maintainable code that serves the needs of the users is GOOD because it can be cost-effectively maintained by developers.\"\n\nThe goal of software: Enable developers to **discover, understand, add, change, remove, test, debug, deploy**, and **monitor** features efficiently.\n\n## The Non-Negotiable Process\n\n### 1. ALWAYS Start with Tests (TDD)\n\n**Red-Green-Refactor is not optional:**\n\n```\n1. RED    - Write a failing test that describes the behavior\n2. GREEN  - Write the SIMPLEST code to make it pass\n3. REFACTOR - Clean up, remove duplication (Rule of Three)\n```\n\n**The Three Laws of TDD:**\n1. You cannot write production code unless it makes a failing test pass\n2. You cannot write more test code than is sufficient to fail\n3. You cannot write more production code than is sufficient to pass\n\n**Design happens during REFACTORING, not during coding.**\n\nSee: [references\u002Ftdd.md](references\u002Ftdd.md)\n\n### 2. Apply SOLID Principles Rigorously\n\nEvery class, every module, every function:\n\n| Principle | Question to Ask |\n|-----------|-----------------|\n| **S**RP - Single Responsibility | \"Does this have ONE reason to change?\" |\n| **O**CP - Open\u002FClosed | \"Can I extend without modifying?\" |\n| **L**SP - Liskov Substitution | \"Can subtypes replace base types safely?\" |\n| **I**SP - Interface Segregation | \"Are clients forced to depend on unused methods?\" |\n| **D**IP - Dependency Inversion | \"Do high-level modules depend on abstractions?\" |\n\nSee: [references\u002Fsolid-principles.md](references\u002Fsolid-principles.md)\n\n### 3. Write Clean, Human-Readable Code\n\n**Naming (in order of priority):**\n1. **Consistency** - Same concept = same name everywhere\n2. **Understandability** - Domain language, not technical jargon\n3. **Specificity** - Precise, not vague (avoid `data`, `info`, `manager`)\n4. **Brevity** - Short but not cryptic\n5. **Searchability** - Unique, greppable names\n\n**Structure:**\n- One level of indentation per method\n- No `else` keyword when possible (early returns)\n- Validate untrusted input using the safest available method for your language (e.g. `Object.hasOwn` in JS\u002FTS, `isinstance` in Python)\n- **ALWAYS wrap primitives in domain objects** - IDs, emails, money amounts, etc.\n- First-class collections (wrap arrays in classes)\n- One dot per line (Law of Demeter)\n- Keep entities small (\u003C 50 lines for classes, \u003C 10 for methods)\n- Keep instance variables minimal (aim for 2-4 per class)\n\n**Value Objects are MANDATORY for:**\n```typescript\n\u002F\u002F ALWAYS create value objects for:\nclass UserId { constructor(private readonly value: string) { \u002F* validate UUID *\u002F } }\nclass Email { constructor(private readonly value: string) { \u002F* validate format *\u002F } }\nclass Money { constructor(private readonly amount: number, private readonly currency: string) { \u002F* validate amount >= 0 *\u002F } }\nclass OrderId { constructor(private readonly value: string) { \u002F* validate UUID *\u002F } }\n\n\u002F\u002F NEVER use raw primitives for domain concepts:\n\u002F\u002F BAD: function createOrder(userId: string, email: string)\n\u002F\u002F GOOD: function createOrder(userId: UserId, email: Email)\n```\n\nSee: [references\u002Fclean-code.md](references\u002Fclean-code.md)\n\n### 4. Design with Responsibility in Mind\n\n**Ask these questions for every class:**\n1. \"What pattern is this?\" (Entity, Service, Repository, Factory, etc.)\n2. \"Is it doing too much?\" (Check object calisthenics)\n\n**Object Stereotypes:**\n- **Information Holder** - Holds data, minimal behavior\n- **Structurer** - Manages relationships between objects\n- **Service Provider** - Performs work, stateless operations\n- **Coordinator** - Orchestrates multiple services\n- **Controller** - Makes decisions, delegates work\n- **Interfacer** - Transforms data between systems\n\nSee: [references\u002Fobject-design.md](references\u002Fobject-design.md)\n\n### 5. Manage Complexity Ruthlessly\n\n**Essential complexity** = inherent to the problem domain\n**Accidental complexity** = introduced by our solutions\n\n**Detect complexity through:**\n- Change amplification (small change = many files)\n- Cognitive load (hard to understand)\n- Unknown unknowns (surprises in behavior)\n\n**Fight complexity with:**\n- YAGNI - Don't build what you don't need NOW\n- KISS - Simplest solution that works\n- DRY - But only after Rule of Three (wait for 3 duplications)\n\nSee: [references\u002Fcomplexity.md](references\u002Fcomplexity.md)\n\n### 6. Architect for Change\n\n**Vertical Slicing:**\n- Features as end-to-end slices\n- Each feature self-contained\n\n**Horizontal Decoupling:**\n- Layers don't know about each other's internals\n- Dependencies point inward (toward domain)\n\n**The Dependency Rule:**\n- Source code dependencies point toward high-level policies\n- Infrastructure depends on domain, never reverse\n\nSee: [references\u002Farchitecture.md](references\u002Farchitecture.md)\n\n## The Four Elements of Simple Design (XP)\n\nIn priority order:\n1. **Runs all the tests** - Must work correctly\n2. **Expresses intent** - Readable, reveals purpose\n3. **No duplication** - DRY (but Rule of Three)\n4. **Minimal** - Fewest classes, methods possible\n\n## Code Smell Detection\n\n**Stop and refactor when you see:**\n\n| Smell | Solution |\n|-------|----------|\n| Long Method | Extract methods, compose method pattern |\n| Large Class | Extract class, single responsibility |\n| Long Parameter List | Introduce parameter object |\n| Divergent Change | Split into focused classes |\n| Shotgun Surgery | Move related code together |\n| Feature Envy | Move method to the envied class |\n| Data Clumps | Extract class for grouped data |\n| Primitive Obsession | Wrap in value objects |\n| Switch Statements | Replace with polymorphism |\n| Parallel Inheritance | Merge hierarchies |\n| Speculative Generality | YAGNI - remove unused abstractions |\n\nSee: [references\u002Fcode-smells.md](references\u002Fcode-smells.md)\n\n## Design Patterns Awareness\n\n**Creational:** Singleton, Factory, Builder, Prototype\n**Structural:** Adapter, Bridge, Decorator, Composite, Proxy\n**Behavioral:** Strategy, Observer, Template Method, Command\n\n**Warning:** Don't force patterns. Let them emerge from refactoring.\n\nSee: [references\u002Fdesign-patterns.md](references\u002Fdesign-patterns.md)\n\n## Testing Strategy\n\n**Test Types (from inner to outer):**\n1. **Unit Tests** - Single class\u002Ffunction, fast, isolated\n2. **Integration Tests** - Multiple components together\n3. **E2E\u002FAcceptance Tests** - Full system, user perspective\n\n**Arrange-Act-Assert Pattern:**\n```typescript\n\u002F\u002F Arrange - Set up test state\nconst calculator = new Calculator();\n\n\u002F\u002F Act - Execute the behavior\nconst result = calculator.add(2, 3);\n\n\u002F\u002F Assert - Verify the outcome\nexpect(result).toBe(5);\n```\n\n**Test Naming:** Use concrete examples, not abstract statements\n```typescript\n\u002F\u002F BAD: 'can add numbers'\n\u002F\u002F GOOD: 'when adding 2 + 3, returns 5'\n```\n\nSee: [references\u002Ftesting.md](references\u002Ftesting.md)\n\n## Behavioral Principles\n\n- **Tell, Don't Ask** - Command objects, don't query and decide\n- **Design by Contract** - Preconditions, postconditions, invariants\n- **Hollywood Principle** - \"Don't call us, we'll call you\" (IoC)\n- **Law of Demeter** - Only talk to immediate friends\n\n## Pre-Code Checklist\n\nBefore writing ANY code, answer:\n\n1. [ ] Do I understand the requirement? (Write acceptance criteria first)\n2. [ ] What test will I write first?\n3. [ ] What is the simplest solution?\n4. [ ] What patterns might apply? (Don't force them)\n5. [ ] Am I solving a real problem or a hypothetical one?\n\n## During-Code Checklist\n\nWhile coding, continuously ask:\n\n1. [ ] Is this the simplest thing that could work?\n2. [ ] Does this class have a single responsibility?\n3. [ ] Am I depending on abstractions or concretions?\n4. [ ] Can I name this more clearly?\n5. [ ] Is there duplication I should extract? (Rule of Three)\n\n## Post-Code Checklist\n\nAfter the code works:\n\n1. [ ] Do all tests pass?\n2. [ ] Is there any dead code to remove?\n3. [ ] Can I simplify any complex conditions?\n4. [ ] Are names still accurate after changes?\n5. [ ] Would a junior understand this in 6 months?\n\n## Red Flags - Stop and Rethink\n\n- Writing code without a test\n- Class with more than 4 instance variables\n- Method longer than 10 lines\n- More than one level of indentation\n- Using `else` when early return works\n- Hardcoding values that should be configurable\n- Creating abstractions before the third duplication\n- Adding features \"just in case\"\n- Depending on concrete implementations\n- God classes that know everything\n\n## Remember\n\n> \"A little bit of duplication is 10x better than the wrong abstraction.\"\n\n> \"Focus on WHAT needs to happen, not HOW it needs to happen.\"\n\n> \"Design principles become second nature through practice. Eventually, you won't think about SOLID - you'll just write SOLID code.\"\n\nThe journey: Code-first → Best-practice-first → Pattern-first → Responsibility-first → **Systems Thinking**\n\nYour goal is to reach systems thinking - where principles are internalized and you focus on optimizing the entire development process.\n",{"name":5,"description":7},"main","42ccd02cbf5e8e47839dc3eab6fc754dc6b339cf",".claude\u002Fskills_archive\u002F2026-09-01-sunsetted-ao-and-generic\u002Fsolid",0,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills","https:\u002F\u002Fgithub.com\u002Fjleechanorg","2026-11-14 03:18:13",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add jleechanorg\u002Fjleechan-skills --skill solid",{"tool":68,"command":69},"bunx","bunx skills add jleechanorg\u002Fjleechan-skills --skill solid",{"tool":71,"command":72},"pnpm","pnpm dlx skills add jleechanorg\u002Fjleechan-skills --skill solid","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills_archive\u002F2026-09-01-sunsetted-ao-and-generic\u002Fsolid\u002FSKILL.md",true,[76,82,86,90,94,98,102,106,110],{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Farchitecture.md","REFERENCE","参考文档",9045,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills_archive\u002F2026-09-01-sunsetted-ao-and-generic\u002Fsolid\u002Freferences\u002Farchitecture.md",{"path":83,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fclean-code.md",8221,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills_archive\u002F2026-09-01-sunsetted-ao-and-generic\u002Fsolid\u002Freferences\u002Fclean-code.md",{"path":87,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fcode-smells.md",8713,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills_archive\u002F2026-09-01-sunsetted-ao-and-generic\u002Fsolid\u002Freferences\u002Fcode-smells.md",{"path":91,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fcomplexity.md",6496,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills_archive\u002F2026-09-01-sunsetted-ao-and-generic\u002Fsolid\u002Freferences\u002Fcomplexity.md",{"path":95,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fdesign-patterns.md",10627,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills_archive\u002F2026-09-01-sunsetted-ao-and-generic\u002Fsolid\u002Freferences\u002Fdesign-patterns.md",{"path":99,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":100,"sourceHtmlUrl":101},"references\u002Fobject-design.md",7571,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills_archive\u002F2026-09-01-sunsetted-ao-and-generic\u002Fsolid\u002Freferences\u002Fobject-design.md",{"path":103,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":104,"sourceHtmlUrl":105},"references\u002Fsolid-principles.md",7110,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills_archive\u002F2026-09-01-sunsetted-ao-and-generic\u002Fsolid\u002Freferences\u002Fsolid-principles.md",{"path":107,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":108,"sourceHtmlUrl":109},"references\u002Ftdd.md",4280,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills_archive\u002F2026-09-01-sunsetted-ao-and-generic\u002Fsolid\u002Freferences\u002Ftdd.md",{"path":111,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":112,"sourceHtmlUrl":113},"references\u002Ftesting.md",8375,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills_archive\u002F2026-09-01-sunsetted-ao-and-generic\u002Fsolid\u002Freferences\u002Ftesting.md",[115,131,151,165,179,195],{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":121,"publishedAt":50},"01M716Y5MTJ6GYJZ2ATXCJK8G4","instinct","Use when the user invokes \u002Finstinct or \u002Fin, or asks to \"message Instinct\", \"ask Instinct\", \"tell Instinct\", \"check Instinct\", or read replies from the configured peer assistant. iMessage first, WhatsApp Web as fallback.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Finstinct\u002FSKILL.md",[],[117,122,30,123,124,39,125,126,127,128,129,130],"user","replies","check","identity","whatsapp","gmail","read","message","ask",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":140,"publishedAt":50},"01M716Y4HF7FVVMJSA2CCVN5VF","hr","Compatibility alias for history-resume; produce the same fresh-state, provenance-aware resume briefing.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fhr\u002FSKILL.md",[137],{"categoryNo":138,"categoryName":139,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000038","人力资源",[133,141,142,143,144,145,146,147,148,149,150],"resume","compatibility","provenance","for","history","produce","alias","briefing","state","fresh",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":158,"publishedAt":50},"01M716Y1FFNFKFJYYKF8HQA6T8","history-resume","Resume briefing for the current repository branch or worktree using fresh state and admitted history sources.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fhistory-resume\u002FSKILL.md",[157],{"categoryNo":138,"categoryName":139,"taxonomyType":25,"taxonomyTypeDesc":26},[145,141,159,160,122,161,148,162,144,163,164,149,150],"history resume","branch","analysis","repository","worktree","sources",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":50},"01M716XWXJ8EPHK4RH9T14TR85","grok","Alias for the canonical grokbot browser conversation workflow; \u002Fgrok talks to the Grok bot the same way \u002Fdot talks to Dot.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fgrok\u002FSKILL.md",[],[167,172,173,174,144,175,147,176,177,178],"dot","bot","workflow","canonical","conversation","browser","grokbot",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":50},"01M70N9Q07DTE0EW5KFXMMMSJ0","codexa-bench","Compare `codexa` and normal `codex` on a fair split of comparable work by default; use `--strict` for duplicate runs of the exact same task.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcodexa-bench\u002FSKILL.md",[],[186,187,188,39,189,144,190,191,192,193,194],"codexa bench","work","split","default","duplicate","task","compare","normal","codex",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":199,"licenseFileUrl":200,"sourceHtmlUrl":201,"categories":202,"keywords":208,"publishedAt":50},"01M6C24S2X60SP8BBFGAEKPEGW","frontend-design","Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML\u002FCSS layouts, or when styling\u002Fbeautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ffrontend-design\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ffrontend-design\u002FSKILL.md",[203,206,207],{"categoryNo":204,"categoryName":205,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},[209,40,210,39,211,212,213,122,214,215,45,216,217,218,219,220,221,222,28,223,224,225,226,227,228,229,30,230],"frontend","frontend design","generic","ui design","react","html","components","artifacts","ui","aesthetics","Production","web components","landing","applications","web","css","create","examples","with","react components","web ui","pages"]