dotnet-techne-csharp-api-design

Solid

Use when designing or changing public C#/.NET APIs with compatibility and versioning constraints. Keywords: breaking change, API design, backward compatibility, binary compatibility, deprecation strategy, versioning.

AI & Automation 12 stars 1 forks Updated 2 days ago MIT

Install

View on GitHub

Quality Score: 85/100

Stars 20%
37
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# Public API Design and Compatibility ## When to Use This Skill Use this skill when: - Designing public APIs for NuGet packages or libraries - Making changes to existing public APIs - Planning wire format changes for distributed systems - Implementing versioning strategies - Reviewing pull requests for breaking changes --- ## The Three Types of Compatibility | Type | Definition | Scope | |------|------------|-------| | **API/Source** | Code compiles against newer version | Public method signatures, types | | **Binary** | Compiled code runs against newer version | Assembly layout, method tokens | | **Wire** | Serialized data readable by other versions | Network protocols, persistence formats | Breaking any of these creates upgrade friction for users. --- ## Extend-Only Design The foundation of stable APIs: **never remove or modify, only extend**. ### Three Pillars 1. **Previous functionality is immutable** - Once released, behavior and signatures are locked 2. **New functionality through new constructs** - Add overloads, new types, opt-in features 3. **Removal only after deprecation period** - Years, not releases ### Benefits - Old code continues working in new versions - New and old pathways coexist - Upgrades are non-breaking by default - Users upgrade on their schedule **Resources:** - [Extend-Only Design](https://aaronstannard.com/extend-only-design/) - [OSS Compatibility Standards](https://aaronstannard.com/oss-compatibility-standards/) --- ## API Change G...

Details

Author
Metalnib
Repository
Metalnib/dotnet-episteme-skills
Created
6 months ago
Last Updated
2 days ago
Language
C#
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

api-versioning

Provides expert knowledge for designing, implementing, and managing REST API versioning strategies with deprecation workflows.

0 Updated yesterday
lgzarturo
API & Backend Listed

api-break-check

Review an API change for backward-incompatible breaking changes before it ships and breaks existing consumers — removed or renamed fields, added required request parameters, narrowed types, tightened validation, changed status codes or error shapes, removed enum values, and (for gRPC) changed field numbers. Explains who breaks and why, then rewrites the change to be compatible: additive evolution, deprecate-then-sunset, or a new version with expand/contract. Use whenever writing, reviewing, or about to merge a change to an API contract — an OpenAPI / Swagger spec, a GraphQL schema, a protobuf / gRPC definition, or the handlers/DTOs/serializers behind them — especially for an API with consumers you don't control.

0 Updated 1 months ago
windchillscalanthes-ship-it
API & Backend Listed

api-versioning

API version lifecycle governance for breaking-change classification, deprecation windows, migration planning, and support matrix management across internal and external consumers. Trigger when contract diffs may break consumers (for example required-field removal, semantic change, or channel change), when deprecation/sunset planning is required, or when multiple consumer cohorts must be supported in parallel. Do not use for first-pass endpoint/schema design.

0 Updated 2 weeks ago
planifest