Comprehensive document creation, editing, and analysis with support for tracked changes, comments, formatting preservation, and text extraction. When GLM needs to work with professional documents (.docx files) for: (1) Creating new documents, (2) Modifying or editing content, (3) Working with tracked changes, (4) Adding comments, or any other document tasks
60
70%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/docx/SKILL.mdQuality
Discovery
77%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a solid description that clearly enumerates capabilities and provides explicit trigger conditions in a numbered list format. Its main weaknesses are the absence of key trigger terms like 'Word' or 'Microsoft Word' that users would naturally use, and the unusual reference to 'GLM' instead of 'Claude'. The description follows a good structural pattern similar to the rubric's good examples.
Suggestions
Add common trigger terms like 'Word', 'Microsoft Word', '.doc', and 'Word document' to improve keyword coverage for natural user queries.
Replace 'GLM' with 'Claude' to match standard skill description conventions and improve clarity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: document creation, editing, analysis, tracked changes, comments, formatting preservation, and text extraction. These are clearly defined capabilities. | 3 / 3 |
Completeness | Clearly answers both 'what' (document creation, editing, analysis with tracked changes, comments, formatting preservation, text extraction) and 'when' (explicit numbered trigger scenarios for when to use the skill). | 3 / 3 |
Trigger Term Quality | Includes some good keywords like '.docx files', 'documents', 'tracked changes', 'comments', but misses common user variations like 'Word', 'Microsoft Word', '.doc', 'Word document'. The term 'GLM' instead of 'Claude' is unusual and wouldn't match natural user language. | 2 / 3 |
Distinctiveness Conflict Risk | The term 'professional documents' and '.docx files' help narrow the scope, but 'document creation, editing, and analysis' is broad enough to potentially overlap with general document or text editing skills. Adding 'Word' or 'Microsoft Word' would sharpen distinctiveness. | 2 / 3 |
Total | 10 / 12 Passed |
Implementation
62%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill excels at actionability and workflow clarity, providing concrete executable examples and well-sequenced multi-step processes with validation checkpoints. However, it is significantly bloated with design-oriented content (color palettes, typography rules, marketing language) that consumes substantial token budget without proportional value in the main skill file. The progressive disclosure is partially effective with external file references but undermined by excessive inline content.
Suggestions
Move the color palette definitions, specialized element styling, and typography rules to a separate `design-guidelines.md` file and reference it from the main skill — this alone would cut ~60 lines of verbose content.
Move the Chinese quote escaping section to the `docx-js.md` reference file where it contextually belongs, keeping only a one-line reminder in the main skill if needed.
Condense the 'Adding Comments' section by removing the duplicate python-docx examples — the 'Common patterns' block repeats the same API pattern three times with minor variations.
Remove marketing language from color palettes (e.g., 'tactile sensation similar to premium cashmere', 'superior visual penetration') — Claude doesn't need persuasion, just the hex values and usage context.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose with significant unnecessary content. The color palette section (~40 lines) with marketing descriptions like 'tactile sensation similar to premium cashmere' is excessive. Design requirements, Chinese quote escaping details, and extensive comment examples add bulk. Much of this could be condensed or moved to reference files. | 1 / 3 |
Actionability | The skill provides fully executable code examples throughout — bash commands for pandoc/soffice, Python scripts for comments and OOXML editing, JavaScript examples for docx-js, and specific CLI invocations for pack/unpack scripts. The redlining workflow includes concrete good/bad XML examples. Commands are copy-paste ready. | 3 / 3 |
Workflow Clarity | Multi-step workflows are clearly sequenced with numbered steps and explicit validation checkpoints. The redlining workflow includes a 6-step process with grep verification, batch strategies, and a final verification step using pandoc + grep to confirm changes. The decision tree at the top clearly routes users to the correct workflow. The editing workflow includes unpack → edit → pack with validation. | 3 / 3 |
Progressive Disclosure | The skill references external files (docx-js.md, ooxml.md, add_toc_placeholders.py, unpack.py, pack.py) appropriately, but the main file itself is monolithic with inline content that should be in separate files — the color palettes, Chinese quote escaping rules, and detailed comment examples bloat the overview. The decision tree is a good navigation aid, but the body content is not well-split. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
52b2597
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.