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

spec-discover

実装前に決定すべき事項を洗い出し、具体的な解決策は後回しにすることで、軽量なプロジェクト仕様書を初期段階で作成し、その後の詳細検討や強化につなげるSkill。

📜 元の英語説明(参考)

Create a lightweight project spec by identifying the decisions that must be made before implementation, without resolving them. Use as the first step in the spec-driven workflow to produce the initial spec for later exploration and fortification.

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

一言でいうと

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

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

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

🍎 Mac / 🐧 Linux

mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o spec-discover.zip https://jpskill.com/download/9642.zip && unzip -o spec-discover.zip && rm spec-discover.zip

🪟 Windows (PowerShell)

$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/9642.zip -OutFile "$d\spec-discover.zip"; Expand-Archive "$d\spec-discover.zip" -DestinationPath $d -Force; ri "$d\spec-discover.zip"

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

💾 手動でダウンロードしたい(コマンドが難しい人向け)

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

⬇ .zip でダウンロード(推奨) ⬇ .skill 形式(上級者用) 元のソース ↗

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

🎯 このSkillでできること

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

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

1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
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 Discover

このスキルは、仕様駆動型ワークフローの発見フェーズで使用します。

指示

プロジェクトの仕様を範囲決定しています。あなたの仕事は、決定を下すことではなく、下す必要のある明確な決定事項を特定することです。

ユーザーはこのスキルを参照した後、何を構築したいかを説明します。その説明から、仕様ファイルを作成し、ディスクに保存してください。

ファイルの命名規則

プロジェクトのルートからの相対パスで specs.local/NNN_<topic-slug>.md として保存します。ここで、NNN は次に利用可能なゼロ埋めインデックス (001, 002, 003 など) です。

仕様ファイルを保存した後、作業ディレクトリが Git リポジトリである場合は、specs.local のローカル無視ルールをまだ設定していない場合は設定します。

ローカル仕様がコミットされないように、.git/info/exclude に specs.local/ を追加します。
Codex が @ でそれらのファイルを参照できるように、.ignore に !specs.local/ を追加します。
上記の行のみがファイルに含まれている場合は、.ignore を .git/info/exclude に追加します。

仕様ファイルの形式

# Spec: <短いタイトル>

## Summary

<構築するもの>

## Constraints

<ユーザーのプロンプトとコンテキストから抽出された、交渉の余地のない要件>

## Decisions

| ID  | Decision | ✅  |
| --- | -------- | --- |
| D01 | <タイトル>  |     |
| D02 | <タイトル>  |     |

---

## Future Ideas

- <最初の実装の範囲外である、明示的に延期されたアイデア>

---

## D01: <タイトル>

<この部分を構築する前に答える必要があること>

## D02: <タイトル>

...

ルール

実際のトレードオフがなく、要件が明確で交渉の余地がない場合は、制約です。
詳細が複数の有効な方法で実装できる可能性がある場合は、決定事項です。
何かが最初の実装の範囲外であるが、覚えておく価値がある場合は、Constraints ではなく Future Ideas に入れてください。
提案されたコントラクト、例、および可能性の高い設計は、未解決の選択を知らせる場合は、決定の入力として保持する必要があります。
直接述べられていること以外に、例または提案されたコントラクトから追加のハード要件を推測しないでください。
より狭い制約とより広い決定を優先します。曖昧さを解決するのではなく保持し、ユーザーが提供した詳細を関連する決定の中に保持します。
基礎となる決定を最初にします。コンテキストの段落で依存関係を呼び出します。
トレードオフを組み立てるために、可能性の高いオプションに名前を付けますが、推奨したり、いずれかにコミットしたりしないでください。
Future Ideas は軽量に保ちます。これは、未解決の要件の2番目のバックログではなく、明示的な延期のための駐車場です。
最終決定する前に、各制約を監査します。直接的なユーザーの意図ではなく解釈に依存する場合は、Decisions に移動し、関連性がある場合は動機となる詳細を保持します。

📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Spec Discover

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

Instructions

You are scoping a project spec. Your job is to identify the distinct decisions that need to be made, not to make them.

The user will describe what they want to build after referencing this skill. From their description, produce a spec file and save it to disk.

File Convention

Save as: specs.local/NNN_<topic-slug>.md relative to the project root, where NNN is the next available zero-padded index (001, 002, 003, etc.).

After saving the spec file, if the working directory is a Git repository, configure local ignore rules for specs.local if not already configured:

add specs.local/ to .git/info/exclude so local specs are not committed
add !specs.local/ to .ignore so Codex can still reference those files with @
add .ignore to .git/info/exclude if the file only contains the line above

Spec File Format

# Spec: <Short Title>

## Summary

<What we're building>

## Constraints

<Non-negotiable requirements extracted from user prompt and context>

## Decisions

| ID  | Decision | ✅  |
| --- | -------- | --- |
| D01 | <title>  |     |
| D02 | <title>  |     |

---

## Future Ideas

- <Explicitly deferred idea that is out of scope for the first implementation>

---

## D01: <Title>

<What needs answering before we can build this part>

## D02: <Title>

...

Rules

If there is no real tradeoff and the requirement is explicit and non-negotiable, it is a constraint.
If a detail could plausibly be implemented in more than one valid way, it is a decision.
If something is intentionally out of scope for the first implementation but worth remembering, put it in Future Ideas, not in Constraints.
Suggested contracts, examples, and likely designs should be preserved as decision input when they inform an unresolved choice.
Do not infer additional hard requirements from examples or suggested contracts beyond what is directly stated.
Prefer narrower constraints plus broader decisions. Preserve ambiguity instead of resolving it, and preserve user-provided detail inside the relevant decision.
Foundational decisions first. Call out dependencies in context paragraphs.
Name likely options to frame the tradeoff, but do not recommend or commit to one.
Keep Future Ideas lightweight. It is a parking lot for explicit deferments, not a second backlog of unresolved requirements.
Before finalizing, audit each constraint: if it depends on interpretation rather than direct user intent, move it to Decisions and keep the motivating detail if it remains relevant.