nb-to-wolfbooklisted

# nb-to-wolfbook Converts Mathematica files (.nb / .m) to Wolfbook `.wb` (a VS Code Notebook JSON), and — critically — makes the resulting cells **bridge-safe** so they evaluate identically through the Wolfbook MCP (`runCell` / `evaluateExpression`) as they do in the Mathematica front end. ## When to invoke `/nb-to-wolfbook <file-or-directory>` — convert .nb/.m to .wb. `/nb-to-wolfbook --fix-wb <file.wb>` — normalize an EXISTING .wb in place (bridge-safe), backup written. ## ⚠️ The bug this skill exists to prevent (READ THIS) A Wolfram cell can wrap **one statement over several physical lines**: ``` Eeqv[{j1_},{k1_}] := (-1)^(j1) j1!/(k1-1) Coefficient[ GenSer, ep[j1,k1]]; MMVbar[j_,k_] := (-1)^(Total[j]+Length[j]) MMV[j,k]; ``` The front end parses each cell as one unit, so this is fine *interactively*. But an evaluator that **splits a cell on newlines** (the Wolfbook MCP `runCell`, a headless `Get` of re-serialised text, naive `ToExpression`) sees broken fragments and either: - throws `Syntax::sntxi: Incomplete expression` (the `Sum[...,⏎{...}]` case), or - treats the newline as **implicit `Times`**: `(-1)^k ⏎ MMV[...]` silently drops to a product / loses the `MMV` factor, and `def1;⏎def2;` becomes `Times[def1;, def2;]` instead of two definitions. This corrupts the kernel **silently** — definitions look present but are wrong — and is exactly what makes a cell-by-cell rebuild "unfaithful." The fix: put **each statement on one physical line**, collapsing