add-resource
GitHub指导如何在 Kubernetes 资源类型中全面添加或扩展支持,涵盖目录、刷新、详情、面板、权限及测试等多个表面。提供工作流与不变性规则,确保各子系统间数据一致性与正确集成。
Trigger Scenarios
Install
npx skills add luxury-yacht/app --skill add-resource -g -y
SKILL.md
Frontmatter
{
"name": "add-resource",
"description": "Add or extend support for a Kubernetes resource kind across the required catalog, refresh, detail, object-panel, object-map, permission, documentation, and test surfaces"
}
Add Resource
Treat resource support as a set of selectable surfaces, not one monolithic workflow. Decide the user-visible contract before editing.
Select surfaces
| Surface | Owner |
|---|---|
| Identity, status, facts, relationships | per-kind package plus backend/resourcemodel |
| Discovery and Browse | object catalog and catalog snapshot |
| List/table rows and streams | backend/refresh/snapshot, refresh system, frontend refresh |
| Rich detail and operations | backend/resources/<kind>, generated app binding |
| Object-panel rendering/actions | Overview descriptors, panel capabilities, action backends |
| Object map | per-kind graph facet, map snapshot, frontend support |
| YAML/apply and permissions | object YAML paths, RBAC/capability contracts |
List/table payloads belong in refresh snapshots; rich details and imperative
operations belong in backend/resources. The catalog owns discovery and
identity metadata; the namespaces refresh domain owns namespace LIST rows.
Workflow
- Identify group, version, kind, plural resource, and scope.
- Inspect one comparable per-kind package; use
backend/resources/deploymentfor a first-class workload example. - Write the surface list and related-object relationships before code changes.
- Read only the references matching those surfaces:
- kind and details for identity, descriptor, model, DTO, service, generated detail bindings, or built-in identity;
- frontend surfaces for Overview rendering, derived detail sections, built-in frontend identity, panel actions, or YAML UI;
- refresh and tests for catalog, table/list snapshots, resource streams, diagnostics, object-map participation, and the validation matrix.
- If status, facts, links, or object references change, read
docs/architecture/shared-resource-model.md. If refresh behavior changes, read the refresh-subsystem skill and only its matching references. If graph behavior changes, use the object-map skill. - Trace every producer and consumer for the chosen surfaces, then work in red/green/refactor cycles.
Invariants
- Define a first-class kind once in its package and register its descriptor once
in
backend/kind/kindregistry/registry.go; subsystems select descriptor facets instead of maintaining kind lists. - Project shared status, facts, and relationships from the per-kind model into DTO, snapshot, stream, and map consumers.
- Generate app detail bindings; never hand-edit generated dispatch or its derived exact-GVK gate.
- Keep snapshot and resource-stream row shapes at parity.
- Custom resources retain discovered group/version; do not place them in built-in identity tables.
- Explain any intentionally omitted user-visible surface before narrowing the requested support.
Validation
Run only checks for changed surfaces while iterating, then follow the root final gate:
mise exec -- go generate ./backend
mise exec -- go test ./backend/resources/... ./backend/resourcemodel ./backend/kind/...
mise exec -- go test ./backend/objectcatalog ./backend/refresh/snapshot ./backend/refresh/system
mise exec -- npm run typecheck --prefix frontend
mise exec -- npm run test --prefix frontend -- <affected module or spec>
Inspect generated files and the worktree after generation or formatting.
Version History
- ee846a6 Current 2026-08-20 13:01


