القائمة
Detect code smells and apply refactoring techniques to improve clarity, testability, and maintainability.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Enforce and guide the Mikado Method when a developer is refactoring, restructuring, or dealing with legacy code. Use this skill whenever the user mentions refactoring, technical debt, legacy code, code restructuring, dependency untangling, or "breaking everything" when making changes. Also trigger when the user wants to make a large change safely, asks how to split a big refactoring task, wants to work on main branch without a long-lived feature branch, or asks how to incrementally improve a codebase. The skill enforces the full Mikado loop: goal → naive attempt → map prerequisites → revert → implement leaves → commit → repeat.
Evaluate TypeScript/JavaScript code against Dave Thomas's OO principles and the Tell Don't Ask rule. Trigger when: class has only static methods; class has a single public method + constructor; code uses GoF pattern names (Decorator/Factory/Strategy/Builder/Command/Observer); class is invalid until setters are called; data class with only constructor + properties; external code reads getters to make decisions (Tell Don't Ask); user asks "is this a code smell?", "should this be a class or a function?", or "why does my code feel procedural?".
Guide users through TDD and TCRDD (Test && Commit || Revert + Test Driven Development). Use this skill whenever a user mentions TDD, test-driven development, writing tests before code, red-green-refactor cycles, or unit testing workflows. Also trigger when a user asks about TCRDD, TCR, "test commit revert", "git gamble", or wants a strict TDD workflow with automatic commits and reverts. Trigger when the user asks to implement a feature, fix a bug, or write a class/function and mentions tests, TDD, or "test first". If the user shares code and asks for a review with any testing angle, consult this skill.
Master testing strategy — philosophy, approach, architecture decisions, test quality audit, and BDD review practices.
Design patterns for TypeScript—Factory, Strategy, Builder, Decorator, Singleton, Mixin, and more with problem-oriented and GoF triggers.
TypeScript error handling via union returns, strictness policy, runtime validation with Zod, monorepo contracts, and domain types vs DTOs.
| name | refactoring |
| description | Detect code smells and apply refactoring techniques to improve clarity, testability, and maintainability. |
| triggers | ["refactoring","code smell","long method","large class","primitive obsession","long parameter list","data clumps","comments code","extract method","extract class","replace conditional","simplify conditional","introduce variable","move method","rename variable","code review smell","refactoring decision guide","when to refactor","when not to refactor"] |
A comprehensive guide to detecting code smells and applying refactoring techniques to improve design, clarity, and maintainability.
| Read When | File |
|---|---|
| Identifying code smells in your codebase | Code Smell Catalog |
| Deciding which refactoring technique to use | Refactoring Techniques |
| Choosing the right pattern for a specific scenario | Decision Guide |
| Step-by-step code review and refactoring workflow | Code Review Workflow |
| Quickly matching smells to activation triggers | Pattern Triggers |
| Understanding where patterns apply in your code | Language Patterns |
| Seeing real-world before/after examples | Real-World Examples |
| Smell | Detection Signal | Technique(s) | Payoff |
|---|---|---|---|
| Long Method | >10 lines, multiple responsibilities | Extract Method | Testable, reusable, clear intent |
| Large Class | >10 methods, multiple concerns, hard to test | Extract Class | Focused, maintainable, easier to extend |
| Primitive Obsession | String/int constants for domain concepts | Create Type/Object | Type-safe, validation once, intent clear |
| Long Parameter List | >3-4 parameters, related params | Parameter Objects/Enums | Self-documenting, testable, extensible |
| Data Clumps | Same variables in multiple places | Extract Class | Validation once, consistency, clarity |
| Comments (What) | Complex expression needs comment | Extract Variable | Self-documenting, testable, reusable |
| Comments (What) | Code block needs comment | Extract Method | Clear intent, reusable, testable |
| Comments (What) | Method purpose unclear from name | Rename Method | Self-documenting, faster onboarding |
| Comments (Precond) | Comment documents a required precondition | Introduce Assertion | Fail-fast, explicit contracts |
| Comments (Behavior) | Comment documents expected behavior/edge cases | Write Tests | Executable spec, living documentation |
| Technique | Use When | Payoff |
|---|---|---|
| Extract Method | Logic has single purpose, appears multiple times, hard to test | Reusable, testable, clearer intent |
| Extract Class | Class has multiple responsibilities or mixed concerns | Focused, reusable, easier to test |
| Replace Conditional | Same type/status check scattered in multiple places | Open/Closed Principle, localized behavior, ext. |
| Introduce Variable | Complex expression is hard to read or repeated | Self-documenting, testable, reusable |
| Simplify Conditional | Nested or complex if/else logic | Readable, fail-fast, happy path clear |
| Move Method/Field | Method/field belongs logically elsewhere | Better cohesion, less coupling, reusable |
| Rename | Name doesn't express intent | Self-documenting, faster onboarding, clarity |
Sometimes code size, complexity, or structure is justified:
Always ask: "Does this complexity serve the code's purpose, or does it obscure it?"
