mcpField
M
mino-interface-implementation-separation

mino-interface-implementation-separation

github.com/my-take-devDevelopment34643 installsUpdated 6w ago
Repository

About mino-interface-implementation-separation

A design, review, and implementation skill for separating consumer-facing purpose and operation contracts from internal technical choices. It checks for implementation leakage and unjustified abstraction, and can guide verified changes when scope and public meaning are clear.

Key features

  1. 01Defines consumer purpose and contract
  2. 02Screens retry and duplicate semantics
  3. 03Keeps implementation details behind boundaries
  4. 04Checks abstractions against real variants
  5. 05Evaluates changes with evidence

Use cases

  1. 01Reviewing an interface for implementation leakage
  2. 02Clarifying operation failure and retry behavior
  3. 03Assessing whether a port or abstraction is justified
  4. 04Planning a scoped contract change

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/my-take-dev/inspired-mino-design-skills --skill mino-interface-implementation-separation

After installing, type/mino-interface-implementation-separationin Claude Code to confirm it loaded.

Bundled filesagents/openai.yamlschemas/package.md

Details

From the project README

Interface / Implementation Separation

Outcome Contract

consumerが必要とする目的・操作・契約と内部技術・手順を分け、漏出と過剰抽象化を判定する。修正が依頼され公開意味と範囲が確定していれば変更・検証まで進める。 正本packageのrootはboundary_package。 対応mode: design, review, implementation。

Reference Routing

  • 初回はskills/mino-core/references/shared-policies.mdを読み、Evidence・承認・判定を適用する。同じcontextで既読なら再読しない。通常の判断は本体とこの共通規則で行う。
  • codeの責務・命名を変更するときはskills/mino-core/references/code-design.md、既存挙動・公開契約の変更時はskills/mino-core/references/change-safety.mdを読み、具体的な変更と検証へ落とす。
  • 対象systemのfile/process/test実行・複数OS要件がある場合はskills/mino-core/references/platform-compatibility.mdを読み、host・対象・検証層を分ける。単なる回答記録の保存では追加読込しない。
  • 正本packageの作成・更新・引継ぎを依頼された場合だけskills/mino-interface-implementation-separation/schemas/package.mdを読み、必須fieldと実在参照を保持する。

Workflow

  1. caller、公開契約、code、依存、品質、実在variantから、domain判断・use-case調整・永続化・外部I/O・表現・運用を分類する。局所guardの問いへ全systemのpackageを要求しない。
  2. consumerのpurpose、must_know、must_not_knowと、operationの入力・結果・失敗・副作用・不変条件を定める。domain契約が該当すれば既存Contractを参照する。genericな技術境界には理由付きN/Aとconsumer semantic operationを使い、業務を発明しない。
  3. operationごとにend_to_end_deadline、retry_semantics、idempotency、duplicate_semantics、ambiguous_outcomeを個別にapplicable / not_applicable / unknownでscreenする。deadlineは上限・owner・timeout結果、retryは許可/禁止条件・owner、idempotency/duplicateは重複結果・owner、曖昧結果は観測結果・照合/復旧ownerを明確にする。
  4. N/Aは理由とEvidence、unknownは確認方法と影響を残す。該当しない意味fieldを空で展開しない。pure/read-onlyという名前だけで全N/Aにせず、外部依存と要求を調べる。冪等性keyは必要な根拠がある場合だけ定める。
  5. SDK型、DB row、framework型、provider手順、serialization、cache、algorithm、backoff、試行単位のtimeoutを実装側へ置く。consumerの判断に必要なretry・重複・曖昧結果の意味は公開面に残す。consumerが契約を使いadapterが実装する依存方向にする。
  6. semantic/invariant/contract/state/source-of-truth/failure-recovery/operational ownerは既存authorityを参照し、system全体の正本や条件の保証を再決定しない。
  7. selection boundaryは実在variantにだけ設ける。一実装でも外部障害隔離・契約安定の根拠があれば小さなportを使える。短いguardは維持し、将来用factoryや階層を作らない。状態・規則・実装variant・一時flagの分岐を区別する。
  8. 実装交換、実在variant追加/変更、業務規則変更の該当scenarioをpass / fail / not_applicable / unknownとEvidenceで評価する。既存caller・公開契約を変える場合だけconsumer一覧、互換window、段階移行、復旧、旧path利用ゼロの観測を設ける。

Hard Gates

  • if数・interface数を品質と扱わない。state・判断・更新は同じ目的と不変条件の責務へ集め、不正状態を全public writerから防げるか調べる。
  • 共通化は目的・契約・変更理由が揃う場合だけ行う。異なる意味を隠した抽象化やcallerへの技術漏出を残さない。
  • 意味不明の箇所を仮定で確定しない。変更予定の暫定pathを導入済みとせず、実在するTMP IDだけを参照する。

Completion

意味と内部実装が分かれればseparated、技術漏出・誤責務はleaky、根拠のない抽象はoverabstracted、適用自体が不要ならnot_applicable、重要未確認はindeterminate。併存するfindingを保持し、対象verdictと現在artifactの完成を分ける。

Comments

Markdown supported