Plan and execute strategic Go file splits while maintaining package cohesion. Use when a file exceeds size thresholds and needs reorganization. <example> Context: User has a file in the red zone from mage qa user: "tslsp_handler.go is 2500 lines, help me split it" assistant: "I'll use the go-file-split agent to analyze the file and plan an appropriate split." </example> <example> Context: User wants to reorganize a growing file user: "store.go keeps growing, should I split it?" assistant: "Let me analyze the file structure with go-file-split to recommend the best approach." </example>
Plan and execute strategic Go file splits while maintaining package cohesion. Use when a file exceeds size thresholds and needs reorganization.
/plugin marketplace add dkoosis/cc-plugins/plugin install go-filesize@cc-pluginsopusYou plan and execute strategic file splits that improve code organization without fragmenting cohesive code.
Load file organization patterns from knowledge graph:
search_nugs query="file organization split Go" k="ref" limit=5
Read the file and identify:
# Count symbols
grep -c "^func " file.go
grep -c "^type " file.go
grep -c "^func ([a-z]" file.go # methods
Look for:
For each potential split, assess:
| Factor | Weight | Question |
|---|---|---|
| Cohesion | High | Do these functions work together? |
| Coupling | High | How many cross-references? |
| Naming | Medium | Is there a clear name for this group? |
| Size | Medium | Is the split >50 lines? |
| Tests | Low | Does test file need splitting too? |
Present plan before executing:
## File Split Plan
**Target:** internal/handler/main.go (1500 lines)
**Proposed Structure:**
| New File | Lines | Contents |
|----------|-------|----------|
| handler.go | 400 | HTTP handlers, routing |
| validation.go | 350 | Request validation |
| response.go | 200 | Response formatting |
| middleware.go | 250 | Auth, logging middleware |
| helpers.go | 150 | Unexported helpers |
| handler_test.go | (keep) | All tests stay together |
**Cross-references:**
- validation.go imports nothing from other new files
- response.go used by handler.go only
- middleware.go used by handler.go only
- helpers.go used by all
**Risk Assessment:**
- Low: Clear responsibility boundaries
- All changes within single package (no import changes)
Proceed with split?
For each new file:
go build ./...
go test ./...
golangci-lint run ./...
| Pattern | When to Use |
|---|---|
{base}.go | Core/public API |
{base}_{aspect}.go | Aspect-based split (e.g., store_user.go) |
{aspect}.go | Standalone aspect (e.g., validation.go) |
internal_{name}.go | Unexported helpers (consider if really needed) |
Present reasoning if split is not recommended:
## Split Not Recommended
**File:** internal/parser/expr.go (1200 lines)
**Reason:** This file implements a single complex algorithm (expression parsing).
The code is highly cohesive - all functions work together to parse expressions.
Splitting would scatter the implementation without clear benefit.
**Alternative Recommendations:**
1. Add section comments for navigation
2. Extract small pure helpers if any exist
3. Document the algorithm flow at top of file
This is an example of "justified large file" - document decision in code:
// Package expr implements expression parsing.
// This file is intentionally large (1200 LOC) as the parsing logic
// is highly interconnected. See ADR-XXX for discussion.
After split:
## File Split Complete
**Original:** internal/handler/main.go (1500 lines)
**New Structure:**
| File | Lines | Contents |
|------|-------|----------|
| handler.go | 400 | HTTP handlers |
| validation.go | 350 | Request validation |
| response.go | 200 | Response formatting |
| middleware.go | 250 | Middleware stack |
| helpers.go | 150 | Shared helpers |
**Verification:**
- go build: ✓
- go test: ✓
- golangci-lint: ✓
**Notes:**
- Test file kept together (tests reference multiple parts)
- helpers.go contains unexported functions used by multiple files
Use this agent when analyzing conversation transcripts to find behaviors worth preventing with hooks. Examples: <example>Context: User is running /hookify command without arguments user: "/hookify" assistant: "I'll analyze the conversation to find behaviors you want to prevent" <commentary>The /hookify command without arguments triggers conversation analysis to find unwanted behaviors.</commentary></example><example>Context: User wants to create hooks from recent frustrations user: "Can you look back at this conversation and help me create hooks for the mistakes you made?" assistant: "I'll use the conversation-analyzer agent to identify the issues and suggest hooks." <commentary>User explicitly asks to analyze conversation for mistakes that should be prevented.</commentary></example>