lsp-cross-repo
À propos
Cette compétence effectue une analyse transversale des dépôts pour identifier tous les appelants d'un symbole de bibliothèque à travers plusieurs bases de code consommatrices. Elle est essentielle lors du remaniement de bibliothèques partagées pour comprendre les schémas d'utilisation en aval. La compétence exploite les capacités LSP telles que les références et les fournisseurs de hiérarchie d'appels via le serveur MCP agent-lsp.
Installation rapide
Claude Code
Recommandénpx skills add blackwell-systems/agent-lsp -a claude-code/plugin add https://github.com/blackwell-systems/agent-lspgit clone https://github.com/blackwell-systems/agent-lsp.git ~/.claude/skills/lsp-cross-repoCopiez et collez cette commande dans Claude Code pour installer cette compétence
Documentation
Requires the agent-lsp MCP server.
lsp-cross-repo
Multi-root cross-repo caller analysis for library + consumer workflows. Finds all usages of a library symbol across one or more consumer codebases in a single call.
Read-only — does not modify any files.
When to use
- Before changing a library API: find all callers in every consumer
- Before deleting a symbol: verify it has no cross-repo dependents
- When a change in repo A might break repo B or C
- Auditing how internal packages are used across services
Use /lsp-impact instead for single-repo blast-radius analysis.
Workflow
Step 1 — Initialize the primary workspace
Start the language server on the library root if not already running:
mcp__lsp__start_lsp({ "root_dir": "/path/to/library" })
Step 2 — Locate the library symbol
Find the symbol's definition to get file_path, line, and column:
mcp__lsp__find_symbol({ "query": "<symbol-name>" })
Pick the result in the library repo (not a test file).
Step 3 — Find all cross-repo references (primary step)
Call get_cross_repo_references with the symbol location and all consumer repo
roots. This adds each consumer as a workspace folder, waits for indexing, runs
find_references across all roots, and returns results partitioned by repo:
mcp__lsp__get_cross_repo_references({
"symbol_file": "/abs/path/to/library/file.go",
"line": <line>,
"column": <column>,
"consumer_roots": [
"/abs/path/to/consumer-a",
"/abs/path/to/consumer-b"
]
})
Returns:
library_references— usages within the library itselfconsumer_references— a map ofconsumer-root → [file:line ...]warnings— any roots that could not be indexed (check these manually)
Decision after Step 3:
| Result | Action |
|---|---|
| No consumer refs | Safe to change — verify warnings is empty first |
| Consumer refs found | Run /lsp-impact on each call site before editing |
warnings non-empty | Re-add that root manually and retry Step 3 |
Step 4 — Callers and implementations (optional)
For a deeper look at how consumers call the symbol:
mcp__lsp__find_callers({
"file_path": "<library-file>",
"line": <line>,
"column": <column>,
"direction": "incoming"
})
For interfaces — all consumer-side implementations:
mcp__lsp__go_to_implementation({
"file_path": "<library-file>",
"line": <line>,
"column": <column>
})
Output format
## Library-internal references
- file:line — brief context
## Consumer references
### /path/to/consumer-a
- file:line — brief context
### /path/to/consumer-b
- file:line — brief context
Decision guide
| Situation | Action |
|---|---|
| No consumer refs, warnings empty | Safe to change |
| Consumer refs found | Run /lsp-impact on each call site before editing |
warnings lists a consumer root | That root failed indexing — check LSP logs |
| Consumer uses interface, not concrete type | Use go_to_implementation to find all implementors |
Example
# Refactoring ParseConfig in a shared config library used by 3 services
start_lsp(root_dir="/repos/config-lib")
find_symbol(query="ParseConfig") # find definition → file:42:6
get_cross_repo_references(
symbol_file="/repos/config-lib/pkg/config/parser.go",
line=42, column=6,
consumer_roots=["/repos/api-service", "/repos/worker-service", "/repos/batch-job"]
)
# → library_references: 2
# → consumer_references: {api-service: [main.go:14, app.go:31], worker-service: [runner.go:8]}
# → warnings: []
Dépôt GitHub
Compétences associées
llamaguard
AutreLlamaGuard est le modèle de Meta, doté de 7 à 8 milliards de paramètres, conçu pour modérer les entrées et sorties des LLM selon six catégories de sécurité comme la violence et les discours haineux. Il offre une précision de 94 à 95 % et peut être déployé avec vLLM, Hugging Face ou Amazon SageMaker. Utilisez cette compétence pour intégrer facilement le filtrage de contenu et des garde-fous de sécurité dans vos applications d'IA.
cost-optimization
AutreCette compétence de Claude aide les développeurs à optimiser les coûts du cloud grâce au redimensionnement des ressources, aux stratégies d'étiquetage et à l'analyse des dépenses. Elle fournit un cadre pour réduire les dépenses cloud et mettre en œuvre une gouvernance des coûts sur AWS, Azure et GCP. Utilisez-la lorsque vous devez analyser les coûts d'infrastructure, redimensionner les ressources ou respecter des contraintes budgétaires.
quantizing-models-bitsandbytes
AutreCette compétence quantifie les LLMs en précision 8 bits ou 4 bits à l'aide de bitsandbytes, permettant une réduction de 50 à 75 % de la mémoire utilisée avec une perte de précision minime. Elle est idéale pour exécuter des modèles plus volumineux sur une mémoire GPU limitée ou pour accélérer l'inférence, prenant en charge des formats comme INT8, NF4 et FP4. La compétence s'intègre à HuggingFace Transformers et permet l'entraînement QLoRA ainsi que l'utilisation d'optimiseurs en 8 bits.
dispatching-parallel-agents
AutreCette compétence Claude déploie plusieurs agents pour enquêter et résoudre simultanément 3 problèmes indépendants ou plus. Elle est conçue pour des scénarios impliquant des défaillances non liées qui peuvent être résolues sans état partagé ni dépendances. La capacité fondamentale est la résolution de problèmes en parallèle, en assignant un agent par domaine problématique indépendant afin de maximiser l'efficacité.
