Content
76%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A strong, highly actionable body: executable code for every common pptx task, dense reference tables instead of prose, and thoughtful failure-mode handling. The main weakness is the destructive XML-edit workflow in §2.3, which overwrites the user's file with no verification step, capping workflow clarity at 3 despite otherwise good sequencing and checkpoints.
Suggestions
Add a post-edit verification checkpoint to §2.3: after writing the updated buffer, run PptxInspect { action: "render", slideNumbers: [N] } (or re-read the slide text) to confirm the new title actually landed before reporting success — this also catches the known 'run 被拆' regex failure mode it currently only warns about.
Add a validation step to the batch-generation workflow (§2.2): after writeFile, run PptxInspect summary or outline to confirm the slide count matches items.length + 1 before delivering the file.
Trim Demo 2.1 from four slides to two (cover + one KPI/chart slide) — the layout-coordinate and CJK fontFace pitfalls are fully demonstrated with half the code, saving ~40 lines of context.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense and table-driven (tool list, dispatch table, error-fallback table) with no padding explaining concepts Claude already knows, and the key-point callouts teach real pitfalls (LAYOUT_WIDE vs LAYOUT_16x9 coordinates, CJK fontFace). Not 5: Demo 2.1 runs ~85 lines across four slides where a cover plus one content slide would demonstrate the same layout/font/chart points. Not 3: the over-length is confined to one demo, so it is a minor trim rather than a noticeable verbosity problem. | 4 / 5 |
Actionability | All three demos are complete, copy-paste-ready Node scripts with correct pptxgenjs object-form options (defineSlideMaster, addShape, addChart with CJK axis fonts), a working adm-zip XML edit, and concrete tool invocations (PptxInspect actions, DocConvert parameters, CloudImageUnderstand payloads with a ready prompt). The error table maps each symptom to a specific fix. Not 4: the common cases — create from scratch, generate per-data pages, edit an existing deck, understand a page visually, convert formats — are each covered by executable code plus a fallback path. | 5 / 5 |
Workflow Clarity | The read path is clearly sequenced (summary → feature dispatch table → render) with SmartArt fallback routes, §2.4 branches on model capability with an explicit anti-hallucination checkpoint, and >20-page batch work has a confirm-first checkpoint. However, §2.3 destructively rewrites deck.pptx in place via adm-zip with no post-edit verification step (no render-back to confirm the new title), and the rubric explicitly caps destructive/batch workflows lacking validation at 3. Not 2: sequencing and most checkpoints are present; the gap is validation on the destructive edit path specifically. | 3 / 5 |
Progressive Disclosure | No bundle files exist (references/, scripts/, assets/ are all absent) and the body is a well-sectioned ~250-line document: numbered sections, a tool table, feature-dispatch tables, and clearly labeled demos make navigation easy, and nothing references nonexistent files. Not 5: the three full demos are borderline content that could live in a references/examples file as the skill grows, which is a minor organization gap rather than a clear misplacement. Not 3: structure is good and content is not buried. | 4 / 5 |
Total | 16 / 20 Passed |