agent-debugger 0.1.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 +131 -0
- package/bin/agent-debugger +2 -0
- package/dist/src/adapters/base.d.ts +45 -0
- package/dist/src/adapters/base.d.ts.map +1 -0
- package/dist/src/adapters/base.js +3 -0
- package/dist/src/adapters/base.js.map +1 -0
- package/dist/src/adapters/go.d.ts +27 -0
- package/dist/src/adapters/go.d.ts.map +1 -0
- package/dist/src/adapters/go.js +144 -0
- package/dist/src/adapters/go.js.map +1 -0
- package/dist/src/adapters/node.d.ts +27 -0
- package/dist/src/adapters/node.d.ts.map +1 -0
- package/dist/src/adapters/node.js +197 -0
- package/dist/src/adapters/node.js.map +1 -0
- package/dist/src/adapters/python.d.ts +27 -0
- package/dist/src/adapters/python.d.ts.map +1 -0
- package/dist/src/adapters/python.js +152 -0
- package/dist/src/adapters/python.js.map +1 -0
- package/dist/src/adapters/registry.d.ts +10 -0
- package/dist/src/adapters/registry.d.ts.map +1 -0
- package/dist/src/adapters/registry.js +45 -0
- package/dist/src/adapters/registry.js.map +1 -0
- package/dist/src/adapters/rust.d.ts +27 -0
- package/dist/src/adapters/rust.d.ts.map +1 -0
- package/dist/src/adapters/rust.js +149 -0
- package/dist/src/adapters/rust.js.map +1 -0
- package/dist/src/cli.d.ts +4 -0
- package/dist/src/cli.d.ts.map +1 -0
- package/dist/src/cli.js +326 -0
- package/dist/src/cli.js.map +1 -0
- package/dist/src/daemon.d.ts +3 -0
- package/dist/src/daemon.d.ts.map +1 -0
- package/dist/src/daemon.js +136 -0
- package/dist/src/daemon.js.map +1 -0
- package/dist/src/dap-client.d.ts +35 -0
- package/dist/src/dap-client.d.ts.map +1 -0
- package/dist/src/dap-client.js +256 -0
- package/dist/src/dap-client.js.map +1 -0
- package/dist/src/dap-types.d.ts +52 -0
- package/dist/src/dap-types.d.ts.map +1 -0
- package/dist/src/dap-types.js +3 -0
- package/dist/src/dap-types.js.map +1 -0
- package/dist/src/protocol.d.ts +253 -0
- package/dist/src/protocol.d.ts.map +1 -0
- package/dist/src/protocol.js +50 -0
- package/dist/src/protocol.js.map +1 -0
- package/dist/src/session.d.ts +30 -0
- package/dist/src/session.d.ts.map +1 -0
- package/dist/src/session.js +407 -0
- package/dist/src/session.js.map +1 -0
- package/dist/src/util/paths.d.ts +5 -0
- package/dist/src/util/paths.d.ts.map +1 -0
- package/dist/src/util/paths.js +7 -0
- package/dist/src/util/paths.js.map +1 -0
- package/dist/src/util/ports.d.ts +3 -0
- package/dist/src/util/ports.d.ts.map +1 -0
- package/dist/src/util/ports.js +19 -0
- package/dist/src/util/ports.js.map +1 -0
- package/dist/test/protocol.test.d.ts +2 -0
- package/dist/test/protocol.test.d.ts.map +1 -0
- package/dist/test/protocol.test.js +25 -0
- package/dist/test/protocol.test.js.map +1 -0
- package/package.json +55 -0
- package/skills/agent-debugger/SKILL.md +225 -0
|
@@ -0,0 +1,225 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: agent-debugger
|
|
3
|
+
description: Use when a program crashes, a test fails, or code produces wrong results and reading the source isn't enough to see why. Lets you pause execution at any line and inspect the actual runtime state, variable values, types, call stacks, to find what went wrong.
|
|
4
|
+
allowed-tools: Bash(agent-debugger:*)
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Agent Debugger
|
|
8
|
+
|
|
9
|
+
A debugger for AI agents. Set breakpoints, inspect state, evaluate expressions, test fixes in-place.
|
|
10
|
+
|
|
11
|
+
## Philosophy
|
|
12
|
+
|
|
13
|
+
The debugger is a scalpel, not a flashlight. You don't turn it on to look around. You turn it on to make one precise cut — confirm or kill a specific hypothesis about why the program is broken. If you're "exploring" in the debugger, you've already lost.
|
|
14
|
+
|
|
15
|
+
**Every session starts before the debugger.** Read the code. Read the traceback. Form a theory. Know exactly what breakpoint you'll set and what eval you'll run before you type a single command. The debugger is the experiment, not the investigation.
|
|
16
|
+
|
|
17
|
+
**`eval` is the only command that matters.** `vars`, `step`, `stack`, `source` — these are all setup. The eval is the actual experiment. It's where you test your hypothesis against reality. Everything else is scaffolding to get you to the right eval at the right moment.
|
|
18
|
+
|
|
19
|
+
**Half of all bugs don't need a debugger.** Read the traceback. Read the code. Check the types. Grep for the error message. Look at git blame. Most bugs surrender to careful reading. Reach for the debugger only when the bug depends on runtime state you can't determine statically.
|
|
20
|
+
|
|
21
|
+
## The Rules
|
|
22
|
+
|
|
23
|
+
1. **Read first, debug second.** Never start a debug session without reading the relevant code and forming a hypothesis. The debugger confirms theories — it doesn't generate them.
|
|
24
|
+
|
|
25
|
+
2. **One breakpoint, one question.** Each breakpoint should answer a specific question. "Is `x` a string here?" "Is `balance` negative after this call?" "Does this branch execute?" If you can't articulate the question, you're not ready to debug.
|
|
26
|
+
|
|
27
|
+
3. **Eval, don't dump.** `vars` dumps everything and answers nothing. `eval "type(data['age'])"` answers exactly one question. Prefer eval. Always.
|
|
28
|
+
|
|
29
|
+
4. **Never step through loops.** A loop with 100 iterations is 100 step commands. A conditional breakpoint is 1 command. Use `--break "file:line:i == 50"` to jump straight to the iteration that matters.
|
|
30
|
+
|
|
31
|
+
5. **Two strikes, new theory.** If your hypothesis was wrong twice, stop. Your mental model of the code is broken, not the debugger session. Close, re-read the code, form a completely different theory, then start a new session with different breakpoints. Continuing to probe the same area has exponentially diminishing returns.
|
|
32
|
+
|
|
33
|
+
6. **Test the fix before writing it.** The debugger gives you a live REPL in the exact context of the bug. Use `eval` to run your proposed fix expression before editing any code. If it works in eval, it'll work in the code.
|
|
34
|
+
|
|
35
|
+
7. **Prove the fix, write the test.** After fixing, re-run the program to verify. Then write the smallest possible test that catches the bug. A fix without a test is a fix that will regress.
|
|
36
|
+
|
|
37
|
+
8. **Close the session.** Always. A stale session blocks the next one.
|
|
38
|
+
|
|
39
|
+
## Commands
|
|
40
|
+
|
|
41
|
+
```bash
|
|
42
|
+
agent-debugger start <script> --break file:line[:condition] [--runtime path] [--args ...]
|
|
43
|
+
agent-debugger eval <expression> # Run any expression in the current frame
|
|
44
|
+
agent-debugger vars # List local variables (prefer eval)
|
|
45
|
+
agent-debugger step [into|out] # Step over / into function / out of function
|
|
46
|
+
agent-debugger continue # Run to next breakpoint or termination
|
|
47
|
+
agent-debugger stack # Show call stack
|
|
48
|
+
agent-debugger break file:line[:cond] # Add breakpoint mid-session
|
|
49
|
+
agent-debugger source # Show source around current line
|
|
50
|
+
agent-debugger status # Show session state and location
|
|
51
|
+
agent-debugger close # Kill session, clean up
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
Multiple `--break` flags supported. Conditions are expressions: `--break "app.py:42:len(items) > 10"`.
|
|
55
|
+
|
|
56
|
+
## Supported Languages
|
|
57
|
+
|
|
58
|
+
| Language | Extension | Adapter | Requirement |
|
|
59
|
+
|----------|-----------|---------|-------------|
|
|
60
|
+
| Python | .py | debugpy | `pip install debugpy` |
|
|
61
|
+
| JavaScript/TypeScript | .js/.ts | Node Inspector | Node.js |
|
|
62
|
+
| Go | .go | Delve | `go install github.com/go-delve/delve/cmd/dlv@latest` |
|
|
63
|
+
| Rust/C/C++ | .rs/.c/.cpp | CodeLLDB | `CODELLDB_PATH` env var |
|
|
64
|
+
|
|
65
|
+
## The Playbook
|
|
66
|
+
|
|
67
|
+
These are not suggestions. These are the right way to handle each class of bug.
|
|
68
|
+
|
|
69
|
+
### Type Bugs
|
|
70
|
+
|
|
71
|
+
A value has the wrong type somewhere in the pipeline. Don't step through — go straight to the suspect and ask.
|
|
72
|
+
|
|
73
|
+
```bash
|
|
74
|
+
agent-debugger start app.py --break "app.py:25"
|
|
75
|
+
agent-debugger eval "type(data['age'])" # <class 'str'> — found it
|
|
76
|
+
agent-debugger eval "int(data['age'])" # 35 — fix is safe
|
|
77
|
+
agent-debugger close
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
Two commands after the breakpoint. Done.
|
|
81
|
+
|
|
82
|
+
### Data Pipeline Bugs
|
|
83
|
+
|
|
84
|
+
Something in a batch is wrong. Don't look at individual records — assert the shape of the whole batch.
|
|
85
|
+
|
|
86
|
+
```bash
|
|
87
|
+
agent-debugger start etl.py --break "etl.py:90" # after the transformation
|
|
88
|
+
agent-debugger eval "all(isinstance(v, int) for v in result.values())" # False
|
|
89
|
+
agent-debugger eval "[k for k,v in result.items() if not isinstance(v, int)]" # ['quantity']
|
|
90
|
+
agent-debugger close
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
One breakpoint, two evals. The first asks "is anything wrong?", the second asks "what exactly?"
|
|
94
|
+
|
|
95
|
+
### Loop Bugs (The Wolf Fence)
|
|
96
|
+
|
|
97
|
+
A loop processes N items and something goes wrong at an unknown iteration. Binary search it.
|
|
98
|
+
|
|
99
|
+
```bash
|
|
100
|
+
agent-debugger start app.py --break "app.py:45:i == 500" # midpoint
|
|
101
|
+
agent-debugger eval "is_valid(result)" # True → bug is after 500
|
|
102
|
+
agent-debugger close
|
|
103
|
+
|
|
104
|
+
agent-debugger start app.py --break "app.py:45:i == 750" # narrow
|
|
105
|
+
agent-debugger eval "is_valid(result)" # False → bug is between 500-750
|
|
106
|
+
agent-debugger close
|
|
107
|
+
|
|
108
|
+
agent-debugger start app.py --break "app.py:45:i == 625" # narrow again
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
~10 iterations to find the bug in 1000 items. Not 1000 step commands.
|
|
112
|
+
|
|
113
|
+
### Invariant Violations
|
|
114
|
+
|
|
115
|
+
You know what should never happen. Tell the debugger to catch the exact moment it does.
|
|
116
|
+
|
|
117
|
+
```bash
|
|
118
|
+
# "balance should never go negative"
|
|
119
|
+
agent-debugger start bank.py --break "bank.py:68:account.balance < 0"
|
|
120
|
+
|
|
121
|
+
# "every value should be numeric"
|
|
122
|
+
agent-debugger start pipeline.py --break "pipeline.py:30:not isinstance(value, (int, float))"
|
|
123
|
+
|
|
124
|
+
# "list should never exceed 100 items"
|
|
125
|
+
agent-debugger start app.py --break "app.py:55:len(results) > 100"
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
If it hits, you've caught the crime in progress. If it doesn't hit, your theory was wrong — move on.
|
|
129
|
+
|
|
130
|
+
### Recursion / Deep Call Chains
|
|
131
|
+
|
|
132
|
+
The stack tells you how you arrived. The eval tells you why you're wrong.
|
|
133
|
+
|
|
134
|
+
```bash
|
|
135
|
+
agent-debugger start tree.py --break "tree.py:22"
|
|
136
|
+
agent-debugger stack # see the recursion depth
|
|
137
|
+
agent-debugger eval "current_depth" # 3
|
|
138
|
+
agent-debugger eval "max_depth" # 3 — off-by-one, should be <, not <=
|
|
139
|
+
agent-debugger close
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
### "Where Does This Bad Data Come From?"
|
|
143
|
+
|
|
144
|
+
You found bad data downstream. Pivot upstream.
|
|
145
|
+
|
|
146
|
+
```bash
|
|
147
|
+
agent-debugger start app.py --break "handler.py:55"
|
|
148
|
+
agent-debugger eval "data['age']" # '35' — string, wrong. But handler didn't create this.
|
|
149
|
+
agent-debugger close # pivot to the source
|
|
150
|
+
|
|
151
|
+
agent-debugger start app.py --break "loader.py:22"
|
|
152
|
+
agent-debugger eval "raw_row" # CSV parser returns strings. Root cause.
|
|
153
|
+
agent-debugger close
|
|
154
|
+
```
|
|
155
|
+
|
|
156
|
+
Don't fix the symptom at the handler. Fix the cause at the loader.
|
|
157
|
+
|
|
158
|
+
### "Which of These 3 Functions Is the Culprit?"
|
|
159
|
+
|
|
160
|
+
Set breakpoints at all suspects. The runtime tells you which one fires.
|
|
161
|
+
|
|
162
|
+
```bash
|
|
163
|
+
agent-debugger start app.py \
|
|
164
|
+
--break "auth.py:30" \
|
|
165
|
+
--break "validate.py:55" \
|
|
166
|
+
--break "handler.py:80"
|
|
167
|
+
|
|
168
|
+
# Hits validate.py:55 — now you know where to focus
|
|
169
|
+
agent-debugger eval "request.payload"
|
|
170
|
+
agent-debugger close
|
|
171
|
+
```
|
|
172
|
+
|
|
173
|
+
### Testing a Fix In-Place
|
|
174
|
+
|
|
175
|
+
You think you know the fix. Prove it before editing.
|
|
176
|
+
|
|
177
|
+
```bash
|
|
178
|
+
# Paused at the crash: total + data['age'] where age is a string
|
|
179
|
+
agent-debugger eval "total + int(data['age'])" # 90 — works
|
|
180
|
+
agent-debugger eval "int(data['age'])" # 35 — safe cast
|
|
181
|
+
|
|
182
|
+
# Prove it works for the entire dataset
|
|
183
|
+
agent-debugger eval "sum(int(d['age']) if isinstance(d['age'], str) else d['age'] for d in users)"
|
|
184
|
+
agent-debugger close
|
|
185
|
+
# NOW edit the code, with confidence
|
|
186
|
+
```
|
|
187
|
+
|
|
188
|
+
### Falsifying Your Theory
|
|
189
|
+
|
|
190
|
+
Design evals that would **break** your hypothesis, not confirm it. Confirmation bias is the #1 debugging trap.
|
|
191
|
+
|
|
192
|
+
```bash
|
|
193
|
+
# Theory: "age is a string only in the third record"
|
|
194
|
+
|
|
195
|
+
# BAD — only confirms
|
|
196
|
+
agent-debugger eval "isinstance(data['age'], str)" # True. But so what?
|
|
197
|
+
|
|
198
|
+
# GOOD — tries to disprove
|
|
199
|
+
agent-debugger eval "isinstance(users[0]['age'], str)" # False — not all records
|
|
200
|
+
agent-debugger eval "isinstance(users[1]['age'], str)" # False — so it IS specific to record 3
|
|
201
|
+
agent-debugger eval "users[2]" # {'name': 'Charlie', 'age': '35'} — source data is wrong
|
|
202
|
+
```
|
|
203
|
+
|
|
204
|
+
## Never Do This
|
|
205
|
+
|
|
206
|
+
**Never step blindly.** If you're running `step` more than 3 times in a row, you need a breakpoint, not more steps.
|
|
207
|
+
|
|
208
|
+
**Never start without reading code.** The debugger doesn't find bugs. You find bugs by reading code and forming theories. The debugger just confirms them.
|
|
209
|
+
|
|
210
|
+
**Never dump vars when you have a question.** `vars` is for the rare case when you genuinely don't know what variables exist. If you have a theory, `eval` tests it directly.
|
|
211
|
+
|
|
212
|
+
**Never debug timing bugs with the debugger.** Pausing execution changes timing. Race conditions disappear under observation. Use logging.
|
|
213
|
+
|
|
214
|
+
**Never keep going after 2 failed hypotheses.** Close. Re-read. Rethink. Your mental model is wrong, and more debugger commands won't fix your mental model.
|
|
215
|
+
|
|
216
|
+
**Never leave a session open.** `agent-debugger close`. Always. Every time.
|
|
217
|
+
|
|
218
|
+
**Never fix without verifying.** Run the program after the fix. If you can, toggle the fix to prove causation. Then write a test.
|
|
219
|
+
|
|
220
|
+
## Notes
|
|
221
|
+
|
|
222
|
+
- Use **absolute paths** for breakpoints
|
|
223
|
+
- One session at a time — `close` before starting another
|
|
224
|
+
- Python requires `debugpy` (`pip install debugpy`)
|
|
225
|
+
- Program stdout goes to the daemon — use `eval` to inspect output values
|