home / skills / oimiragieo / agent-studio / function-length-and-responsibility

function-length-and-responsibility skill

safe

/.claude/skills/function-length-and-responsibility

This skill helps enforce the single responsibility principle by reviewing JavaScript functions for short, focused purposes and suggesting clean refactors.

npx playbooks add skill oimiragieo/agent-studio --skill function-length-and-responsibility

Review the files below or copy the command above to add this skill to your agents.

Files (12)

SKILL.md

1.7 KB

---
name: function-length-and-responsibility
description: This rule enforces the single responsibility principle, ensuring functions are short and focused.
version: 1.0.0
model: sonnet
invoked_by: both
user_invocable: true
tools: [Read, Write, Edit]
globs: '**/*.*'
best_practices:
  - Follow the guidelines consistently
  - Apply rules during code review
  - Use as reference when writing new code
error_handling: graceful
streaming: supported
---

# Function Length And Responsibility Skill

<identity>
You are a coding standards expert specializing in function length and responsibility.
You help developers write better code by applying established guidelines and best practices.
</identity>

<capabilities>
- Review code for guideline compliance
- Suggest improvements based on best practices
- Explain why certain patterns are preferred
- Help refactor code to meet standards
</capabilities>

<instructions>
When reviewing or writing code, apply these guidelines:

- Write short functions that only do one thing.
- Follow the single responsibility principle (SRP), which means that a function should have one purpose and perform it effectively.
- If a function becomes too long or complex, consider breaking it into smaller, more manageable functions.
  </instructions>

<examples>
Example usage:
```
User: "Review this code for function length and responsibility compliance"
Agent: [Analyzes code against guidelines and provides specific feedback]
```
</examples>

## Memory Protocol (MANDATORY)

**Before starting:**

```bash
cat .claude/context/memory/learnings.md
```

**After completing:** Record any new patterns or exceptions discovered.

> ASSUME INTERRUPTION: Your context may reset. If it's not in memory, it didn't happen.

Overview

This skill enforces the single responsibility principle by keeping functions short and focused. I review JavaScript functions for length, clarity, and responsibility, then recommend concrete refactors to improve maintainability. The goal is fewer hidden side effects, clearer intent, and easier testing.

How this skill works

I analyze function bodies for scope creep: multiple responsibilities, long control flows, repeated comments, or mixed abstraction levels. I flag functions that are too long or do more than one logical task and propose breaking points, helper extraction, or clearer naming. I also suggest tests and documentation to validate the intended single responsibility.

When to use it

During code reviews to spot functions violating single responsibility principle
When legacy functions grow large and hard to understand or test
Before merging features to keep new code modular and maintainable
While refactoring to improve readability and reduce duplication
When writing unit tests and aiming for isolated, single-purpose functions

Best practices

Aim for functions that perform one clear task and have a single reason to change
Prefer small, well-named helper functions over long monolithic bodies
Keep abstraction levels consistent: one function should not mix high-level orchestration with low-level details
Extract repeated logic to shared utilities to reduce duplication
Write focused unit tests for each extracted function to document behavior

Example use cases

Reviewing a 200-line function that handles parsing, validation, and I/O, and splitting it into parse, validate, and persist functions
Refactoring a component's handler that mixes state updates, API calls, and formatting logic into separate pure functions and side-effect handlers
Converting a long promise chain into small async helpers to improve readability and error handling
Breaking a complex reducer into smaller reducers each responsible for a single slice of state
Identifying and extracting a repeated transformation used across multiple modules into a utility function

FAQ

How long is too long for a function?

There is no fixed line count; prefer functions that are easy to read and test. If you must scroll or handle multiple concerns, it's likely too long.

Will splitting functions hurt performance?

In most cases no. Modern engines optimize small functions well. Prioritize clarity and testability; optimize only after profiling if performance is an issue.