jpskill.com
🛠️ 開発・MCP コミュニティ

spec-fortify

プロジェクトの仕様決定後、矛盾点や抜け漏れ、不要な複雑さなどの問題点がないか最終チェックを行い、実装前に仕様を強化して手戻りを防ぐSkill。

📜 元の英語説明(参考)

Examine a project spec after its decisions have been explored to find contradictions, gaps, accidental complexity, and other issues. Use as the final step in the spec-driven workflow to strengthen the spec before implementation begins.

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

一言でいうと

プロジェクトの仕様決定後、矛盾点や抜け漏れ、不要な複雑さなどの問題点がないか最終チェックを行い、実装前に仕様を強化して手戻りを防ぐSkill。

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

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

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

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

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

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

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

🎯 この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 Fortify

このスキルは、spec-driven workflow の強化フェーズで使用します。

手順

決定が解決された後のプロジェクト仕様書をレビューします。

ユーザーは仕様書ファイルを参照します。それをすべて読んでください。

チェック項目

  1. 矛盾点。 解決済みの決定事項の中に、互いに矛盾するものや、明示された制約に違反するものはありませんか?再検討が必要な決定事項を指摘してください。

  2. 抜け穴。 解決策が想定しているものの、明示的に決定されていないことはありませんか?仕様書に新しい保留中の決定事項を追加してください。

  3. 偶発的な複雑さ。 すべての解決策を全体として読んでください。全体の複雑さは概要に見合っていますか?誰も意図的に選択しなかったような、セッションを跨いで忍び寄ったものがあれば指摘してください。簡略化または再検討すべき点を提案してください。

  4. セキュリティリスク。 現在の決定事項は、明らかなセキュリティ上の懸念、安全でないデフォルト、または不明確な信頼境界をもたらしていませんか?明示的な決定または制約が必要なものを指摘してください。

  5. スケーリングリスク。 ここで言うスケーリングとは、リクエスト量、同時実行性、またはデータサイズが増加したときに、システムが許容できるパフォーマンスと信頼性を維持する能力を意味します。仕様書に書かれている内容から、具体的かつもっともらしい懸念事項のみを指摘してください。

  6. 検証手順。 現在の決定事項は、実装がどのように検証されるかを明確にしていますか?テストカバレッジ、ランタイム検証、または動作チェックが曖昧すぎて自信を持って計画できないものを指摘してください。

仕様書の更新

仕様書ファイルにレビューメモやコメントを追加しないでください。レビューで何か実行可能なことが明らかになった場合は、ユーザーの承認を得て、それを仕様書に直接適用してください。

実行可能な変更には、次のものが含まれます。

  • 新しい保留中の決定事項の追加
  • 解決済みの決定事項の再検討
  • 制約の追加または明確化
  • 明示的に延期された「あったらいいな」機能を Future Ideas に移動
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Spec Fortify

Use this skill for the fortification phase of the spec-driven workflow.

Instructions

You are reviewing a project spec after its decisions have been resolved.

The user will reference a spec file. Read it in full.

Check For

  1. Contradictions. Do any resolved decisions conflict with each other or violate a stated constraint? Flag which decision to reopen.

  2. Gaps. Is there something the resolutions assume but never explicitly decided? Add new pending decisions to the spec.

  3. Accidental complexity. Read all resolutions as a whole. Is the total complexity proportional to the summary? Flag anything that crept in across sessions that nobody would have chosen deliberately. Suggest what to simplify or reopen.

  4. Security risks. Do the current decisions introduce obvious security concerns, unsafe defaults, or unclear trust boundaries? Flag anything that needs an explicit decision or constraint.

  5. Scaling risks. Scaling here means the system's ability to maintain acceptable performance and reliability as request volume, concurrency, or data size increases. Only flag concerns that are concrete and plausible from the spec as written.

  6. Verification steps. Do the current decisions make clear how the implementation will be verified? Flag anything that leaves test coverage, runtime validation, or behavior checks too vague to plan confidently.

Update the Spec

Don't add review notes or commentary to the spec file. If the review surfaces something actionable, apply it directly to the spec with the user's approval.

Actionable changes include:

  • adding a new pending decision
  • reopening a resolved decision
  • adding or clarifying a constraint
  • moving explicitly deferred nice-to-haves into Future Ideas