Search for a keyword in the current directory (wrapper around ripgrep).

Args: keyword (str): The keyword to search for (case insensitive). working_directory (str): The directory to search in. Use full absolute path. num_context_lines (int): The number of lines of context to return (both before and after the keyword). Default is 2.

Returns: str: The file path and the lines of context around the keyword.

Run kit symbols <repo> and keep the header plus rows that satisfy the filters.

Parameters

repo : str | Path Path or name passed to kit symbols. working_directory : str The directory to run the command from. Use full absolute path. keep_types : Iterable[str] | None Exact values allowed in the Type column (e.g. {"function", "method", "class"}). None ⇒ no type filter. file_must_contain : str | None post-filter: Keep only rows whose File column contains this substring. None ⇒ no inclusion filter. file_must_not_contain : str | None post-filter: Discard rows whose File column contains this substring. None ⇒ no exclusion filter.

Returns

list[str] | str Filtered output, ready to print() or write to a file.

Run kit usages <repo> <symbol_name> and optionally filter by symbol type at the CLI level and then post-filter the rows by file inclusion/exclusion substrings.

Parameters

repo : str | Path Path or name passed to kit usages. Use full absolute path. symbol_name_or_substring : str The symbol whose usages we want to inspect, or a substring of the symbol name (which can be used to find multiple symbols which share a naming convention). working_directory : str Directory from which to run the command (absolute path). symbol_type : str | None "function" or "method" or "class" file_must_contain : str | None post-filter: Keep only rows whose File column contains this substring. None ⇒ no inclusion filter. file_must_not_contain : str | None post-filter: Discard rows whose File column contains this substring. None ⇒ no exclusion filter.

Returns

list[str] | str Filtered output, ready to print() or write to a file.

Analyze repository importance using CodeRank algorithm to identify critical modules.

Args: repo_path: Path to the repository (absolute path) external_modules: Comma-separated list of external modules to track top_n: Number of top modules to return analyze_markdown: Include markdown files in analysis output_format: "summary" for key results, "detailed" for full analysis, "json" for machine-readable

Returns: Ranked list of most important modules with scores

Identify code hotspots by combining CodeRank with symbol usage frequency. Uses kit usages + coderank to find modules that are both highly connected and frequently used.

Args: repo_path: Repository to analyze working_directory: Working directory for commands (absolute path) min_connections: Minimum import connections to consider include_external: Include external module dependencies top_n: Number of top hotspots to return

Returns: Hotspot analysis with modules ranked by importance and usage

Trace dependency chains and analyze refactoring impact for a module. Combines dependency tracing with impact analysis.

Args: repo_path: Repository path target_module: Module to analyze (e.g., 'src.auth.middleware') working_directory: Working directory (absolute path) analysis_type: "dependency" for chain tracing, "refactoring" for impact analysis, "both" for combined max_depth: Maximum depth to trace dependencies change_type: For refactoring - "modify", "split", "merge", or "remove"

Returns: Dependency chains and/or refactoring impact analysis

Enhanced search that combines ripgrep with CodeRank to prioritize results from more important modules.

Args: keyword: Search term (supports regex) repo_path: Repository path working_directory: Working directory (absolute path) rank_results: Sort results by module importance context_lines: Lines of context around matches max_results: Maximum number of results to return

Returns: Search results prioritized by code importance

Analyze recent changes using CodeRank to identify most important modifications. Aggregates changes over the last N days and ranks them by impact.

Args: repo_path: Repository path (absolute) days_back: Number of days to look back for commits target_branch: Branch to analyze (default: main) min_commits: Minimum commits to a file to be considered top_n: Number of top changes to return include_stats: Include detailed statistics

Returns: Ranked list of most important recent changes with metrics

Find modules that are frequently changed together in commits. Identifies coupled modules that might have hidden dependencies.

Args: repo_path: Repository path days_back: Days to analyze min_cochange_frequency: Minimum times modules must change together top_n: Number of top coupled module pairs to return

Returns: Analysis of modules that frequently change together

Analyze contributor patterns and their impact on important modules. Identifies key contributors and their areas of expertise.

Args: repo_path: Repository path days_back: Days to analyze min_commits: Minimum commits by a contributor to be included focus_on_important_modules: Weight contributions by module importance

Returns: Contributor impact analysis with expertise areas

Analyze how changes in one module historically propagate to others. Uses commit history to predict ripple effects of changes.

Args: repo_path: Repository path changed_module: Module to analyze (e.g., 'src.auth.user') days_back: Days of history to analyze include_test_impact: Include analysis of test file changes

Returns: Analysis of likely modules to be affected by changes

Trace how specific data flows through the system from source to destination.

Use this tool when you need to understand:

• How a piece of data (user_id, email, order_data, etc.) moves through the codebase

• What functions transform or modify the data

• Where data comes from and where it goes

• What side effects might occur when processing this data

Perfect for debugging data-related issues, understanding data dependencies, or planning changes that affect data flow.

Args: repo_path: Repository path (absolute) working_directory: Working directory (absolute path) data_identifier: Name of the data to trace (e.g., "user_id", "email", "order") max_depth: How deep to trace the data flow include_transformations: Whether to show data transformation points show_side_effects: Whether to identify potential side effects

Returns: Comprehensive data flow analysis with transformation points and dependencies

Discover error handling patterns and inconsistencies in the codebase.

Use this tool when you need to understand:

• How errors are typically handled in this codebase

• What error handling patterns to follow for consistency

• Where error handling might be missing or inconsistent

• How error handling has evolved over time

Essential for implementing proper error handling that matches the codebase style, debugging error-related issues, or improving error handling consistency.

Args: repo_path: Repository path (absolute) working_directory: Working directory (absolute path) focus_area: Specific area to focus on (e.g., "database", "api", "file_io") custom_patterns: Custom regex patterns for error handling (overrides defaults) custom_antipatterns: Custom regex patterns for antipatterns (overrides defaults) include_antipatterns: Whether to identify problematic error handling show_evolution: Whether to show how error handling has changed days_back: Days of git history to analyze for evolution

Returns: Comprehensive error handling analysis with patterns and recommendations

Map all code involved in implementing a specific feature from UI to data layer.

Use this tool when you need to:

• Understand all components involved in a feature before modifying it

• Map feature implementation across multiple layers (UI, business logic, data)

• Find all related code that might be affected by feature changes

• Understand how a feature is structured and organized

Perfect for feature modification, debugging feature issues, or understanding complex feature implementations that span multiple modules.

Args: repo_path: Repository path (absolute) working_directory: Working directory (absolute path) feature_keywords: List of keywords that identify the feature (e.g., ["login", "authenticate"]) file_categories: Dictionary mapping category names to path patterns for file organization. Format: {"category_name": ["pattern1", "pattern2", ...]}

    Example:
    {
        "ui_frontend": ["view", "template", "component", "ui", "frontend"],
        "api_controllers": ["api", "controller", "endpoint", "route"],
        "business_logic": ["service", "business", "logic", "core"],
        "data_models": ["model", "entity", "schema", "db"],
        "utilities": ["util", "helper", "common"],
        "tests": ["test", "spec"],
        "config": ["config", "setting", "env"]
    }
    
    Files are categorized by checking if any pattern appears in the file path.
    Use descriptive category names that match your project structure.
include_tests: Whether to include test files in the analysis
include_config: Whether to include configuration files
trace_depth: How deep to trace dependencies

Returns: Complete feature implementation map with all involved components by layer

Find real usage examples of APIs, functions, or classes in the codebase.

Use this tool when you need to:

• Learn how to properly use an existing API by seeing real examples

• Understand the different ways an API is used across the codebase

• Find patterns and best practices for API usage

• See what parameters are commonly used and how

Perfect for learning unfamiliar APIs, understanding usage patterns before making changes, or finding examples to follow when implementing similar functionality.

Args: repo_path: Repository path (absolute) working_directory: Working directory (absolute path) api_name: Name of the API/function/class to find examples for max_examples: Maximum number of examples to return group_by_pattern: Whether to group similar usage patterns together include_test_examples: Whether to include examples from test files show_context_lines: Number of context lines around each usage

Returns: Categorized real usage examples with context and patterns

Discover all potential side effects of calling a function or method.

Use this tool when you need to understand:

• What else might happen when you call a specific function

• All the systems/resources that might be affected by a function call

• Potential unintended consequences of code changes

• What to test or monitor when modifying a function

Critical for understanding the full impact of code changes, planning testing strategies, or debugging issues that might be caused by unexpected side effects.

Args: repo_path: Repository path (absolute) working_directory: Working directory (absolute path) target_function: Name of the function to analyze for side effects side_effect_patterns: Dictionary mapping effect types to regex patterns. Format: {"category": ["regex1", "regex2", ...]}

    Example:
    {
        "file": [r"open\(", r"\.write\(", r"\.read\(", r"os\.remove", r"pathlib\."],
        "network": [r"requests\.", r"urllib\.", r"\.get\(", r"\.post\("],
        "database": [r"\.execute\(", r"\.query\(", r"\.commit\(", r"session\."],
        "global_state": [r"global ", r"os\.environ", r"setattr\("],
        "logging": [r"log\.", r"logger\.", r"print\("],
        "cache": [r"\.cache", r"redis\.", r"@lru_cache"]
    }
    
    Each regex pattern will be searched for in the function body to identify
    potential side effects. Use Python regex syntax.
trace_depth: How deep to trace function calls for side effects
include_historical_bugs: Whether to analyze git history for side effect bugs

Returns: Comprehensive side effect analysis with risk assessment and mitigation suggestions

Map all external integration points and their characteristics.

Use this tool when you need to understand:

• What external services or systems the codebase integrates with

• How those integrations are implemented and configured

• Error handling patterns for external dependencies

• Potential failure points and their impact

Essential for understanding system dependencies, planning for service outages, or designing resilient integration patterns.

Args: repo_path: Repository path (absolute) working_directory: Working directory (absolute path) integration_types: Types of integrations to look for (default: common types) custom_patterns: Custom regex patterns for integrations (overrides defaults) include_error_handling: Whether to analyze error handling for integrations show_configuration: Whether to find configuration related to integrations risk_assessment: Whether to assess risks of each integration

Returns: Integration architecture map with dependency risks and patterns

Analyze all possible execution paths through a function and what triggers each path.

Use this tool when you need to understand:

• All the different ways a complex function can execute

• What conditions or parameters lead to different code paths

• Potential edge cases or error conditions

• Decision points and branching logic

Perfect for understanding complex business logic, debugging function behavior, or planning test cases that cover all execution paths.

Args: repo_path: Repository path (absolute) working_directory: Working directory (absolute path) function_name: Name of the function to analyze max_depth: How deep to analyze nested function calls include_call_contexts: Whether to show how the function is called highlight_complex_paths: Whether to identify complex/risky paths

Returns: Execution path analysis with decision points and complexity assessment

Analyze what code is affected by specific configuration values.

Use this tool when you need to understand:

• What code will behave differently if you change a config setting

• How configuration values flow through the system

• What the default behavior is when config is missing

• How configuration changes have been handled historically

Critical for understanding the impact of configuration modifications, planning configuration changes, or debugging configuration-related issues.

Args: repo_path: Repository path (absolute) working_directory: Working directory (absolute path) config_key: Configuration key to analyze (e.g., "DEBUG", "DATABASE_URL") trace_dependent_logic: Whether to trace through conditional logic include_default_handling: Whether to analyze default value handling show_historical_changes: Whether to show config-related git history

Returns: Configuration impact analysis with affected code paths and recommendations

Identify potential performance bottlenecks by analyzing code patterns and complexity.

Use this tool when you need to:

• Find likely performance issues before they become problems

• Prioritize optimization efforts on high-impact code

• Understand which parts of the codebase might be slow

• Plan performance improvements based on actual usage patterns

Perfect for performance optimization planning, code reviews focused on performance, or debugging existing performance issues.

Args: repo_path: Repository path (absolute) working_directory: Working directory (absolute path) focus_areas: Specific performance areas to focus on (default: common bottlenecks) custom_patterns: Custom regex patterns for bottlenecks (overrides defaults) include_usage_frequency: Whether to weight results by code usage frequency days_back: Days of git history to analyze for frequently changed performance code

Returns: Performance bottleneck analysis with optimization recommendations

Analyze testing strategies and identify gaps for better test coverage.

Use this tool when you need to understand:

• How different parts of the code are tested and what patterns are used

• Where test coverage might be missing or insufficient

• What testing frameworks and patterns the codebase follows

• How to write tests that fit the existing testing strategy

Perfect for understanding how to test new code, improving test coverage, or learning the testing patterns used in an unfamiliar codebase.

Args: repo_path: Repository path (absolute) working_directory: Working directory (absolute path) test_types: Types of tests to analyze (default: common test types) custom_file_patterns: Custom regex patterns for test files (overrides defaults) custom_framework_patterns: Custom regex patterns for frameworks (overrides defaults) show_coverage_gaps: Whether to identify modules that might lack tests include_testing_patterns: Whether to analyze testing patterns and frameworks focus_on_important_modules: Whether to prioritize important modules in analysis

Returns: Testing strategy analysis with patterns, gaps, and recommendations