Conciseness

The body is dense with tool-specific operational detail Claude cannot know (Session pooler vs Direct, pg_dump 17-vs-18 caveat, macOS `chmod -N` ACL behavior, `auth.dump` handling) and never explains generic concepts, so it is above anchor 3. But inline version-history asides — "from 2.2.4", "Since 2.10.0", "before 2.9.0" — are time-sensitive info not placed in a compatibility/deprecated section, and long prose paragraphs (restore step 5) could be tightened, keeping it below anchor 5.

Actionability

Every command is copy-paste ready and complete: full subshell wrappers that unset inherited vars, source `.env.backupdrill`, and stop on load failure (e.g. `set -a; . ./.env.backupdrill 2>/dev/null || { echo ".env.backupdrill could not be loaded" >&2; exit 1; }; set +a`), a pinned `npx -y backupdrill@2.10.0` invocation per operation, an exact env template, and a concrete error-to-fix mapping in "When something fails". Matches anchor 5's "fully executable; copy-paste ready; specific examples cover the common cases".

Workflow Clarity

The restore workflow is a numbered, user-driven sequence with explicit validation checkpoints: a dry run that "checks everything and writes nothing", timestamp pinning ("replace `--dry-run` with `--snapshot <timestamp> --confirm-target <target-ref>`... so a backup that lands in between can't change what gets restored"), and "Run the real restore only after the user asks for it". Backup/drill outputs are validated ("Go through the check lines... quote the failing check as printed"), a config check runs "before the first command", and a troubleshooting section provides feedback loops — matching anchor 5. The destructive-operation cap does not apply: the write operation (restore) has explicit pre-flight validation.

Progressive Disclosure

The main body appropriately holds the core workflow, and `references/postgres-backup-basics.md` exists, is one level deep, and is clearly signaled for off-path requests ("If the user asks what Supabase already backs up... read [references/postgres-backup-basics.md]"). However, the entire scheduling section depends on `[assets/scheduled-backup.yml]` — a referenced path that does not exist in the bundle (there is no `assets/` directory), so navigation dead-ends and that workflow is unexecutable as written. A missing referenced file is more than the "minor organization gaps" of anchor 4, landing this at anchor 3.

Specificity

The description lists five concrete capabilities — "back up a Supabase project to their own S3, R2 or B2 bucket", "estimate what those backups add to their Supabase egress bill", "a restore drill in Docker", "schedule backups in GitHub Actions", "restore a backupdrill snapshot into a new Supabase project" — with concrete specifics (bucket providers, bill impact, restore target). This matches the anchor-5 example's breadth of distinct concrete actions; anchor 4 would require minor coverage gaps, but every CLI use case is enumerated.

Completeness

It opens with an explicit trigger clause — "Use when the user wants to back up..." — and answers 'what' with concrete capabilities in the same sentence, mirroring the anchor-5 exemplar. Not 4: the 'when' is not merely present but itemized across five concrete trigger conditions.

Trigger Term Quality

Natural user phrasing is comprehensive for the niche: "back up a Supabase project", "egress bill", "check that a backup actually restores", "schedule backups", "restore ... into a new Supabase project", with synonyms covered ("back up"/"backups", "restore"/"restore drill"). It exceeds anchor 4 ("a few natural terms missing") — a user requesting any of these tasks would phrase it in these terms.

Distinctiveness Conflict Risk

It carves a clear niche — Supabase backups to a user-owned bucket via a named CLI ("backupdrill") — with distinct triggers (Supabase, S3/R2/B2, egress bill, restore drill, GitHub Actions scheduling). No realistic overlap with other skills; matches anchor 5's "clear niche with distinct triggers; minimal conflict risk".