go-cms-resource-fields

Defines typed field persistence, querying, and indexing rules for Go CMS resources.

Updated Jun 15, 2026
One-click install
npx skills add https://github.com/vernal96/go-cms --skill go-cms-resource-fields-vernal96
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: go-cms-resource-fields
Source: https://github.com/vernal96/go-cms/tree/main/.codex/skills/go-cms-resource-fields
Command: npx skills add https://github.com/vernal96/go-cms --skill go-cms-resource-fields-vernal96

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Template field values stored in generic resource Settings JSONB cannot be filtered, sorted, or indexed with typed semantics, and LibraryItems risk getting a weaker parallel query model. This Skill provides the architectural rules for migrating to typed field-value persistence in the Go CMS backend. ## Core Features & Use Cases - Typed Field-Value Persistence: Replace JSONB settings with a dedicated table keyed by resource identity, using storage kinds (string, integer, float, boolean, timestamp, reference, json) and typed value columns. - Adapter-Neutral Query Contract: Keep resource.field.<key> paths semantic while PostgreSQL translates them into typed predicates, with correct multi-value set semantics and deterministic missing-field behavior. - LibraryItem Sort Projection: Maintain an adapter-local denormalized library_id projection for high-volume custom sorting, synchronized across Create, Update, Move, Delete, and Restore paths. - Use Case: When refactoring the backend so vacancies can be filtered by resource.field.salary >= 150000 with real typed comparisons and indexed sorts, follow this Skill to design the schema, write paths, and tests. ## Quick Start Ask the AI to refactor Go CMS template field values out of the resources settings JSONB into typed field-value persistence following this skill's rules.

Frequently Asked Questions about go-cms-resource-fields

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I store CMS template field values so they can be filtered and sorted?▼

Persist field values in a dedicated table keyed by stable resource identity, with one typed column per storage kind (string, integer, float, boolean, timestamp, reference, json). Avoid storing all fields in one JSONB object, since that prevents typed comparisons and predictable indexing.

How should multi-value fields be queried in PostgreSQL?▼

Represent filterable multi-values as multiple rows sharing the same resource_id and field_key with a deterministic position. Negative predicates like NOT IN must use NOT EXISTS set semantics so a resource is excluded only when no matching row exists, not merely because another row differs.

Should LibraryItems use a separate field filtering model?▼

No. LibraryItems and ordinary TreeResources must share the same field-value abstraction and query vocabulary, attached to the common stable resource identity. Building a second weaker LibraryItem filter model that cannot query typed template fields is explicitly disallowed.

When is a denormalized library_id column acceptable in field-value rows?▼

Only as an adapter-local PostgreSQL query projection for high-volume LibraryItem sorting, invisible to domain and API contracts. It must be written atomically with field values, updated on Move and Restore, and never redefine canonical Library ownership.

Do I need to keep JSONB compatibility code when migrating field storage?▼

No. The project is pre-production, so replace the schema directly, squash migrations, update seeds and tests, and remove dual-write or legacy conversion code. Only design a real data migration when production or external data must explicitly be retained.