dap-dbgeng: Skill for Claude Code

DAP Request Review

Use this skill when reviewing or tightening the implementation of any DAP request handler such as launch, attach, initialize, configurationDone, continue, evaluate, stackTrace, setBreakpoints, pause, next, stepIn, stepOut, threads, scopes, variables, terminate, or disconnect.

This skill is for implementation quality, not coverage (see dap-request-coverage for that). The goal is to make each handler easy to audit: parse first, validate required inputs early, turn arguments into typed values, and only then touch debugger-session state, server state, or protocol side effects.

Principles

• Parse request arguments first. Do not interleave parsing with session creation, engine calls, thread selection, event emission, or state mutation.
• Validate required inputs before any side effect. If a required argument is missing or malformed, send the protocol error before creating or mutating anything.
• Prefer typed locals or a typed request-specific struct. Do not pass raw nlohmann::json into dap_server helpers, debugger_session methods, or engine-facing code - convert to typed values at the top and pass those down.
• Use canonical option names. The wire format and the implementation agree on one name per option (program, cwd, dbgengPath, stopAtEntry, sources, symbolPath, processId, connectionString, kernel, dumpFile). There are no alias chains or legacy fallbacks in this repo - keep it that way; do not add a ?? b reads.
• Use the project's lower_case naming for locals (a stopAtEntry argument reads into stop_at_entry); never carry a JSON spelling that differs from the canonical key.
• Keep comments rare but useful: explain why a branch, validation, or ordering constraint exists, not what the code does.
• Make the handler read top-to-bottom as: parse -> validate -> build typed inputs -> perform session/state changes -> send responses/events.

Review Procedure