Débogage avec DAP

VérifiéSûr

Utiliser le débogueur VS Code (DAP) pour définir des points d'arrêt, exécuter pas à pas et inspecter l'état d'exécution.

Spar Skills Guide Bot
DeveloppementIntermédiaire
1025/07/2026
Claude Code
#debug#dap#runtime#breakpoints#vscode

Recommandé pour

Notre avis

Utilise le débogueur VS Code (DAP) pour définir des points d'arrêt, parcourir le code et inspecter l'état d'exécution.

Points forts

  • Placement intelligent des points d'arrêt basé sur l'analyse LSP
  • Automatisation du débogage avec une seule commande
  • Évaluation d'expressions personnalisées
  • Plusieurs modes de pas à pas (pas-à-pas, entrer, sortir)

Limites

  • Nécessite une configuration préalable du débogueur VS Code
  • Ne fonctionne que pour les langages supportés par DAP
  • Les commandes bridge peuvent ne pas être disponibles partout
Quand l'utiliser

Quand vous avez besoin de comprendre le comportement d'exécution réel, notamment pour des bugs dépendants de données.

Quand l'éviter

Pour des erreurs de syntaxe ou de types statiques ; préférez LSP et le linting.

Analyse de sécurité

Sûr
Score qualité85/100

The skill only uses predefined debugging commands (bridge-smart-debug, bridge-inspect, bridge-recon) which are restricted to setting breakpoints, launching programs, and inspecting variables; no arbitrary shell execution, network exfiltration, or destructive actions are possible. The skill does not execute untrusted input beyond the expression evaluation in a debugger sandbox, which is standard and safe in this context.

Aucun point d'attention détecté

Exemples

Smart debug a specific symbol
Debug the function findUser in app.js to see where it fails.
Manual breakpoint at a line
Set a breakpoint at line 15 of app.js and inspect the user variable.
Step through code using MCP tools
Step over the next line of code and show me all local variables.

name: dap-debug description: Use VS Code debugger (DAP) to set breakpoints, step through code, and inspect runtime state. Invoke when you need to understand runtime behavior, not just static types. user_invocable: true allowed-tools: Bash(bridge-smart-debug *), Bash(bridge-inspect *), Bash(bridge-recon *)

Debug

Smart debug (preferred — LSP-informed)

One command: auto-fix → LSP recon → analyze → set breakpoints at suspicious lines → launch → dump variables at each hit → stop.

# With a symbol to focus on (best results)
bridge-smart-debug <type> <program> <file> <symbol>

# Without a symbol (breaks at diagnostic errors or first function)
bridge-smart-debug <type> <program> <file>

# With expression evaluation
bridge-smart-debug node app.js app.js findUser --eval "typeof user" --eval "users.length"

The script automatically decides WHERE to break based on LSP analysis:

  • Lines with type errors from diagnostics
  • Callers that invoke the target symbol (where bad data originates)
  • Reference sites of the symbol
  • The symbol's definition
  • Falls back to first function if nothing else found

Manual inspect (when you know the exact line)

bridge-inspect <type> <program> <file> <line>
bridge-inspect node app.js app.js 15 --condition "user === undefined" --eval "users.length"

For interactive stepping, use MCP tools directly

When you need to step through code line by line, fetch DAP tools via ToolSearch:

  • mcp__vscode-bridge__debugSetBreakpoints + debugStart + debugWaitForEvent
  • mcp__vscode-bridge__debugStepOver / debugStepInto / debugStepOut
  • mcp__vscode-bridge__debugGetVariables + debugEvaluate
  • mcp__vscode-bridge__debugContinue + debugStop

When to use debug (not just LSP)

  • Bug depends on runtime data (what value a variable actually has)
  • Dynamic language where static types aren't available
  • Need to trace actual execution path
  • Want to inspect state without modifying code
Skills similaires