CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

postgresql-planning

Plan and implement OpenMeld PostgreSQL business persistence, schemas and migrations, transactions, Hyperdrive access, and data cutover. Use for the shared relational database transition or PostgreSQL work; not for unrelated D1 performance fixes or OpenConnector's upstream database.

Quality

87%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

82%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a dense, high-signal planning skill: concrete commands, decided architecture constraints, and strong safety stop-conditions for a database cutover domain, with detail appropriately deferred to canonical repo documents. The main gaps are the externalized migration/cutover execution steps, error recovery expressed only as stop/freeze directives, and unverifiable deep relative links.

Suggestions

Inline the entry command (or a one-line summary) of the migration/cutover workflow from the external postgresql.md doc so the critical path is executable without leaving the skill.

Add an explicit failure-recovery loop after step 5 (e.g., "If `pnpm pg:check` or behavior checks fail: fix, then re-run before proceeding") to complement the stop/freeze directives.

Verify the `../../../developing/...` relative links resolve from the skill's installed location, or mirror the two referenced docs as bundled references/ files so navigation does not depend on repo layout.

DimensionReasoningScore

Conciseness

Every line carries project-specific constraints Claude could not infer ("Pass `--org amplft` explicitly", "Application Hyperdrive caching is disabled", "Migrations and backup tools use the direct TLS endpoint on port 5432", "Keep PostgreSQL baseline/migrations under `packages/db/postgresql/migrations`"). There is no tutorial filler or explanation of concepts Claude already knows; the date (2026-10-04 cutover) and version (PostgreSQL 18) state decided baselines rather than time-conditional instructions. Not 4: there is no padding left to trim.

5 / 5

Actionability

The "Shortest useful start" gives concrete, copy-paste-ready commands and paths (`pnpm pg plan`, `tooling/postgresql/resources.json`, `pnpm pg:check`, `pnpm staging:deploy`) plus specific file locations. It is not anchor 5 because execution details for migrations and cutover are deliberately deferred to an external workflow doc, and planning steps like "Define who writes each fact and which readers need a transaction" are unavoidably abstract; it clearly exceeds anchor 3's pseudocode-level guidance.

4 / 5

Workflow Clarity

A clear 5-step sequence ends in explicit validation ("Run `pnpm pg:check`... add the smallest real PostgreSQL behavior checks"), and the cutover section lists checkpoint items (checksums, lock ownership, runtime grants, restore evidence) plus explicit stop conditions ("Stop the affected operation on a mismatched environment/branch, unknown owner, applied migration drift, failed restore..."). It is not anchor 5 because error recovery is expressed only as stop/freeze directives with no in-file fix-and-revalidate loop, and the detailed checklist is external; it is well above anchor 3, whose checkpoints are missing or implicit.

4 / 5

Progressive Disclosure

Sections are well organized (Shortest useful start, Decisions that change implementation, Before applying or cutting over), with clearly signaled one-level-deep pointers to canonical docs ("Read [physical database ownership](../../../developing/architecture/physical-db-split.md)") and deliberate deferral ("Use the workflow's migration and cutover checklist rather than copying it here"). No bundle files (references/, scripts/, assets/) exist, and the deep relative links point outside the skill bundle where they cannot be verified — a minor organization gap that keeps it below anchor 5.

4 / 5

Total

17

/

20

Passed

Description

87%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong third-person description that pairs a concrete multi-capability what-statement with an explicit, boundary-aware Use-for clause, including negative triggers to prevent misfires. Its only weaknesses are minor: a narrow action-verb set and a few missing natural synonyms (e.g., "Postgres") in the trigger phrasing.

DimensionReasoningScore

Specificity

"Plan and implement OpenMeld PostgreSQL business persistence, schemas and migrations, transactions, Hyperdrive access, and data cutover" lists several concrete capabilities (persistence, schemas/migrations, transactions, Hyperdrive access, cutover). It falls short of anchor 5 only because the verbs are limited to "plan and implement" and some domain actions (e.g., grants/roles, backup handling) are left implicit; it clearly exceeds anchor 3's 1-2 concrete actions.

4 / 5

Completeness

It explicitly answers both: what ("Plan and implement OpenMeld PostgreSQL business persistence, schemas and migrations, transactions, Hyperdrive access, and data cutover") and when ("Use for the shared relational database transition or PostgreSQL work; not for unrelated D1 performance fixes or OpenConnector's upstream database") with concrete trigger phrases and explicit negative boundaries. Not 4: the when-clause is specific and trigger-anchored, not merely present.

5 / 5

Trigger Term Quality

The when-clause "Use for the shared relational database transition or PostgreSQL work" plus the exclusion "not for unrelated D1 performance fixes" gives good natural keyword coverage (PostgreSQL, database transition, D1). It is not anchor 5 because common synonyms like "Postgres" and triggers for "migrations"/"cutover" are absent from the trigger phrasing; it is well above anchor 3's partial coverage.

4 / 5

Distinctiveness Conflict Risk

The description names a specific project and stack ("OpenMeld PostgreSQL", "Hyperdrive") and explicitly excludes adjacent domains ("not for unrelated D1 performance fixes or OpenConnector's upstream database"), giving it a clear niche with minimal conflict risk — a direct match to anchor 5, and clearly beyond anchor 4's minor-overlap profile.

5 / 5

Total

18

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

relative_links

Relative link issues: 2 suspicious

Warning

Total

15

/

16

Passed

Repository

amplifthq/opentag

Path

.agents/skills/postgresql-planning/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.