Content
57%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 deliberately thin orchestration skill: clean, lean, and honest about deferring to a canonical recipe. Its weaknesses are the flip side of that design — the body has no executable content, the recipe it depends on sits outside the skill bundle behind a fragile relative path that does not resolve here, and verification steps are named as recipe scope but never given as explicit checkpoints in the skill itself.
Suggestions
Bring the recipe inside the skill bundle (e.g. copy it to references/recipe.md and link relatively) or inline the few critical commands (MPG proxy setup, pg_dump/pg_restore invocations) so the skill is self-contained and the link cannot dangle.
State the expected restore-verification outcome explicitly (e.g. what query or row count confirms the restore succeeded before starting the app), so the checkpoint does not depend entirely on the external recipe.
Drop or compress the 'When to trigger' section (it duplicates the frontmatter description) and the maintainer-facing 'Keep the skill focused' bullet to tighten token efficiency.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is lean and assumes Claude's competence — no concept explanations, no restated Postgres knowledge, every bullet is a directive. It misses 5 because the 'When to trigger' section substantially duplicates the frontmatter description's trigger list, and 'Keep the skill focused on orchestration and verification, not duplicating the full runbook' is maintainer-facing rather than agent guidance — minor tokens that could be trimmed. It is above 3 because there is no unnecessary explanation, only these small redundancies. | 4 / 5 |
Actionability | Guidance is concrete in its delegation — it names the exact canonical scope (proxy setup, URL rewriting, pg_dump/pg_restore, extension precreation, restore verification) and the specific file 'docker-compose.restore-test.yaml' with a clear precondition for its use. But the body contains no executable commands at all, and its sole source of executable steps is a reference outside the bundle at '../../../docs/recipes/fly-mpg-backup-restore.md', a relative path that does not resolve from the skill's directory. It is above 2 (more than high-level hints — precise file names and scope rules) but below 4 (nothing in the body is directly executable, and the primary pointer is fragile). | 3 / 5 |
Workflow Clarity | The 'Treat the recipe as canonical for' bullet implies a real phase sequence (proxy setup → URL rewriting → pg_dump/pg_restore → extension precreation → restore verification → restored-db app startup), and 'Use docker-compose.restore-test.yaml only after the recipe has created the restored database container' gives one explicit ordering constraint. However, the body provides no explicit validation checkpoints or error-recovery loops of its own, and the rubric caps workflow clarity at 3 for destructive/batch database operations without validation steps in the skill itself. It is above 2 because an ordered phase list plus one sequencing rule is present, but the cap and the fully deferred verification keep it from 4. | 3 / 5 |
Progressive Disclosure | Sections are well organized, and the single reference is one level deep and clearly signaled ('Use the human-facing recipe as the source of truth for the exact commands and restore procedure'). However, there are no bundle files at all — no references/, scripts/, or assets/ — and the one detailed material the skill depends on lives outside the skill bundle at a relative path ('../../../docs/recipes/fly-mpg-backup-restore.md') that does not resolve from the skill's location, making navigation fragile and the skill non-self-contained. This is more than a minor organization gap (ruling out 4) but the reference is clearly signaled and nothing inlined belongs elsewhere (ruling out 2). | 3 / 5 |
Total | 13 / 20 Passed |