
Refactor Method Complexity Reduce
Shrink a named method’s cognitive complexity at or below a threshold by extracting focused helper methods.
Overview
Refactor Method Complexity Reduce is an agent skill most often used in Ship (also Build backend, Operate iterate) that refactors one method below a cognitive-complexity threshold by extracting helpers.
Install
npx skills add https://github.com/github/awesome-copilot --skill refactor-method-complexity-reduceWhat is this skill?
- Targets a named method and explicit cognitive-complexity threshold as inputs
- Analyzes nesting, switch chains, repeated blocks, and boolean expressions as complexity sources
- Extracts Validate*, handler, and utility helpers with single responsibilities
- Simplifies the main method via orchestration, reduced nesting, and cleaner dispatch
Adoption & trust: 9.2k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
One method fails complexity gates or is unreadable, and you need a repeatable extraction plan instead of ad-hoc edits.
Who is it for?
A single overstuffed handler, parser, or validator you can point the agent at by name with a numeric threshold from your analyzer.
Skip if: Repo-wide redesign, performance-only micro-optimizations with no complexity issue, or greenfield code with no existing method body.
When should I use this skill?
Refactor given method to reduce cognitive complexity to threshold or below by extracting helper methods.
What do I get? / Deliverables
The target method meets the complexity threshold with focused helpers and a simpler control-flow spine in the same codebase.
- Refactored main method under threshold
- New private or static helper methods with focused responsibilities
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Complexity reduction is a canonical code-review and quality pass before merge or release. Review subphase is where cognitive-complexity limits and readability fixes are enforced on specific hotspots.
Where it fits
CI reports cognitive complexity 25 on ProcessOrder; agent extracts validators until below 15.
Feature branch added switch-on-type logic; extract handlers before opening the PR.
Hotfix added nested guards; simplify the method so the next on-call engineer can trace paths.
How it compares
Use for one-method cognitive-complexity extraction—not as a full architecture or domain-modeling refactor playbook.
Common Questions / FAQ
Who is refactor-method-complexity-reduce for?
Solo builders and small teams maintaining backend or service code who hit Sonar-style cognitive complexity limits on specific methods.
When should I use refactor-method-complexity-reduce?
Use it in Ship review before merge when complexity fails CI, in Build backend while implementing a feature that grew nested branches, and in Operate iterate when fixing production paths without re-breaking readability.
Is refactor-method-complexity-reduce safe to install?
It drives refactors in your repository—review diffs carefully and check the Security Audits panel on this page; it has no bundled network or secret access by default.
SKILL.md
READMESKILL.md - Refactor Method Complexity Reduce
# Refactor Method to Reduce Cognitive Complexity ## Objective Refactor the method `${input:methodName}`, to reduce its cognitive complexity to `${input:complexityThreshold}` or below, by extracting logic into focused helper methods. ## Instructions 1. **Analyze the current method** to identify sources of cognitive complexity: - Nested conditional statements - Multiple if-else or switch chains - Repeated code blocks - Multiple loops with conditions - Complex boolean expressions 2. **Identify extraction opportunities**: - Validation logic that can be extracted into a separate method - Type-specific or case-specific processing that repeats - Complex transformations or calculations - Common patterns that appear multiple times 3. **Extract focused helper methods**: - Each helper should have a single, clear responsibility - Extract validation into separate `Validate*` methods - Extract type-specific logic into handler methods - Create utility methods for common operations - Use appropriate access levels (static, private, async) 4. **Simplify the main method**: - Reduce nesting depth - Replace massive if-else chains with smaller orchestrated calls - Use switch statements where appropriate for cleaner dispatch - Ensure the main method reads as a high-level flow 5. **Preserve functionality**: - Maintain the same input/output behavior - Keep all validation and error handling - Preserve exception types and error messages - Ensure all parameters are properly passed to helpers 6. **Best practices**: - Make helper methods static when they don't need instance state - Use null checks and guard clauses early - Avoid creating unnecessary local variables - Consider using tuples for multiple return values - Group related helper methods together ## Implementation Approach - Extract helper methods before refactoring the main flow - Test incrementally to ensure no regressions - Use meaningful names that describe the extracted responsibility - Keep extracted methods close to where they're used - Consider making repeated code patterns into generic methods ## Result The refactored method should: - Have cognitive complexity reduced to the target threshold of `${input:complexityThreshold}` or below - Be more readable and maintainable - Have clear separation of concerns - Be easier to test and debug - Retain all original functionality ## Testing and Validation **CRITICAL: After completing the refactoring, you MUST:** 1. **Run all existing tests** related to the refactored method and its surrounding functionality 2. **MANDATORY: Explicitly verify test results show "failed=0"** - **NEVER assume tests passed** - always examine the actual test output - Search for the summary line containing pass/fail counts (e.g., "passed=X failed=Y") - **If the summary shows any number other than "failed=0", tests have FAILED** - If test output is in a file, read the entire file to locate and verify the failure count - Running tests is NOT the same as verifying tests passed - **Do not proceed** until you have explicitly confirmed zero failures 3. **If any tests fail (failed > 0):** - State clearly how many tests failed - Analyze each failure to understand what functionality was broken - Common causes: null handling, empty collection checks, condition logic errors - Identify the root cause in the refactored code - Correct the refactored code to restore the original behavior - Re-run tests and verify "failed=0" in the output - Repeat until all tests pass (failed=0) 4. **Verify compilation** - Ensure there are no compilation errors 5. **Check cognitive complexity** - Confirm the metric is at or below the target threshold of `${input