mcpField
R
resolve-spec-conflict

resolve-spec-conflict

github.com/plainlang開発8043 回インストール今日更新
リポジトリ

resolve-spec-conflict について

`.plain` の機能仕様間の競合を診断・解決するスキルです。実装やテストの問題と要件の矛盾を区別し、修正後の検証手順を示します。

主な機能

  1. 01競合する仕様の組み合わせを特定
  2. 02実装・テスト・要件の問題を区別
  3. 03解決方針を選択
  4. 04修正後の仕様とテストを検証

活用シーン

  1. 01合格済み適合性テストの失敗を調査
  2. 02新旧仕様間の矛盾を解消
  3. 03要件修正後にテストシナリオを更新

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/plainlang/plain-forge --skill resolve-spec-conflict

インストール後、Claude Code で/resolve-spec-conflictを入力して読み込まれたか確認します。

詳細

仕様の矛盾を解決する

まずルールを読み込んでください。 .plain ファイルを読んだり、編集したり、書き込んだりする前に、load-plain-reference スキルを呼び出し、案内されたルールファイルを読んでください。この会話ですでに load-plain-reference が実行されている場合に限り、この手順を省略してください。

該当するケース

次のいずれかに該当する場合、矛盾が存在するか、その疑いがあります。

  • 以前は合格していた機能仕様の適合性テストが、新しい仕様のレンダリング後に失敗し始める。
  • add-functional-spec または add-functional-specs スキルを使って追加しようとしている新しい仕様が、既存の仕様と矛盾しているように見える。
  • 2つの仕様が、同じ動作、データ、または状態について両立しない主張をしている。

ワークフロー

ステップ 1：矛盾する組み合わせを特定する

.plain ファイルを読み、緊張関係にある2つの仕様を特定します。適合性テストの失敗によって矛盾が検出された場合は、動作がどう変わったかを理解するため、失敗したテストと plain_modules/ 内の生成済み実装も読みます。

ステップ 2：根本原因を診断する

考えられる結果は3つあります。変更を加える前に、どれに該当するかを判断してください。

結果症状修正
実装が誤っている生成されたコードが仕様の意図と一致していません。仕様自体に問題はありません。レンダラーが正しく解釈できるよう、曖昧な仕様を明確にします。再レンダリングします。
適合性テストが誤っているテストが仕様を正確に検証していません。実装は実際には正しい状態です。***test reqs*** を調整するか、add-test-scenarios を使ってテスト用 plain ファイルのシナリオを調整し、より良いテストが生成されるようにします。再レンダリングします。
要件が実際に矛盾している2つの仕様は本質的に矛盾しており、両方を満たす実装はありません。一方または両方の仕様を改訂する必要があります。ステップ 3 を参照してください。

診断方法：

  1. 2つの機能仕様を注意深く読みます。単一の実装で両方を同時に満たせますか？
  2. はい → 仕様に矛盾はありません。問題は曖昧さ（結果 1）または不適切なテスト（結果 2）です。
  3. いいえ → 要件は実際に矛盾しています（結果 3）。
ステップ 3：矛盾を解決する

要件が実際に矛盾している場合は、解決策を選択します。

戦略 A：詳細を加えて曖昧さを解消する。 仕様は矛盾しているのではなく、曖昧さのためにレンダラーが矛盾する解釈を選んでいるだけの場合がよくあります。一方または両方の仕様に明示的なコンテキストを追加すれば、曖昧さを解消できます。

変更前（曖昧）：

***functional specs***

# list-resources
All :Resource: items are returned.

# list-active-resources
Only active :Resource: items are returned.

変更後（曖昧さを解消）：

***functional specs***

# list-resources
All :Resource: items are returned when no filter is specified.

# list-active-resources
When the "active" filter is specified, only active :Resource: items are returned.

戦略 B：新しい仕様を改訂する。 新しい仕様が矛盾を引き起こした場合は、以前の仕様で確立された動作と両立するように書き直します。

戦略 C：古い仕様を改訂する。 古い仕様の記述が不十分で、新しい要件によってより良い設計が明らかになった場合は、古い仕様を更新します。これは影響が大きく、その仕様とそれ以降のすべての適合性テストを再レンダリングする必要が生じる場合があります。

戦略 D：1つの仕様に統合する。 2つの仕様が重複する動作を記述している場合は、1つの明確な仕様にまとめます。重複する仕様とそのテスト用 plain ファイルを削除し、引き続き有効なシナリオは残す方の機能のファイルに移します。200 LOC の上限に注意してください。

ステップ 4：解決を検証する

編集後、次のことを行います。

  1. ***functional specs*** セクション全体を読み直し、新たな矛盾が生じていないことを確認します。
  2. 改訂した仕様が引き続き 200 LOC の上限を守っていることを確認します。
  3. 時系列順が妥当であることを確認します（先行する仕様が後続の仕様に依存してはいけません）。
  4. テストの調整によって解決した場合は、***test reqs*** またはテスト用 plain ファイルの変更が適切であることを確認します。
  5. 改訂した機能ごとに add-test-scenarios を呼び出し、テスト用 plain ファイルを新しいテキストに合わせます。

防止策（add-functional-spec / add-functional-specs の実行時に使用）

新しい仕様を追加する前に、次の簡単な競合チェックを行います。

  1. 新しい仕様と同じ :Concepts: に関わる既存の機能仕様をすべて列挙します。
  2. それぞれについて、「単一の実装で、この既存の仕様と新しい仕様の両方を満たせるか」と確認します。
  3. 答えが「明らかにできる」ではないものがあれば、曖昧さをなくすため、新しい仕様に明示的な詳細を追加してから挿入します。

検証チェックリスト

  • 根本原因を診断した（実装／テスト／実際の競合）
  • 解決方針を選択し、適用した
  • 修正した仕様が言語に依存しない
  • concise-specs.md に従って修正した仕様を簡潔にした — 追加した曖昧さの解消に関する記述は、可能な限り短くした
  • 修正した各仕様から想定されるコードが 200 LOC 以下である
  • 修正によって新たな競合が生じていない
  • 時系列順を維持した
  • 参照されている :Concepts: がすべて定義されている
  • add-test-scenarios を使い、手順で修正した機能のプレーンファイルをテストに追加した

コメント

Markdown 対応