Content
80%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 concise, actionable body that earns top marks for token efficiency and structure. The main weakness is workflow clarity around destructive migration operations, which lacks an explicit validation feedback loop.
Suggestions
Add an explicit validate-fix-retry loop for migrations, e.g. run prisma migrate status / validate after edits and re-inspect migration.sql before re-applying on failure.
Show concrete query examples for select, include, and $transaction rather than only naming them, to lift actionability.
Clarify the backfill step for destructive operations with a short example sequence so the destructive-op workflow has a visible checkpoint.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Lean and operational with no padding about what Prisma is; every line adds non-obvious knowledge (checksum rule, @map rename gotcha, hot-reload singleton, P2002), assuming Claude's competence as the score-5 anchor requires. | 5 / 5 |
Actionability | Provides executable commands (migrate dev/deploy, generate, db push) and a complete copy-paste singleton, but query patterns (select, include, $transaction) are named rather than shown in code, leaving minor gaps versus the fully-executable score-5 anchor. | 4 / 5 |
Workflow Clarity | Sequencing and implicit checkpoints exist ('inspect migration.sql before applying', checksum-failure warning), but destructive/batch database operations lack an explicit validate-fix-retry feedback loop, so the rubric's destructive-operations cap holds this at 3. | 3 / 5 |
Progressive Disclosure | A single under-50-line file with clean section organization and one-level-deep external references (database-config.md, docs URL); the simple-skill exception allows a 5 for well-organized sections. | 5 / 5 |
Total | 17 / 20 Passed |