Content
46%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.
The body is rich in concrete, copy-paste-ready Hasura configuration and covers the major feature areas well, but it is a bloated monolith that inlines material (deployment, patterns, troubleshooting, conceptual explanations) that belongs in separate reference files, and its operational workflows omit validation checkpoints. It functions as a condensed reproduction of the Hasura docs rather than a lean, well-structured skill.
Suggestions
Split the body into one-level-deep reference files (e.g. references/permissions.md, references/auth.md, references/event-triggers.md, references/deployment.md, references/patterns.md, references/troubleshooting.md) and reduce SKILL.md to a concise overview with clearly signaled links.
Cut conceptual padding — the "Core Concepts" bullet lists, generic best-practice advice, and five full example-app schemas — keeping only Hasura-specific knowledge and configuration Claude cannot be assumed to know.
Add explicit validation checkpoints to operational workflows: verify migrations with `hasura migrate status` after `migrate apply`, reload metadata and check `/healthz` after deployment, and test permission rules with a non-admin role before promoting changes.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | A ~1670-line monolith with substantial padding Claude does not need: conceptual "Core Concepts" bullet lists ("Zero Code: No resolver writing...", "Real-time by Default: Every query automatically has a subscription counterpart"), generic best-practice advice ("Create appropriate indexes", "Document custom actions"), five complete example applications, and a links section — much of which restates Hasura's documented behavior. Not 1 because a large share is concrete configuration and commands rather than pure concept explanation; not 3 because the padding is extensive and time-sensitive details ("hasura/graphql-engine:v2.36.0", "Last Updated: January 2025") are not isolated in a deprecated/old-patterns section. | 2 / 5 |
Actionability | Provides extensive concrete, mostly executable guidance: a full docker-compose.yml, Kubernetes manifests, `hasura migrate create/apply/status` commands, complete Metadata API JSON bodies, JWT claim structures, Auth0/Firebase/webhook code, and CI/CD YAML. Not 5 because several examples depend on undefined placeholder functions (`sendEmail`, `processPayment`, `fetchOrderDetails`, `validateToken`, `esClient`) and some listed env vars (e.g. `HASURA_GRAPHQL_RATE_LIMIT_PER_MINUTE`) are not standard engine configuration, leaving minor gaps. | 4 / 5 |
Workflow Clarity | Sequences are present and coherent ("How it works" 1-2-3, the six-step Auth Flow, the create/edit/apply migration flow, the GitHub Actions deploy pipeline), and a Troubleshooting section lists error fixes, but workflows involving database and batch operations (metadata apply, migrate apply, production deployment) lack explicit validation checkpoints and feedback loops — `hasura migrate status` is shown but there is no verify-after-apply or rollback-on-failure step — which caps workflow clarity at 3 per the batch/database-operation rule. Not 4 because checkpoints are absent rather than a minor gap; not 2 because steps are clearly listed and ordered. | 3 / 5 |
Progressive Disclosure | No bundle files exist (no references/, scripts/, or assets/ directories) and everything is inlined in a single ~1670-line file: deployment manifests, five full application patterns, troubleshooting recipes, and API-level examples clearly belong in separate reference files, and the body never links out to any other file. Not 1 because section headers do provide navigable structure; not 3 because references are not merely unclearly signaled — they are entirely absent, and the inlined bulk is the core problem. | 2 / 5 |
Total | 11 / 20 Passed |