s4h-logic-consistency-check について
文書や一連の主張の論理的一貫性を確認するスキルです。目標、制約、前提、要件を整理し、矛盾や境界ケースを調べます。
主な機能
- 01主張と要件の整理
- 02目標と制約の衝突確認
- 03要件間の矛盾確認
- 04境界ケースと前提の検討
- 05発見事項と修正案の構造化
活用シーン
- 01複数人で作成した仕様書の確認
- 02段階的に決めた内容の検査
- 03実装前の矛盾の発見
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ human-avatar/ skills-for-humanity --skill s4h-logic-consistency-checkインストール後、Claude Code で/s4h-logic-consistency-checkを入力して読み込まれたか確認します。
詳細
論理的整合性のチェック
要件は変化します。仕様は積み重なります。複数人が数週間かけて書いた文書や、段階的に決められた一連の事項には、各項目が個別にレビューされたために誰も気づかなかった矛盾が含まれていることがあります。
このスキルでは、文書全体を読み、各部分の食い違いを見つけます。
作業の進め方
ステップ 1:主張を整理する 整合性をチェックする前に、文書で述べられている内容を洗い出します。
- 明記された目標と目的
- 明記された制約と譲れない条件
- 明記または暗示された前提
- 決定事項と、その理由として示された内容
- 番号付きの要件や受け入れ基準
この整理をもとに、文書内部の整合性をチェックします。確認するのは、各主張が正しいかどうかではなく、主張同士に一貫性があるかどうかです。
前提の確認: 続行する前に、対象となる文書または主張の一式を確認します。分析対象そのものと主要な条件(文書の種類、範囲、緊張関係にある主な主張)を特定したことを1文で述べてから、AskUserQuestion を使用します。
- 質問:「次のように理解しています:[チェック対象の具体的な文書または主張の一式についての、1文での説明]。この理解で合っていますか?」
- ヘッダー:「前提」
- 選択肢:
- はい — 続行 — 前提は正しい
- 調整 — 1つの要素が違うため、続行する前にユーザーが修正する
- 再設定 — 想定されている状況とは異なるため、修正を反映してから続行する
ステップ 2:目標と制約の衝突をチェックする 記載された目標を達成するために、記載された制約に違反する必要がありますか?よくあるパターン:
- 予算の範囲を超えるリソースが必要なパフォーマンス目標
- 複雑さを必要とする機能一覧と組み合わされた、シンプルさの目標
- 品質要件が求める工程の省略を必要とするスケジュール
ステップ 3:要件同士の衝突をチェックする 個々の要件は互いに矛盾していますか?
- 同時に満たせない2つの要件
- 別の要件の特別なケースでありながら、異なる方法で扱われている要件
- 暗黙の意味が異なるのに同じ用語を使っている要件(要件間の多義性)
ステップ 4:衝突が明らかになるエッジケースを探す 矛盾が境界条件でのみ現れることがあります。次の場合に何が起きるかを確認します。
- 入力が最小値と最大値を同時に求められる場合
- 独立して設計された2つの機能が相互作用する場合
- 想定された正常系が成り立たない場合
- 明記された例外が明記されたルールに該当する場合
ステップ 5:前提の整合性をチェックする 暗黙の前提は、最も危険な不整合の原因です。どこにも明記されていないのに、あらゆる箇所の土台になっています。以下を明らかにします。
- 各要件を満たすために、何が真である必要がありますか?
- それらの前提に矛盾するものはありますか?
- 明記された事実と矛盾する前提はありますか?
ユーザーへの確認
続行する前に、AskUserQuestion ツールを使用します。状況についての解釈を1〜2文で述べます。分析対象と中心的な問いを示してから、次のように尋ねます。
- 質問:「私の理解は次のとおりです:[1〜2文での解釈]。どのように進めますか?」
- ヘッダー:「範囲」
- 選択肢:
- 完全な分析 — すべてのステップを完了し、全体を通じて推論を示す
- 主な調査結果のみ — 結論だけを出し、ステップごとの詳細は省略する
- 矛盾の一覧のみ — 完全な分析は行わず、具体的な不整合を示す
- 再設定 — 理解が違うため、修正後の前提に基づいて分析する
選択に応じて進めます。ユーザーが前提を再設定した場合は、分析を始める前にその修正を反映します。
出力形式
対象: [チェックした内容]
見つかった矛盾
| 種類 | 項目 A | 項目 B | 矛盾 |
|---|---|---|---|
| 目標と制約 | [目標] | [制約] | [矛盾する理由] |
| 要件と要件 | [要件] | [要件] | [矛盾する理由] |
| 前提と事実 | 前提 | [事実] | [矛盾する理由] |
問題がなければ「見つかりませんでした」と記載します。
矛盾が明らかになるエッジケース
隠れた前提
判定 [全体的な整合性の評価 — 問題なし、軽微な問題あり、または進行前に解決が必要な重大な矛盾あり]
推奨される解決策
- [矛盾ごとの具体的な変更 — どの項目をどう修正するか]
注記
不整合の緊急度はそれぞれ異なります。中核となる要件の矛盾はブロッカーですが、エッジケースにおける曖昧さは、判断を記録するだけでよい場合もあります。目的は、暗黙の矛盾を明らかにし、本番環境で発覚する前に意識的に解決できるようにすることです。
次のステップ
この出力を提示した後、AskUserQuestion を使って次の対応を提案してください。
- 質問: 「整合性を確認しました。次は何をしますか?」
- ヘッダー: 「次へ」
- 選択肢:
/s4h-logic-fixer— 見つかった不整合を解決する/s4h-aesthetic-coherence-check— 論理的整合性に加えて、概念的・美的な一貫性を確認する/s4h-identity-values-clarification— 不整合の根底にある価値観の衝突を解決する- 完了 — ここまでの内容をまとめて終了する