new-api-version

What problem does it solve?

When upstream Jellyfin releases introduce breaking API changes that require a new if m.getApiVersion() >= N dispatch level, implementing the new tier incorrectly can lead to half-built, broken API dispatch that leaves JellyRock non-functional for users on newer Jellyfin server versions. This Skill eliminates that risk by providing a step-by-step guided workflow that coordinates every required surface change in the correct order.

Core Features & Use Cases

• End-to-end tier scaffolding: Walks contributors through every required update in sequence: the YAML version boundary map, the resolveApiVersion() BrightScript twin, new sdkVN.bs endpoint shims, dispatch branches in ApiClient.bs, device profile updates, manifest tier clamps, and documentation updates.
• Built-in consistency guardrails: Includes static verification gates (twin-consistency checks, manifest drift detection, boundary validation) that catch mismatches between the boundary map, dispatch logic, and manifest before code is merged, preventing broken dispatch.
• Use Case: When proactive triage via /server-upgrade <rc-or-unstable> identifies a breaking API shift requiring a new tier (e.g., V3 for Jellyfin 10.12+), this skill ensures all related changes are implemented and validated together, avoiding partial implementations that break user functionality.

Quick Start

Use the new-api-version skill to stand up a new Jellyfin API version tier for the breaking changes introduced in Jellyfin server version X, following the guided steps to update all required surfaces and run all validation checks.