nb-to-wolfbook

# 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 (bridge-safe + PUA→ASCII). `/nb-to-wolfbook --fix-wb <file.wb>` — normalize an EXISTING .wb in place (bridge-safe + PUA→ASCII), backup written. `/nb-to-wolfbook --puafix <file.wb>` — de-rectangle ONLY (PUA→ASCII, no newline reflow): the smallest diff that removes the rectangle glyphs from an already-bridge-safe .wb. ## ⚠️ 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 definitio...