القائمة
Design patterns for TypeScript—Factory, Strategy, Builder, Decorator, Singleton, Mixin, and more with problem-oriented and GoF triggers.
التثبيت باستخدام 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?".
Detect code smells and apply refactoring techniques to improve clarity, testability, and maintainability.
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.
TypeScript error handling via union returns, strictness policy, runtime validation with Zod, monorepo contracts, and domain types vs DTOs.
| name | typescript-design-patterns |
| description | Design patterns for TypeScript—Factory, Strategy, Builder, Decorator, Singleton, Mixin, and more with problem-oriented and GoF triggers. |
| triggers | ["design patterns","typescript design patterns","Strategy pattern","Factory pattern","Abstract Factory","Builder pattern","Singleton pattern","Decorator pattern","Proxy pattern","Mixin pattern","Observer pattern","Flyweight pattern","Mediator pattern","Companion Object","swap algorithms at runtime","create families of related objects","construct a complex object step-by-step","add cross-cutting behavior","share behavior across classes","pair a type and factory","decouple components via a hub","reuse instances to reduce memory"] |
| Problem | Pattern |
|---|---|
| One shared instance (DB, config, logger) | Singleton |
| Swap algorithms at runtime | Strategy |
| Create families of related objects | Abstract Factory |
| Create objects without naming the concrete class | Factory |
| Construct complex objects step-by-step | Builder |
| Pair a type and utility object under one name | Companion Object |
| Notify subscribers on state change | Observer |
| Add cross-cutting behavior non-invasively | Decorator (TS 5+ standard) |
| Intercept/validate/log property access | Proxy |
| Share behavior across unrelated classes | Mixin (class-expression pattern) |
| Reuse instances to reduce memory | Flyweight |
| Decouple via a central hub | Mediator |
→ Full pattern examples with trade-offs: references/patterns.md
For every pattern question, provide:
Factory — Create objects without exposing concrete classes. Pair type and factory via companion object. → references/patterns.md
Strategy — Encapsulate interchangeable algorithms; swap at runtime without changing caller. → references/patterns.md
Abstract Factory — Interface for compatible product families. Client depends on factory, never concretes. → references/patterns.md
Builder — Fluent step-by-step construction with validation and immutable product. Covers Step Builder for compile-time field enforcement. → references/patterns.md
Companion Object Pattern — Bind same name to type and utility object. One import covers both. → references/patterns.md
Real Mixins ⚠️ — Use class-expression pattern only; legacy applyMixins is outdated. (is-a → inheritance; has-a → delegation; can-do → mixin.) → references/patterns.md
Decorator (TS 5.0+ Standard) ⚠️ — Cross-cutting concerns declaratively. Standard API needs no flag. Frameworks like Angular/NestJS still require "experimentalDecorators": true (APIs not interoperable). → references/patterns.md
