Content
68%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-organized, concrete guidelines body with strong executable code examples for the $type/customType decisions and genuinely non-obvious upstream grounding. Weaknesses are the absence of an explicit migration validation feedback loop and the lack of code examples in the schema/migration and query-builder rule sections.
Suggestions
Add an explicit migration feedback loop to lift workflow clarity: e.g., 1) generate migration with drizzle-kit, 2) review generated SQL against the snapshot diff, 3) fix schema and regenerate if wrong — only apply when the review passes.
Add a short code example under Schema And Migration Rules showing the single exported schema object wired into drizzle(...) and drizzle.config.ts, since that rule currently has no executable form.
Trim the duplicated statement of the serialization principle in Keep Data in Intermediate Representation (the intro sentence and '**The principle**' paragraph say the same thing).
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is largely lean and assumes competence (repo-specific Postgres-only context, upstream-source grounding, bad/good code pairs), but has minor trimmable redundancy — the "Keep Data in Intermediate Representation" intro sentence is restated almost verbatim in "**The principle**", and "$type<T>() is a compile-time-only type override" re-explains what the cited source already shows. This matches anchor 4 (efficient with minor over-explanation) rather than 5, where every token would earn its place. | 4 / 5 |
Actionability | The $type<T>() and customType sections give executable, copy-paste-ready TypeScript with bad/good pairs and a concrete decision rule ("If `toDriver` and `fromDriver` would be identity functions, use `$type<T>()`"). However, the Schema/Migration and Query Builder rule sections state directives without any code examples (e.g., how to export the schema object or wire drizzle-zod), leaving minor gaps — anchor 4 rather than 5. | 4 / 5 |
Workflow Clarity | Content is organized as rule lists rather than sequenced workflows; the only validation checkpoint is the implicit "Review generated SQL and snapshot changes together". Per the rubric's cap, database/migration operations without an explicit validate-then-fix feedback loop (generate → review snapshot/SQL → fix → regenerate) cannot score above 3, and there is no multi-step sequence that would warrant a higher anchor. | 3 / 5 |
Progressive Disclosure | The single SKILL.md (no bundle files exist in references/, scripts/, or assets/) is well-sectioned with clear headers and one external upstream link, so navigation is easy. It is over 50 lines (~120) and the detailed $type/customType and intermediate-representation sections (~70 lines) could arguably live in a separate reference file, which keeps it at anchor 4 rather than 5. | 4 / 5 |
Total | 15 / 20 Passed |