Workflow tool: misleading "TypeScript syntax" error when a script has an unescaped backtick in a template literal

Summary

The Workflow tool's script parser rejects scripts with a generic error:

Invalid workflow script: Script parse error: Unexpected token (146:10). Workflow scripts must be plain JavaScript — TypeScript syntax (type annotations like : string[], interfaces, generics) fails to parse.

This message is shown even when the script contains zero TypeScript syntax. In my case, the actual cause was an unescaped backtick character used for markdown-style inline code (` last -F `) inside the content of a JS template literal that was itself backtick-delimited. That inner backtick terminates the outer template literal early, desyncing the rest of the parse — but the reported error location (line 146) was well downstream of the real mistake (which was earlier in the file), making it hard to find.

Impact

• The error message actively misdirects debugging effort toward "remove TypeScript syntax," which isn't present, instead of "you have a stray backtick."
• The reported line/column doesn't correspond to the actual defect, since backtick-driven template-literal desync cascades forward until another stray backtick happens to "close" a fake string.
• This is an easy mistake to make by construction: Workflow scripts are often long natural-language instructional strings (agent prompts) written as JS template literals, and that instructional text naturally wants markdown formatting (code spans, emphasis) that collides with JS template-literal syntax.

Suggested improvements (any one would help; ideally more than one)

1. When the underlying parser throws, sniff for unmatched/odd-count backticks in the source and, if found, surface a distinct message like "Unescaped backtick found near line X — template literals cannot contain a literal unless escaped as \" instead of defaulting to the generic TypeScript-syntax message.
2. Document in the Workflow tool description that prompt strings should avoid raw template literals for long instructional text, and recommend the ['line one', 'line two'].join('\n') pattern (or an equivalent) specifically to avoid backtick collisions — right now the guidance only warns about TypeScript syntax, not this.
3. Consider accepting a non-JS-literal way to pass multi-line prompt text (e.g., a plain string field alongside the script) so authors aren't forced to embed long natural-language content inside JS syntax at all.

Environment

• Claude Code CLI
• Model: Sonnet 5 (claude-sonnet-5)
• Observed while authoring a multi-agent forensic Workflow script with several long agent() prompt strings

Note: I can't confirm whether this behavior is new to Sonnet 5 specifically or a pre-existing rough edge that just surfaced now — filing this as a UX/tooling issue on its own merits, not as a claimed regression.