| name | compatibility-check |
| description | Use when introducing dependencies or auditing runtime support, peer conflicts, deprecations, vulnerability posture, and rollback risk. |
Compatibility Check
Purpose
Prevent dependency and runtime surprises before they become build failures, production bugs, or security risks.
Announce: "I'm using the compatibility-check skill to validate tech stack compatibility."
Modes
| Mode | Trigger | Scope | Output |
|---|
| Pre-flight | /sc-plan introduces dependencies, vendors, runtimes, containers, or major version changes | Proposed changes | Compatibility section in the plan |
| Audit | /sc-audit compat or explicit request | Current project stack | Read-only compatibility report |
| Debug support | A failure looks version-related | Suspect dependency pair | Root-cause note and fix options |
Reference Router
Load only the active branch:
- Determine manifests, lockfiles, runtime declarations, platform constraints, provenance, and suspicious names: inspection surface
- Proposed dependency, runtime, vendor, container, or major-version change: pre-flight
- Existing stack or codebase-wide compatibility review: audit
- Select ecosystem-native checks: commands
- Classify and present supported findings: reporting
- Counter upgrade and audit shortcuts: red flags
Use context7-docs or current primary documentation for version-specific support. Load command and reporting references only when producing or verifying those outputs.
Mandatory Gates
- Mutation gate: Audit mode is read-only. Caller boundary: inside
/sc-audit, approval selects /sc-plan, /sc-debug, /sc-work, or /sc-go; transition to that owner before installing, upgrading, pinning, replacing, or editing configuration.
- Inventory gate: Read both manifests and lockfiles plus runtime, CI, container, and deployment declarations. Check direct and critical transitive dependencies, peer and optional-peer requirements, native extensions, platform limits, provenance, licenses, and install scripts as applicable.
- Evidence gate: Record current and proposed versions, exact manifest or lockfile evidence, supported runtime range, primary documentation, command output, vulnerability posture, and rollback path. Never infer support from “latest.”
- Tool gate: If a required tool is missing, report that limitation instead of inventing a result. Separate unverified areas from verified no-findings.
- STOP gate: Do not approve implementation with an unresolved P0 or P1, unsupported production runtime, incompatible peer requirement, active breakage, or missing rollback path. Propose supported alternatives first.
- Verification gate: Run only project-appropriate native checks, inspect breaking-change and deprecation notes, and verify the selected version pair in the project’s actual runtime and build path.
Related Skills
Use context7-docs for version-specific documentation, security-audit for broader risk, writing-plans for pre-flight decisions, systematic-debugging for version failures, and knowledge-compounding for resolved compatibility patterns.
