CtrlK
BlogDocsLog inGet started
Tessl Logo

stage-design

The baseline method for building ONE stage — a single classroom — with this runtime. Covers how the plan is settled in conversation, the order the generation tools are called in, how the classroom roster is written, when narration has to be re-synthesized, and what must be true before a stage is called done. Load this before generating or rebuilding any stage from scratch, whatever its subject; it is the floor the topic skills build on, not an alternative to them.

72

Quality

90%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

88%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.

The content is a tightly written operational procedure: an ordered tool sequence with explicit verification steps, a bounded retry policy, and a completion checklist. Its only minor costs are slight rhetorical padding and a length near the comfortable limit for a single inline body with no reference files.

DimensionReasoningScore

Conciseness

The body is largely lean and operational — tool names, parameters, and rules with no explanation of concepts Claude already knows. A few rhetorical flourishes ('a roster settled late is a roster half the stage never saw', 'leaves the user holding an empty deck') pad slightly beyond the bare rule, which is the 'minor instances that could be trimmed' case, not the every-token-earns-its-place case.

4 / 5

Actionability

Every step is executable instruction, not description: exact tools with parameters (`create_stage` with `folderId`, `set_roster` with persona spec and `providerId::voiceId` binding, `generate_scene` with settled `title`/`type`/`brief`, `read_stage` with `path:/scenes/<order|id>` and `detail:"source"`), plus concrete field checks (`audioId` on speech actions). For an instruction-only skill this covers the common cases fully.

5 / 5

Workflow Clarity

The build sequence is a clearly ordered 5-step list with explicit validation checkpoints: `list_scenes` to verify persistence, `read_stage` to check `audioId` before calling the stage done, and a full feedback loop for failures (retry once with a changed brief, then stop and name the gap). This matches the top anchor — sequence, checkpoints, error recovery, and a done-checklist.

5 / 5

Progressive Disclosure

No bundle files exist, and the body is a well-sectioned, self-contained overview whose only cross-references are to sibling skills (`pro-editing`, topic skills) used as boundary signals rather than nested file refs. At ~95 lines it sits at the upper bound of what belongs inline in one SKILL.md, so structure is good but not the ideal split/overview case.

4 / 5

Total

18

/

20

Passed

Description

88%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 description: it enumerates concrete capabilities, gives an explicit load-time trigger, and explicitly delineates its relationship to sibling topic skills. The only soft spot is trigger-term breadth — a few natural phrasings a user might say are absent.

DimensionReasoningScore

Specificity

The description lists five concrete, distinct actions: 'how the plan is settled in conversation', 'the order the generation tools are called in', 'how the classroom roster is written', 'when narration has to be re-synthesized', and 'what must be true before a stage is called done' — comprehensive coverage of the build lifecycle. It is not merely naming the domain; each clause names a specific capability.

5 / 5

Completeness

It explicitly answers 'what' ('The baseline method for building ONE stage... Covers [five capabilities]') and 'when' ('Load this before generating or rebuilding any stage from scratch, whatever its subject') with a concrete trigger clause. Both halves are explicit, matching the top anchor.

5 / 5

Trigger Term Quality

Natural trigger phrases are present — 'building ONE stage', 'generating or rebuilding any stage from scratch', 'classroom', 'narration' — which a user of this runtime would plausibly say. A few natural variations are missing (e.g., 'create a lesson', 'new deck', 'pages'), keeping it just below the comprehensive-with-synonyms anchor.

4 / 5

Distinctiveness Conflict Risk

It carves a clear niche ('the baseline method for building ONE stage') and explicitly positions itself against the topic skills ('it is the floor the topic skills build on, not an alternative to them'), minimizing conflict. However, 'whatever its subject' makes it broad enough to co-trigger with those closely related skills, so it is not quite minimal-conflict.

4 / 5

Total

18

/

20

Passed

Validation

93%

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

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository
THU-MAIC/OpenMAIC
Reviewed

Table of Contents

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.