permissions-capabilities

Validate Kubernetes RBAC permission checks and capability descriptors across backend and frontend workflows.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill reduces the risk of incorrect Kubernetes RBAC behavior by ensuring permission checks, capability descriptors, diagnostics, and UI action availability stay consistent across backend and frontend.

Core Features & Use Cases

  • RBAC capability enforcement: Implement permission-gated backend and action services so mutating operations (delete, edit, scale, restart, suspend, YAML changes) only run when allowed.
  • Concrete-object permission modeling: Validate that permission checks correctly use injected catalog-backed GVK/GVR/scope resolution rather than guessing resources from kinds.
  • Permission-denied diagnostics: Keep permission-denied refresh domains visible in diagnostics and provide stable, feature-keyed permission reporting to help users understand why actions are blocked.
  • Frontend action availability parity: Mirror backend capability rules in the UI via permission feature keys and an object action permission matrix, including derived action IDs that reuse backend mutations.
  • Testing and safety: Add tests that cover allowed, denied, and resolution-error cases, including degraded visibility for restricted-RBAC behavior.

Quick Start

Use the permissions-capabilities skill to implement or update the backend permission gates and capability descriptors, then verify that the UI action availability and diagnostics reflect the same denied reasons across snapshot and refresh flows.

Frequently Asked Questions about permissions-capabilities

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

FAQPage Schema
How do I keep Kubernetes RBAC permission checks consistent between backend services and frontend UI actions?

To keep Kubernetes RBAC consistent, you need to mirror backend capability rules in the UI using permission feature keys and an object action permission matrix. This ensures mutating operations like delete, edit, scale, and restart only run when allowed.

Why does my Kubernetes permission-denied reason disappear during snapshot and refresh flows?

Permission-denied reasons disappear when snapshot and resource-stream permission contracts are misaligned. You must keep permission-denied refresh domains visible in diagnostics by exposing denied and pending reasons through stable PERMISSION_FEATURES keys.

How do I correctly resolve Kubernetes resource permissions for concrete objects instead of guessing from kinds?

To correctly resolve Kubernetes resource permissions, you must use injected catalog-backed GVK/GVR/scope resolution. This validates that permission checks correctly determine whether object actions are allowed or denied without guessing resources from kinds.

Does my RBAC testing need to cover resolution-error cases for restricted Kubernetes environments?

Yes, your RBAC testing needs to cover allowed, denied, and resolution-error cases. Including degraded visibility for restricted-RBAC behavior ensures your permission gating remains robust when catalog-backed GVK/GVR/scope resolution fails.

What is the best way to implement frontend gating for Kubernetes mutating actions like YAML edits and suspensions?

The best way to implement frontend gating is to mirror backend capability rules via permission feature keys and an object action permission matrix. This includes derived action IDs that reuse backend mutations for YAML, edit, scale, restart, delete, and suspend workflows.