extensibilitylisted

# /extensibility — Extensible Design Enforcement Every design, plan, and implementation MUST allow new functionality to be added without modifying existing code. The system should be open for extension but closed for modification. **Why this matters:** Software that requires modifying core code for every new feature becomes brittle, risky, and slow to evolve. Extensible design lets you add capabilities by writing NEW code — not editing existing, tested, working code. This is the difference between systems that scale with the team and systems that bottleneck at every change. **When to invoke:** During PLANNING (after `/gsd:discuss-phase`, before `/gsd:plan-phase`) and during REVIEW (as part of code review criteria). This skill applies to both new code and modifications to existing code. --- ## The Rules ### Rule 1: Open-Closed Principle Modules MUST be open for extension but closed for modification: | Closed for modification | Open for extension | |-------------------------|--------------------| | Core processing pipeline | New processors via registration | | Validation engine | New validators via interface | | Authentication system | New auth providers via adapter pattern | | Report generator | New report formats via strategy pattern | | Event system | New event handlers via subscription | **The test:** Can you add a new [feature type] without editing any existing file? If yes, the design is extensible. If no, find the extension point and create it. ### Rule 2: Exte