# Implementation Strategy

> 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.

- Skill: `pproenca/implementation-strategy` (Agent Skill)
- Install (CLI): `npx skillmds@latest add pproenca/implementation-strategy`
- Raw SKILL.md: https://api.skillmd.com/api/skills/pproenca/implementation-strategy/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: pproenca (https://skillmd.com/u/pproenca)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/pproenca/implementation-strategy

---


# 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

1. Identify the surface you are changing: released MCP tool API, unreleased branch-local API, internal helper, configuration surface, or docs only.
2. Determine the latest release boundary:
   ```bash
   git tag -l 'v*' --sort=-v:refname | head -n1
   ```
3. Judge breaking-change risk against that latest release tag, not against unreleased branch churn.
4. Prefer the simplest implementation. Update callers, tests, and docs directly instead of preserving superseded unreleased interfaces.
5. 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.`