Content
86%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 tight, well-structured instruction-only skill body: lean prose, concrete tool names and parameter guidance, and a clear classify-then-create workflow with guard rails. The remaining gaps are a worked invocation example and a validation checkpoint on the created/reused room.
Suggestions
Add one short example invocation of `roomflow create_task_room` (projectId plus source metadata) so the call syntax and argument shape are copy-paste ready rather than inferred.
Add a validation step after room creation, e.g. confirm the returned room name normalizes to `TASK:<projectId>` and route errors back to describe_room when classification is ambiguous.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is lean and operational throughout: "Call `roomflow describe_room` when a Matrix room's purpose is unclear", "Pass a stable `projectId`", "Do not infer room purpose from joined-room IDs alone". There is no explanation of what Matrix or DingTalk are, no padding, and every sentence directs action — matching "every token earns its place". | 5 / 5 |
Actionability | Concrete, actionable guidance for an instruction-only skill: it names the exact tools and their inputs — "Pass a stable `projectId`", "Pass the current source metadata exactly as received, such as DingTalk `sourceRoomId` and `sender`", "Pass the complete Matrix user IDs for Workers" — and gives a machine-checkable classification rule ("room name starts with `TASK:<projectId>`"). It falls short of anchor 5 because no complete invocation example (a full tool-call or command block) is ever shown, leaving the call syntax and argument shape implicit. | 4 / 5 |
Workflow Clarity | The sequence is clear and ordered: (1) classify the room via describe_room with explicit criteria, (2) from a requester room call create_task_room before creating project/task state, (3) use the returned room for handoff and completion reports, with guard rails like "Do not use source room or sender identity to decide task-room reuse" serving as checkpoints. It is not a 5 because there is no validation step on the outcome — e.g., confirm the returned room name matches `TASK:<projectId>` or what to do when classification is ambiguous. The destructive/batch cap does not apply since room creation is neither. | 4 / 5 |
Progressive Disclosure | The skill is a single ~40-line SKILL.md with no references/, scripts/, or assets/ directories and no external reference needs. Per the rubric guideline that skills under 50 lines with no need for external references score 5 with well-organized sections, the three clearly headed sections ("Describe Room", "Create Or Reuse Task Room") with the short intro qualify — everything is appropriately in one place and easy to navigate. | 5 / 5 |
Total | 18 / 20 Passed |