Content
82%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 well-built native-development guide: highly actionable setup code, a valuable web-vs-native distinction table, and real bundled scripts that correctly gate doc fetching. The recurring 'always fetch docs' repetition and absence of explicit validation checkpoints in the setup workflow are the main refinements.
Suggestions
Consolidate the repeated 'always fetch component docs before implementing' directives (currently stated three times across sections) into a single prominent workflow step to save tokens and sharpen the fetch→implement sequence.
Add an explicit validation checkpoint to the Expo setup, e.g. step 4 'Reload the app and confirm HeroUINativeProvider renders without a Uniwind warning' — this converts the numbered setup into a verified workflow.
Consider moving the semantic-variants table and Card anatomy example out of SKILL.md (or trimming them to one-line pointers), since the skill already delegates full component detail to `get_component_docs.mjs` and the fetched MDX docs.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense with skill-specific, non-obvious information (Native vs Web table: Uniwind vs Tailwind v4, HSL vs oklch, `heroui-native` vs `@heroui/react`; "Use onPress, not onClick"; "Card.Body (not Card.Content)") and wastes few tokens on concepts Claude already knows. Minor trims exist: the directive to fetch docs is repeated three times ("Always fetch Native docs before implementing", "Always fetch component docs before implementing", "Fetch component docs for complete anatomy"), and installation appears in both a curl one-liner and an npm Essentials section — fitting the 'efficient; minor instances that could be trimmed' anchor rather than the lean 5. | 4 / 5 |
Actionability | Guidance is copy-paste ready throughout: complete install commands ("npm i heroui-native react-native-reanimated ..."), a full `global.css` block, a complete provider-wrapping Layout component, exact script invocations ("node scripts/get_component_docs.mjs Button"), concrete MDX URLs, and executable theming snippets (`useThemeColor`, `Uniwind.setTheme`). The common cases are covered with runnable code, matching the 5 anchor. | 5 / 5 |
Workflow Clarity | The Expo setup is a clear numbered sequence with exact commands (install dependencies → create `global.css` → wrap app with providers), and "Critical Setup Requirements" acts as a checklist with the fetch-docs-before-implementing guard stated up front. It falls short of the 5 anchor because there are no explicit validation checkpoints (e.g., verify the app renders or the theme variables resolve) and the fetch→implement→confirm loop is implied rather than sequenced — matching 'clear sequence with most checkpoints present; minor validation gaps'. No destructive/batch operations, so the cap of 3 does not apply. | 4 / 5 |
Progressive Disclosure | Good structure against the actual bundle: all four referenced scripts (`scripts/list_components.mjs`, `get_component_docs.mjs`, `get_theme.mjs`, `get_docs.mjs`) exist and are invoked by exact path, one level deep, and bulk component detail is delegated to fetched MDX docs rather than inlined. Minor gaps keep it below the 5: no local references/ files carry the semantic-variant table or component anatomy (they sit inline in a 230-line body), and those sections could be split or left to the fetched docs; references are script/URL based and clearly signaled but the body itself is on the long side for an overview. | 4 / 5 |
Total | 17 / 20 Passed |