scheduling-basics

Core concepts of the scheduling package — event types, schedules, bookings, hosts, teams, and how they compose.

Quality

75%

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

Fix and improve this skill with Tessl

tessl review fix ./packages/scheduling/docs/skills/scheduling-basics/SKILL.md

Quality

Content

80%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 body is an efficient, well-organized domain reference: concise product-specific definitions, a complete public-URL map, and a request-to-command table that makes common tasks immediately actionable. Its main gaps are placeholder-laden command examples with no full flag reference, and multi-step workflows (notably the destructive cancel path) lacking explicit verification or validation steps.

Suggestions

Add a brief verification step to destructive flows, e.g. after `list-bookings`, "confirm the uid and attendee match the user's request before running `cancel-booking`".

Replace elided placeholders like `--from ... --to ...` and `--intervals []` with realistic example values so the commands are copy-paste executable.

Note where full flag/argument definitions for the CLI commands live (e.g. a `references/commands.md`) so the table's one-line forms can be completed.

Dimension	Reasoning	Score
Conciseness	The body is lean bullets and two tables with no padding; every token is product-specific knowledge Claude cannot already have (URL scheme, host round-robin weights, stable iCalUID), and the one analogy ("Like ChiliPiper") costs three tokens.	5 / 5
Actionability	The "Common tasks" table maps concrete user requests to concrete CLI commands, but several commands embed elided placeholders ("--from ... --to ...", "--uid ...", "--teamId ...", "--intervals []") and there is no pointer to where full flag definitions live.	4 / 5
Workflow Clarity	Multi-step flows are sequenced ("list-bookings --status upcoming, then cancel-booking --uid ..."; "create-event-type ..., then set-event-type-hosts"), but the destructive cancel workflow has no explicit verification step and no validate/retry feedback loops anywhere — the guideline caps destructive workflows lacking validation at 3.	3 / 5
Progressive Disclosure	No bundle files exist (references/, scripts/, assets/ are all absent) and the body references none, so there are no broken or buried references; at under 50 lines with clean, well-organized sections (mental model, workflows, URLs, common tasks), the skill meets the simple-skill exception for a top score.	5 / 5
	Total	17 / 20 Passed

Description

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

The description clearly identifies the domain and its constituent concepts, but it reads as a table of contents rather than a capability statement: no actions, and no explicit trigger guidance telling Claude when to load it. Adding a "Use when..." clause with user-facing synonyms (calendar, availability, meeting) would address the two weakest dimensions at once.

Suggestions

Add an explicit trigger clause, e.g. "Use when working with the scheduling package: bookings, event types, availability, or hosts."

Include natural user-facing synonyms such as "calendar", "availability", and "meeting" to broaden trigger-term coverage.

Lead with what the skill does (e.g. "Explains and navigates..." / "Reference for...") rather than only listing topics, so the description states a capability, not just a contents list.

Dimension	Reasoning	Score
Specificity	The description names the domain ("the scheduling package") and enumerates six concrete topics ("event types, schedules, bookings, hosts, teams"), but contains no action verbs at all — it is a topic list, not a statement of what the skill does.	3 / 5
Completeness	The "what" is clear (core concepts of the scheduling package, with topics enumerated), but there is no "Use when..." clause or equivalent trigger guidance, which caps completeness at 3.	3 / 5
Trigger Term Quality	"scheduling", "event types", "schedules", "bookings", "hosts", and "teams" are natural phrases a user would say, but common variations such as "calendar", "availability", and "meeting" are absent.	4 / 5
Distinctiveness Conflict Risk	Tying the description to "the scheduling package" gives it a niche, but broad terms like "scheduling", "bookings", and "teams" could overlap with other scheduling/calendar-related skills.	3 / 5
	Total	13 / 20 Passed

Validation

100%

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: BuilderIO/agent-native
Path: packages/scheduling/docs/skills/scheduling-basics/SKILL.md
Commit: a941a2e

Reviewed: 9 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.