## TL;DR
JupyterLab shows `kernel error` with nothing in the traceback when the kernel process dies before logging, which almost always means the kernelspec's python is missing, broken, or lacks ipykernel. Open `jupyter kernelspec list`, read the kernel.json `argv`, and run that exact command in a terminal. The terminal prints the real error; fix that, reinstall the spec if needed, and the Lab error clears.

```text
kernel failed to start: 'kernel error' with empty traceback in jupyter lab
```

## Use this when
- JupyterLab shows `kernel error` and the traceback panel is empty.
- The server log shows the launch attempt but no python error.
- Other kernels (or the same kernel elsewhere) work.

## Not for this skill when
- The traceback is non-empty. Read it; the answer is in there.
- The kernel starts but dies later. That is a runtime crash.

## Steps
1. List specs: `jupyter kernelspec list`. Verify: the failing kernel's spec exists.
2. Read its kernel.json and note `argv[0]`, the python path. Verify: that path exists on disk.
3. Hand-launch: `[that python] -m ipykernel_launcher -f /tmp/test.json`. Verify: you see the real error (no module, bad path, permission).
4. Fix the revealed problem: install ipykernel into that python, or fix the path. Verify: the hand launch stays alive.
5. Reinstall the spec from the fixed python if the path changed. Verify: Lab launches the kernel cleanly.

## Variant phrasings
### jupyterlab kernel error empty traceback
Short form. The spec's python is broken.

### kernel error no details jupyter lab
UI phrasing. Hand-launch reveals the error.

### kernelspec broken python kernel error
The cause phrasing. Fix the spec's python.

Compatibility: JupyterLab 3/4, ipykernel 6.x. kernelspec layout is stable.

## Why it happens
Lab renders whatever the kernel process reported, and a process that fails during interpreter startup reports nothing, so the panel is empty by construction. The usual underlying failures are a deleted conda env still referenced by a spec, a python path that moved, or ipykernel missing from that python. All three are invisible from the UI and obvious from a terminal.

## Edge cases / pitfalls
- Deleting and recreating a conda env with the same name leaves a spec pointing at the old path. Reinstall specs after env recreation.
- The default `python3` spec may resolve differently for the server than for your shell. Check the spec's absolute path, not your PATH.
- A spec with extra env vars in `env` can break the launch. Compare against a known-good spec.
- Fixing your shell python does not fix the spec python. Work from kernel.json outward.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_RQel0dsKjQrZ91izfGsiSQ