d3k
免费d3k assistant for debugging web apps
中文简介正在准备中。当前显示原文说明。
Use when the user is debugging a bug, tracing an error, or asking why something fails. Examples: "Why is X failing?", "Where does this error come from?", "Trace this bug"
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
A root cause traced in the wrong repository is a wrong root cause.
Call list_repos {} before the first tool call. With one indexed repository,
use the examples below as written. With more than one, pass repo on every
call: an omitted repo normally errors, but under an MCP policy with a
configured default it resolves to that default silently. If you cannot tell
which repository is meant, stop and ask. This matters most for cypher, whose
statement carries no in-band hint of which database it ran against.
list_repos is paginated, so page with offset: pagination.nextOffset until
hasMore is false before concluding a repository is absent.
A stale index describes the code from before your bug, so refresh before trusting a trace, and state the repository and index freshness with the diagnosis.
0. list_repos {} → Bind repo
1. query({search_query: "<error or symptom>"}) → Find related execution flows
2. context({name: "<suspect>"}) → See callers/callees/processes
3. READ gitnexus://repo/{name}/process/{name} → Trace execution flow
4. cypher({statement: "MATCH path..."}) → Custom traces if needed
If "Index is stale" → run
node .gitnexus/run.cjs analyzein terminal.
- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous
- [ ] Understand the symptom (error message, unexpected behavior)
- [ ] query for error text or related code
- [ ] Identify the suspect function from returned processes
- [ ] context to see callers and callees
- [ ] Trace execution flow via process resource if applicable
- [ ] cypher for custom call chain traces if needed
- [ ] Read source files to confirm root cause
- [ ] State the repository and index freshness with the diagnosis
| Symptom | GitNexus Approach |
|---|---|
| Error message | query for error text → context on throw sites |
| Wrong return value | context on the function → trace callees for data flow |
| Intermittent failure | context → look for external calls, async deps |
| Performance issue | context → find symbols with many callers (hot paths) |
| Recent regression | detect_changes to see what your changes affect — pass worktree for a linked worktree |
| "How does A reach B?" | trace between the two symbols — shortest call chain in one call |
query — find code related to error:
query({search_query: "payment validation error", repo: "my-app"})
→ Processes: CheckoutFlow, ErrorHandling
→ Symbols: validatePayment, handlePaymentError, PaymentException
context — full context for a suspect:
context({name: "validatePayment", repo: "my-app"})
→ Incoming calls: processCheckout, webhookHandler
→ Outgoing calls: verifyCard, fetchRates (external API!)
→ Processes: CheckoutFlow (step 3/7)
cypher — custom call chain traces. Pass repo alongside the statement; the
Cypher text itself names no repository, so the result is unattributable without
it:
MATCH path = (a)-[:CodeRelation {type: 'CALLS'}*1..2]->(b:Function {name: "validatePayment"})
RETURN [n IN nodes(path) | n.name] AS chain
trace — shortest call chain between two symbols ("how does A reach B?"), one call instead of chaining context hops:
trace({ from: "processCheckout", to: "fetchRates", repo: "my-app" })
→ status: ok, hopCount: 3
→ hops: processCheckout → validatePayment → verifyCard → fetchRates
→ edges: CALLS (1.0), CALLS (0.95), CALLS (1.0)
When no path exists, trace reports the furthest reachable node — exactly where the chain breaks (dynamic dispatch, reflection, or an external boundary).
0. list_repos {}
→ total: 2 (my-app, billing-api) — bind my-app explicitly on every call
1. query({search_query: "payment error handling", repo: "my-app"})
→ Processes: CheckoutFlow, ErrorHandling
→ Symbols: validatePayment, handlePaymentError
2. context({name: "validatePayment", repo: "my-app"})
→ Outgoing calls: verifyCard, fetchRates (external API!)
3. READ gitnexus://repo/my-app/process/CheckoutFlow
→ Step 3: validatePayment → calls fetchRates (external)
4. Root cause: fetchRates calls external API without proper timeout
Repository: my-app Index: current
With a single indexed repository, step 0 returns total: 1 and the repo
argument drops out of every call above.
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
d3k assistant for debugging web apps
中文简介正在准备中。当前显示原文说明。
Use when the user needs to run GitNexus CLI commands like analyze/index a repo, check status, clean the index, generate a wiki, or list indexed repos. Examples: "Index this repo", "Reanalyze the codebase", "Generate a wiki"
中文简介正在准备中。当前显示原文说明。
Use when the user asks how code works, wants to understand architecture, trace execution flows, or explore unfamiliar parts of the codebase. Examples: "How does X work?", "What calls this function?", "Show me the auth flow"
中文简介正在准备中。当前显示原文说明。
Use when the user asks about GitNexus itself — available tools, how to query the knowledge graph, MCP resources, graph schema, or workflow reference. Examples: "What GitNexus tools are available?", "How do I use GitNexus?"
中文简介正在准备中。当前显示原文说明。
Use when the user wants to know what will break if they change something, or needs safety analysis before editing code. Examples: "Is it safe to change X?", "What depends on this?", "What will break?"
中文简介正在准备中。当前显示原文说明。
Use when the user wants to rename, extract, split, move, or restructure code safely. Examples: "Rename this function", "Extract this into a module", "Refactor this class", "Move this to a separate file"
中文简介正在准备中。当前显示原文说明。