slide-dsl

The complete slide DSL manual — the canvas and its background, the ten element types field by field with units, defaults and legal values, where each type keeps its words, which field the renderer actually paints when two disagree, exactly what happens to the HTML you put in `content`, and the structure schema that is now the ONLY thing a write is checked against. Nothing filters your markup and nothing normalises your values, so this manual is the whole of what makes a page render correctly. Load it before patching a field you have not patched before, when a patch comes back rejected, when a patch lands but nothing moves on screen, or when you need to know where a colour, a font, a table cell or a code line really lives. This is a field reference and not a procedure — `page-clone` and `pro-editing` decide which pages to touch, `slide-craft` decides what a good page looks like, and this one says what the JSON means.

Quality

86%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

77%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

An exceptionally actionable and well-sequenced reference with strong validation feedback loops, undercut mainly by basic-HTML over-explanation and a monolithic, all-inline structure that forgoes progressive disclosure despite its size.

Suggestions

Trim basic-HTML tag explanations (e.g. the italic/underline/line-through rows in the reset table) to only the product-specific behaviour, since Claude already knows those tags.

Split the per-element-type field tables into one-level-deep reference files (e.g. references/elements.md or one file per type) with clearly signaled links from SKILL.md, keeping the manual as an overview plus the precedence/working rules.

Move the long PPTX-export and CSS-property tables into a separate reference file, linking to it from the main body to reduce inline token weight.

Dimension	Reasoning	Score
Conciseness	The bulk is dense, product-specific reference that earns its place, but it over-explains basic HTML Claude already knows (e.g. '<em>/<i> — Italic', '<u> — Underline', '<s>/<strike>/<del> — Line-through') and could be tightened in those spots.	3 / 5
Actionability	Provides copy-paste-ready, executable guidance throughout — exact JSON Pointer paths, a worked-examples table mapping each change to a concrete path and value, and per-field units, defaults and legal values covering the common cases.	5 / 5
Workflow Clarity	The 'Write-is-what-you-store' section gives an explicit feedback loop (read detail:'source' → write one leaf → read back and compare → fix if bytes differ), and the Hard Rules reinforce 'A rejected patch changed nothing. Read the message, fix the path, retry' and 'Read the page back after every write.'	5 / 5
Progressive Disclosure	Internal structure is good (numbered Contents, per-element sections, Quick reference), but the ~66KB reference is entirely inlined in SKILL.md with no bundle files and no one-level-deep references, so content that could live in separate per-type reference files is not progressively disclosed.	3 / 5
	Total	16 / 20 Passed

Description

92%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong, specific description that clearly states both what the skill covers and when to load it, with concrete trigger conditions and explicit boundary-setting against related skills. Its only weakness is a measure of technical jargon ('DSL', 'structure schema') mixed into otherwise natural trigger phrasing.

Dimension	Reasoning	Score
Specificity	Names the domain (slide DSL) and enumerates multiple concrete contents — 'the ten element types field by field with units, defaults and legal values', 'which field the renderer actually paints when two disagree', 'the structure schema' — giving comprehensive coverage rather than vague abstraction.	5 / 5
Completeness	Explicitly answers both 'what' (the manual's contents) and 'when' with multiple concrete trigger phrases ('Load it before patching a field you have not patched before, when a patch comes back rejected, when a patch lands but nothing moves on screen').	5 / 5
Trigger Term Quality	Includes natural trigger phrases users would say ('when a patch comes back rejected', 'nothing moves on screen', 'where a colour, a font, a table cell or a code line really lives') with synonyms, but mixes in technical jargon ('DSL', 'structure schema') that a user would not naturally say.	4 / 5
Distinctiveness Conflict Risk	Occupies a clear niche — a field reference for the slide JSON — and explicitly distinguishes itself from sibling skills ('page-clone and pro-editing decide which pages to touch, slide-craft decides what a good page looks like, and this one says what the JSON means'), minimizing conflict risk.	5 / 5
	Total	19 / 20 Passed

Validation

87%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (900 lines); consider splitting into references/ and linking	Warning
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	14 / 16 Passed

Repository: THU-MAIC/OpenMAIC
Path: skills/agent-runtime/slide-dsl/SKILL.md
Commit: 636fab0

Reviewed: 3 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

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.