| name | streamline |
| description | Identifies files over 300 lines and decomposes them into smaller modules while preserving functionality exactly. Use when user says "streamline", "decompose files", "refactor large files", or wants to break down oversized source files. |
| disable-model-invocation | true |
Streamline Skill
Autonomously identifies oversized source files (>300 lines), creates decomposition plans, and implements refactoring while preserving functionality exactly.
References Folder
Location: .claude/skills/streamline/references/
- file-inventory.json - Single source of truth for file state (line counts, exceptions, decomposed history)
- config.json - Optional project overrides (only create if customizing defaults)
Default Configuration
Embedded defaults (override via references/config.json if needed):
lineThreshold: 300 (files above this need decomposition)targetLineCount: 200 (aim for this after decomposition)backupPath: "deprecated" (where backups go)- Auto-detect source root (looks for
src/directory) - Auto-detect file extensions based on project type
Workflow
Step 1: Load or Initialize Inventory
If references/file-inventory.json doesn't exist:
- Auto-detect source root (find
src/directory, or use project root) - Auto-detect file extensions (scan for .py, .vue, .js, .ts, .tsx)
- Count lines in all matching files
- Create initial inventory JSON
If inventory exists but lastScanned is not today:
- Re-scan all files in the source root
- Update line counts for existing files
- Add any new files discovered
- Remove files that no longer exist
- Update
lastScannedto today's date
Step 2: Select Candidate
From files in inventory:
- Filter to files with
lines > 300 - Exclude paths in
exceptionsarray - Exclude paths in
decomposedarray - Select the largest remaining file
If no candidates remain: Report "No files need decomposition" and exit successfully.
Step 3: Decompose (Interactive Mode)
- Analyze the file - Read and understand its structure
- Create decomposition plan:
- Break into smaller files, each ≤200 lines
- Group by logical area of concern
- Preserve all functionality exactly
- Present plan to user - Explain the logical groupings
- Wait for approval before proceeding
- Create backup in
deprecated/folder with date prefix (e.g.,2025-12-19-tray.py) - Decompose:
- Create new helper/utility modules
- Update original file to import from new modules
- Ensure all imports and references are correct
- Update inventory:
- Add original path to
decomposedarray - Update line counts for all affected files
- Add original path to
- Suggest tests for user to verify functionality
Step 4: Decompose (YOLO Mode)
Same as Step 3 but:
- Skip approval step - proceed immediately
- Auto-select best candidate (largest file)
- Skip test suggestions
- Commit and push changes (see YOLO Mode section)
YOLO Mode
Trigger: Invoked with "yolo" argument or from CI/automated workflow.
When in YOLO mode, complete the entire workflow autonomously:
Autonomous Workflow
- Load inventory - Initialize or update as needed
- Select candidate - Choose largest file over 300 lines
- Create decomposition plan - Design without waiting for approval
- Decompose - Create backup and refactor
- Update inventory - Record the decomposition
- Commit and push changes
Git Operations (YOLO Mode Only)
After successful decomposition:
# Ensure on main branch with latest
git checkout main
git pull origin main
# Stage all changes
git add -A
# Commit with descriptive message
git commit -m "refactor: decompose [filename] into smaller modules
- Created [list new modules]
- Original file reduced from X to Y lines
- Backup saved to deprecated/
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>"
# Push to main
git push origin main
CRITICAL: Do NOT exit without pushing. Unpushed commits will be lost.
No Changes Scenario
If no files need decomposition:
- Report success without making commits
- Exit cleanly
Decomposition Guidelines
File Size Targets
- Files >300 lines → decompose
- Target ≤200 lines per new module
- Original file should import from new modules
Logical Grouping
- Group by area of concern (e.g., UI, data, utilities)
- Keep related functions together
- Maintain clear module boundaries
Naming Conventions
- New modules: descriptive names reflecting their purpose
- Use existing project patterns
- Avoid generic names like
utils.pyorhelpers.js
DRY vs KISS
- Apply DRY (Don't Repeat Yourself) where beneficial
- But prioritize KISS (Keep It Simple) over DRY when:
- Abstraction adds significant complexity
- Code becomes less readable
- Maintenance burden increases
Constraints
Absolute requirements:
- NO functional changes - Reproduce existing functionality exactly
- NO design changes - Preserve visual appearance exactly
- NO behavioral changes - Maintain all existing behavior
- Create dated backup before decomposing any file
- Use forward slashes in all paths (cross-platform)
Linting:
- Interactive mode: Delegate to beautifier agent after completion
- YOLO mode: Rely on pre-commit hooks
Exception Management
Adding Exceptions
To exempt a file from decomposition:
- Add path to
exceptionsarray infile-inventory.json:
"exceptions": ["src/app/tray.py"]
- Document reason below (keep this list updated):
Current Exceptions
(None yet - add as needed)
Example reasons for exemption:
- Virtual scrolling implementation (tight coupling required)
- Threading/async coordination (state must be centralized)
- GUI event handlers (tight coupling to framework)
Auto-Detection Logic
Source Root Detection
Priority order:
src/directory if existslib/directory if exists- Project root (fallback)
File Extension Detection
Scan source root for:
.py→ Python project.vue,.js,.ts,.tsx→ JavaScript/TypeScript project- Multiple types → track all found
Config Override
Create references/config.json to override auto-detection:
{
"sourceRoot": "custom/path",
"fileExtensions": [".py", ".pyx"]
}