| name | implementation-strategy |
| description | Decide how to implement runtime and API changes before editing code. Use when a task changes exported APIs, MCP tool definitions, runtime behavior, or configuration, and you need to choose the compatibility boundary and implementation shape. |
Implementation Strategy
Overview
Use this skill before editing code when the task changes runtime behavior or anything that might look like a compatibility concern. The goal is to keep implementations simple while protecting real released contracts.
Quick start
- Identify the surface you are changing: released MCP tool API, unreleased branch-local API, internal helper, configuration surface, or docs only.
- Determine the latest release boundary:
git tag -l 'v*' --sort=-v:refname | head -n1
- Judge breaking-change risk against that latest release tag, not against unreleased branch churn.
- Prefer the simplest implementation. Update callers, tests, and docs directly instead of preserving superseded unreleased interfaces.
- Add a compatibility layer only when there is a concrete released consumer or the user explicitly asks for a migration path.
Compatibility boundary rules
- Released MCP tool API or documented external behavior: preserve compatibility or provide an explicit migration path.
- Configuration, environment variables, and externally consumed settings: treat as compatibility-sensitive when part of the latest release.
- Interface changes on the current branch or after the latest release tag: not a compatibility target. Rewrite directly.
- Internal helpers, private types, tests, and fixtures: update directly.
Default implementation stance
- Prefer deletion or replacement over shims and feature flags when the old shape is unreleased.
- Do not preserve a confusing abstraction just because it exists in the current branch diff.
- If a change truly crosses the latest released contract boundary, call that out explicitly.
When to stop and confirm
- The change would alter behavior shipped in the latest release tag.
- The change would modify MCP tool schemas that clients depend on.
- The user explicitly asked for backward compatibility or migration support.
Output
State the decision briefly:
Compatibility boundary: latest release tag v0.x.y; branch-local interface rewrite, no shim needed.Compatibility boundary: released tool schema; preserve compatibility and add migration path.
