callgraph-mcp 1.2.0 → 1.3.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +0 -39
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -184,45 +184,6 @@ When an agent is generating new code, it can call `flowmap_analyze_workspace` be
|
|
|
184
184
|
- No existing entry points were broken
|
|
185
185
|
- The intended call relationships were actually created
|
|
186
186
|
|
|
187
|
-
---
|
|
188
|
-
|
|
189
|
-
## Example Prompts for VS Code Copilot
|
|
190
|
-
|
|
191
|
-
```
|
|
192
|
-
I just modified processPayment. Without reading any code, tell me every function
|
|
193
|
-
that could break and rank them by how many hops away they are from the change.
|
|
194
|
-
```
|
|
195
|
-
```
|
|
196
|
-
We're about to merge a PR that touches validateCart. Give me an impact report —
|
|
197
|
-
what's the worst case if this function throws.
|
|
198
|
-
```
|
|
199
|
-
```
|
|
200
|
-
Which functions in this codebase are architectural nasty-surprises — called by everything
|
|
201
|
-
but calling a lot themselves. I want names, file paths, and exact counts.
|
|
202
|
-
```
|
|
203
|
-
```
|
|
204
|
-
Find every cycle in the call graph. For each one tell me which file I should break
|
|
205
|
-
the dependency in to resolve it cleanly.
|
|
206
|
-
```
|
|
207
|
-
```
|
|
208
|
-
I want to delete code safely. Give me every function that is provably unreachable —
|
|
209
|
-
not called by anything, not an entry point. Include file and line number.
|
|
210
|
-
```
|
|
211
|
-
```
|
|
212
|
-
I just joined this team. Walk me through this codebase starting from the entry points —
|
|
213
|
-
explain each major flow in plain English without me having to read a single file.
|
|
214
|
-
```
|
|
215
|
-
```
|
|
216
|
-
I want to extract the payment logic into its own module. Based purely on call
|
|
217
|
-
relationships, which functions naturally belong together and which ones would need to stay behind.
|
|
218
|
-
```
|
|
219
|
-
```
|
|
220
|
-
Cursor just made changes across 14 files. Based on what it touched, what else in the
|
|
221
|
-
codebase should I be nervous about that it didn't touch.
|
|
222
|
-
```
|
|
223
|
-
|
|
224
|
-
---
|
|
225
|
-
|
|
226
187
|
## How It Works
|
|
227
188
|
|
|
228
189
|
1. Tree-sitter WASM grammars parse each source file into an AST — no runtime execution, no imports
|