Content
92%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 tight, well-structured body that gives Claude exactly the non-obvious RLS gotchas and a validated migration workflow with feedback loops. Actionability is the only slight gap, where a couple of prose steps could be backed by runnable commands.
Suggestions
Add a copy-paste-ready SQL snippet for the per-role RLS check (e.g., example SET ROLE anon/user/admin SELECT queries) so step 2 is fully executable.
Provide a concrete command or snippet for the post-deploy 'data sanity query' referenced in step 5.
Optionally show a one-line example of a migration filename with inline intent/rollback comment to make step 1 immediately actionable.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Lean bullet gotchas and a tight numbered workflow assume Claude's knowledge (no explanation of what RLS or a migration is), and the two short code blocks are purposeful with every token earning its place. | 5 / 5 |
Actionability | Provides executable SQL and bash snippets plus concrete directive steps, but some steps ('Review the SQL for destructive actions', per-role RLS checks) are described in prose without copy-paste-ready commands. | 4 / 5 |
Workflow Clarity | The migration workflow is a clear 5-step sequence with explicit validation checkpoints (per-role RLS checks, CI re-run, post-deploy re-verify) and a feedback loop ('On failure: revert, adjust, re-run') — satisfying the destructive/batch validation requirement. | 5 / 5 |
Progressive Disclosure | Well-organized sections with a single clearly-signaled one-level-deep reference (supabase-config.md); under 50 lines with no need for bundle files, meeting the simple-skill exception. | 5 / 5 |
Total | 19 / 20 Passed |