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.
ソース情報
- リポジトリ
- pproenca/unifi-mcp
- ソースの最終更新活動
- 2026年4月7日 07:52
- 検出された SKILL.md の言語
- 英語
- スター
- 2
- フォーク
- 0
インストール方法
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
ソースファイルを確認
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
SKILL.md を表示中
SKILL.md
ソースの指示 · 読み取り専用プレビュー- 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
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.`
GitHubで見る