Hebrew RTL Formatting Skill
Ensures Hebrew Word, PowerPoint, HTML and PDF outputs from Claude get correct right-to-left layout, compatible fonts, and proper punctuation and date formats.
The skill only unzips/rewrites local docx/pptx files into /tmp; no network calls, no credential access, no destructive operations; MIT declared in README. Deducted for: regex-based OOXML rewriting with no input validation, no rollback/recovery path, and incomplete disclosure of failure behavior and data flow.
RTL patterns are concrete and internally consistent (attribute-less <w:bidi/>, hint=cs, bidiVisual, pptx post-processing) with reusable code. Deducted for: no tests or committed sample outputs; regex XML parsing is fragile against attribute ordering or CDATA; no error handling or diagnosable failure feedback, leaving abnormal-input debugging to the user.
Triggers are explicit (Hebrew requests or Hebrew deliverables), supported formats and install paths for Cursor/Claude Code are clear. Deducted for: undeclared capability boundaries (Excel, LaTeX, mixed RTL/LTR layouts) and dependency on external resources (Google Fonts, PptxGenJS) with no fallback discussion; environment fit unsupported by evidence.
Well-organized docs with per-format guidance and checklists; Hebrew README with install examples and MIT license. Deducted for: no versioning, changelog, maintainer or update path; license absent from SKILL.md itself; hidden assumption of requiring a real Hebrew Word template without explaining how to obtain one.
Key findings (docx needs bare bidi, pptx needs post-processing) derive from reverse-engineering a real Hebrew Word document and likely deliver real formatting value. Deducted for: static review cannot confirm outputs are directly usable; no generated samples committed; marginal value versus alternatives (e.g., Word's built-in RTL) is asserted, not evidenced.
Claims are traceable to a stated reverse-engineering source with auditable XML patterns and code, giving limited reproducibility. Deducted for: no test suite, no CI evidence, no third-party corroboration, no sample outputs — single, thin evidence type.
- Regex-based OOXML rewriting may fail on unusual or malformed docx/pptx files; back up originals before generation.
- The skill requires a real Hebrew Word template as base but does not explain how to obtain one or ship one; first use may be blocked.
- The HTML path depends on Google Fonts (potentially unreachable from mainland China); provide Heebo locally in offline environments.
- No versioning or changelog exists; diff against upstream before overwriting local copies on update.
- Publisher identity is unverified/unknown; this is a static source review — no code was executed and no outputs were validated.
What does this skill do, and when should you use it?
A skill for Cursor and Claude Code that fixes the formatting problems AI tools produce when generating Hebrew documents. It ships a reverse-engineered, verified RTL XML pattern for Word, a Python post-processing script for PptxGenJS, and RTL style templates for HTML and PDF. It triggers automatically whenever a request is written in Hebrew or mentions "בעברית". The README is written in Hebrew and declares an MIT license.
For .docx: injects XML with <w:bidi/> paragraphs and w:hint="cs" font runs into a real Hebrew Word template via Python zipfile, plus right-aligned bullets via numbering.xml and bidiVisual tables. For .pptx: sets align:"right" and rtlMode:true in PptxGenJS, then runs fix_rtl_pptx() to set rtlCol="1", swap margin/indent direction, and set lang="he-IL" on Hebrew runs. For HTML/PDF: provides a lang="he" dir="rtl" template with the Heebo font and WeasyPrint conversion. It also enforces plain hyphens (never em-dash), straight quotes, and DD.MM.YYYY dates.
- A user asking Claude for a Hebrew Word project-summary document
- A team needing a Hebrew quarterly-results PowerPoint deck
- A developer building a Hebrew HTML page with a data table and exporting it as PDF
- An engineer in Cursor who wants every Hebrew output automatically RTL-formatted
- Anyone generating Hebrew tables or timelines where the first column or item must start on the right
What are this skill's strengths and limitations?
- Contains an RTL XML pattern reverse-engineered from a real Hebrew Word document, plus an explicit list of approaches that do NOT work (w:jc right, docx-js bidirectional, python-docx alignment)
- Includes ready-to-use Python post-processing code that fixes RTL bullets and table column order, which PptxGenJS handles incorrectly
- Covers docx, pptx, HTML and PDF, with per-format checklists
- The docx approach depends on having a real Hebrew-locale Word template file; it cannot build one from scratch
- PPTX generation requires an extra Python regex-based post-processing pass, adding workflow friction
- No automated test suite; GitHub metadata lacks a license field (README declares MIT) and topics
- Code samples live only in the Markdown; no scripts directory or executable files are shown
How do you install this skill?
Cursor: copy SKILL.md to ~/.cursor/skills/hebrew-rtl/SKILL.md. Claude Code: copy SKILL.md to .claude/skills/hebrew-rtl/SKILL.md in the project root, or alternatively add it as an AGENTS.md file in the project. No other dependency installation steps are documented.
How do you use this skill?
After installation, simply ask in Hebrew, e.g. "תכין לי מסמך Word עם סיכום פרויקט בעברית" (prepare a Hebrew Word project summary), "תייצר מצגת PowerPoint בעברית" (generate a Hebrew PowerPoint), or "תבנה דף HTML בעברית עם טבלת נתונים" (build a Hebrew HTML page with a data table). Requirements: the docx workflow needs a real .docx template created by Word with a Hebrew locale as the base; every generated pptx must be run through the fix_rtl_pptx() post-processing script.