Get the FREE Ultimate OpenClaw Setup Guide →

pointbreak

npx machina-cli add skill withpointbreak/pointbreak-claude/pointbreak --openclaw
Files (1)
SKILL.md
7.6 KB

Pointbreak Debugging Skill

Debug programs using real debuggers controlled through MCP tools. Set breakpoints, inspect variables, step through code, and understand execution flow without modifying source files.

Core Debugging Workflow

1. Start Debug Session

Launch debugging with ide_start_debugging:

{
  "configuration": {
    "type": "python",  // or "node", "lldb", etc.
    "request": "launch",
    "program": "${file}",
    "stopOnEntry": false
  },
  "breakpoints": [{
    "source": {"uri": "file:///path/to/file.py"},
    "breakpoints": [{"line": 42}]
  }]
}

Omit registrationId - auto-detected. Set initial breakpoints in the same call.

2. Set Strategic Breakpoints

Use ide_set_breakpoints instead of adding print statements:

{
  "source": {"uri": "file:///path/to/file.py"},
  "breakpoints": [
    {"line": 42},
    {"line": 50, "condition": "x > 0"},
    {"line": 60, "hitCondition": "5"}
  ]
}

Breakpoint types:

  • Basic: Pause at line
  • Conditional: "condition": "x > 0" - break only when true
  • Hit count: "hitCondition": "5" - break on Nth hit
  • Logpoint: "logMessage": "Value: {x}" - print without stopping

Logpoint caveat: Expressions evaluate at line start. Variables declared on same line are NOT accessible. Place logpoint on next line or use regular breakpoint + ide_evaluate.

3. Resume to Breakpoint

Execute with ide_continue_session - runs until hitting breakpoint or completion.

4. Inspect State

When paused, examine variables with ide_get_variables:

Recommended (80% faster):

{
  "sessionId": "abc-123",
  "variableNames": ["result", "error", "config"]
}

Alternative (slower):

{
  "sessionId": "abc-123"
}  // Returns all local variables

Auto-selects correct thread/frame, searches scopes (Locals → Globals), expands nested objects.

5. Evaluate Expressions

Test hypotheses without code changes using ide_evaluate:

{
  "expression": "user_input.strip().lower()",
  "sessionId": "abc-123"
}

Examples:

  • Variable values: config.settings.debug
  • Conditionals: x > 0 && y < 10
  • Function calls: calculate_total(items)
  • Nested access: response.data.users[0].email

6. Step Through Execution

Control execution flow:

  • ide_step_over - Execute current line, pause at next (skip function internals)
  • ide_step_in - Enter function to trace execution inside
  • ide_step_out - Run until current function returns

7. Understand Call Chain

When execution pauses, use ide_get_stack_trace to see how code reached current point:

{
  "threadId": "1",
  "sessionId": "abc-123"
}

Returns frames from current location (top) to entry point (bottom). Use frame IDs with ide_evaluate or ide_get_scopes.

Critical: Frame IDs change after stepping. Always call ide_get_stack_trace before using ide_evaluate or ide_get_scopes.

Common Debugging Patterns

"Why is this variable wrong?"

  1. ide_set_breakpoints - Pause where variable is used
  2. ide_continue_session - Run to breakpoint
  3. ide_get_variables with variableNames - Check specific values
  4. ide_evaluate - Test expressions to identify issue

"What's happening in this loop?"

  1. ide_set_breakpoints with condition: "i == 3" - Break on specific iteration
  2. ide_step_over - Step through loop body line by line
  3. ide_get_variables with variableNames: ["i", "item", "total"] - Track state changes

"Where does this value come from?"

  1. ide_set_breakpoints - Pause where value is wrong
  2. ide_get_stack_trace - See call chain
  3. ide_step_out then ide_step_over - Trace through callers
  4. ide_get_variables - Inspect at each frame

"When does this exception occur?"

  1. ide_set_exception_breakpoints - Configure filters: ["uncaught"] or ["all"]
  2. ide_continue_session - Run until exception
  3. ide_get_stack_trace - See where it happened
  4. ide_get_variables - Check state at failure point

Advanced Features

Watch Expressions

Track values across steps with ide_add_watch:

{
  "expression": "user.balance",
  "sessionId": "abc-123"
}

Re-evaluate all watches: ide_get_watches

Data Breakpoints (Watchpoints)

Break when variable is accessed:

  1. ide_get_data_breakpoint_info - Check if variable supports it
  2. ide_add_data_breakpoint - Set with accessType: "write", "read", or "readWrite"

Requires supportsDataBreakpoints capability. Check with ide_get_capabilities.

Console Output

Fetch program output: ide_get_console with optional category: "stdout", "stderr", or "console".

Thread Debugging

Multi-threaded programs:

  1. ide_get_threads - List all threads
  2. ide_get_stack_trace - Examine specific thread
  3. ide_pause_session - Pause running threads

Session Management

  • ide_list_sessions - View all active debug sessions
  • ide_terminate_session - End current or specific session
  • Session/registration IDs auto-detected - usually omit these parameters

Best Practices

Use breakpoints over print statements. Inspect on demand without code modification.

Specify variable names. ide_get_variables with variableNames is 80% faster than retrieving all variables.

Refresh frame IDs after stepping. Frame IDs invalidate on step operations - call ide_get_stack_trace before ide_evaluate or ide_get_scopes.

Conditional breakpoints save time. Instead of breaking every iteration, use condition: "i >= 100" to skip to relevant state.

Check capabilities first. Use ide_get_capabilities before attempting advanced features like data breakpoints or frame restart.

Logpoints for quick inspection. When you just need to see values without pausing, use logMessage: "x={x}, y={y}" breakpoints.

Limitations & Fallbacks

Advanced features: Not all debug adapters support data breakpoints, frame restart, or step-in targets. Check ide_get_capabilities first.

Custom protocols: For debug adapter commands not covered by tools, use ide_send_custom_request with raw Debug Adapter Protocol commands.

Multiple IDEs: If auto-detection fails, use ide_list_registrations to find IDE and pass registrationId explicitly.

Quick Reference

TaskToolKey Parameters
Start debuggingide_start_debuggingconfiguration, breakpoints
Set breakpointside_set_breakpointssource.uri, breakpoints array
Resume executionide_continue_session(auto-detected)
Inspect variableside_get_variablesvariableNames (recommended)
Test expressionide_evaluateexpression
Step over lineide_step_over(auto-detected)
Step into functionide_step_in(auto-detected)
Step out of functionide_step_out(auto-detected)
View call stackide_get_stack_tracethreadId
List threadside_get_threads(auto-detected)
Set exception breakside_set_exception_breakpointsfilters array
Add watchide_add_watchexpression
Get console outputide_get_consolesessionId, optional category
End sessionide_terminate_session(auto-detected)

Resources

Full tool reference: https://docs.withpointbreak.com/reference/mcp-tools

Source

git clone https://github.com/withpointbreak/pointbreak-claude/blob/main/skills/pointbreak/SKILL.mdView on GitHub

Overview

Pointbreak lets you debug programs using IDE debuggers controlled through MCP. It replaces console.log/print debugging with breakpoints, variable inspection, and step-through execution, giving you real insight into how code runs. It supports Python, JavaScript/TypeScript, Rust, Go, C, C++, and any language that implements the Debug Adapter Protocol, making it ideal for crashes, wrong outputs, performance issues, or understanding unfamiliar code.

How This Skill Works

Start a debugging session with ide_start_debugging, choosing a language adapter and target program. Set breakpoints with ide_set_breakpoints (including basic, conditional, hit count, and logpoints), then resume with ide_continue_session to pause at the next breakpoint. While paused, inspect state using ide_get_variables, evaluate expressions with ide_evaluate, and control flow with ide_step_over, ide_step_in, or ide_step_out.

When to Use It

  • When you encounter bugs or crashes and need to identify root causes
  • When behavior is unexpected and existing logs are insufficient to explain why
  • When you need to understand program execution flow and the call stack
  • When debugging wrong outputs or performance issues to locate hot paths
  • When exploring unfamiliar code or third-party libraries and want to map behavior without editing source

Quick Start

  1. Step 1: Start a debug session with ide_start_debugging and select the language adapter
  2. Step 2: Set breakpoints with ide_set_breakpoints (including conditions or logpoints) for the target code
  3. Step 3: Run to a breakpoint using ide_continue_session, then inspect variables and evaluate expressions with ide_get_variables and ide_evaluate

Best Practices

  • Start with a minimal reproducible scenario to limit noise
  • Use strategic breakpoints: basic, conditional, hit count, and logpoints; remember logpoints evaluate at line start
  • Prefer ide_get_variables with variableNames to quickly verify key values
  • Use ide_continue_session to reach the next breakpoint, then step through with ide_step_over/in/out for precise tracing
  • Always call ide_get_stack_trace before ide_evaluate or ide_get_scopes to lock the current frame

Example Use Cases

  • Debug a Python script that crashes by pausing at the failure line and inspecting the traceback
  • Trace a JavaScript loop using a conditional breakpoint to inspect each iteration
  • Investigate a Rust function that returns wrong results by stepping into compute_total
  • Diagnose a Go performance bottleneck by stepping through the hot path
  • Understand unfamiliar C++ code by inspecting the stack trace and evaluating variables

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers