Clean oop design
Enforces clean Object-Oriented Programming (OOP) principles when writing or refactoring TypeScript code, ensuring high readability, testability, and maintainability. Trigger when writing new classes or modifying existing methods.From its SKILL.md
npx -y skills add pawel-up/lupa --skill clean-oop-designAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
1.9 KB, 370 tokens by cl100k_base, as published. Nobody here has run it
Clean OOP Design Principles
When writing or refactoring Object-Oriented code in this workspace, you MUST adhere to the following principles to maintain readability and clarity:
1. Single Responsibility Principle (SRP)
- Classes and methods should have one primary reason to change.
- A method should do exactly one thing. If a method exceeds ~20-30 lines, consider breaking it down.
- Avoid large monolithic methods (like "God functions" or massive
exec()loops).
2. Extract Methods for Clarity
- If a block of code within a method can be conceptually grouped (e.g., executing a specific list mode vs test mode, or collecting configuration), extract it into a dedicated
protectedorprivatehelper method. - Name the extracted method descriptively so that it acts as its own documentation.
3. Encapsulation & Access Modifiers
- Use
private(or#in modern JS/TS) for internal state and helpers that should not be exposed. - Use
protectedfor methods that subclasses might need to override or access. - Only expose
publicmethods that form the core API contract of the class.
4. Push Logic to Data Owners
- Instead of an external manager reaching into an object's internal state to serialize or filter it, push that logic into the object itself (e.g., adding a
toJSON()method to the data-holding class instead of mapping it externally).
5. Favor Getters for Derived State
- Instead of evaluating complex boolean checks inline (e.g.,
typeof window !== 'undefined' && !!window.__lupa__?.config?.list), extract them into explicit getters (e.g.,get isList(): boolean) to improve legibility.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most design frontend skills give in 370 tokens
Counted across 1,169 of the 1,878 authors here whose files we hold, read 2026-08-07
- Use CSS variables for color consistencyin 72 of 1169, across 23 files
- Commit to one bold aesthetic direction before codingin 72 of 1169, across 27 files
- Match implementation complexity to the aesthetic visionin 70 of 1169, across 20 files
- Add atmospheric background effects and texturesin 57 of 1169, across 9 files
- Use unexpected spatial compositions and layoutsin 56 of 1169, across 8 files
- Implement real working codein 55 of 1169, across 7 files
- Vary themes and aesthetics across different designsin 48 of 1169, across 7 files
- Launch chromium in headless modein 47 of 1169, across 4 files
- Close the browser when donein 47 of 1169, across 4 files
- Run provided scripts with help flag firstin 47 of 1169, across 4 files
- Wait for network idle statein 47 of 1169, across 4 files
- Use descriptive selectors for elementsin 47 of 1169, across 4 files
Said here and by no other author read
- Ensure classes and methods have one responsibility
- Break down methods exceeding 30 lines
- Avoid monolithic functions
- Extract grouped code blocks into helper methods
- Name extracted methods descriptively
- Hide internal state and helpers using private modifiers
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.