Content
85%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.
An action-dense, well-sequenced operational skill: every workflow is executable with copy-paste commands and genuine validation loops, including the tricky rebase and stale-image cases. Its main weakness is structural — everything lives in one long file when the rebase procedure and reference material clearly belong in separate, clearly signaled reference files.
Suggestions
Split the detailed rebase procedure (Steps 1–5 with its chain-following and stale-image caveats) into a references/rebase.md file, keeping a short trigger summary in SKILL.md that links to it.
Move the default help text, Key File Locations, and Common Pitfalls into a references/reference.md so the main body stays a lean overview of the eight actions.
Tighten the rebase Step 2 and Step 5 prose — long multi-clause sentences explaining the stale-image false failure could be reduced to a short bulleted warning.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is command-first with almost no padding — no primer on what Alembic or migrations are, and the caveats (rename detection limits, NOT NULL backfill, stale data-import images) are genuinely non-obvious project knowledge rather than concepts Claude already knows. A few passages could still be tightened: the rebase Step 2/Step 5 prose uses dense multi-clause sentences, and the default help block repeats the section headers almost verbatim. | 4 / 5 |
Actionability | Every action opens with copy-paste-ready bash (docker compose ps, alembic current, git diff, git show origin/main:...), placeholders are explicit (`<new-file>.py`, `<target>`, `<old-parent-revision>`), and file locations and naming patterns are spelled out, fully covering the common cases. | 5 / 5 |
Workflow Clarity | Multi-step processes are explicitly sequenced (numbered Steps 1–5 for create and rebase) with real validation checkpoints throughout: verify the DB is running before generating, review the autogenerate output, test the downgrade round-trip, confirm one head after rebasing, and the explicit rebuild-before-verify loop for stale Docker images. Destructive operations (downgrade, down) all have verification steps, so the database-operations cap does not apply. | 5 / 5 |
Progressive Disclosure | The file is well-sectioned with clear headers, but it is a ~246-line single file with no bundle structure at all — the rebase deep-dive (multi-file chain-following, stale-image caveats) and the help text are detail-heavy content that would sit better in one-level-deep reference files. This fits the anchor where content that should be separate is inline despite decent structure. | 3 / 5 |
Total | 17 / 20 Passed |