102 skills · sorted by relevance
Apply consistent deprecation notices to public Remotion APIs that remain available. Use TypeScript annotations and documentation formatting to mark APIs as no longer recommended, identify replacements, and review whether both representations follow the conventions.
後方互換性がゴミコードを量産する構造を検出し、互換性を「契約と撤去計画」として管理する ガバナンスを支援するスキル。公開API境界の明確化、非推奨化サイクル（deprecation cycle）の 制度化、互換層の局所化（Adapter/Strangler Fig）、契約テスト（CDC）による互換性検証、 AI生成コードの互換性ゲート設計を含む。コードレビュー、API設計、リファクタリング、 レガシー移行時に互換性起因の技術的負債を防ぐために使用。 対象言語: 言語非依存（Java, TypeScript, Go, Python, Rust等すべて）。 トリガー：「後方互換性を保ちたい」「非推奨APIをどうする」「互換層が増えてきた」 「レガシー移行の戦略」「API設計レビュー」「互換性のためのコードが多い」 「deprecation policyを作りたい」「破壊的変更の管理」といった互換性管理関連リクエストで起動。
The English summary is being prepared. Showing the original description.
Use when you need to design, review, or improve REST APIs with Quarkus REST (Jakarta REST) — including resource classes, HTTP methods, status codes, request/response DTOs, Bean Validation, exception mappers, optional runtime OpenAPI exposure (SmallRye), contract-first generation from OpenAPI, content negotiation, pagination, sorting and filtering, API versioning, idempotency (Idempotency-Key), optimistic concurrency (ETag / If-Match), HTTP caching (Cache-Control), API deprecation (Sunset / Deprecation headers), RFC 7807 Problem Details, ISO-8601 for time in contracts, and security-aware boundaries. This should trigger for requests such as Review or improve JAX-RS resources in a Quarkus project; Design HTTP APIs with validation and error handling on Quarkus; Add API versioning, idempotency, ETag concurrency, or deprecation headers; Implement pagination, sorting, or RFC 7807 Problem Details error responses; Improve Quarkus REST resources and exception mappers. Part of Plinth Toolkit
The English summary is being prepared. Showing the original description.
Audit existing changelog and deprecation practices — find missing entries, undocumented breaks, and stale deprecations. Use when asked to "audit our changelog", "find undocumented breaking changes", or "check for stale deprecations".
The English summary is being prepared. Showing the original description.
API migration strategies, deprecation workflows, and header/URL/content versioning. Activate on: API versioning, backward compatibility, deprecation, breaking change, API migration, v1 v2, sunset header. NOT for: schema evolution in data (use schema-evolution-manager), gateway routing (use api-gateway-reverse-proxy-expert).
The English summary is being prepared. Showing the original description.
Use when you need to design, review, or improve REST APIs with Quarkus REST (Jakarta REST) — including resource classes, HTTP methods, status codes, request/response DTOs, Bean Validation, exception mappers, optional runtime OpenAPI exposure (SmallRye), contract-first generation from OpenAPI, content negotiation, pagination, sorting and filtering, API versioning, idempotency (Idempotency-Key), optimistic concurrency (ETag / If-Match), HTTP caching (Cache-Control), API deprecation (Sunset / Deprecation headers), RFC 7807 Problem Details, ISO-8601 for time in contracts, and security-aware boundaries. This should trigger for requests such as Review or improve JAX-RS resources in a Quarkus project; Design HTTP APIs with validation and error handling on Quarkus; Add API versioning, idempotency, ETag concurrency, or deprecation headers; Implement pagination, sorting, or RFC 7807 Problem Details error responses. Part of cursor-rules-java project
The English summary is being prepared. Showing the original description.
API migration strategies, deprecation workflows, and header/URL/content versioning. Activate on: API versioning, backward compatibility, deprecation, breaking change, API migration, v1 v2, sunset header. NOT for: schema evolution in data (use schema-evolution-manager), gateway routing (use api-gateway-reverse-proxy-expert).
The English summary is being prepared. Showing the original description.
Plans safe API evolution with versioning strategies, client migration guides, deprecation timelines, and backward compatibility considerations. Use for "API versioning", "deprecation planning", "API evolution", or "breaking changes".
The English summary is being prepared. Showing the original description.
Plan the retirement of old APIs, features, and systems, then move their users to replacements in stages. The skill also guides database schema changes through additive steps that keep old and new application code compatible during rollout.
Audit Kiln’s model list against provider APIs and catalogs to identify removed models and upcoming retirements. Get findings organized by provider, then mark affected entries as deprecated after reviewing and approving the proposed changes.
Check whether Kiln’s base models still support fine-tuning, the process of adapting a model with additional training. Compare configured identifiers and Fireworks’ allowlist with provider information, then report unsupported entries and recommend specific updates.
Check Apple documentation for deprecated SwiftUI APIs and their replacements. Updates the SwiftUI Expert Skill reference with version requirements, code examples, and a lookup table, then prepares a pull request using Sosumi MCP.
Write an API versioning strategy document for a service or API platform. Use when asked to define versioning policy, plan API deprecation, classify breaking changes, or document version lifecycle. Produces a complete versioning strategy with breaking-change classification table, deprecation timeline, migration guide template, and client communication template.
The English summary is being prepared. Showing the original description.
Version REST and GraphQL APIs. Use when a user asks to version an API, handle breaking changes, implement API deprecation, manage multiple API versions, or design an API evolution strategy.
The English summary is being prepared. Showing the original description.
Manages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when migrating a database schema in production, such as renaming or dropping a column without downtime (expand/contract). Use when deciding whether to maintain or sunset existing code.
The English summary is being prepared. Showing the original description.
Design an API versioning and deprecation policy — semver rules, sunset timelines, and communication channels. Use when asked to "design a deprecation policy", "how should we version the API", or "set a sunset timeline".
The English summary is being prepared. Showing the original description.
Design an API compatibility and deprecation policy — stability tiers, sunset timelines, and CI gates. Use when asked to "define an API stability policy", "set our deprecation timeline", or "write semver rules".
The English summary is being prepared. Showing the original description.
Plan deprecation and migration—replacement first, consumer migration, strangler and adapter patterns, zombie code removal. Use when sunsetting APIs, libraries, or legacy modules.
The English summary is being prepared. Showing the original description.
Manages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when deciding whether to maintain or sunset existing code.
The English summary is being prepared. Showing the original description.
Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs.
The English summary is being prepared. Showing the original description.
Manages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when deciding whether to maintain or sunset existing code.
The English summary is being prepared. Showing the original description.
Use when replacing an old system, API, or library, sunsetting a feature, consolidating duplicate implementations, removing dead code nobody owns, or deciding whether to maintain a legacy system versus migrate off it. Covers deprecation timelines, migration paths, and safe removal.
The English summary is being prepared. Showing the original description.
Plan or implement retirement of a system, API, feature, persisted configuration, or database shape. Use for compatibility cutovers, explicit deprecation review, or an explicit unreleased replacement decision, including determining whether consumers or data exist; not ordinary dependency bumps, local renames, prose edits, or generic architecture discussion.
The English summary is being prepared. Showing the original description.
Deprecate APIs, features, or systems safely — announce, migrate consumers, sunset on a timeline, and document alternatives. Load when removing an old API, migrating users between implementations, sunsetting a feature, or the user asks about deprecation policy, migration guides, or breaking changes. Not for deleting dead code with zero consumers (use code-simplification). Distinct from meta `deprecate-skill` (skill library retirement).
The English summary is being prepared. Showing the original description.