This skill should be used when the user asks to "review a branch", "compare code quality", mentions "branch review", "code quality scorecard", discusses comparing old vs new code, or wants a scored assessment of changes on a feature branch.
This skill should be used when the user asks about "boy scout rule", "leaving code cleaner", mentions "continuous improvement", discusses incremental code quality improvements, or wants to improve code they are already touching.
This skill should be used when the user asks to "find code smells", "review code quality", mentions "code smells", "technical debt", discusses identifying problematic code patterns, or wants a systematic code quality assessment.
This skill should be used when the user asks about "functional error handling", mentions "Result type", "Either type", "Option type", "Maybe monad", discusses replacing try-catch with types, or wants to handle errors without exceptions.
This skill should be used when the user asks about "higher-order functions", "HOFs", mentions "map filter reduce", "callbacks", discusses reducing loop duplication, or wants to abstract common patterns with function parameters.
This skill should be used when the user asks about "pure functions", "side effects", mentions "immutability", "referential transparency", discusses hidden state changes, or wants to make functions more predictable and testable.
This skill should be used when the user asks about "domain isolation", "anti-corruption layer", mentions "keeping domain pure", discusses preventing infrastructure leakage into business logic, or wants to protect the domain model from external concerns.
This skill should be used when the user asks about "ports and adapters", "hexagonal architecture", mentions "clean architecture boundaries", discusses separating infrastructure from domain, or wants to structure code with clear system boundaries.
This skill should be used when the user asks about "composition over inheritance", mentions "favoring composition", discusses deep inheritance hierarchies, fragile base class problems, or wants to combine behaviors flexibly.
This skill should be used when the user asks about "encapsulation", "information hiding", mentions "exposing internal state", discusses public fields, getter/setter abuse, or wants to protect object invariants.
This skill should be used when the user asks to "extract a method", "break up a long function", mentions "extract method refactoring", discusses reducing method length, or wants to decompose complex logic into smaller pieces.
This skill should be used when the user asks to "rename a variable", "improve naming", mentions "meaningful names", "naming conventions", discusses unclear or misleading identifiers, or wants to make code more readable through better names.
This skill should be used when the user asks to "replace conditionals", "refactor switch statements", mentions "polymorphism", discusses complex branching logic, type-based conditionals, or wants to eliminate long if-else or switch-case chains.
This skill should be used when the user asks about "dependency inversion", "DIP", mentions "depending on abstractions", discusses decoupling from implementations, or wants to make high-level modules independent of low-level details.
This skill should be used when the user asks about "interface segregation", "ISP", mentions "fat interfaces", discusses clients forced to depend on methods they don't use, or wants to design smaller, focused interfaces.
This skill should be used when the user asks about "Liskov substitution", "LSP", mentions "subtype behavior", discusses inheritance hierarchies, or wants to verify that subtypes are safe replacements for their base types.
This skill should be used when the user asks about "open-closed principle", "OCP", mentions "extending behavior without modifying code", discusses adding new features to existing systems, or wants to design extensible modules.
This skill should be used when the user asks about "single responsibility", "SRP", mentions "separation of concerns", discusses classes doing too much, or wants to identify when a class has multiple reasons to change.
This skill should be used when the user asks to "structure tests", "organize test code", mentions "arrange act assert", "AAA pattern", "given when then", discusses test readability, or wants to improve test structure.
This skill should be used when the user asks to "do TDD", "write tests first", mentions "red-green-refactor", discusses test-driven development cycles, or wants to build features incrementally with tests.
This skill should be used when the user asks to "write tests first", "start with a test", mentions "test-first development", discusses writing tests before implementation, or wants to ensure code is testable by design.
★not rated 2 6mo agoA49 tokens
originalMIT
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: