go-cms-resources

Guides Go CMS resource architecture including tree resources, Library items, routing, and storage boundaries.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Designing resource architecture in the Go CMS backend is error-prone: mixing tree resources with high-volume LibraryItem collections, leaking PostgreSQL partition details into domain code, or allowing route collisions can cause serious data and scalability problems. This Skill encodes the architectural invariants and design rules for the CMS resource model. ## Core Features & Use Cases - Resource Model Guidance: Enforces separation of resource identity, tree placement, and physical storage, including the Library vs LibraryItem distinction. - Routing and URL Patterns: Defines a small URL-pattern DSL, route namespace collision checks, and bounded validation that never loads entire collections into memory. - Storage and Lifecycle Rules: Keeps PostgreSQL partitioning behind repository adapters and defines move, soft-delete, permission, and pagination invariants. - Use Case: When adding a new resource type or modifying Library behavior, follow this Skill to validate type immutability, route uniqueness, and adapter boundaries before writing code. ## Quick Start Ask the AI to review or design a change to the Go CMS resource model, such as adding a LibraryItem move operation, using the go-cms-resources guidelines.

Frequently Asked Questions about go-cms-resources

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

FAQPage Schema
How do I model high-volume resource collections in a CMS tree?▼

Model them as LibraryItem resources owned by a Library via an explicit LibraryID relation, not as ordinary tree children via ParentID. This keeps tree children and large item collections unambiguous and avoids loading items into the resource tree.

How should LibraryItem URLs be routed without storing full paths?▼

Resolve item routes from the owning Library's current path plus a small URL-pattern DSL with tokens like {id}, {slug}, {year}, {month}, {day}. This avoids rewriting millions of stored paths when a Library moves.

Should PostgreSQL partition details appear in CMS domain code?▼

No. Core domain code must only see repository operations like Create, Get, Move, and Resolve. Partition topology, partition timestamps, and pruning logic belong entirely inside the PostgreSQL adapter.

Can a Library resource type be changed to another type?▼

No. The library type is immutable and enforced in backend domain validation: library-to-other and other-to-library conversions are both forbidden. Move, update, soft-delete, and restore remain separate operations.

How do I validate route collisions for millions of LibraryItems?▼

Use set-based or indexed repository checks instead of loading items into Go memory. If a pattern or path change cannot be proven safe without scanning all items, reject it with a domain error or defer it to a maintenance operation.

What pagination approach suits large Library collections?▼

Use bounded queries with deterministic ordering and cursor/keyset pagination rather than deep OFFSET scans. Never expose ListAll-style repository APIs for a Library, and keep filters adapter-neutral.