From grimoire
Implements Chain of Responsibility pattern to decouple request senders from handlers, passing requests along a chain until handled.
How this skill is triggered — by the user, by Claude, or both
Slash command
/grimoire:apply-chain-of-responsibility-patternThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Pass a request along a chain of handlers; each handler decides to process it or forward it to the next handler.
Pass a request along a chain of handlers; each handler decides to process it or forward it to the next handler.
Adopted by: Java Servlet Filter API (every Java web request passes through a
configurable filter chain — the foundation of Spring Security, CORS handling, and
logging in all Java web apps), Express.js app.use() middleware (the core request
pipeline model), Python's logging module (each logger's handlers form a chain),
and browser DOM event propagation (bubbling is a chain-of-responsibility).
Impact: GoF documents that without Chain of Responsibility, the sender must know
which object handles its request — adding conditional routing logic that must be updated
every time a new handler is added. Java Servlet's filter chain allows adding security,
compression, or logging filters without modifying the servlet or other filters.
Why best: Direct if/elif dispatch — the alternative — couples the sender to all
possible handlers and requires modification for every new handler. Chain of Responsibility
lets handlers be added, removed, and reordered without touching the sender or other handlers.
Sources: Gamma et al. (1994) pp. 223–232; Java Servlet Filter specification; Express.js middleware documentation
from abc import ABC, abstractmethod
from typing import Optional
class SupportHandler(ABC):
def __init__(self):
self._next: Optional["SupportHandler"] = None
def set_next(self, handler: "SupportHandler") -> "SupportHandler":
self._next = handler
return handler # allows chaining: h1.set_next(h2).set_next(h3)
@abstractmethod
def handle(self, ticket_level: int) -> str | None: ...
class FrontlineSupport(SupportHandler):
def handle(self, level: int) -> str | None:
if level <= 1:
return "Frontline resolved the ticket"
if self._next:
return self._next.handle(level)
return None
class TechSupport(SupportHandler):
def handle(self, level: int) -> str | None:
if level <= 3:
return "Tech support resolved the ticket"
if self._next:
return self._next.handle(level)
return None
class EngineeringSupport(SupportHandler):
def handle(self, level: int) -> str | None:
return "Engineering resolved the ticket" # always handles
frontline = FrontlineSupport()
tech = TechSupport()
engineering = EngineeringSupport()
frontline.set_next(tech).set_next(engineering)
for level in [1, 2, 3, 4, 5]:
result = frontline.handle(level)
print(f"Level {level}: {result}")
If every request must be handled, add a final handler that always handles (catches all):
class FallbackHandler(SupportHandler):
def handle(self, level: int) -> str | None:
return f"No handler found for level {level} — escalated to manager"
Alternatively, let None return indicate "not handled" and check at the call site.
Forgetting to call self._next.handle() — if a handler doesn't forward when it can't handle the request, the chain silently swallows it. Always forward when not handling.
Circular chains. If h1.next = h2 and h2.next = h1, the chain loops forever. Validate chain configuration or use a framework (Spring Security, Express) that prevents this.
Coupling handler order to business logic. If the chain only works in one specific order, it's not really flexible. Handlers should be order-independent for the cases they handle.
npx claudepluginhub jeffreytse/grimoire --plugin grimoireImplements the Chain of Responsibility pattern with linked handler chains and async middleware pipelines. Useful for request routing, validation, and event processing.
Generates Chain of Responsibility pattern for PHP 8.4, creating handler chains for middleware-style request processing like validation and approvals. Includes unit tests.
Adds runtime object responsibilities via wrapping (Decorator pattern). Applies to OOP codebases, especially Java I/O streams, Python decorators, and Django middleware.