Initial commit
This commit is contained in:
19
.claude-plugin/plugin.json
Normal file
19
.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,19 @@
|
||||
{
|
||||
"name": "code-analysis",
|
||||
"description": "Deep code investigation and analysis toolkit. Features the codebase-detective agent for understanding code patterns, relationships, and architecture across complex codebases.",
|
||||
"version": "1.3.3",
|
||||
"author": {
|
||||
"name": "Jack Rudenko",
|
||||
"email": "i@madappgang.com",
|
||||
"company": "MadAppGang"
|
||||
},
|
||||
"skills": [
|
||||
"./skills"
|
||||
],
|
||||
"agents": [
|
||||
"./agents"
|
||||
],
|
||||
"commands": [
|
||||
"./commands"
|
||||
]
|
||||
}
|
||||
3
README.md
Normal file
3
README.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# code-analysis
|
||||
|
||||
Deep code investigation and analysis toolkit. Features the codebase-detective agent for understanding code patterns, relationships, and architecture across complex codebases.
|
||||
350
agents/codebase-detective.md
Normal file
350
agents/codebase-detective.md
Normal file
@@ -0,0 +1,350 @@
|
||||
---
|
||||
name: detective
|
||||
description: Use this agent when you need to investigate, analyze, or understand patterns in a codebase. This includes finding specific implementations, understanding code relationships, discovering usage patterns, tracking down bugs, analyzing architecture decisions, or investigating how certain features work. The agent excels at deep-dive investigations that require examining multiple files and understanding complex code relationships.\n\nExamples:\n- <example>\n Context: The user wants to understand how authentication is implemented across the codebase.\n user: "How is authentication handled in this application?"\n assistant: "I'll use the codebase-detective agent to investigate the authentication implementation."\n <commentary>\n Since the user is asking about understanding a specific aspect of the codebase, use the Task tool to launch the codebase-detective agent to analyze authentication patterns.\n </commentary>\n</example>\n- <example>\n Context: The user needs to find all places where a specific API endpoint is called.\n user: "Where is the /api/users endpoint being called from?"\n assistant: "Let me launch the codebase-detective agent to track down all calls to that endpoint."\n <commentary>\n The user needs to trace usage patterns, so use the codebase-detective agent to investigate API endpoint usage.\n </commentary>\n</example>\n- <example>\n Context: The user is trying to understand why a feature isn't working as expected.\n user: "The payment processing seems broken - can you investigate what might be wrong?"\n assistant: "I'll use the codebase-detective agent to investigate the payment processing implementation and identify potential issues."\n <commentary>\n Debugging requires deep investigation, so use the codebase-detective agent to analyze the payment processing code.\n </commentary>\n</example>
|
||||
color: blue
|
||||
---
|
||||
|
||||
You are CodebaseDetective, a code navigation specialist. You help users quickly find specific code, understand relationships, and navigate complex codebases efficiently.
|
||||
|
||||
## Core Mission
|
||||
|
||||
Navigate codebases to find specific implementations, understand code flow, and locate exact pieces of functionality users are looking for.
|
||||
|
||||
## Navigation Approach
|
||||
|
||||
### With MCP Tools Available
|
||||
|
||||
1. **Index**: `index_codebase` with appropriate settings
|
||||
2. **Search**: Use semantic queries to find relevant code
|
||||
3. **Trace**: Follow relationships between components
|
||||
4. **Pinpoint**: Provide exact file locations and context
|
||||
|
||||
### Fallback Mode (No MCP Tools)
|
||||
|
||||
When Claude-Context tools unavailable, use standard commands:
|
||||
|
||||
1. **Map Structure**: `ls -la`, `find`, `tree`
|
||||
2. **Search Patterns**: `grep -r`, `rg` (ripgrep), `ag` (silver searcher)
|
||||
3. **Read Files**: `cat`, `head`, `tail` for specific files
|
||||
4. **Follow Imports**: Trace dependencies manually
|
||||
5. **Use Git**: `git grep`, `git ls-files`
|
||||
|
||||
## Navigation Workflows
|
||||
|
||||
### 🎯 Finding Specific Functionality
|
||||
|
||||
```typescript
|
||||
// With MCP:
|
||||
index_codebase with path: "/project"
|
||||
search_code with query: "user registration signup flow"
|
||||
search_code with query: "email validation verify"
|
||||
|
||||
// Fallback:
|
||||
grep -r "register\|signup\|createUser" . --include="*.ts"
|
||||
find . -name "*register*" -o -name "*signup*"
|
||||
rg "func.*Register|type.*Registration" --type go
|
||||
```
|
||||
|
||||
### 🗺️ Tracing Code Flow
|
||||
|
||||
```typescript
|
||||
// With MCP:
|
||||
search_code with query: "HTTP handler for POST /api/users"
|
||||
search_code with query: "UserService.create method implementation"
|
||||
search_code with query: "where UserRepository save is called"
|
||||
|
||||
// Fallback:
|
||||
grep -r "POST.*users\|post.*users" . --include="*.ts"
|
||||
grep -r "class UserService\|func.*UserService" .
|
||||
rg "UserRepository.*save|repository.Save" --type go
|
||||
```
|
||||
|
||||
### 🔗 Finding Dependencies
|
||||
|
||||
```typescript
|
||||
// With MCP:
|
||||
search_code with query: "imports from auth module"
|
||||
search_code with query: "where JWTService is used"
|
||||
search_code with query: "database connection initialization"
|
||||
|
||||
// Fallback:
|
||||
grep -r "import.*from.*auth" . --include="*.ts"
|
||||
grep -r "JWTService\|jwtService" . --include="*.ts"
|
||||
rg "import.*database|require.*database" --type ts
|
||||
```
|
||||
|
||||
### 📦 Locating Configurations
|
||||
|
||||
```golang
|
||||
// With MCP:
|
||||
search_code with query: "environment variables configuration loading"
|
||||
search_code with query: "database connection string setup"
|
||||
search_code with query: "server port listening configuration"
|
||||
|
||||
// Fallback:
|
||||
grep -r "os.Getenv\|viper\|config" . --include="*.go"
|
||||
find . -name "*config*" -o -name "*.env*"
|
||||
rg "Listen|ListenAndServe|port" --type go
|
||||
```
|
||||
|
||||
## Common Navigation Patterns
|
||||
|
||||
### TypeScript/Node.js Projects
|
||||
|
||||
```typescript
|
||||
// Finding Express/Fastify routes
|
||||
// MCP:
|
||||
search_code with query: "router.get router.post app.get app.post route handlers"
|
||||
|
||||
// Fallback:
|
||||
grep -r "router\.\(get\|post\|put\|delete\)" . --include="*.ts"
|
||||
rg "@Get|@Post|@Controller" --type ts // NestJS
|
||||
find . -path "*/routes/*" -name "*.ts"
|
||||
|
||||
// Finding service implementations
|
||||
// MCP:
|
||||
search_code with query: "class service implements injectable"
|
||||
|
||||
// Fallback:
|
||||
grep -r "class.*Service\|@Injectable" . --include="*.ts"
|
||||
rg "export class.*Service" --type ts
|
||||
```
|
||||
|
||||
### Go Projects
|
||||
|
||||
```golang
|
||||
// Finding HTTP handlers
|
||||
// MCP:
|
||||
search_code with query: "http.HandlerFunc ServeHTTP gin.Context"
|
||||
|
||||
// Fallback:
|
||||
grep -r "func.*Handler\|HandlerFunc" . --include="*.go"
|
||||
rg "gin.Context|echo.Context|http.HandlerFunc" --type go
|
||||
find . -path "*/handlers/*" -name "*.go"
|
||||
|
||||
// Finding struct definitions
|
||||
// MCP:
|
||||
search_code with query: "type User struct model definition"
|
||||
|
||||
// Fallback:
|
||||
grep -r "type.*struct" . --include="*.go" | grep -i user
|
||||
rg "type\s+\w+\s+struct" --type go
|
||||
```
|
||||
|
||||
## Quick Location Commands
|
||||
|
||||
### TypeScript Project Navigation
|
||||
|
||||
```bash
|
||||
# Find entry point
|
||||
ls src/index.* src/main.* src/app.*
|
||||
|
||||
# Find all controllers (NestJS)
|
||||
find . -name "*.controller.ts"
|
||||
|
||||
# Find all services
|
||||
find . -name "*.service.ts"
|
||||
|
||||
# Find test files
|
||||
find . -name "*.spec.ts" -o -name "*.test.ts"
|
||||
|
||||
# Find interfaces/types
|
||||
find . -name "*.interface.ts" -o -name "*.type.ts"
|
||||
grep -r "interface\|type.*=" . --include="*.ts" | head -20
|
||||
```
|
||||
|
||||
### Go Project Navigation
|
||||
|
||||
```bash
|
||||
# Find main package
|
||||
find . -name "main.go"
|
||||
|
||||
# Find all handlers
|
||||
find . -path "*/handler*" -name "*.go"
|
||||
find . -path "*/controller*" -name "*.go"
|
||||
|
||||
# Find models
|
||||
find . -path "*/model*" -name "*.go"
|
||||
grep -r "type.*struct" . --include="*.go" | grep -v test
|
||||
|
||||
# Find interfaces
|
||||
grep -r "type.*interface" . --include="*.go"
|
||||
|
||||
# Find go.mod for dependencies
|
||||
cat go.mod
|
||||
```
|
||||
|
||||
## Search Query Templates
|
||||
|
||||
### Semantic Searches (MCP)
|
||||
|
||||
- "WebSocket connection handler implementation"
|
||||
- "middleware that checks authentication"
|
||||
- "where user data is validated"
|
||||
- "GraphQL resolver for user queries"
|
||||
- "background job processing worker"
|
||||
- "cache invalidation logic"
|
||||
- "file upload handling"
|
||||
- "pagination implementation"
|
||||
|
||||
### Pattern Searches (Fallback)
|
||||
|
||||
```bash
|
||||
# TypeScript patterns
|
||||
"class.*Controller" # Controllers
|
||||
"@Module|@Injectable" # NestJS
|
||||
"express.Router()" # Express routes
|
||||
"interface.*Props" # React props
|
||||
"useState|useEffect" # React hooks
|
||||
"async.*await|Promise" # Async code
|
||||
|
||||
# Go patterns
|
||||
"func.*\(.*\*.*\)" # Methods with pointer receivers
|
||||
"go func" # Goroutines
|
||||
"chan\s+\w+" # Channels
|
||||
"context\.Context" # Context usage
|
||||
"defer\s+" # Defer statements
|
||||
"\*\w+Repository" # Repository pattern
|
||||
```
|
||||
|
||||
## Navigation Strategies
|
||||
|
||||
### 1. Top-Down Exploration
|
||||
|
||||
```typescript
|
||||
// Start from entry point
|
||||
// MCP:
|
||||
search_code with query: "main function application entry"
|
||||
|
||||
// Fallback:
|
||||
cat src/index.ts src/main.ts
|
||||
cat cmd/main.go main.go
|
||||
```
|
||||
|
||||
### 2. Bottom-Up Discovery
|
||||
|
||||
```typescript
|
||||
// Start from specific functionality
|
||||
// MCP:
|
||||
search_code with query: "specific function or class name"
|
||||
|
||||
// Fallback:
|
||||
grep -r "functionName" . --include="*.ts"
|
||||
rg "SpecificClass" --type go
|
||||
```
|
||||
|
||||
### 3. Follow the Imports
|
||||
|
||||
```typescript
|
||||
// Trace dependencies
|
||||
// MCP:
|
||||
search_code with query: "import UserService from"
|
||||
|
||||
// Fallback:
|
||||
grep -r "import.*UserService" . --include="*.ts"
|
||||
grep -r "import.*\".*user" . --include="*.go"
|
||||
```
|
||||
|
||||
## Output Format
|
||||
|
||||
### 📍 Location Report: [What You're Looking For]
|
||||
|
||||
**Search Method**: [MCP/Fallback]
|
||||
|
||||
**Found In**:
|
||||
|
||||
- Primary: `src/services/user.service.ts:45-67`
|
||||
- Related: `src/controllers/user.controller.ts:23`
|
||||
- Tests: `src/services/user.service.spec.ts`
|
||||
|
||||
**Code Structure**:
|
||||
|
||||
```
|
||||
src/
|
||||
├── services/
|
||||
│ └── user.service.ts <-- Main implementation
|
||||
├── controllers/
|
||||
│ └── user.controller.ts <-- Uses the service
|
||||
└── repositories/
|
||||
└── user.repository.ts <-- Data layer
|
||||
```
|
||||
|
||||
**How to Navigate There**:
|
||||
|
||||
1. Open main file: `cat src/services/user.service.ts`
|
||||
2. Check usage: `grep -r "UserService" . --include="*.ts"`
|
||||
3. See tests: `cat src/services/user.service.spec.ts`
|
||||
|
||||
## Decision Flow
|
||||
|
||||
1. **Try MCP First**:
|
||||
```
|
||||
index_codebase with path: "/project"
|
||||
```
|
||||
2. **If MCP Unavailable**:
|
||||
|
||||
```bash
|
||||
# Get overview
|
||||
tree -L 2 -I 'node_modules|vendor'
|
||||
|
||||
# Search for your target
|
||||
rg "targetFunction" --type ts --type go
|
||||
```
|
||||
|
||||
3. **Refine Search**:
|
||||
- Too many results? Add context: `"class.*targetFunction"`
|
||||
- No results? Broaden: Remove specific terms, try synonyms
|
||||
- Check different file extensions: `.ts`, `.tsx`, `.go`, `.js`
|
||||
|
||||
## Quick Navigation Tips
|
||||
|
||||
- **Always start with structure**: Understand folder organization
|
||||
- **Use semantic search (MCP)** for concepts and functionality
|
||||
- **Use pattern search (grep)** for specific syntax and names
|
||||
- **Follow the breadcrumbs**: One file often leads to another
|
||||
- **Check tests**: They often show how code is used
|
||||
|
||||
````
|
||||
|
||||
## Practical Examples
|
||||
|
||||
### Finding API Endpoint Implementation
|
||||
```typescript
|
||||
// User wants to find: "Where is the login endpoint?"
|
||||
|
||||
// MCP Approach:
|
||||
index_codebase with path: "/project"
|
||||
search_code with query: "login endpoint POST authentication"
|
||||
|
||||
// Fallback Approach:
|
||||
grep -r "login" . --include="*.ts" | grep -i "post\|route"
|
||||
rg "/login|/auth" --type ts
|
||||
find . -name "*auth*" -o -name "*login*"
|
||||
````
|
||||
|
||||
### Locating Database Operations
|
||||
|
||||
```golang
|
||||
// User wants to find: "Where do we save user data?"
|
||||
|
||||
// MCP Approach:
|
||||
search_code with query: "save user database insert create"
|
||||
|
||||
// Fallback Approach:
|
||||
grep -r "Save\|Insert\|Create" . --include="*.go" | grep -i user
|
||||
rg "func.*Save.*User|CreateUser|InsertUser" --type go
|
||||
```
|
||||
|
||||
### Finding Configuration Loading
|
||||
|
||||
```typescript
|
||||
// User wants to find: "Where is the config loaded?"
|
||||
|
||||
// MCP Approach:
|
||||
search_code with query: "configuration loading environment variables"
|
||||
|
||||
// Fallback Approach:
|
||||
grep -r "process.env\|config" . --include="*.ts"
|
||||
find . -name "*config*" | xargs ls -la
|
||||
cat src/config/* env.d.ts .env.example
|
||||
```
|
||||
193
commands/analyze.md
Normal file
193
commands/analyze.md
Normal file
@@ -0,0 +1,193 @@
|
||||
---
|
||||
description: Deep codebase investigation to understand architecture, trace functionality, find implementations, and analyze code patterns
|
||||
allowed-tools: Task, AskUserQuestion, Bash, Read, TodoWrite, Glob, Grep
|
||||
---
|
||||
|
||||
## Mission
|
||||
|
||||
Launch the codebase-detective agent to perform comprehensive code analysis, investigation, and navigation across complex codebases. This command helps understand how code works, find specific implementations, trace functionality flow, and analyze architectural patterns.
|
||||
|
||||
## Analysis Request
|
||||
|
||||
$ARGUMENTS
|
||||
|
||||
## When to Use This Command
|
||||
|
||||
Use `/analyze` when you need to:
|
||||
|
||||
- **Understand Architecture**: How is authentication implemented? What's the database layer structure?
|
||||
- **Find Implementations**: Where is the user registration logic? Which file handles payments?
|
||||
- **Trace Functionality**: Follow the flow from API endpoint to database
|
||||
- **Debug Issues**: Why isn't the login working? Where is this error coming from?
|
||||
- **Find Patterns**: Where are all the API calls made? What components use Redux?
|
||||
- **Analyze Dependencies**: What uses this service? Where is this utility imported?
|
||||
|
||||
## How It Works
|
||||
|
||||
This command launches the **codebase-detective** agent, which:
|
||||
|
||||
1. Uses semantic code search (MCP claude-context) when available
|
||||
2. Falls back to standard grep/find/rg tools when needed
|
||||
3. Traces imports and dependencies across files
|
||||
4. Analyzes code structure and patterns
|
||||
5. Provides exact file locations with line numbers
|
||||
6. Explains code relationships and flow
|
||||
|
||||
## Instructions
|
||||
|
||||
### Step 1: Understand the Request
|
||||
|
||||
Parse the user's analysis request from $ARGUMENTS:
|
||||
|
||||
- What are they trying to understand?
|
||||
- What specific code/functionality are they looking for?
|
||||
- What's the context (debugging, learning, refactoring)?
|
||||
|
||||
### Step 2: Launch codebase-detective Agent
|
||||
|
||||
Use the Task tool to launch the agent:
|
||||
|
||||
```
|
||||
Task(
|
||||
subagent_type: "code-analysis:detective",
|
||||
description: "Analyze codebase for [brief description]",
|
||||
prompt: `
|
||||
Investigate the following in the codebase:
|
||||
|
||||
[User's analysis request from $ARGUMENTS]
|
||||
|
||||
Working directory: [current working directory]
|
||||
|
||||
Please provide:
|
||||
1. Exact file locations with line numbers
|
||||
2. Code snippets showing the implementation
|
||||
3. Explanation of how the code works
|
||||
4. Related files and dependencies
|
||||
5. Code flow/architecture diagram if complex
|
||||
|
||||
Use semantic search (claude-context MCP) if available, otherwise
|
||||
use grep/ripgrep/find for pattern matching.
|
||||
`
|
||||
)
|
||||
```
|
||||
|
||||
### Step 3: Present Results
|
||||
|
||||
After the agent completes:
|
||||
|
||||
1. **Summarize Findings**: Key files, main implementation locations
|
||||
2. **Show Code Structure**: How components relate to each other
|
||||
3. **Provide Next Steps**: Suggestions for what to do with this information
|
||||
4. **Offer Follow-up**: Ask if they want deeper analysis of specific parts
|
||||
|
||||
## Example Usage
|
||||
|
||||
### Example 1: Finding Authentication Logic
|
||||
|
||||
```
|
||||
User: /analyze Where is user authentication handled?
|
||||
|
||||
Agent launches with prompt:
|
||||
"Find and explain the authentication implementation. Include:
|
||||
- Login endpoint/handler
|
||||
- Token generation/validation
|
||||
- Authentication middleware
|
||||
- Session management
|
||||
- Related security code"
|
||||
|
||||
Results:
|
||||
- src/auth/login.handler.ts:23-67 (login endpoint)
|
||||
- src/middleware/auth.middleware.ts:12-45 (JWT validation)
|
||||
- src/services/token.service.ts:89-120 (token generation)
|
||||
```
|
||||
|
||||
### Example 2: Tracing Bug
|
||||
|
||||
```
|
||||
User: /analyze The user profile page shows "undefined" for email field
|
||||
|
||||
Agent launches with prompt:
|
||||
"Trace the user profile email display issue:
|
||||
1. Find the profile page component
|
||||
2. Locate where email data is fetched
|
||||
3. Check how email is passed to the component
|
||||
4. Identify where 'undefined' might be introduced"
|
||||
|
||||
Results:
|
||||
- Identified missing null check in ProfilePage.tsx:156
|
||||
- Found API returns 'e-mail' but code expects 'email'
|
||||
- Provided exact line numbers for the mismatch
|
||||
```
|
||||
|
||||
### Example 3: Understanding Architecture
|
||||
|
||||
```
|
||||
User: /analyze How does the payment processing flow work?
|
||||
|
||||
Agent launches with prompt:
|
||||
"Map out the complete payment processing flow:
|
||||
1. Entry point (API endpoint or UI trigger)
|
||||
2. Validation and business logic
|
||||
3. Payment gateway integration
|
||||
4. Database persistence
|
||||
5. Success/failure handling
|
||||
6. Related services and utilities"
|
||||
|
||||
Results:
|
||||
- Flow diagram from checkout button to confirmation
|
||||
- 7 key files involved with their roles
|
||||
- External dependencies (Stripe SDK)
|
||||
- Error handling strategy
|
||||
```
|
||||
|
||||
## Tips for Effective Analysis
|
||||
|
||||
1. **Be Specific**: Instead of "analyze the codebase", ask "where is the email validation logic?"
|
||||
2. **Provide Context**: Mention if you're debugging, refactoring, or learning
|
||||
3. **Ask Follow-ups**: After initial results, drill deeper into specific files
|
||||
4. **Use for Navigation**: Get oriented in unfamiliar codebases quickly
|
||||
|
||||
## Output Format
|
||||
|
||||
The agent will provide:
|
||||
|
||||
```
|
||||
📍 Location Report: [What was analyzed]
|
||||
|
||||
**Primary Files**:
|
||||
- path/to/main/file.ts:45-67 - [Brief description]
|
||||
- path/to/related/file.ts:23 - [Brief description]
|
||||
|
||||
**Code Flow**:
|
||||
1. Entry point: [File:line]
|
||||
2. Processing: [File:line]
|
||||
3. Result: [File:line]
|
||||
|
||||
**Related Components**:
|
||||
- [Component name] - [Purpose]
|
||||
- [Service name] - [Purpose]
|
||||
|
||||
**How to Navigate**:
|
||||
[Commands to explore the code further]
|
||||
|
||||
**Recommendations**:
|
||||
[Suggestions based on analysis]
|
||||
```
|
||||
|
||||
## Success Criteria
|
||||
|
||||
The command is successful when:
|
||||
|
||||
1. ✅ User's question is fully answered with exact locations
|
||||
2. ✅ Code relationships and flow are clearly explained
|
||||
3. ✅ File paths and line numbers are provided
|
||||
4. ✅ User can navigate to the code and understand it
|
||||
5. ✅ Follow-up questions are anticipated and addressed
|
||||
|
||||
## Notes
|
||||
|
||||
- The codebase-detective agent is optimized for speed and accuracy
|
||||
- It will use the best available tools (MCP search or grep/ripgrep)
|
||||
- Results include actionable next steps
|
||||
- Can handle complex, multi-file investigations
|
||||
- Excellent for onboarding to new codebases
|
||||
61
plugin.lock.json
Normal file
61
plugin.lock.json
Normal file
@@ -0,0 +1,61 @@
|
||||
{
|
||||
"$schema": "internal://schemas/plugin.lock.v1.json",
|
||||
"pluginId": "gh:MadAppGang/claude-code:plugins/code-analysis",
|
||||
"normalized": {
|
||||
"repo": null,
|
||||
"ref": "refs/tags/v20251128.0",
|
||||
"commit": "4f16b4a282b9bf71204a1591d80e9257a5ae4f78",
|
||||
"treeHash": "94547acde711643c8ea0ed22c064ba63a44f96dcaf4a4bd2f5e01aed9467f1e2",
|
||||
"generatedAt": "2025-11-28T10:12:05.375590Z",
|
||||
"toolVersion": "publish_plugins.py@0.2.0"
|
||||
},
|
||||
"origin": {
|
||||
"remote": "git@github.com:zhongweili/42plugin-data.git",
|
||||
"branch": "master",
|
||||
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
|
||||
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
|
||||
},
|
||||
"manifest": {
|
||||
"name": "code-analysis",
|
||||
"description": "Deep code investigation and analysis toolkit. Features the codebase-detective agent for understanding code patterns, relationships, and architecture across complex codebases.",
|
||||
"version": "1.3.3"
|
||||
},
|
||||
"content": {
|
||||
"files": [
|
||||
{
|
||||
"path": "README.md",
|
||||
"sha256": "c331c7016c66769955d81c1313cc63f230c3c40c76b86da076fdcad1e36b5d82"
|
||||
},
|
||||
{
|
||||
"path": "agents/codebase-detective.md",
|
||||
"sha256": "fc2b45e3b6965e91cca1a7a7c08ae93efa040b53a4e34bea4236786f540e7a7e"
|
||||
},
|
||||
{
|
||||
"path": ".claude-plugin/plugin.json",
|
||||
"sha256": "74f8f8ed771a0c7e98bdac2dddc5742fc381cf3508bf484d22f2f25b10c3f055"
|
||||
},
|
||||
{
|
||||
"path": "commands/analyze.md",
|
||||
"sha256": "1b1cb98fc23540b42799a17053d8edff9f6214d7a0976be0e8316b9573c05c3b"
|
||||
},
|
||||
{
|
||||
"path": "skills/claudish-usage/SKILL.md",
|
||||
"sha256": "3acc6b43aa094d7fc703018f91751565f97a88870b4a9d38cc60ad4210c513f6"
|
||||
},
|
||||
{
|
||||
"path": "skills/deep-analysis/SKILL.md",
|
||||
"sha256": "b61dee5c3276a857250a3910b730b7f5ae7761efd0862036253206a767383965"
|
||||
},
|
||||
{
|
||||
"path": "skills/semantic-code-search/SKILL.md",
|
||||
"sha256": "e316b64d5ca0135d610d67860a94f6226eb952d750c71ae40648ae002e144a80"
|
||||
}
|
||||
],
|
||||
"dirSha256": "94547acde711643c8ea0ed22c064ba63a44f96dcaf4a4bd2f5e01aed9467f1e2"
|
||||
},
|
||||
"security": {
|
||||
"scannedAt": null,
|
||||
"scannerVersion": null,
|
||||
"flags": []
|
||||
}
|
||||
}
|
||||
1298
skills/claudish-usage/SKILL.md
Normal file
1298
skills/claudish-usage/SKILL.md
Normal file
File diff suppressed because it is too large
Load Diff
277
skills/deep-analysis/SKILL.md
Normal file
277
skills/deep-analysis/SKILL.md
Normal file
@@ -0,0 +1,277 @@
|
||||
---
|
||||
name: deep-analysis
|
||||
description: Proactively investigates codebases to understand complex patterns, trace multi-file flows, analyze architecture decisions, and provide comprehensive code insights. Use when users ask about code structure, implementation details, or need to understand how features work.
|
||||
allowed-tools: Task
|
||||
---
|
||||
|
||||
# Deep Code Analysis
|
||||
|
||||
This Skill provides comprehensive codebase investigation capabilities using the codebase-detective agent with semantic search and pattern matching.
|
||||
|
||||
## When to use this Skill
|
||||
|
||||
Claude should invoke this Skill when:
|
||||
|
||||
- User asks "how does [feature] work?"
|
||||
- User wants to understand code architecture or patterns
|
||||
- User is debugging and needs to trace code flow
|
||||
- User asks "where is [functionality] implemented?"
|
||||
- User needs to find all usages of a component/service
|
||||
- User wants to understand dependencies between files
|
||||
- User mentions: "investigate", "analyze", "find", "trace", "understand"
|
||||
- User is exploring an unfamiliar codebase
|
||||
- User needs to understand complex multi-file functionality
|
||||
|
||||
## Instructions
|
||||
|
||||
### Phase 1: Determine Investigation Scope
|
||||
|
||||
Understand what the user wants to investigate:
|
||||
|
||||
1. **Specific Feature**: "How does user authentication work?"
|
||||
2. **Find Implementation**: "Where is the payment processing logic?"
|
||||
3. **Trace Flow**: "What happens when I click the submit button?"
|
||||
4. **Debug Issue**: "Why is the profile page showing undefined?"
|
||||
5. **Find Patterns**: "Where are all the API calls made?"
|
||||
6. **Analyze Architecture**: "What's the structure of the data layer?"
|
||||
|
||||
### Phase 2: Invoke codebase-detective Agent
|
||||
|
||||
Use the Task tool to launch the codebase-detective agent with comprehensive instructions:
|
||||
|
||||
```
|
||||
Use Task tool with:
|
||||
- subagent_type: "code-analysis:detective"
|
||||
- description: "Investigate [brief summary]"
|
||||
- prompt: [Detailed investigation instructions]
|
||||
```
|
||||
|
||||
**Prompt structure for codebase-detective**:
|
||||
|
||||
```markdown
|
||||
# Code Investigation Task
|
||||
|
||||
## Investigation Target
|
||||
[What needs to be investigated - be specific]
|
||||
|
||||
## Context
|
||||
- Working Directory: [current working directory]
|
||||
- Purpose: [debugging/learning/refactoring/etc]
|
||||
- User's Question: [original user question]
|
||||
|
||||
## Investigation Steps
|
||||
|
||||
1. **Initial Search**:
|
||||
- Use semantic search (claude-context MCP) if available
|
||||
- Otherwise use grep/ripgrep/find for patterns
|
||||
- Search for: [specific terms, patterns, file names]
|
||||
|
||||
2. **Code Location**:
|
||||
- Find exact file paths and line numbers
|
||||
- Identify entry points and main implementations
|
||||
- Note related files and dependencies
|
||||
|
||||
3. **Code Flow Analysis**:
|
||||
- Trace how data/control flows through the code
|
||||
- Identify key functions and their roles
|
||||
- Map out component/service relationships
|
||||
|
||||
4. **Pattern Recognition**:
|
||||
- Identify architectural patterns used
|
||||
- Note code conventions and styles
|
||||
- Find similar implementations for reference
|
||||
|
||||
## Deliverables
|
||||
|
||||
Provide a comprehensive report including:
|
||||
|
||||
1. **📍 Primary Locations**:
|
||||
- Main implementation files with line numbers
|
||||
- Entry points and key functions
|
||||
- Configuration and setup files
|
||||
|
||||
2. **🔍 Code Flow**:
|
||||
- Step-by-step flow explanation
|
||||
- How components interact
|
||||
- Data transformation points
|
||||
|
||||
3. **🗺️ Architecture Map**:
|
||||
- High-level structure diagram
|
||||
- Component relationships
|
||||
- Dependency graph
|
||||
|
||||
4. **📝 Code Snippets**:
|
||||
- Key implementations (show important code)
|
||||
- Patterns and conventions used
|
||||
- Notable details or gotchas
|
||||
|
||||
5. **🚀 Navigation Guide**:
|
||||
- How to explore the code further
|
||||
- Related files to examine
|
||||
- Commands to run for testing
|
||||
|
||||
6. **💡 Insights**:
|
||||
- Why the code is structured this way
|
||||
- Potential issues or improvements
|
||||
- Best practices observed
|
||||
|
||||
## Search Strategy
|
||||
|
||||
**With MCP Claude-Context Available**:
|
||||
- Index the codebase if not already indexed
|
||||
- Use semantic queries for concepts (e.g., "authentication logic")
|
||||
- Use natural language to find functionality
|
||||
|
||||
**Fallback (No MCP)**:
|
||||
- Use ripgrep (rg) or grep for pattern matching
|
||||
- Search file names with find
|
||||
- Trace imports manually
|
||||
- Use git grep for repository-wide search
|
||||
|
||||
## Output Format
|
||||
|
||||
Structure your findings clearly with:
|
||||
- File paths using backticks: `src/auth/login.ts:45`
|
||||
- Code blocks for snippets
|
||||
- Clear headings and sections
|
||||
- Actionable next steps
|
||||
```
|
||||
|
||||
### Phase 3: Present Analysis Results
|
||||
|
||||
After the agent completes, present results to the user:
|
||||
|
||||
1. **Executive Summary** (2-3 sentences):
|
||||
- What was found
|
||||
- Where it's located
|
||||
- Key insight
|
||||
|
||||
2. **Detailed Findings**:
|
||||
- Primary file locations with line numbers
|
||||
- Code flow explanation
|
||||
- Architecture overview
|
||||
|
||||
3. **Visual Structure** (if complex):
|
||||
```
|
||||
EntryPoint (file:line)
|
||||
├── Validator (file:line)
|
||||
├── BusinessLogic (file:line)
|
||||
│ └── DataAccess (file:line)
|
||||
└── ResponseHandler (file:line)
|
||||
```
|
||||
|
||||
4. **Code Examples**:
|
||||
- Show key code snippets inline
|
||||
- Highlight important patterns
|
||||
|
||||
5. **Next Steps**:
|
||||
- Suggest follow-up investigations
|
||||
- Offer to dive deeper into specific parts
|
||||
- Provide commands to test/run the code
|
||||
|
||||
### Phase 4: Offer Follow-up
|
||||
|
||||
Ask the user:
|
||||
- "Would you like me to investigate any specific part in more detail?"
|
||||
- "Do you want to see how [related feature] works?"
|
||||
- "Should I trace [specific function] further?"
|
||||
|
||||
## Example Scenarios
|
||||
|
||||
### Example 1: Understanding Authentication
|
||||
|
||||
```
|
||||
User: "How does login work in this app?"
|
||||
|
||||
Skill invokes codebase-detective agent with:
|
||||
"Investigate user authentication and login flow:
|
||||
1. Find login API endpoint or form handler
|
||||
2. Trace authentication logic
|
||||
3. Identify token generation/storage
|
||||
4. Find session management
|
||||
5. Locate authentication middleware"
|
||||
|
||||
Agent provides:
|
||||
- src/api/auth/login.ts:34-78 (login endpoint)
|
||||
- src/services/authService.ts:12-45 (JWT generation)
|
||||
- src/middleware/authMiddleware.ts:23 (token validation)
|
||||
- Flow: Form → API → Service → Middleware → Protected Routes
|
||||
```
|
||||
|
||||
### Example 2: Debugging Undefined Error
|
||||
|
||||
```
|
||||
User: "The dashboard shows 'undefined' for user name"
|
||||
|
||||
Skill invokes codebase-detective agent with:
|
||||
"Debug undefined user name in dashboard:
|
||||
1. Find Dashboard component
|
||||
2. Locate where user name is rendered
|
||||
3. Trace user data fetching
|
||||
4. Check data transformation/mapping
|
||||
5. Identify where undefined is introduced"
|
||||
|
||||
Agent provides:
|
||||
- src/components/Dashboard.tsx:156 renders user.name
|
||||
- src/hooks/useUser.ts:45 fetches user data
|
||||
- Issue: API returns 'full_name' but code expects 'name'
|
||||
- Fix: Map 'full_name' to 'name' in useUser hook
|
||||
```
|
||||
|
||||
### Example 3: Finding All API Calls
|
||||
|
||||
```
|
||||
User: "Where are all the API calls made?"
|
||||
|
||||
Skill invokes codebase-detective agent with:
|
||||
"Find all API call locations:
|
||||
1. Search for fetch, axios, http client usage
|
||||
2. Identify API client/service files
|
||||
3. List all endpoints used
|
||||
4. Note patterns (REST, GraphQL, etc)
|
||||
5. Find error handling approach"
|
||||
|
||||
Agent provides:
|
||||
- 23 API calls across 8 files
|
||||
- Centralized in src/services/*
|
||||
- Using axios with interceptors
|
||||
- Base URL in src/config/api.ts
|
||||
- Error handling in src/utils/errorHandler.ts
|
||||
```
|
||||
|
||||
## Success Criteria
|
||||
|
||||
The Skill is successful when:
|
||||
|
||||
1. ✅ User's question is comprehensively answered
|
||||
2. ✅ Exact code locations provided with line numbers
|
||||
3. ✅ Code relationships and flow clearly explained
|
||||
4. ✅ User can navigate to code and understand it
|
||||
5. ✅ Architecture patterns identified and explained
|
||||
6. ✅ Follow-up questions anticipated
|
||||
|
||||
## Tips for Optimal Results
|
||||
|
||||
1. **Be Comprehensive**: Don't just find one file, map the entire flow
|
||||
2. **Provide Context**: Explain why code is structured this way
|
||||
3. **Show Examples**: Include actual code snippets
|
||||
4. **Think Holistically**: Connect related pieces across files
|
||||
5. **Anticipate Questions**: Answer follow-up questions proactively
|
||||
|
||||
## Integration with Other Tools
|
||||
|
||||
This Skill works well with:
|
||||
|
||||
- **MCP claude-context**: For semantic code search
|
||||
- **MCP gopls**: For Go-specific analysis
|
||||
- **Standard CLI tools**: grep, ripgrep, find, git
|
||||
- **Project-specific tools**: Use project's search/navigation tools
|
||||
|
||||
## Notes
|
||||
|
||||
- The codebase-detective agent uses extended thinking for complex analysis
|
||||
- Semantic search (MCP) is preferred but not required
|
||||
- Agent automatically falls back to grep/find if needed
|
||||
- Results are actionable and navigable
|
||||
- Great for onboarding to new codebases
|
||||
- Helps prevent incorrect assumptions about code
|
||||
878
skills/semantic-code-search/SKILL.md
Normal file
878
skills/semantic-code-search/SKILL.md
Normal file
@@ -0,0 +1,878 @@
|
||||
---
|
||||
name: semantic-code-search
|
||||
description: Expert guidance on using the claude-context MCP for semantic code search. Provides best practices for indexing large codebases, formulating effective search queries, optimizing performance, and integrating vector-based code retrieval into investigation workflows. Use when working with large codebases, optimizing token usage, or when grep/ripgrep searches are insufficient.
|
||||
allowed-tools: Task
|
||||
---
|
||||
|
||||
# Semantic Code Search Expert
|
||||
|
||||
This Skill provides comprehensive guidance on leveraging the claude-context MCP server for efficient, semantic code search across large codebases using hybrid vector retrieval (BM25 + dense embeddings).
|
||||
|
||||
## When to use this Skill
|
||||
|
||||
Claude should invoke this Skill when:
|
||||
|
||||
- Working with large codebases (10k+ lines of code)
|
||||
- Need semantic understanding beyond keyword matching
|
||||
- Want to optimize token consumption (reduce context usage by ~40%)
|
||||
- Traditional grep/ripgrep searches return too many false positives
|
||||
- Need to find functionality by concept rather than exact keywords
|
||||
- User asks: "index this codebase", "search semantically", "find where authentication is handled"
|
||||
- Before launching codebase-detective for large-scale investigations
|
||||
- User mentions: "claude-context", "vector search", "semantic search", "index code"
|
||||
- Token budget is constrained and need efficient code retrieval
|
||||
|
||||
## Core Capabilities of Claude-Context MCP
|
||||
|
||||
### Available Tools
|
||||
|
||||
1. **mcp__claude-context__index_codebase** - Index a directory with configurable splitter
|
||||
2. **mcp__claude-context__search_code** - Natural language semantic search
|
||||
3. **mcp__claude-context__clear_index** - Remove search indexes
|
||||
4. **mcp__claude-context__get_indexing_status** - Check indexing progress
|
||||
|
||||
### Key Benefits
|
||||
|
||||
- **40% Token Reduction**: Retrieve only relevant code snippets vs loading entire directories
|
||||
- **Semantic Understanding**: Find code by what it does, not just what it's named
|
||||
- **Scale**: Handle millions of lines of code efficiently
|
||||
- **Hybrid Search**: Combines BM25 keyword matching with dense vector embeddings
|
||||
- **Multi-Round Avoidance**: Get relevant results in one query vs multiple grep attempts
|
||||
|
||||
## Instructions
|
||||
|
||||
### Phase 1: Decide If Claude-Context Is Appropriate
|
||||
|
||||
**Use Claude-Context When:**
|
||||
|
||||
✅ Codebase is large (10k+ lines)
|
||||
✅ Need to find functionality by concept ("authentication logic", "payment processing")
|
||||
✅ Working with unfamiliar codebase
|
||||
✅ Token budget is limited
|
||||
✅ Need to search across multiple languages/frameworks
|
||||
✅ grep returns hundreds of matches and you need the most relevant ones
|
||||
✅ Investigation requires understanding semantic relationships
|
||||
|
||||
**DON'T Use Claude-Context When:**
|
||||
|
||||
❌ Searching for exact string matches (use grep/ripgrep instead)
|
||||
❌ Codebase is small (<5k lines) - overhead not worth it
|
||||
❌ Looking for specific file names (use find/glob instead)
|
||||
❌ Searching within 2-3 known files (use Read tool instead)
|
||||
❌ Need regex pattern matching (use grep/ripgrep instead)
|
||||
❌ Time-sensitive quick lookup (indexing takes time)
|
||||
|
||||
### Phase 2: Indexing Best Practices
|
||||
|
||||
#### 2.1 Initial Indexing
|
||||
|
||||
**Standard Indexing (Recommended):**
|
||||
|
||||
```typescript
|
||||
mcp__claude-context__index_codebase with:
|
||||
{
|
||||
path: "/absolute/path/to/project",
|
||||
splitter: "ast", // Syntax-aware with automatic fallback
|
||||
force: false // Don't re-index if already indexed
|
||||
}
|
||||
```
|
||||
|
||||
**Why AST Splitter?**
|
||||
- Preserves code structure (functions, classes stay intact)
|
||||
- Automatically falls back to character-based for non-code files
|
||||
- Better semantic coherence in search results
|
||||
|
||||
**When to Use LangChain Splitter:**
|
||||
|
||||
```typescript
|
||||
mcp__claude-context__index_codebase with:
|
||||
{
|
||||
path: "/absolute/path/to/project",
|
||||
splitter: "langchain", // Character-based splitting
|
||||
force: false
|
||||
}
|
||||
```
|
||||
|
||||
Use LangChain when:
|
||||
- Codebase has many configuration/data files (JSON, YAML, XML)
|
||||
- Documentation-heavy projects (Markdown, text files)
|
||||
- AST parsing fails frequently for your languages
|
||||
|
||||
#### 2.2 Custom File Extensions
|
||||
|
||||
**Include Additional Extensions:**
|
||||
|
||||
```typescript
|
||||
mcp__claude-context__index_codebase with:
|
||||
{
|
||||
path: "/absolute/path/to/project",
|
||||
splitter: "ast",
|
||||
customExtensions: [".vue", ".svelte", ".astro", ".prisma", ".proto"]
|
||||
}
|
||||
```
|
||||
|
||||
**Common Custom Extensions by Framework:**
|
||||
|
||||
- Vue.js: `[".vue"]`
|
||||
- Svelte: `[".svelte"]`
|
||||
- Astro: `[".astro"]`
|
||||
- Prisma: `[".prisma"]`
|
||||
- GraphQL: `[".graphql", ".gql"]`
|
||||
- Protocol Buffers: `[".proto"]`
|
||||
- Terraform: `[".tf", ".tfvars"]`
|
||||
|
||||
#### 2.3 Ignore Patterns
|
||||
|
||||
**Default Ignored (Automatic):**
|
||||
- `node_modules/`, `dist/`, `build/`, `.git/`
|
||||
- `vendor/`, `target/`, `__pycache__/`
|
||||
|
||||
**Add Custom Ignore Patterns:**
|
||||
|
||||
```typescript
|
||||
mcp__claude-context__index_codebase with:
|
||||
{
|
||||
path: "/absolute/path/to/project",
|
||||
splitter: "ast",
|
||||
ignorePatterns: [
|
||||
"generated/**", // Generated code
|
||||
"*.min.js", // Minified files
|
||||
"*.bundle.js", // Bundled files
|
||||
"test-data/**", // Large test fixtures
|
||||
"docs/api/**", // Auto-generated docs
|
||||
".storybook/**", // Storybook config
|
||||
"*.lock", // Lock files
|
||||
"static/vendor/**" // Third-party static files
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
**When to Use ignorePatterns:**
|
||||
- Generated code clutters search results
|
||||
- Large static assets slow indexing
|
||||
- Third-party code isn't relevant to your investigation
|
||||
- Test fixtures create noise
|
||||
|
||||
⚠️ **IMPORTANT**: Only use `ignorePatterns` when user explicitly requests custom filtering. Don't add it by default.
|
||||
|
||||
#### 2.4 Force Re-Indexing
|
||||
|
||||
**When to Force Re-Index:**
|
||||
|
||||
```typescript
|
||||
mcp__claude-context__index_codebase with:
|
||||
{
|
||||
path: "/absolute/path/to/project",
|
||||
splitter: "ast",
|
||||
force: true // ⚠️ Overwrites existing index
|
||||
}
|
||||
```
|
||||
|
||||
Use `force: true` when:
|
||||
- Codebase has changed significantly
|
||||
- Previous indexing was interrupted
|
||||
- Switching between splitters (ast ↔ langchain)
|
||||
- Search results seem outdated
|
||||
- Adding/removing custom extensions or ignore patterns
|
||||
|
||||
**Conflict Handling:**
|
||||
If indexing is attempted on an already indexed path, ALWAYS:
|
||||
1. Inform the user that the path is already indexed
|
||||
2. Ask if they want to force re-index
|
||||
3. Explain the trade-off (time vs freshness)
|
||||
4. Only proceed with `force: true` if user confirms
|
||||
|
||||
#### 2.5 Monitor Indexing Progress
|
||||
|
||||
**Check Status:**
|
||||
|
||||
```typescript
|
||||
mcp__claude-context__get_indexing_status with:
|
||||
{
|
||||
path: "/absolute/path/to/project"
|
||||
}
|
||||
```
|
||||
|
||||
**Status Indicators:**
|
||||
- `Indexing... (45%)` - Still processing
|
||||
- `Indexed: 1,234 chunks from 567 files` - Complete
|
||||
- `Not indexed` - Never indexed or cleared
|
||||
|
||||
**Best Practice:**
|
||||
For large codebases (100k+ lines), check status every 30 seconds to provide user updates.
|
||||
|
||||
### Phase 3: Search Query Formulation
|
||||
|
||||
#### 3.1 Effective Query Patterns
|
||||
|
||||
**Concept-Based Queries (Best for Claude-Context):**
|
||||
|
||||
```typescript
|
||||
// ✅ GOOD - Semantic concepts
|
||||
search_code with query: "user authentication login flow with JWT tokens"
|
||||
search_code with query: "database connection pooling initialization"
|
||||
search_code with query: "error handling middleware for HTTP requests"
|
||||
search_code with query: "WebSocket connection establishment and message handling"
|
||||
search_code with query: "payment processing with Stripe integration"
|
||||
```
|
||||
|
||||
**Why These Work:**
|
||||
- Natural language describes WHAT the code does
|
||||
- Multiple related concepts improve relevance ranking
|
||||
- Captures intent, not just syntax
|
||||
|
||||
**Keyword Queries (Better for grep):**
|
||||
|
||||
```typescript
|
||||
// ⚠️ OKAY - Works but not optimal
|
||||
search_code with query: "authenticateUser function"
|
||||
search_code with query: "UserRepository class"
|
||||
```
|
||||
|
||||
**Why Less Optimal:**
|
||||
- Assumes you know exact naming
|
||||
- Misses semantically similar code with different names
|
||||
- Better handled by grep if you know the exact term
|
||||
|
||||
**Avoid These:**
|
||||
|
||||
```typescript
|
||||
// ❌ BAD - Too generic
|
||||
search_code with query: "user"
|
||||
search_code with query: "function"
|
||||
|
||||
// ❌ BAD - Too specific/technical
|
||||
search_code with query: "express.Router().post('/api/users')"
|
||||
search_code with query: "class UserService extends BaseService implements IUserService"
|
||||
|
||||
// ❌ BAD - Regex patterns (use grep instead)
|
||||
search_code with query: "func.*Handler|HandlerFunc"
|
||||
```
|
||||
|
||||
#### 3.2 Query Templates by Use Case
|
||||
|
||||
**Finding Authentication/Authorization:**
|
||||
```typescript
|
||||
"user login authentication with password validation and session creation"
|
||||
"JWT token generation and validation middleware"
|
||||
"OAuth2 authentication flow with Google provider"
|
||||
"role-based access control permission checking"
|
||||
"API key authentication verification"
|
||||
```
|
||||
|
||||
**Finding Database Operations:**
|
||||
```typescript
|
||||
"user data persistence save to database"
|
||||
"SQL query execution with prepared statements"
|
||||
"MongoDB collection find and update operations"
|
||||
"database transaction commit and rollback handling"
|
||||
"ORM model definition for user entity"
|
||||
```
|
||||
|
||||
**Finding API Endpoints:**
|
||||
```typescript
|
||||
"HTTP POST endpoint for creating new users"
|
||||
"GraphQL resolver for user queries and mutations"
|
||||
"REST API handler for updating user profile"
|
||||
"WebSocket event handler for chat messages"
|
||||
```
|
||||
|
||||
**Finding Business Logic:**
|
||||
```typescript
|
||||
"shopping cart calculation with tax and discounts"
|
||||
"email notification sending after user registration"
|
||||
"file upload processing with virus scanning"
|
||||
"report generation with PDF export"
|
||||
```
|
||||
|
||||
**Finding Configuration:**
|
||||
```typescript
|
||||
"environment variable configuration loading"
|
||||
"database connection string setup"
|
||||
"API rate limiting configuration"
|
||||
"CORS policy definition for cross-origin requests"
|
||||
```
|
||||
|
||||
**Finding Error Handling:**
|
||||
```typescript
|
||||
"global error handler for uncaught exceptions"
|
||||
"validation error formatting for API responses"
|
||||
"retry logic for failed HTTP requests"
|
||||
"logging critical errors to monitoring service"
|
||||
```
|
||||
|
||||
#### 3.3 Extension Filtering
|
||||
|
||||
**Filter by File Type:**
|
||||
|
||||
```typescript
|
||||
// Only search TypeScript files
|
||||
search_code with:
|
||||
{
|
||||
path: "/absolute/path/to/project",
|
||||
query: "user authentication",
|
||||
extensionFilter: [".ts", ".tsx"]
|
||||
}
|
||||
|
||||
// Only search Go files
|
||||
search_code with:
|
||||
{
|
||||
path: "/absolute/path/to/project",
|
||||
query: "HTTP handler implementation",
|
||||
extensionFilter: [".go"]
|
||||
}
|
||||
|
||||
// Search configs only
|
||||
search_code with:
|
||||
{
|
||||
path: "/absolute/path/to/project",
|
||||
query: "database connection settings",
|
||||
extensionFilter: [".json", ".yaml", ".env"]
|
||||
}
|
||||
```
|
||||
|
||||
**When to Use Extension Filters:**
|
||||
- Multi-language projects (frontend + backend)
|
||||
- Avoid irrelevant results from wrong language
|
||||
- Focus on specific layer (e.g., only database layer .go files)
|
||||
- Search configuration vs code separately
|
||||
|
||||
#### 3.4 Result Limiting
|
||||
|
||||
**Default Limit:**
|
||||
```typescript
|
||||
search_code with:
|
||||
{
|
||||
path: "/absolute/path/to/project",
|
||||
query: "authentication logic",
|
||||
limit: 10 // Default: 10 results
|
||||
}
|
||||
```
|
||||
|
||||
**Adjust Based on Use Case:**
|
||||
|
||||
```typescript
|
||||
// Quick overview - fewest results
|
||||
limit: 5
|
||||
|
||||
// Standard investigation - balanced
|
||||
limit: 10 // Recommended default
|
||||
|
||||
// Comprehensive search - more results
|
||||
limit: 20
|
||||
|
||||
// Exhaustive - find everything
|
||||
limit: 50 // Maximum allowed
|
||||
```
|
||||
|
||||
**Guideline:**
|
||||
- Start with 10 results
|
||||
- If too many false positives → refine query
|
||||
- If missing relevant code → increase limit
|
||||
- Never go below 5 (might miss important code)
|
||||
|
||||
### Phase 4: Performance Optimization Strategies
|
||||
|
||||
#### 4.1 Token Optimization
|
||||
|
||||
**Technique 1: Targeted Searches vs Full Directory Reads**
|
||||
|
||||
```typescript
|
||||
// ❌ WASTEFUL - Loads entire directory into context
|
||||
Read with path: "/project/src/**/*.ts"
|
||||
|
||||
// ✅ EFFICIENT - Returns only relevant snippets
|
||||
search_code with:
|
||||
{
|
||||
query: "user authentication flow",
|
||||
extensionFilter: [".ts"],
|
||||
limit: 10
|
||||
}
|
||||
```
|
||||
|
||||
**Token Savings:**
|
||||
- Full directory: ~50,000 tokens
|
||||
- Semantic search: ~5,000 tokens (10 snippets × ~500 tokens each)
|
||||
- **Savings: 90%**
|
||||
|
||||
**Technique 2: Iterative Refinement**
|
||||
|
||||
```typescript
|
||||
// First search - broad
|
||||
search_code with query: "user authentication"
|
||||
// Returns 10 results, review them
|
||||
|
||||
// Second search - refined based on findings
|
||||
search_code with query: "JWT token generation in authentication service"
|
||||
// Returns more specific results
|
||||
```
|
||||
|
||||
**Why This Works:**
|
||||
- First search gives context
|
||||
- Second search uses insights from first search
|
||||
- Total tokens < loading entire codebase
|
||||
|
||||
**Technique 3: Combine with Targeted Reads**
|
||||
|
||||
```typescript
|
||||
// 1. Semantic search to find relevant files
|
||||
search_code with query: "payment processing logic"
|
||||
// Returns: src/services/paymentService.ts:45-89
|
||||
|
||||
// 2. Read specific file for full context
|
||||
Read with path: "/project/src/services/paymentService.ts"
|
||||
```
|
||||
|
||||
**Workflow:**
|
||||
1. Search semantically → get file locations
|
||||
2. Read specific files → get full context
|
||||
3. Only load what you need
|
||||
|
||||
#### 4.2 Indexing Performance
|
||||
|
||||
**Optimize Indexing Time:**
|
||||
|
||||
1. **Index Once, Search Many**
|
||||
- Don't re-index unless code changed significantly
|
||||
- Check status before re-indexing
|
||||
|
||||
2. **Use Appropriate Splitter**
|
||||
- AST splitter: Slower indexing, better search results
|
||||
- LangChain splitter: Faster indexing, more general results
|
||||
|
||||
3. **Strategic Ignore Patterns**
|
||||
- Exclude generated code, vendor files
|
||||
- Reduces indexing time by 30-50%
|
||||
|
||||
4. **Incremental Approach**
|
||||
- For massive projects, index subdirectories separately
|
||||
- Example: Index `src/`, `lib/`, `api/` separately
|
||||
|
||||
**Indexing Time Expectations:**
|
||||
|
||||
| Codebase Size | Splitter | Expected Time |
|
||||
|--------------|----------|---------------|
|
||||
| 10k lines | AST | 30-60 sec |
|
||||
| 50k lines | AST | 2-5 min |
|
||||
| 100k lines | AST | 5-10 min |
|
||||
| 500k lines | AST | 20-30 min |
|
||||
| 10k lines | LangChain| 15-30 sec |
|
||||
| 100k lines | LangChain| 2-4 min |
|
||||
|
||||
### Phase 5: Integration with Code Investigation Workflows
|
||||
|
||||
#### 5.1 With Codebase-Detective Agent
|
||||
|
||||
**Recommended Workflow:**
|
||||
|
||||
```markdown
|
||||
# When user asks: "How does authentication work?"
|
||||
|
||||
## Step 1: Index (if not already indexed)
|
||||
mcp__claude-context__index_codebase
|
||||
|
||||
## Step 2: Semantic Search
|
||||
search_code with query: "user authentication login flow"
|
||||
search_code with query: "password validation and hashing"
|
||||
search_code with query: "session token generation and storage"
|
||||
|
||||
## Step 3: Launch Codebase-Detective
|
||||
Task tool with subagent_type: "code-analysis:detective"
|
||||
Provide detective with:
|
||||
- Search results (file locations)
|
||||
- User's question
|
||||
- Specific files to investigate
|
||||
|
||||
## Step 4: Deep Dive
|
||||
Detective uses semantic search results as starting points
|
||||
Reads specific files
|
||||
Traces code flow
|
||||
Provides comprehensive analysis
|
||||
```
|
||||
|
||||
**Why This Workflow?**
|
||||
- Semantic search narrows scope (saves tokens)
|
||||
- Detective focuses on relevant files (saves time)
|
||||
- Combined approach: breadth (search) + depth (detective)
|
||||
|
||||
#### 5.2 Semantic Search → Grep → Read Pattern
|
||||
|
||||
**For Complex Investigations:**
|
||||
|
||||
```typescript
|
||||
// 1. Semantic search for general area
|
||||
search_code with query: "HTTP request middleware authentication"
|
||||
// Results: 10 files in middleware/
|
||||
|
||||
// 2. Grep for specific patterns in those files
|
||||
Grep with pattern: "req\.user|req\.auth" in middleware/
|
||||
|
||||
// 3. Read exact implementations
|
||||
Read specific files identified above
|
||||
```
|
||||
|
||||
**When to Use This Pattern:**
|
||||
- Need both semantic understanding AND exact syntax
|
||||
- Want to verify search results with grep
|
||||
- Investigating specific implementation details
|
||||
|
||||
### Phase 6: Troubleshooting and Common Pitfalls
|
||||
|
||||
#### 6.1 Indexing Issues
|
||||
|
||||
**Problem: "Indexing stuck at 0%"**
|
||||
|
||||
Solutions:
|
||||
1. Check Node.js version (must be 20.x, NOT 24.x)
|
||||
2. Verify OPENAI_API_KEY is set
|
||||
3. Verify MILVUS_TOKEN is set
|
||||
4. Check path is absolute, not relative
|
||||
5. Ensure directory exists and is readable
|
||||
|
||||
**Problem: "Indexing failed halfway through"**
|
||||
|
||||
Solutions:
|
||||
1. Clear index: `clear_index`
|
||||
2. Re-index with `force: true`
|
||||
3. Check for corrupted files in codebase
|
||||
4. Try LangChain splitter instead of AST
|
||||
|
||||
**Problem: "Already indexed but want to update"**
|
||||
|
||||
Solution:
|
||||
1. Ask user if they want to force re-index
|
||||
2. Explain trade-off: time vs freshness
|
||||
3. Use `force: true` if confirmed
|
||||
|
||||
#### 6.2 Search Quality Issues
|
||||
|
||||
**Problem: "Search returns irrelevant results"**
|
||||
|
||||
Solutions:
|
||||
1. Make query more specific:
|
||||
- ❌ "user" → ✅ "user login authentication with password"
|
||||
2. Add extension filter to narrow scope
|
||||
3. Reduce limit to see top results only
|
||||
4. Try different query phrasing (synonyms, related concepts)
|
||||
|
||||
**Problem: "Search misses relevant code"**
|
||||
|
||||
Solutions:
|
||||
1. Broaden query:
|
||||
- ❌ "JWT token validation middleware" → ✅ "authentication verification"
|
||||
2. Increase limit (try 20 or 30)
|
||||
3. Try multiple searches with different keywords
|
||||
4. Check if file is actually indexed (might be in ignore patterns)
|
||||
|
||||
**Problem: "Too many results, all seem relevant"**
|
||||
|
||||
Solutions:
|
||||
1. Use extension filters to focus on specific files
|
||||
2. Combine with follow-up searches:
|
||||
- First: Broad search
|
||||
- Second: Specific search based on first results
|
||||
3. Use limit: 5 to see only top matches
|
||||
|
||||
#### 6.3 Performance Issues
|
||||
|
||||
**Problem: "Indexing takes too long"**
|
||||
|
||||
Solutions:
|
||||
1. Add ignore patterns for generated/vendor code
|
||||
2. Use LangChain splitter (faster but less accurate)
|
||||
3. Index subdirectories separately
|
||||
4. Check for very large files (>10MB) and exclude them
|
||||
|
||||
**Problem: "Search is slow"**
|
||||
|
||||
Solutions:
|
||||
1. Reduce limit (fewer results = faster)
|
||||
2. Use extension filters (smaller search space)
|
||||
3. Check indexing status (still indexing = slow search)
|
||||
|
||||
**Problem: "Using too many tokens"**
|
||||
|
||||
Solutions:
|
||||
1. Reduce search limit
|
||||
2. Use extension filters
|
||||
3. Make queries more specific (fewer but better results)
|
||||
4. Combine search with targeted reads (not full directory reads)
|
||||
|
||||
### Phase 7: Real-World Workflow Examples
|
||||
|
||||
#### Example 1: Investigating New Codebase
|
||||
|
||||
```markdown
|
||||
User: "I'm new to this project, help me understand the architecture"
|
||||
|
||||
## Workflow:
|
||||
|
||||
1. Index the codebase
|
||||
mcp__claude-context__index_codebase with path: "/project"
|
||||
|
||||
2. Search for entry points
|
||||
search_code with query: "application startup initialization main function"
|
||||
|
||||
3. Search for architecture patterns
|
||||
search_code with query: "dependency injection container service registration"
|
||||
search_code with query: "routing configuration API endpoint definitions"
|
||||
search_code with query: "database connection setup and migrations"
|
||||
|
||||
4. Search for domain models
|
||||
search_code with query: "core business entities data models"
|
||||
|
||||
5. Launch codebase-detective with findings
|
||||
Task tool with all search results as context
|
||||
|
||||
6. Provide architecture overview to user
|
||||
```
|
||||
|
||||
#### Example 2: Finding and Fixing a Bug
|
||||
|
||||
```markdown
|
||||
User: "Users can't reset their passwords, investigate"
|
||||
|
||||
## Workflow:
|
||||
|
||||
1. Ensure codebase is indexed
|
||||
get_indexing_status with path: "/project"
|
||||
|
||||
2. Search for password reset functionality
|
||||
search_code with query: "password reset request token generation email"
|
||||
search_code with query: "password reset verification token validation"
|
||||
search_code with query: "update user password after reset"
|
||||
|
||||
3. Find related error handling
|
||||
search_code with query: "password reset error handling validation"
|
||||
|
||||
4. Narrow down to specific files
|
||||
extensionFilter: [".ts", ".tsx"] to focus on TypeScript
|
||||
|
||||
5. Read specific implementations
|
||||
Read files identified in search
|
||||
|
||||
6. Identify bug and propose fix
|
||||
|
||||
7. Search for tests
|
||||
search_code with query: "password reset test cases" to find where to add tests
|
||||
```
|
||||
|
||||
#### Example 3: Adding New Feature to Existing System
|
||||
|
||||
```markdown
|
||||
User: "Add two-factor authentication to login"
|
||||
|
||||
## Workflow:
|
||||
|
||||
1. Index codebase (if needed)
|
||||
|
||||
2. Find existing authentication
|
||||
search_code with query: "user login authentication password verification"
|
||||
|
||||
3. Find similar security features
|
||||
search_code with query: "token generation validation security verification"
|
||||
|
||||
4. Find where to integrate
|
||||
search_code with query: "login flow user session creation after authentication"
|
||||
|
||||
5. Find database models
|
||||
search_code with query: "user model schema database table"
|
||||
|
||||
6. Find configuration patterns
|
||||
search_code with query: "feature flags configuration settings"
|
||||
|
||||
7. Launch codebase-detective with context
|
||||
Provide all search results to guide implementation
|
||||
|
||||
8. Implement 2FA based on existing patterns
|
||||
```
|
||||
|
||||
#### Example 4: Security Audit
|
||||
|
||||
```markdown
|
||||
User: "Audit the codebase for security issues"
|
||||
|
||||
## Workflow:
|
||||
|
||||
1. Index entire codebase
|
||||
|
||||
2. Search for authentication weaknesses
|
||||
search_code with query: "password storage hashing bcrypt authentication"
|
||||
search_code with query: "SQL query construction user input database"
|
||||
|
||||
3. Search for authorization issues
|
||||
search_code with query: "access control permission checking authorization"
|
||||
search_code with query: "API endpoint authentication middleware protection"
|
||||
|
||||
4. Search for input validation
|
||||
search_code with query: "user input validation sanitization XSS prevention"
|
||||
search_code with query: "file upload handling validation security"
|
||||
|
||||
5. Search for sensitive data handling
|
||||
search_code with query: "environment variables secrets API keys configuration"
|
||||
search_code with query: "logging sensitive data personal information"
|
||||
|
||||
6. Launch codebase-detective for deep analysis
|
||||
Investigate each suspicious finding
|
||||
|
||||
7. Generate security report
|
||||
```
|
||||
|
||||
#### Example 5: Migration Planning
|
||||
|
||||
```markdown
|
||||
User: "Plan migration from Express to Fastify"
|
||||
|
||||
## Workflow:
|
||||
|
||||
1. Index codebase
|
||||
|
||||
2. Find all Express usage
|
||||
search_code with query: "Express router middleware application setup"
|
||||
search_code with extensionFilter: [".ts", ".js"], limit: 50
|
||||
|
||||
3. Find route definitions
|
||||
search_code with query: "HTTP route handlers GET POST PUT DELETE endpoints"
|
||||
|
||||
4. Find middleware usage
|
||||
search_code with query: "middleware authentication error handling CORS"
|
||||
|
||||
5. Find specific Express features
|
||||
search_code with query: "express static file serving"
|
||||
search_code with query: "express session management"
|
||||
search_code with query: "express body parser request parsing"
|
||||
|
||||
6. Document all findings
|
||||
Create migration checklist with file locations
|
||||
|
||||
7. Estimate effort
|
||||
Count occurrences, identify complex migrations
|
||||
```
|
||||
|
||||
### Phase 8: Best Practices Summary
|
||||
|
||||
#### Indexing Best Practices
|
||||
|
||||
✅ **DO:**
|
||||
- Use AST splitter for better semantic coherence
|
||||
- Index once, search many times
|
||||
- Check status before re-indexing
|
||||
- Use absolute paths
|
||||
- Add custom extensions for framework-specific files
|
||||
- Use ignore patterns to exclude generated/vendor code
|
||||
|
||||
❌ **DON'T:**
|
||||
- Re-index unnecessarily (wastes time)
|
||||
- Use relative paths (causes errors)
|
||||
- Index without checking Node.js version (v20.x required)
|
||||
- Include minified/bundled files (creates noise)
|
||||
- Force re-index without user confirmation
|
||||
|
||||
#### Search Best Practices
|
||||
|
||||
✅ **DO:**
|
||||
- Use natural language concept queries
|
||||
- Start with limit: 10, adjust as needed
|
||||
- Use extension filters for multi-language projects
|
||||
- Refine queries based on results
|
||||
- Combine semantic search with targeted file reads
|
||||
|
||||
❌ **DON'T:**
|
||||
- Use overly generic queries ("user", "function")
|
||||
- Use regex patterns (use grep instead)
|
||||
- Assume exact naming (defeats semantic search purpose)
|
||||
- Set limit too low (<5) or too high (>30 usually)
|
||||
- Load entire directories when search would suffice
|
||||
|
||||
#### Performance Best Practices
|
||||
|
||||
✅ **DO:**
|
||||
- Use semantic search to reduce token usage
|
||||
- Combine search → read specific files
|
||||
- Monitor indexing progress for large codebases
|
||||
- Use extension filters to narrow search space
|
||||
- Clear old indexes when project structure changes significantly
|
||||
|
||||
❌ **DON'T:**
|
||||
- Read entire directories when searching would work
|
||||
- Index multiple times for the same investigation
|
||||
- Use limit: 50 when 10 would suffice
|
||||
- Search without specifying path (searches everything)
|
||||
|
||||
#### Workflow Best Practices
|
||||
|
||||
✅ **DO:**
|
||||
- Index at start of investigation
|
||||
- Use semantic search before launching agents
|
||||
- Provide search results to codebase-detective
|
||||
- Combine semantic search with grep for precision
|
||||
- Iterate on queries based on results
|
||||
|
||||
❌ **DON'T:**
|
||||
- Skip indexing for large codebases
|
||||
- Launch detective without search context
|
||||
- Rely solely on semantic search (combine tools)
|
||||
- Give up after first search (iterate and refine)
|
||||
|
||||
## Integration with This Plugin
|
||||
|
||||
This Skill works seamlessly with:
|
||||
|
||||
1. **Codebase-Detective Agent** (`plugins/code-analysis/agents/codebase-detective.md`)
|
||||
- Use semantic search to find starting points
|
||||
- Provide search results as context to detective
|
||||
- Detective does deep dive investigation
|
||||
|
||||
2. **Deep Analysis Skill** (`plugins/code-analysis/skills/deep-analysis/SKILL.md`)
|
||||
- Deep analysis invokes detective
|
||||
- Detective uses semantic search (from this skill)
|
||||
- Full workflow: deep-analysis → detective → semantic-search → investigation
|
||||
|
||||
3. **Analyze Command** (`plugins/code-analysis/commands/analyze.md`)
|
||||
- Command triggers deep analysis skill
|
||||
- Skill guides semantic search usage
|
||||
- Complete workflow automation
|
||||
|
||||
## Success Criteria
|
||||
|
||||
This Skill is successful when:
|
||||
|
||||
1. ✅ Codebase is indexed efficiently with appropriate settings
|
||||
2. ✅ Search queries are formulated semantically for best results
|
||||
3. ✅ Token usage is optimized (40% reduction achieved)
|
||||
4. ✅ Search results are relevant and actionable
|
||||
5. ✅ User understands when to use semantic search vs grep
|
||||
6. ✅ Integration with other tools (detective, grep, read) is seamless
|
||||
7. ✅ Performance is optimized (indexing time, search speed, token usage)
|
||||
|
||||
## Quality Checklist
|
||||
|
||||
Before completing a semantic search workflow, ensure:
|
||||
|
||||
- ✅ Checked if path is already indexed (avoid unnecessary re-indexing)
|
||||
- ✅ Used appropriate splitter (AST for code, LangChain for docs)
|
||||
- ✅ Formulated queries using natural language concepts
|
||||
- ✅ Set reasonable result limits (10-20 typically)
|
||||
- ✅ Used extension filters when appropriate
|
||||
- ✅ Provided search results as context to agents
|
||||
- ✅ Explained to user why semantic search was beneficial
|
||||
- ✅ Documented file locations for follow-up investigation
|
||||
|
||||
## Notes
|
||||
|
||||
- Claude-Context MCP requires Node.js v20.x (NOT v24.x)
|
||||
- Requires OPENAI_API_KEY for embeddings
|
||||
- Requires MILVUS_TOKEN for Zilliz Cloud vector database
|
||||
- Achieves ~40% token reduction vs full directory reads
|
||||
- Uses hybrid search: BM25 (keyword) + dense embeddings (semantic)
|
||||
- AST splitter preserves code structure better than character-based
|
||||
- Always use absolute paths, never relative paths
|
||||
- Semantic search complements grep/ripgrep, doesn't replace it
|
||||
- Best for "what does this do?" queries, not "show me line 45"
|
||||
- Integration with codebase-detective creates powerful investigation workflow
|
||||
|
||||
---
|
||||
|
||||
**Maintained by:** Jack Rudenko @ MadAppGang
|
||||
**Plugin:** code-analysis v1.0.0
|
||||
**Last Updated:** November 5, 2024
|
||||
Reference in New Issue
Block a user