jpskill.com
📦 その他 コミュニティ

Spec Kit整合性監査

spec-kit-analyze

spec.md、plan.md、tasks.mdが存在する際に、実装前に仕様書、計画、タスク間の整合性や要件の網羅性、曖昧さ、重複、矛盾などを監査し、仕様キットの品質向上を支援するSkill。

📜 元の英語説明(参考)

Use when `spec.md`, `plan.md`, and `tasks.md` exist and you need a read-only Spec Kit audit for consistency, requirement-to-task coverage, ambiguity, duplication, or constitution conflicts before implementation.

🇯🇵 日本人クリエイター向け解説

一言でいうと

spec.md、plan.md、tasks.mdが存在する際に、実装前に仕様書、計画、タスク間の整合性や要件の網羅性、曖昧さ、重複、矛盾などを監査し、仕様キットの品質向上を支援するSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux 
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o spec-kit-analyze.zip https://jpskill.com/download/10645.zip && unzip -o spec-kit-analyze.zip && rm spec-kit-analyze.zip
🪟 Windows (PowerShell) 
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/10645.zip -OutFile "$d\spec-kit-analyze.zip"; Expand-Archive "$d\spec-kit-analyze.zip" -DestinationPath $d -Force; ri "$d\spec-kit-analyze.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して spec-kit-analyze.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → spec-kit-analyze フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動
⬇ .zip でダウンロード(推奨) ⬇ .skill 形式(上級者用) 元のソース ↗

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

Spec Kit Analyze

実装前に、非破壊的な成果物間の品質監査を実行します。

使用する場面

  • tasks.md が存在し、実装前に仕様/計画/タスク全体の一貫性チェックを行いたい場合。
  • カバレッジのギャップ、要件のずれ、曖昧な表現、または矛盾する成果物が疑われる場合。
  • まだ成果物を編集せずに、憲章（constitution）との整合性を確認したい場合。

使用しない場面

  • 必要な成果物が不足している場合（最初に spec-kit-specify、spec-kit-plan、または spec-kit-tasks を実行してください）。
  • 今すぐ対象を絞った修正編集が必要な場合（spec-kit-reconcile）。
  • 実装作業を実行している場合（spec-kit-implement）。

ルーターへの適合

  • spec-kit-tasks 後の spec-kit からの主要なルート。
  • spec-kit-implement の前の読み取り専用の品質ゲート。
  • 発見された問題が連携した成果物の更新を必要とする場合は、spec-kit-reconcile へのデフォルトのハンドオフ。

重要な制約

  • 厳密に読み取り専用：ファイルを変更しないでください。
  • memory/constitution.md を信頼できるものとして扱います。MUST レベルの矛盾は CRITICAL です。

前提条件

  • リポジトリのルート（またはその中のサブディレクトリ）から実行します。
  • アクティブなフィーチャーコンテキストが、spec.md、plan.md、および tasks.md を持つ1つのフィーチャーディレクトリに解決されること。

ワークフロー

  1. 成果物のパスを解決し、前提条件ゲートを適用します。

    • scripts/check-prerequisites.sh --json --require-tasks --include-tasks を正確に1回実行します。
    • 以下を解析します。
      • FEATURE_DIR
      • AVAILABLE_DOCS
    • 以下を導出します。
      • SPEC = FEATURE_DIR/spec.md
      • PLAN = FEATURE_DIR/plan.md
      • TASKS = FEATURE_DIR/tasks.md
    • 必要な成果物が不足している場合は、停止して、所有する兄弟スキルにルーティングします。

  2. 以下から、焦点を絞ったセクションをロードします。

    • spec.md: 要件、ストーリー、受け入れ基準、エッジケース。
    • plan.md: アーキテクチャ/スタックの決定、フェーズ、制約。
    • tasks.md: タスク ID、フェーズのグループ化、[P] マーカー、参照されるパス。
    • memory/constitution.md: 原則名と規範的な MUST/SHOULD ステートメント。

  3. 内部マップを構築します。

    • 安定したキーを持つ要件インベントリ（機能的 + 非機能的）。
    • 受け入れテストの意図を持つストーリー/アクションインベントリ。
    • タスクから要件/ストーリーへのカバレッジマッピング。
    • 仕様/計画/タスクの範囲に関連する憲章の義務。

  4. 問題を検出して分類します。

    • 重複：重複する、またはほぼ重複する要件。
    • 曖昧さ/プレースホルダー：曖昧な品質用語、TODO/TKTK/プレースホルダー トークン。
    • 仕様不足：測定可能な結果または明確なオブジェクトが欠落している要件。
    • 憲章の矛盾：MUST 原則に対する違反（CRITICAL）。
    • カバレッジギャップ：タスクのない要件、およびマッピングされた要件/ストーリーのないタスク。
    • 成果物間の不整合：用語のずれ、エンティティの不一致、順序の矛盾。
    • 発見された問題を 50 行に制限します。カテゴリ別にオーバーフロー数を要約します。

  5. 重大度を割り当て、安定した ID、カバレッジテーブル、およびメトリックを含むコンパクトなレポートを出力します。

    • CRITICAL: 憲章の MUST 違反、ベースラインの動作をブロックするコアカバレッジの欠落。
    • HIGH: 矛盾/重複する要件、テストできない、またはリスクの高い曖昧さ。
    • MEDIUM: 用語のずれ、非機能的なカバレッジギャップ、仕様が不十分なエッジケース。
    • LOW: 実行に影響を与えない言い回し/スタイルのクリーンアップ。

  6. 次のアクションを推奨します。

    • CRITICAL/HIGH の発見された問題が成果物間の編集を必要とする場合は、spec-kit-implement をブロックし、簡潔なギャップの概要とともに spec-kit-reconcile にルーティングします。
    • 1つの成果物のみが焦点を絞った更新を必要とする場合は、その所有者スキル（spec-kit-specify、spec-kit-plan、または spec-kit-tasks）にルーティングします。
    • それ以外の場合は、優先順位付けされた改善策と、実装を進めることができるかどうかを提供します。

  7. フォローアップのみを提供します。

    • 上位の発見された問題をギャップレポートとして使用して、spec-kit-reconcile を実行するかどうかを尋ねます。
    • このスキルでは編集を適用しないでください。

出力

  • Markdown レポートのみ（ファイル書き込みなし）。以下を含みます。
    • 発見された問題のテーブル：ID | Category | Severity | Location(s) | Summary | Recommendation
    • 要件カバレッジテーブル：Requirement Key | Has Task? | Task IDs | Notes
    • 憲章の整合性の問題（存在する場合）
    • マッピングされていないタスク（存在する場合）
    • メトリクス：
      • 要件の合計
      • タスクの合計
      • カバレッジ率
      • 曖昧さの数
      • 重複の数
      • 重大な問題の数
    • 次のステップのルーティング推奨

参考文献

  • references/command-analyze.md
  • scripts/check-prerequisites.sh
  • https://github.com/github/spec-kit/blob/9111699cd27879e3e6301651a03e502ecb6dd65d/templates/commands/analyze.md
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Spec Kit Analyze

Run a non-destructive cross-artifact quality audit before implementation.

When to Use

  • tasks.md exists and you want a pre-implementation consistency check across spec/plan/tasks.
  • You suspect coverage gaps, requirement drift, ambiguous language, or contradictory artifacts.
  • You need a constitution-alignment gate without editing artifacts yet.

When Not to Use

  • Any prerequisite artifact is missing (spec-kit-specify, spec-kit-plan, or spec-kit-tasks first).
  • You need targeted remediation edits now (spec-kit-reconcile).
  • You are executing implementation work (spec-kit-implement).

Router Fit

  • Primary route from spec-kit after spec-kit-tasks.
  • Read-only quality gate before spec-kit-implement.
  • Default handoff to spec-kit-reconcile when findings require coordinated artifact updates.

Critical Constraints

  • Strictly read-only: do not modify files.
  • Treat memory/constitution.md as authoritative; any MUST-level conflict is CRITICAL.

Preconditions

  • Run from repository root (or a subdirectory inside it).
  • Active feature context resolves to one feature directory with spec.md, plan.md, and tasks.md.

Workflow

  1. Resolve artifact paths and enforce prerequisite gate:

    • Run scripts/check-prerequisites.sh --json --require-tasks --include-tasks exactly once.
    • Parse:
      • FEATURE_DIR
      • AVAILABLE_DOCS
    • Derive:
      • SPEC = FEATURE_DIR/spec.md
      • PLAN = FEATURE_DIR/plan.md
      • TASKS = FEATURE_DIR/tasks.md
    • If any required artifact is missing, stop and route to the owning sibling skill.

  2. Load focused sections from:

    • spec.md: requirements, stories, acceptance criteria, edge cases.
    • plan.md: architecture/stack decisions, phases, constraints.
    • tasks.md: task IDs, phase grouping, [P] markers, referenced paths.
    • memory/constitution.md: principle names and normative MUST/SHOULD statements.

  3. Build internal maps:

    • Requirement inventory (functional + non-functional) with stable keys.
    • Story/action inventory with acceptance-test intent.
    • Task-to-requirement/story coverage mapping.
    • Constitution obligations relevant to spec/plan/tasks scope.

  4. Detect and classify issues:

    • Duplication: overlapping or near-duplicate requirements.
    • Ambiguity/placeholders: vague quality terms, TODO/TKTK/placeholder tokens.
    • Underspecification: requirements lacking measurable outcomes or clear objects.
    • Constitution conflicts: violations against MUST principles (CRITICAL).
    • Coverage gaps: requirements without tasks and tasks without mapped requirement/story.
    • Cross-artifact inconsistency: terminology drift, entity mismatch, ordering contradictions.
    • Cap findings at 50 rows; summarize overflow counts by category.

  5. Assign severity and output a compact report with stable IDs, coverage table, and metrics.

    • CRITICAL: constitution MUST violations, missing core coverage that blocks baseline behavior.
    • HIGH: conflicting/duplicate requirements, untestable or high-risk ambiguity.
    • MEDIUM: terminology drift, non-functional coverage gaps, underspecified edge cases.
    • LOW: wording/style cleanup without execution impact.

  6. Recommend next actions:

    • If CRITICAL/HIGH findings require cross-artifact edits, block spec-kit-implement and route to spec-kit-reconcile with a concise gap summary.
    • If only one artifact needs focused updates, route to its owner skill (spec-kit-specify, spec-kit-plan, or spec-kit-tasks).
    • Otherwise provide prioritized improvements and whether implementation can proceed.

  7. Offer follow-up only:

    • Ask whether to run spec-kit-reconcile using top findings as the gap report.
    • Do not apply any edits in this skill.

Output

  • Markdown report only (no file writes) containing:
    • Findings table: ID | Category | Severity | Location(s) | Summary | Recommendation
    • Requirement coverage table: Requirement Key | Has Task? | Task IDs | Notes
    • Constitution alignment issues (if any)
    • Unmapped tasks (if any)
    • Metrics:
      • Total requirements
      • Total tasks
      • Coverage percentage
      • Ambiguity count
      • Duplication count
      • Critical issues count
    • Next-step routing recommendation

References

  • references/command-analyze.md
  • scripts/check-prerequisites.sh
  • https://github.com/github/spec-kit/blob/9111699cd27879e3e6301651a03e502ecb6dd65d/templates/commands/analyze.md