From cocosearch
Guides onboarding to new or unfamiliar codebases by checking CocoSearch index, exploring architecture, key modules, and code patterns via semantic search.
npx claudepluginhub violetcranberry/coco-search --plugin cocosearchThis skill uses the workspace's default tool permissions.
Welcome to a new codebase. I'll guide you through understanding it step-by-step, like a senior developer giving you the tour. We'll use CocoSearch's semantic search to explore the architecture, key modules, and patterns without getting lost in the details.
Explores codebases to answer questions about how code works, trace execution flows, or research topics via semantic search. Offers autonomous mode for structured subagent output and interactive mode with narrative checkpoints.
Performs semantic code search across the codebase using ccc CLI, manages initialization, indexing freshness, path/language filtering, and pagination.
Sets up and optimizes Cursor codebase indexing for @Codebase semantic search. Configures .cursorignore files, verifies status, and details embedding workflow.
Share bugs, ideas, or general feedback.
Welcome to a new codebase. I'll guide you through understanding it step-by-step, like a senior developer giving you the tour. We'll use CocoSearch's semantic search to explore the architecture, key modules, and patterns without getting lost in the details.
Before we start exploring, let me check if we have a CocoSearch index for this codebase.
I'll run:
cocosearch.yaml for indexName field -- if found, use itlist_indexes() and match the current project's directory name against available indexes. The MCP tools auto-derive index names from directory paths (e.g., my-project/ -> my_project), so a match is likely if the repo was indexed without a config file.cocosearch.yaml is missing.list_indexes() - Check what indexes existindex_stats(index_name="<resolved-name>") - Check index health and freshnessWhat to look for:
index_codebase(path, index_name="<resolved-name>") to create one before we start.Why this matters: Stale indexes might miss recent refactorings or new modules. A fresh index gives you the most accurate picture of the codebase.
Let me get the big picture first. I'll search for entry points and project organization to understand what this codebase does and how it's structured.
I'll search for:
search_code("main entry point application startup", symbol_type="function")search_code("module initialization configuration setup")search_code("config settings environment variables")I'll synthesize findings into:
Adaptive branching:
Before moving on: I'll ask "Want me to drill deeper into any specific area?" You might already know where you need to focus.
Based on what I found in Step 1, I'll drill into 2-3 key architectural layers with concrete code examples. I'll use smart_context=True to show you full function bodies, not just snippets.
Common layers to explore:
API/Interface Layer:
search_code("API endpoint handler route", symbol_type=["function", "class"])Business Logic Layer:
search_code("service business logic core", symbol_type="class")Data Layer:
search_code("database model schema repository", symbol_type="class")Adaptive: I'll skip layers that don't exist. A pure library won't have an API layer. A stateless service won't have a data layer.
For each layer I find, I'll show you:
If I discover specific identifiers (like class names or function signatures) in one layer, I'll use use_hybrid_search=True when searching related layers to find connections.
Now that you understand what the codebase does, let me show you how it does it. I'll search for common patterns to help you write code that fits in.
Error Handling:
search_code("error handling exception")Testing Approach:
search_code("test setup fixture mock")Configuration:
search_code("configuration settings environment")I'll synthesize findings:
Adaptive: If the codebase has unique patterns (custom decorators, specific architectural patterns like CQRS or event sourcing), I'll highlight those.
Now you've seen the architecture, key layers, and conventions. Would you like me to generate a codebase summary document for future reference?
If yes, I'll create CODEBASE_OVERVIEW.md in the project root with:
Contents:
Freshness marker:
Why this helps: Future you (or future teammates) can read the overview without re-exploring. The freshness marker tells you when to regenerate if the codebase evolves significantly.
If no: That's fine. You now have a mental model of the codebase from our exploration. You can always run this workflow again later.
During exploration:
After onboarding:
rg "processPayment"Keeping fresh:
index_codebase(path)index_stats() shows last update dateFor installation instructions, see skills/README.md.