Conciseness

Lean and efficient throughout: every section carries gbrain-specific facts Claude could not know ("effective_engine: null (no brain) → Step 2", "the docker rung needs --allow-docker", "graduation_source_writer_held names the process to stop"), with zero padding and no explanation of concepts Claude already knows. Matches anchor 5; it is not 4 because there is no identifiable over-explanation to trim.

Actionability

Fully executable, copy-paste-ready commands cover every common case: "gbrain engine status --json", "gbrain init --prefer-postgres", "gbrain migrate --to postgres --url-env GBRAIN_TARGET_URL --yes --expect <plan_hash>", "gbrain migrate --status --json", plus the exact JSON fields to branch on (effective_engine, db_url_source, graduation.state). Matches anchor 5; not 4 because no key step lacks its concrete command.

Workflow Clarity

A clearly sequenced 4-step workflow with explicit validation checkpoints and feedback loops for the destructive migration: plan first ("exits 3 with the confirmation_required document"), run only after user consent with "--yes --expect <plan_hash>", "preview_changed means the plan changed: go back to step 2", and post-run doctor verification. The destructive-operation cap at 3 does not apply because validation is thoroughly present; this matches anchor 5, not 4, since every checkpoint is explicit and every failure path names its fix.

Progressive Disclosure

No bundle files exist; the skill is a single ~155-line file with well-organized sections, and the deep migration detail is correctly deferred to a clearly signaled external guide ("Full reference: [Move a PGLite brain to Postgres](...move-to-postgres.md)") plus sibling-skill links. Matches anchor 4 (good structure, references clear, minor organization gaps) rather than 5 because nothing is split across bundle files and the Step 3 sub-procedure is detailed enough that it could live in a reference file; not 3 because structure and signaling are genuinely good, not merely present.

Specificity

Lists multiple concrete actions with comprehensive coverage: "Detect which gbrain engine is in use (PGLite vs Postgres)", "install/provision Postgres (Supabase discovery via SUPABASE_ACCESS_TOKEN, local Postgres, opt-in Docker)", and "move an existing PGLite brain to Postgres with its history (plan, ask, run)". Every action is specific down to env-var names, matching the anchor for comprehensive concrete actions rather than the score-4 anchor, which expects minor coverage gaps.

Completeness

The "what" is explicit and detailed (detect, install/provision, move with history), but the description field itself contains no "Use when..." clause or equivalent trigger guidance — the when-guidance lives in separate frontmatter fields ("triggers", "when_to_use") rather than in the description. Per the guideline that a missing 'Use when...' clause caps completeness at 3, this matches anchor 3 (clear 'what', 'when' missing); it is not 4 because the 'when' is not explicit within the description text itself.

Trigger Term Quality

Good natural-phrase coverage: "pglite or postgres", "upgrade to postgres", "switch gbrain to postgres", "move my brain to supabase", "install postgres for gbrain". Not 5 because the verb "migrate" — the command's own word and a likely user phrasing ("migrate my brain to postgres") — is absent from the description's keywords; not 3 because many natural user phrasings are present, not just technical jargon.

Distinctiveness Conflict Risk

Occupies a clear niche with distinct triggers: "gbrain engine", "PGLite", "Supabase discovery via SUPABASE_ACCESS_TOKEN" are highly specific to this one tool and workflow, so it would not trigger for unrelated skills. Matches anchor 5 (clear niche, minimal conflict risk) rather than 4, which expects some overlap with closely related skills.