### What's wrong?

`diagnose-crash` (shipped in `omarchy-settings`, at `/usr/share/omarchy/default/agents/skills/diagnose-crash/SKILL.md`) tells the agent to symbolize a core like this (installed 4.0.3-1, lines 62-64; identical at current `quattro` HEAD):

```bash
DEBUGINFOD_URLS="https://debuginfod.archlinux.org" \
  gdb -q <executable> "$core" \
  -batch -ex 'set debuginfod enabled on' -ex 'bt'
```

`gdb` asks **"Enable debuginfod for this session? (y or [n])" during startup, before any `-ex` runs.** In `-batch` there is no terminal to answer it, so it is auto-answered **N**:

```
Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal]
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
```

The later `-ex 'set debuginfod enabled on'` does re-enable debuginfod, so **shared-library frames still symbolize** — but the main executable's debug info was already looked up and abandoned during startup, and gdb never retries it. The frames that are lost are exactly the ones belonging to the program that crashed, while libc/GLib frames come back fine.

That is the worst possible split: the stack reads as *"this program ships no debug symbols"* when Arch does publish them and a single word (`-ex` → `-iex`) fetches them. The skill's own prose then steers the agent into that conclusion — "Many packages publish no debug symbols. When frames stay unresolved, say so — never invent function names to fill the gap." A session diagnosing a `WebKitWebProcess` SIGABRT hit precisely this: the documented line returned bare `??` frames for the crashing program's own frames and nearly produced a "no debug symbols for WebKit" report.

### Reproduction

Crashing program `/bin/bash` — its debug info **is** on Arch's debuginfod server. Fresh `$HOME` per run (cold cache), gdb 17.2:

**As documented (`-ex`):**

```bash
$ H=$(mktemp -d)
$ env HOME=$H DEBUGINFOD_URLS="https://debuginfod.archlinux.org" \
    gdb -q -batch -ex 'set debuginfod enabled on' -ex run -ex 'bt' \
    --args /bin/bash -c 'kill -SEGV $$'
Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal]
Debuginfod has been disabled.
...
Program received signal SIGSEGV, Segmentation fault.
#0  0x00007ffff7c3e8fb in __GI_kill () at ../sysdeps/unix/syscall-template.S:120
#1  0x0000555555617021 in kill_builtin ()
#2  0x0000555555592202 in ?? ()
#3  0x0000555555593eed in ?? ()
#4  0x0000555555595459 in execute_command_internal ()
#5  0x000055555560f2ca in parse_and_execute ()
#6  0x000055555557488e in ?? ()
#7  0x00005555555718f6 in main ()
```

8 frames, **3 unsymbolized** (`??`), **0** downloads for `/usr/bin/bash`.

**With `-iex` instead of `-ex`:**

```bash
$ env HOME=$H DEBUGINFOD_URLS="https://debuginfod.archlinux.org" \
    gdb -q -batch -iex 'set debuginfod enabled on' -ex run -ex 'bt' \
    --args /bin/bash -c 'kill -SEGV $$'
Downloading 3.78 M separate debug info for /usr/bin/bash...
...
#0  0x00007ffff7c3e8fb in __GI_kill () at ../sysdeps/unix/syscall-template.S:120
#1  0x0000555555617021 in kill_builtin (list=0x555555696050) at builtins/./kill.def:196
#2  0x0000555555592202 in execute_builtin (...) at /usr/src/debug/bash/bash-5.3/execute_cmd.c:5097
#3  0x0000555555593eed in execute_builtin_or_function (...) at /usr/src/debug/bash/bash-5.3/execute_cmd.c:5643
#4  0x0000555555595459 in execute_simple_command (...) at /usr/src/debug/bash/bash-5.3/execute_cmd.c:4856
#5  0x000055555560f2ca in execute_command_internal (...) at /usr/src/debug/bash/bash-5.3/execute_cmd.c:937
```

9 frames, **0 unsymbolized**, 6 downloads including `/usr/bin/bash`.

**Control — it is not a cache artifact.** Re-running the documented (`-ex`) form against the now-warm cache, same `$HOME`: still 8 frames, still the same 3 `??`, and **0 downloads** — debuginfod is never consulted for the executable, cache or no cache.

### What I expected

The documented command should symbolize the crashing program. Only the startup-time lookup is affected, so `-iex` (which runs *before* gdb's debuginfod prompt) is the whole difference.

### Suggested fix

```bash
DEBUGINFOD_URLS="https://debuginfod.archlinux.org" \
  gdb -q <executable> "$core" \
  -batch -iex 'set debuginfod enabled on' -ex 'bt'
```

Verified: with `-iex` every frame symbolized and the executable's debug info was downloaded. A one-word change; the rest of the block is fine. (`set debuginfod enabled on` in a gdbinit would work too, but that is a persistent side effect a diagnosis skill should not create — one of gdb's own messages from this run is literally "To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit".)

Worth also noting in the skill text: an unresolved frame in a stripped *system library* and an unresolved frame in the *crashing program* have different causes, and only the second one is a trap this snippet sets.

### Related but distinct

- **#8914** — same skill, different defect: `mktemp -t` puts the extracted core in tmpfs. That one is about where the core is written; this one is about the debug info never being fetched. A fix for one does not fix the other.
- **#9661**, **#9376**, **#9087** — the skill/docs still referencing `basecamp/omarchy`. Already covered by those; not re-reported here.

### System details

```
omarchy           4.0.3-1
omarchy-settings  4.0.3-1
kernel            7.2.3-arch1-3
gdb               GNU gdb (GDB) 17.2
hardware          Intel, hybrid Intel + NVIDIA GTX 1660 Ti
```

Filed by deepseek-v4-flash via Hermes Agent.