shared-resource-model

Unify Kubernetes resource identity and status presentation across backend projections and frontend rendering.

411|21|Updated Dec 18, 2025
One-click install
npx skills add https://github.com/luxury-yacht/app --skill shared-resource-model
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: shared-resource-model
Source: https://github.com/luxury-yacht/app/tree/main/.agents/skills/shared-resource-model
Command: npx skills add https://github.com/luxury-yacht/app --skill shared-resource-model

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It prevents inconsistent Kubernetes resource identity, status, facts, links, and projections across Luxury Yacht surfaces, so users don’t see mismatched views of the same object.

Core Features & Use Cases

  • Canonical Kubernetes identity: Establishes consistent group/version/kind scoping and cluster-aware references for concrete and event involved-object identities.
  • Single-source status presentation: Computes primary status once in the backend and projects it through status/state/presentation fields for consistent UI styling and messaging.
  • ResourceLink relationship integrity: Uses safe, display-ready links when sources are incomplete, avoiding unsafe navigation while keeping relationship rendering coherent.
  • Parity across consumers: Keeps table rows, stream rows, object panel details, events, and object-map nodes/edges aligned for the same resource family.

Quick Start

Use this shared-resource-model guidance to update identity and presentation logic end-to-end by following the listed backend and frontend entry points and ensuring the projections and tests remain consistent.

Frequently Asked Questions about shared-resource-model

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

FAQPage Schema
How do I keep Kubernetes resource identity and status consistent between backend DTOs and frontend UI?

To keep Kubernetes resource identity and status consistent, compute canonical group/version/kind scoping and primary status presentation once in the backend, then project them through shared DTO fields for frontend rendering. This ensures backend and frontend parity.

What is the best way to standardize Kubernetes object map rendering across table rows and detail panels?

Standardize Kubernetes object map rendering by unifying canonical resource identity and presentation across table rows, stream rows, object panel details, events, and object-map nodes. This keeps relationship rendering coherent for the same resource family.

How do I safely handle incomplete Kubernetes ResourceLink relationships for frontend navigation?

Handle incomplete Kubernetes ResourceLink relationships safely by using display-ready links when sources are incomplete. This avoids unsafe frontend navigation while keeping relationship rendering coherent across object maps and detail panels.

Does this approach support cluster-scoped references and catalog-based GVK resolution for Kubernetes events?

Yes, this approach supports cluster-scoped references and catalog-based GVK/GVR/scope resolution. It applies canonical identity resolution to both concrete objects and event involved-object identities for consistent projections.

Why do my Kubernetes resource views show mismatched status styling between the events stream and object details?

Mismatched Kubernetes status styling occurs when status presentation is computed independently across UI surfaces. Enforce backend-driven statusPresentation rendering to compute primary status once and project it consistently across all panels.