Skip to content
Back to News
release
v8.1
refactoring
announcement

CKB 8.1: Refactoring Intelligence — Cycles, Move Analysis, and Proactive Suggestions

By CKB Team

CKB 8.1 is here, and it's focused on one thing: making refactoring less terrifying. Four new capabilities help your AI assistant understand not just what your code does, but how to safely change it.

What's New

Dependency Cycle Detection (findCycles)

Circular dependencies are one of those problems that slowly strangle a codebase. Module A imports B, B imports C, C imports A. Build times increase. Test isolation becomes impossible. Nobody wants to touch the cycle because they don't know which edge to cut.

findCycles uses Tarjan's strongly-connected-component algorithm to detect every circular dependency in your codebase. It works at three levels of granularity — module, directory, or file — and for each cycle it recommends which edge to break based on import strength.

User: "Are there any dependency cycles in the codebase?"

AI: [calls findCycles with granularity=directory]

"Found 3 dependency cycles:

1. internal/auth → internal/session → internal/auth (severity: low)
   Recommended break: session → auth (2 imports, break cost: 0.2)

2. pkg/api → pkg/models → pkg/validation → pkg/api (severity: medium)
   Recommended break: validation → api (1 import, break cost: 0.1)

3. internal/billing → internal/plans → internal/users →
   internal/permissions → internal/billing (severity: high)
   Recommended break: permissions → billing (3 imports, break cost: 0.15)

Summary: 1 high, 1 medium, 1 low severity."

The break-cost score (0 to 1) tells you how hard each edge is to remove. Lower means fewer imports to untangle. Start with the cheapest break in the highest-severity cycle.

Optimal usage tip: Run findCycles at directory granularity first — it's the most actionable level. File-level cycles are noisy, module-level cycles may be too coarse. If you find cycles, use prepareChange on the recommended break edge to see the full impact before refactoring.

Move/Relocate Analysis

prepareChange now supports a move change type. When you're relocating a file or symbol to a different package, CKB scans the entire repo for affected imports and checks the target location for naming conflicts.

User: "What happens if I move auth/middleware.go to http/middleware.go?"

AI: [calls prepareChange with changeType: "move", targetPath: "internal/http"]

"Move analysis for auth/middleware.go → internal/http/:

Affected imports: 14 files need updating
- internal/api/handlers/user.go (line 8)
- internal/api/handlers/admin.go (line 7)
- internal/api/handlers/webhook.go (line 9)
- ... 11 more files

Target conflicts: 1
- internal/http/middleware.go already exists (file conflict)

Package changes: 14
Risk: medium (many import updates, 1 conflict to resolve)"

With SCIP indexing available, import scanning is precise and complete. Without SCIP, CKB falls back to heuristic scanning that matches import patterns across Go, TypeScript, JavaScript, and Python files.

Optimal usage tip: Always check target conflicts before moving. If CKB reports a file conflict, you'll need to either rename the source file or merge with the existing target. Use planRefactor with changeType: "move" for a complete step-by-step plan including the import updates.

Extract Variable Flow Analysis

The extract change type in prepareChange now uses tree-sitter to analyze variable flow across the extraction boundary. Instead of guessing which variables become parameters and which become return values, CKB reads the AST and tells you.

User: "I want to extract lines 45-80 of processOrder into a separate function."

AI: [calls prepareChange with changeType: "extract"]

"Extract analysis for processOrder (internal/orders/processor.go):

Parameters (defined outside, used in extraction region):
- order Order (defined line 38, used 6 times)
- config *Config (defined line 12, used 3 times)

Returns (defined in region, used after):
- total float64 (defined line 52, used at line 85)
- err error (defined line 60, used at line 88)

Locals (defined and used only in region):
- discount float64 (defined line 55, used 2 times)
- taxRate float64 (defined line 58, used 1 time)

Suggested signature:
func calculateOrderTotal(order Order, config *Config) (float64, error)"

This works for Go, JavaScript/TypeScript, and Python. When CGO isn't available (rare in development, common in some CI environments), CKB gracefully degrades to boundary-only analysis.

Optimal usage tip: The suggested signature is a starting point — review the parameter types, since tree-sitter infers them from the AST rather than full type resolution. Pair this with planRefactor to get the complete extraction plan including test updates.

Proactive Refactoring Suggestions (suggestRefactorings)

Instead of waiting for you to ask "should I refactor this?", suggestRefactorings proactively scans your codebase and surfaces the highest-priority opportunities. It combines four existing analyzers in parallel:

Analyzer What It Detects Suggestion Types
Complexity Functions with cyclomatic > 10 and > 50 lines, cognitive > 15 extract_function, simplify_function
Coupling Files with co-change correlation > 0.7, > 10 dependents reduce_coupling, split_file
Dead code Unused exports and unreferenced symbols remove_dead_code
Risk + test gaps High-risk files without test coverage add_tests

Each suggestion includes a severity (critical/high/medium/low), effort estimate (small/medium/large), and a priority score for ranking.

User: "What should I refactor in the billing module?"

AI: [calls suggestRefactorings with scope: "internal/billing"]

"Found 7 refactoring opportunities:

1. [critical] Extract parts of CalculateInvoice (cyclomatic: 34, 210 lines)
   Effort: large | Priority: 55
   Rationale: Cyclomatic complexity 34 exceeds threshold of 10

2. [high] Add tests for pricing.go (risk: high, score: 72)
   Effort: medium | Priority: 72
   Rationale: Risk score 72, no test file found

3. [high] Simplify ApplyDiscounts (cognitive complexity: 22)
   Effort: medium | Priority: 22
   Rationale: Deeply nested conditionals, hard to follow

4. [medium] Remove unused ExportLegacyFormat (dead code, 95% confidence)
   Effort: small | Priority: 95
   Rationale: No references found in codebase

5. [medium] Reduce coupling for invoice.go (4 highly coupled files)
   Effort: medium | Priority: 40
   Rationale: 4 files change together >70% of the time

... 2 more (low severity)"

Optimal usage tip: Use minSeverity: "medium" to cut noise. Filter by type if you're focused — types: ["extract_function", "simplify_function"] when you're doing complexity cleanup, types: ["remove_dead_code"] for a cleanup sprint. After identifying a target, feed it into prepareChange or planRefactor for the detailed impact analysis.

Unified Refactoring with planRefactor

All of these new capabilities feed into planRefactor, the compound tool introduced in 8.1 that ties everything together. It runs prepareChange, auditRisk, and analyzeTestGaps in parallel, then generates ordered refactoring steps.

User: "Plan the refactoring for moving UserService to a new package."

AI: [calls planRefactor with changeType: "move", targetPath: "internal/services/user"]

"Refactoring plan for UserService:

Risk Assessment: medium (score: 52)
- 8 risk factors analyzed
- Function complexity: handleAuth (cyclomatic: 18), validate (12)

Impact: 23 direct dependents, 41 transitive, 15 affected files

Test Strategy:
- 18 existing tests cover this code
- 2 test gaps found (highest risk: handleAuth)
- Coverage: 78%

Coupling: 5 co-change files (highest: user_repository.go)

Steps:
1. Verify target location — check for conflicts [low risk]
2. Move file/symbol — relocate to target [low risk]
3. Update imports — 23 dependent files [medium risk]
4. Run affected tests — verify nothing broke [low risk]"

Updated Presets: 92 Tools

CKB 8.1 brings the total to 92 MCP tools. The preset system has been updated to reflect this:

Preset Tools Tokens What's New
core 21 ~2k planRefactor added
review 27 ~3k scanSecrets added
refactor 33 ~4k findCycles, suggestRefactorings, analyzeTestGaps, planRefactor
docs 27 ~3k
ops 33 ~4k
federation 34 ~4k
full 92 ~11k All tools

The refactor preset is where most of the new action is. If you're planning a refactoring session, start your AI with:

ckb mcp --preset=refactor

For day-to-day work, the default core preset includes planRefactor so you always have access to unified refactoring planning without loading the full refactoring toolkit. Your AI can expand mid-session if it needs cycle detection or suggestions.

Putting It All Together: A Refactoring Workflow

Here's how to use 8.1's features together for a real refactoring session:

1. Survey the landscape

Ask your AI to scan for refactoring opportunities:

"Run suggestRefactorings on the api/ directory, medium severity and above"

This gives you a prioritized list of what deserves attention.

2. Check for structural problems

"Are there any dependency cycles involving the api/ package?"

findCycles reveals circular dependencies that might be causing the complexity issues surfaced in step 1.

3. Plan the specific refactoring

Pick the highest-priority suggestion and get a detailed plan:

"Plan the extraction of the validation logic from HandleRequest"

planRefactor gives you the risk assessment, impact analysis, test gaps, and ordered steps.

4. Check the move impact (if relocating)

"What happens if I move the extracted validator to internal/validation?"

prepareChange with move shows you every import that needs updating and any conflicts at the target.

5. Execute and verify

Make the changes, run the affected tests identified by CKB, and use the generated PR description to document the refactoring.

Upgrade

CKB 8.1 is backward compatible. Update and you're done:

npm update -g @tastehub/ckb

If you're using CKB via MCP, restart your AI assistant or run /clear to pick up the new tools.


Links: