Api Compat

Change public APIs without breaking clients—versioning schemes, additive vs breaking changes, deprecation windows, and comms. Use when shipping breaking chan...

Security Scan

This is an instruction-only guidance skill about API versioning and deprecation; it requests no credentials, installs nothing, and its instructions align with the stated purpose.

Purpose & Capability

Name, description, and SKILL.md all describe API compatibility practices. There are no unrelated requirements (no env vars, binaries, or install steps) that would be inconsistent with the stated purpose.

Instruction Scope

SKILL.md contains prose-level guidance, checklists, and best practices. It does not instruct the agent to run commands, read files, access environment variables, or transmit data to external endpoints.

Install Mechanism

No install spec and no code files — instruction-only skill. This minimizes risk because nothing is downloaded or written to disk during install.

Credentials

The skill declares no required environment variables, credentials, or config paths. There is no disproportionate access requested relative to its stated function.

Persistence & Privilege

always is false and the skill makes no claims about modifying agent/system configuration. Autonomous invocation is allowed by default but presents no extra risk here because the skill performs only static guidance.

Assessment

This skill is purely advisory text about managing API changes and appears internally consistent and low-risk: it doesn't install software or request secrets. Before installing, consider provenance — the source/homepage is unknown, so if you require trusted provenance for your environment, prefer skills from known authors or internal docs. Also remember: "benign" here means the skill is coherent with its description, not that the guidance is guaranteed correct for your organization; review the recommendations against your own policies and telemetry systems before acting on them.

API Compatibility

Own the lifecycle of a public API: who breaks when you ship, how long old behavior lives, and how clients discover what’s next. Pair with http-api for how requests look today; this skill is about time and promises.

When to use

• Adding/removing fields, routes, or semantics that existing clients rely on.
• Choosing URL vs header vs package versioning—or when no formal version and only additive JSON.
• Deprecation: timelines, metrics (who still calls old paths?), and removal gates.

Core ideas

• Additive first — nullable new fields beat silent behavior changes.
• Explicit contracts — integration tests or consumer-driven checks for critical partners.
• Communicate — changelog, developer email, in-response Sunset / warnings where standards allow.

Avoid

• “We’ll just bump the version” without a migration story for slow-moving apps.
• Breaking auth or pagination with no coordination window.
• Deprecating without usage data—you’ll cut traffic you didn’t know existed.

Checklist before breaking

• Who is affected (internal only vs third parties)?
• Minimum notice period and rollback if telemetry spikes errors?
• Docs + examples updated before the flag day?

Done when

• Old and new behaviors are measurable; removal is gated on evidence, not hope.