node -e inline execution tends to corrupt CJK / non-ASCII content

## `node -e` inline execution tends to corrupt CJK / non-ASCII content

### Summary

When generating `.docx` files with Chinese, Japanese, or Korean text, I've observed a recurring pattern where the model initially uses `node -e "..."` to run the generation script inline. This passes the script through the shell, which can mangle multi-byte UTF-8 sequences before Node ever sees them — resulting in garbled or `?`-substituted CJK characters in the output file.

The model does eventually catch the issue and self-correct (usually by switching to a file-based approach), but by that point the user has spent several extra rounds of tokens on what is a predictable, avoidable failure.

### Why this happens

The skill shows JS code but doesn't specify how to execute it. Given no guidance, the model's natural default is:

```bash
node -e "const { Document, Packer, ... } = require('docx'); ... new TextRun({ text: '你好世界' }) ..."
```

The shell processes the string argument and mangles the multi-byte characters. The file gets created without error, but the CJK content is already corrupted — making the failure harder to catch immediately.

### Suggested fix

A note in the Setup section or Critical Rules that scripts containing non-ASCII characters should be written to a file first:

```bash
# Write to file first — shell never touches the string contents
cat << 'SCRIPT' > /tmp/build_doc.js
// full JS here, CJK characters intact
SCRIPT
node /tmp/build_doc.js
```

The quoted heredoc (`<< 'SCRIPT'`) bypasses shell interpolation entirely. This is a well-known workaround for passing multi-byte content safely.

### Suggested addition: CJK font stack

A secondary issue: even when bytes survive intact, CJK characters can render as boxes in Word without an explicit font declaration. The skill currently recommends Arial as the default, which has no CJK glyphs.

A small reference table would help:

| Language | Recommended font |
|---|---|
| Simplified Chinese | `宋体` (body) / `黑体` (headings) |
| Traditional Chinese | `新細明體` |
| Japanese | `MS Mincho` / `Yu Mincho` |
| Korean | `Batang` |

Font should be set on both the document default style and each `TextRun` to be safe.

### Impact

This affects any user generating `.docx` files with CJK content. The self-correction does eventually happen, but it costs extra token rounds that could be avoided with a small addition to the skill.

I'm attaching a `docx-cjk.md` skill I put together based on these observations — feel free to use any of it as reference.

[docx-cjk.md](https://github.com/user-attachments/files/27604629/docx-cjk.md)