Skip to content
Back to skills

Srp

ASecurity

Refactor a class toward the Single Responsibility Principle by identifying responsibilities, grouping cohesive behavior, and extracting focused classes. Use when the user says `/srp`, asks for SRP refactoring, or runs `/refactor:srp`.

  • 8 stars
  • 0 votes
  • 0 copies
  • 3 views
  • Added September 9, 2026
code-qualityrefactoring

Security analysis

A100/100

Scanned September 9, 2026

npx -y skills add SDiamante13/dotfiles --skill srp --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Srp?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Srp
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/sdiamante13-srp/badge)](https://www.skillsdirectory.com/skills/sdiamante13-srp)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: srp
description: Refactor a class toward the Single Responsibility Principle by identifying responsibilities, grouping cohesive behavior, and extracting focused classes. Use when the user says `/srp`, asks for SRP refactoring, or runs `/refactor:srp`.
metadata:
  legacy-name: refactor:srp
---

Refactor the class provided in $ARGUMENTS to adhere to the Single Responsibility Principle by extracting classes and simplifying the design.

## Instructions:
1. Identify all responsibilities within the given class
2. Group related methods and properties by their cohesive purpose
3. Extract each responsibility into its own focused class
4. Consider alternative, simpler designs that make future changes easier
5. Ensure each resulting class has only one reason to change

## Analysis approach:
- **Identify responsibilities by**:
    - Methods that serve different actors/users
    - Distinct areas of functionality
    - Different reasons for change
    - Unrelated data and behavior groupings
    - Infrastructure vs domain logic separation
    - I/O operations vs business logic

## Common responsibility patterns to separate:
- Data persistence/storage from business logic
- Validation logic from core behavior
- Formatting/presentation from domain logic
- External service communication from internal logic
- Configuration from implementation
- Factory/creation logic from usage
- Orchestration/coordination from execution
- Logging/metrics from business operations

## Output format:
1. **Current responsibilities**: List each identified responsibility with supporting methods/properties
2. **Proposed class structure**:
    - Name and purpose of each extracted class
    - Methods and properties it would contain
    - Clear single responsibility statement
3. **Refactored design**: Show the transformed code structure
4. **Alternative designs**: Present 1-2 simpler alternatives if applicable
5. **Benefits**: Explain how each extraction improves:
    - Testability
    - Maintainability
    - Flexibility for change
    - Code clarity

## Design principles to apply:
- Prefer composition over inheritance
- Keep classes small and focused
- High cohesion within classes
- Low coupling between classes
- Clear, single purpose for each class
- Consider using interfaces for flexibility

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.