pdd-skills 3.0.0

package/skills/entropy/expert-code-quality/SKILL.md

@@ -0,0 +1,468 @@
+---
+name: expert-code-quality
+description: "Code quality expert integrating refactoring techniques and design patterns for systematic improvement. Call when reviewing code, refactoring, or applying SOLID principles."
+license: "MIT"
+author: "neuqik@hotmail.com"
+version: "2.0"
+---
+
+# Code Quality Expert
+
+## Overview
+
+This skill integrates two foundational software engineering disciplines:
+1. **Refactoring** - Improving code structure without changing behavior
+2. **Design Patterns** - Proven solutions to common design problems
+
+Combined, they form a powerful toolkit for writing clean, maintainable, and extensible code.
+
+## Directory Structure
+
+```
+expert-code-quality/
+├── SKILL.md              # Skill definition file
+├── LICENSE               # MIT License
+└── references/           # Reference documents
+    ├── refactoring-catalog.md    # Complete catalog of refactoring techniques
+    ├── design-patterns.md         # 23 GoF patterns
+    ├── code-smells.md             # Detailed description of code smells
+    └── solid-principles.md        # In-depth analysis of SOLID principles
+```
+
+## Trigger Conditions
+
+**Automatic Triggers:**
+- User asks about code quality issues
+- Need to identify code smells
+- Request for design pattern recommendations
+- Performing code refactoring
+- Evaluating SOLID principle compliance
+
+**Manual Triggers:**
+- User enters commands like `/code-quality`, `/refactor`, `/pattern`, etc.
+
+---
+
+## Core Capabilities
+
+### 1. Code Smell Detection
+
+#### 1.1 Quick Reference: 22 Code Smells
+
+**Method-Level Smells:**
+
+| Smell | Detection Pattern | Severity |
+|-------|------------------|----------|
+| **Long Method** | Method > 20 lines | High |
+| **Duplicated Code** | Similar code blocks | Critical |
+| **Long Parameter List** | Parameters > 4 | Medium |
+| **Switch Statements** | Large switch/case blocks | Medium |
+
+**Class-Level Smells:**
+
+| Smell | Detection Pattern | Severity |
+|-------|------------------|----------|
+| **Large Class** | Class > 300 lines or > 10 fields | High |
+| **Divergent Change** | One class changes for multiple reasons | High |
+| **Shotgun Surgery** | One change requires modifying many classes | High |
+| **Feature Envy** | Method uses data from other classes more | Medium |
+
+**Relationship-Level Smells:**
+
+| Smell | Detection Pattern | Severity |
+|-------|------------------|----------|
+| **Inappropriate Intimacy** | Classes access each other's private parts | Medium |
+| **Message Chains** | `a.b().c().d()` chains | Medium |
+| **Middle Man** | Class only does delegation | Low |
+| **Data Clumps** | Same data items always appear together | Medium |
+
+#### 1.2 Smell Detection Checklist
+
+When reviewing code, check:
+- [ ] Are there methods longer than 20 lines?
+- [ ] Is there duplicated code?
+- [ ] Are there classes with more than 10 fields?
+- [ ] Are there switch statements that could use polymorphism?
+- [ ] Are there methods with more than 4 parameters?
+- [ ] Is there deep inheritance hierarchy (> 3 levels)?
+- [ ] Does the class change for multiple reasons?
+- [ ] Are there message chains with more than 3 calls?
+- [ ] Are there "data classes" with only data and no behavior?
+- [ ] Are there "lazy classes" that do almost nothing?
+
+---
+
+### 2. Refactoring Techniques
+
+#### 2.1 Refactoring Principles
+
+**Two Hats (Kent Beck):**
+
+| Hat | Activity | Rule |
+|-----|----------|------|
+| **Adding Features** | Add new functionality | Don't modify existing code |
+| **Refactoring** | Improve structure | Don't add new features |
+
+**Never wear both hats at the same time!**
+
+**Refactoring Rhythm:**
+```
+Test → Small Change → Test → Small Change → Test
+```
+
+#### 2.2 Key Refactoring Techniques
+
+**Composing Methods:**
+
+| Refactoring | When to Use | Steps |
+|-------------|-------------|-------|
+| **Extract Method** | Method too long, code block needs naming | 1.Create new method 2.Copy code 3.Replace original code with call |
+| **Inline Method** | Method body as clear as its name | 1.Replace calls with method body 2.Delete method |
+| **Replace Temp with Query** | Temporary variable holds expression | 1.Extract expression to method 2.Replace temp with call |
+| **Replace Method with Method Object** | Too many temporaries in long method | 1.Create class for method 2.Temporaries become fields |
+
+**Moving Features:**
+
+| Refactoring | When to Use | Steps |
+|-------------|-------------|-------|
+| **Move Method** | Method uses other class more | 1.Copy to target 2.Delegate in source 3.Delete source method |
+| **Extract Class** | Class does too much | 1.Create new class 2.Move fields/methods 3.Link classes |
+| **Hide Delegate** | Client knows delegation chain | 1.Add delegate method 2.Hide chain |
+
+**Simplifying Conditionals:**
+
+| Refactoring | When to Use | Steps |
+|-------------|-------------|-------|
+| **Decompose Conditional** | Complex conditional logic | 1.Extract condition 2.Extract then/else |
+| **Consolidate Conditional** | Multiple checks with same result | 1.Combine with && or \|\| 2.Extract method |
+| **Replace Nested Conditional with Guard Clauses** | Deeply nested if-else | 1.Add guard clause returns 2.Flatten structure |
+| **Replace Conditional with Polymorphism** | Switch by type | 1.Create subclasses 2.Move behavior to each subclass |
+
+#### 2.3 Refactoring Decision Tree
+
+```
+Found code smell?
+    │
+    ├─ Do you have tests?
+    │   ├─ No → Write tests first
+    │   └─ Yes → Continue
+    │
+    ├─ Do you understand the code?
+    │   ├─ No → Refactor to understand
+    │   └─ Yes → Continue
+    │
+    └─ Choose refactoring approach:
+        │
+        ├─ Method too long → Extract Method
+        ├─ Duplicated code → Extract Method / Pull Up
+        ├─ Class too large → Extract Class
+        ├─ Parameter list too long → Introduce Parameter Object
+        ├─ Switch statement → Replace with Polymorphism
+        └─ Complex conditionals → Decompose / Guard Clauses
+```
+
+---
+
+### 3. Design Patterns
+
+#### 3.1 SOLID Principles Foundation
+
+Before applying patterns, ensure understanding of SOLID principles:
+
+| Principle | Name | Description |
+|-----------|------|-------------|
+| **S** | Single Responsibility | One reason to change |
+| **O** | Open/Closed | Open for extension, closed for modification |
+| **L** | Liskov Substitution | Subtypes must be substitutable |
+| **I** | Interface Segregation | Small, focused interfaces |
+| **D** | Dependency Inversion | Depend on abstractions |
+
+#### 3.2 Selection by Problem Type
+
+| Problem | Pattern | Key Benefit |
+|---------|---------|-------------|
+| Need single instance | Singleton | Controlled access |
+| Flexible object creation | Factory Method | Decouple creation |
+| Create families of objects | Abstract Factory | Consistent products |
+| Build complex objects | Builder | Step-by-step construction |
+| Incompatible interfaces | Adapter | Make incompatible work |
+| Dynamically add responsibilities | Decorator | Flexible extension |
+| Control access | Proxy | Indirection layer |
+| Simplify complex system | Facade | Simple interface |
+| Tree structure | Composite | Uniform handling |
+| Switch algorithms | Strategy | Interchangeable behaviors |
+| Event notification | Observer | Loose coupling |
+| Encapsulate requests | Command | Undo/redo support |
+| State-dependent behavior | State | Clear state transitions |
+
+#### 3.3 Selection by Code Smell
+
+| Smell | Pattern Solution |
+|-------|------------------|
+| Large switch statement | State, Strategy |
+| Multiple conditionals | Strategy, State, Null Object |
+| Tight coupling | Observer, Mediator, Facade |
+| Difficult object creation | Factory, Builder |
+| Hard to extend class | Decorator, Adapter |
+| Complex subsystem | Facade |
+| Need varying algorithms | Strategy, Template Method |
+
+#### 3.4 Pattern Quick Reference
+
+**Creational Patterns:**
+
+| Pattern | When to Use |
+|---------|-------------|
+| Singleton | Need single instance |
+| Factory Method | Don't know exact class to create |
+| Abstract Factory | Need families of related objects |
+| Builder | Complex object with many options |
+| Prototype | Clone existing objects |
+
+**Structural Patterns:**
+
+| Pattern | When to Use |
+|---------|-------------|
+| Adapter | Incompatible interfaces |
+| Decorator | Dynamically add responsibilities |
+| Proxy | Control access, lazy loading |
+| Facade | Simplify complex interfaces |
+| Composite | Tree structure, uniform handling |
+| Flyweight | Many similar objects, share state |
+| Bridge | Separate abstraction from implementation |
+
+**Behavioral Patterns:**
+
+| Pattern | When to Use |
+|---------|-------------|
+| Strategy | Interchangeable algorithms |
+| Observer | One-to-many notifications |
+| Command | Encapsulate requests, undo/redo |
+| State | State-dependent behavior |
+| Template Method | Algorithm skeleton, varying steps |
+| Iterator | Uniform collection traversal |
+| Mediator | Complex object interactions |
+| Memento | Save/restore state |
+| Chain of Resp. | Request has multiple handlers |
+| Visitor | Add operations to object structure |
+
+---
+
+### 4. Integrated Workflow
+
+#### 4.1 Code Quality Improvement Process
+
+```
+1. IDENTIFY
+   └── Detect code smells
+       └── Use smell checklist
+           └── Rate severity (Critical/High/Medium/Low)
+
+2. DIAGNOSE
+   └── Understand root cause
+       └── Why does this smell exist?
+           └── What problems will it cause?
+
+3. PLAN
+   └── Choose refactoring or pattern
+       └── Consider dependencies
+           └── Estimate impact
+
+4. PREPARE
+   └── Ensure tests exist
+       └── Run tests to verify behavior
+           └── Create tests if missing
+
+5. EXECUTE
+   └── Apply small changes
+       └── Test after each change
+           └── Keep code working
+
+6. VERIFY
+   └── Run all tests
+       └── Check for new smells
+           └── Confirm improvement
+```
+
+#### 4.2 Smell→Refactoring→Pattern Flow
+
+```
+Detected code smell
+        │
+        ▼
+┌───────────────────┐
+│ Is this a method  │
+│ level problem?    │
+└────────┬──────────┘
+         │
+    ┌────┴────┐
+    │ Yes     │ No
+    ▼         ▼
+Extract    Is this a class
+Method     level problem?
+              │
+         ┌────┴────┐
+         │ Yes     │ No
+         ▼         ▼
+    Extract    Is this a
+    Class      relationship
+              problem?
+                  │
+             ┌────┴────┐
+             │ Yes     │ No
+             ▼         ▼
+        Move/Hide   Consider
+        Delegate    Pattern
+                        │
+                        ▼
+                  ┌──────────────┐
+                  │ Which        │
+                  │ pattern fits │
+                  │ best?        │
+                  └──────┬───────┘
+                         │
+         ┌───────────────┼───────────────┐
+         ▼               ▼               ▼
+    Creational      Structural      Behavioral
+    Patterns        Patterns        Patterns
+```
+
+---
+
+### 5. Collaboration Table
+
+#### 5.1 Collaboration with Other Skills
+
+| Collaborating Skill | Collaboration Mode | Description |
+|--------------------|-------------------|-------------|
+| **test-driven-development** | Sequential | Write tests before refactoring |
+| **systematic-debugging** | Consultation | Find root cause before fixing |
+| **requesting-code-review** | Reference | Get feedback on refactored code |
+| **pdd-code-reviewer** | Reference | Get PDD project code review |
+| **software-engineer** | Delegation | Quality check after code implementation |
+
+#### 5.2 Collaboration Workflow
+
+```
+Code quality issue detected
+    ↓
+Invoke expert-code-quality
+    ↓
+Identify code smells + Recommend refactoring/patterns
+    ↓
+(If tests needed first) → Invoke test-driven-development
+    ↓
+(If code implementation needed) → Invoke software-engineer
+    ↓
+Complete code quality improvement
+```
+
+---
+
+### 6. Quick Decision Matrix
+
+| Scenario | Primary Action |
+|----------|---------------|
+| Found duplicated code | Extract Method |
+| Method too long | Extract Method |
+| Class too large | Extract Class |
+| Parameter list too long | Introduce Parameter Object |
+| Switch by type | Replace with Polymorphism |
+| Need single instance | Consider Singleton |
+| Need flexible creation | Factory Method or Builder |
+| Incompatible interfaces | Adapter |
+| Need to add behavior | Decorator |
+| Complex subsystem | Facade |
+| Need varying algorithms | Strategy |
+| Need event notification | Observer |
+
+---
+
+### 7. Anti-Patterns
+
+#### 7.1 Refactoring Anti-Patterns
+
+| Anti-Pattern | Description | Correct Approach |
+|--------------|-------------|------------------|
+| **Big Bang Refactoring** | Rewrite everything at once | Small incremental changes |
+| **Refactoring Without Tests** | Change code without safety net | Write tests first |
+| **Over-Refactoring** | Refactor clean code | Stop when code is clear |
+| **Refactoring Addiction** | Only refactor, never deliver | Balance refactoring with features |
+| **Random Refactoring** | No clear goal | Identify smells first |
+
+#### 7.2 Pattern Anti-Patterns
+
+| Anti-Pattern | Description | Correct Approach |
+|--------------|-------------|------------------|
+| **Pattern Obsession** | Use patterns everywhere | Use patterns to solve problems |
+| **Singleton Abuse** | Everything is singleton | Use only when truly needed |
+| **Factory Overkill** | Factory for single product | Use factory for multiple products |
+| **Decorator Nesting** | Too many decorator layers | Limit nesting depth |
+| **Premature Pattern** | Use pattern before needed | Let patterns emerge from refactoring |
+
+---
+
+### 8. Practice Checklists
+
+#### 8.1 Code Review Checklist
+
+Before approving code, verify:
+- [ ] No critical code smells
+- [ ] Reasonable method size (< 20 lines)
+- [ ] Class has single responsibility
+- [ ] No duplicated code
+- [ ] Clear conditionals
+- [ ] Meaningful names
+- [ ] Tests exist and pass
+- [ ] Follows SOLID principles
+- [ ] Patterns used appropriately (not overused)
+
+#### 8.2 Refactoring Safety Checklist
+
+Before refactoring:
+- [ ] All tests pass
+- [ ] Tests cover code to refactor
+- [ ] Understand code functionality
+- [ ] Have rollback plan
+- [ ] Make small changes
+- [ ] Test after each change
+
+#### 8.3 Pattern Application Checklist
+
+Before applying pattern:
+- [ ] Problem matches pattern intent
+- [ ] Pattern solves real problem (not imagined)
+- [ ] Team understands pattern
+- [ ] Pattern doesn't overcomplicate
+- [ ] Alternatives considered
+- [ ] Pattern fits project context
+
+---
+
+## Guardrails
+
+- Must provide suggestions based on Martin Fowler's refactoring catalog and GoF design patterns
+- Refactoring suggestions need specific code transformation examples
+- Pattern application needs to weigh pros and cons, not blindly recommend
+- Code review needs to specifically point out problems and improvement suggestions
+- Clearly state uncertain issues to avoid misleading
+
+---
+
+## Version History
+
+### v2.0 (2026-03-21)
+- Unified to Chinese description
+- Added collaboration table, clarified collaboration with other skills
+- Enhanced quick decision matrix
+- Optimized refactoring decision tree
+- Added anti-pattern checklist
+
+### v1.0 (Initial version)
+- Basic code quality detection
+- Refactoring technique catalog
+- Design pattern reference
+
+---
+
+> **Remember**: Good code isn't about being clever—it's about being clear. Refactoring and patterns are tools to achieve clarity, not ends in themselves.

package/skills/entropy/expert-code-quality/_meta.json

@@ -0,0 +1 @@
+{"name": "expert-code-quality", "version": "1.0.0", "category": "entropy", "description": "Code quality expert integrating refactoring techniques and design patterns for systematic improvement. Call when reviewing code, refactoring, checking code smells, or applying SOLID principles.", "triggers": ["代码审查", "重构", "设计模式", "SOLID原则"]}

package/skills/entropy/expert-code-quality/evals/default-evals.json

@@ -0,0 +1 @@
+[{"name": "SKILL.md-exists", "description": "技能文件存在且格式正确", "type": "structure", "expect": {"exists": true, "hasDescription": true}, "checks": {"file_exists": "SKILL.md"}}, {"name": "_meta.json-valid", "description": "元数据文件格式正确", "type": "structure", "expect": {"exists": true, "hasName": true, "hasVersion": true, "hasTriggers": true}, "checks": {"file_exists": "_meta.json"}}, {"name": "quality-dimensions-defined", "description": "定义了代码质量维度(重构+设计模式)", "type": "content", "contains": ["quality", "Refactoring", "Design Patterns", "maintainable", "SOLID"]}, {"name": "refactoring-techniques-defined", "description": "整合了重构技术和设计模式", "type": "content", "contains": ["Refactoring", "Design Patterns", "clean", "extensible"]}, {"name": "references-defined", "description": "定义了参考文档目录结构", "type": "content", "contains": ["references", "catalog", "patterns", "smells", "principles"]}]

package/skills/entropy/expert-code-quality/evals/evals.json

@@ -0,0 +1,109 @@
+{
+  "skill_name": "code-quality-expert",
+  "evals": [
+    {
+      "id": 1,
+      "name": "detect-code-smells",
+      "prompt": "Review this Java code and identify any code smells:\n\n```java\npublic class OrderManager {\n    public void processOrder(Order order) {\n        // Validate order\n        if (order.getItems() == null || order.getItems().isEmpty()) {\n            throw new IllegalArgumentException(\"Order has no items\");\n        }\n        if (order.getCustomer() == null) {\n            throw new IllegalArgumentException(\"Order has no customer\");\n        }\n        if (order.getCustomer().getAddress() == null) {\n            throw new IllegalArgumentException(\"Customer has no address\");\n        }\n        \n        // Calculate total\n        double total = 0;\n        for (OrderItem item : order.getItems()) {\n            total += item.getPrice() * item.getQuantity();\n        }\n        \n        // Apply discount\n        double discount = 0;\n        if (order.getCustomer().getType().equals(\"VIP\")) {\n            discount = total * 0.1;\n        } else if (order.getCustomer().getType().equals(\"Premium\")) {\n            discount = total * 0.15;\n        } else if (order.getCustomer().getType().equals(\"Gold\")) {\n            discount = total * 0.2;\n        }\n        \n        // Save order\n        DatabaseConnection db = new DatabaseConnection();\n        db.connect();\n        db.execute(\"INSERT INTO orders VALUES (...) \");\n        db.close();\n        \n        // Send email\n        EmailService email = new EmailService();\n        email.send(order.getCustomer().getEmail(), \"Order confirmed\");\n    }\n}",
+      "expected_output": "Should identify multiple code smells: Long Method, Switch Statements, Feature Envy, Primitive Obsession, and suggest appropriate refactorings",
+      "assertions": [
+        {
+          "name": "identifies_long_method",
+          "description": "Should identify the method is too long and doing too many things"
+        },
+        {
+          "name": "identifies_switch_statements",
+          "description": "Should identify switch/if-else on customer type as a smell"
+        },
+        {
+          "name": "suggests_refactorings",
+          "description": "Should suggest specific refactorings like Extract Method, Replace Conditional with Polymorphism"
+        }
+      ]
+    },
+    {
+      "id": 2,
+      "name": "recommend-design-pattern",
+      "prompt": "I have a class that needs to create different types of report objects (PDFReport, ExcelReport, HTMLReport) based on user configuration. The creation logic is getting complex with many conditionals. What design pattern should I use and how should I implement it?",
+      "expected_output": "Should recommend Factory Method or Abstract Factory pattern with clear explanation and implementation example",
+      "assertions": [
+        {
+          "name": "recommends_factory_pattern",
+          "description": "Should recommend Factory Method or Abstract Factory pattern"
+        },
+        {
+          "name": "provides_implementation",
+          "description": "Should provide code example showing the pattern implementation"
+        },
+        {
+          "name": "explains_benefits",
+          "description": "Should explain why this pattern fits the problem"
+        }
+      ]
+    },
+    {
+      "id": 3,
+      "name": "refactoring-guidance",
+      "prompt": "I found this code smell in my codebase - a class called 'UserManager' that handles user authentication, user profile management, user notifications, and user reporting. It's over 500 lines. How should I refactor this?",
+      "expected_output": "Should identify this as Large Class and Divergent Change smells, recommend Extract Class refactoring, and provide step-by-step guidance",
+      "assertions": [
+        {
+          "name": "identifies_smells",
+          "description": "Should correctly identify Large Class and Divergent Change"
+        },
+        {
+          "name": "recommends_extract_class",
+          "description": "Should recommend Extract Class refactoring"
+        },
+        {
+          "name": "provides_steps",
+          "description": "Should provide step-by-step refactoring guidance"
+        },
+        {
+          "name": "mentions_srp",
+          "description": "Should mention Single Responsibility Principle"
+        }
+      ]
+    },
+    {
+      "id": 4,
+      "name": "solid-principle-violation",
+      "prompt": "Review this code for SOLID principle violations:\n\n```java\npublic class ReportGenerator {\n    private MySQLDatabase db;\n    \n    public ReportGenerator() {\n        this.db = new MySQLDatabase();\n    }\n    \n    public void generateReport(String type) {\n        if (type.equals(\"PDF\")) {\n            generatePdfReport();\n        } else if (type.equals(\"Excel\")) {\n            generateExcelReport();\n        } else if (type.equals(\"HTML\")) {\n            generateHtmlReport();\n        }\n    }\n    \n    private void generatePdfReport() { /* ... */ }\n    private void generateExcelReport() { /* ... */ }\n    private void generateHtmlReport() { /* ... */ }\n}\n```",
+      "expected_output": "Should identify OCP violation (switch on type), DIP violation (direct instantiation), and suggest improvements",
+      "assertions": [
+        {
+          "name": "identifies_ocp_violation",
+          "description": "Should identify Open/Closed Principle violation in generateReport method"
+        },
+        {
+          "name": "identifies_dip_violation",
+          "description": "Should identify Dependency Inversion Principle violation in constructor"
+        },
+        {
+          "name": "suggests_improvements",
+          "description": "Should suggest Strategy pattern and dependency injection"
+        }
+      ]
+    },
+    {
+      "id": 5,
+      "name": "pattern-selection",
+      "prompt": "I need to implement a feature where multiple objects need to be notified when a user's status changes. What design pattern should I use?",
+      "expected_output": "Should recommend Observer pattern with explanation and implementation example",
+      "assertions": [
+        {
+          "name": "recommends_observer",
+          "description": "Should recommend Observer pattern"
+        },
+        {
+          "name": "explains_pattern",
+          "description": "Should explain how Observer pattern works"
+        },
+        {
+          "name": "provides_example",
+          "description": "Should provide code example"
+        }
+      ]
+    }
+  ]
+}