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

Spec Kit 仕様策定

spec-kit-specify

Spec Kitの機能を実現するために、自然言語で書かれた要件から`spec.md`を作成したり、既存の仕様が曖昧な場合に書き直したりして、より具体的な計画を立てられるようにするSkill。

📜 元の英語説明(参考)

Use when a Spec Kit feature needs `spec.md` authored or rewritten from natural-language requirements, especially when the feature has no usable specification or requirements are too vague for planning.

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

一言でいうと

Spec Kitの機能を実現するために、自然言語で書かれた要件から`spec.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-specify.zip https://jpskill.com/download/10652.zip && unzip -o spec-kit-specify.zip && rm spec-kit-specify.zip
🪟 Windows (PowerShell) 
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/10652.zip -OutFile "$d\spec-kit-specify.zip"; Expand-Archive "$d\spec-kit-specify.zip" -DestinationPath $d -Force; ri "$d\spec-kit-specify.zip"

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

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して spec-kit-specify.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → spec-kit-specify フォルダができる
  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 Specify

アクティブな Spec Kit 機能の機能仕様を作成または更新します。

使用する場面

  • 新しい機能を開始し、最初の spec.md を作成します。
  • 自由形式の要件を、構造化され、テスト可能で、実装に依存しない仕様に変換します。
  • 既存の仕様のドラフトを、spec-kit-clarify または spec-kit-plan の準備ができるように修正します。

使用しない場面

  • すでに書かれた仕様の曖昧さを、書き直さずに明確にする場合 (spec-kit-clarify)。
  • 承認された仕様から設計成果物またはタスクを生成する場合 (spec-kit-plan、spec-kit-tasks)。
  • 既存の機能における成果物間のずれを調整する場合 (spec-kit-reconcile)。

ルーターの適合性

  • spec.md がまだ存在しない場合、spec-kit からの主要なルート。
  • ダウンストリーム: spec-kit-clarify (影響の大きい曖昧さが残っている場合) または spec-kit-plan (仕様の準備ができている場合) に引き渡します。

前提条件

  • ユーザーが空でない機能の説明を提供していること。
  • リポジトリのルート (またはリポジトリ内のサブディレクトリ) から実行すること。

ワークフロー

  1. 入力を正規化します。

    • ユーザーからの完全なリクエストを機能の説明として扱います。
    • 空の場合は停止します: ERROR: No feature description provided。

  2. 短いブランチのサフィックスを生成します (2〜4語、kebab-case)。

    • 意味のある技術用語/頭字語を保持します。
    • action-noun の言い回しを優先します (例: user-auth、bulk-export-audit-log)。

  3. 機能ブランチと仕様を正確に一度だけブートストラップします。

    • scripts/create-new-feature.sh --json --short-name "<short-name>" "<feature description>" を実行します。
    • ブランチ番号を手動で事前に計算しないでください。スクリプトに次の番号を割り当てさせます。
    • JSON 出力を解析して、以下をキャプチャします。
      • BRANCH_NAME
      • SPEC_FILE
      • FEATURE_NUM
    • FEATURE_DIR を dirname(SPEC_FILE) として導出します。

  4. テンプレートコンテキストをロードします。

    • 優先テンプレート: {REPO_ROOT}/templates/spec-template.md。
    • フォールバックテンプレート: assets/spec-template.md。
    • 選択したテンプレートの見出しの順序を保持します。

  5. spec.md のコンテンツをドラフトします (HOW ではなく WHAT/WHY に焦点を当てます)。

    • 優先順位付けされたユーザーストーリーを、独立したテストと受け入れシナリオで埋めます。
    • テスト可能な機能要件を記述します。
    • エッジケースとスコープの境界を追加します。
    • 測定可能で、テクノロジーに依存しない成功基準を追加します。
    • データが中心となる場合は、主要なエンティティを含めます。
    • 必要な場合は、妥当なデフォルトを使用し、前提条件を文書化します。

  6. ドラフト作成中の明確化ポリシー:

    • まず、ドメインの標準を使用して、情報に基づいたデフォルトを作成します。
    • 影響の大きい不確実性についてのみ [NEEDS CLARIFICATION: ...] を追加します。
    • ハードリミット: 最大3つの明確化マーカー。
    • 影響によって優先順位を付けます: スコープ > セキュリティ/プライバシー > UX > 技術的な詳細。

  7. spec.md を SPEC_FILE に書き込みます。

  8. 要件品質検証を作成して実行します。

    • FEATURE_DIR/checklists/requirements.md を作成します。
    • このチェックリストに対して仕様を検証します。
      • 実装の詳細がないこと (フレームワーク、言語、API、内部アーキテクチャ)。
      • 必須セクションが完了していること。
      • 要件が明確でテスト可能であること。
      • 成功基準が測定可能で、テクノロジーに依存しないこと。
      • ユーザーシナリオとエッジケースが網羅されていること。
      • スコープの境界、依存関係、および前提条件が明示的であること。
      • プラン準備完了の仕様に未解決の [NEEDS CLARIFICATION] マーカーがないこと。
    • 明確化以外の問題が失敗した場合は、仕様を修正して再検証します (最大3回)。

  9. 検証後に明確化マーカーが残っている場合:

    • 合計で最大3つの番号付きの明確化の質問をします。
    • 各質問について、2〜3の具体的なオプションと短いカスタム回答パスを提示します。
    • ユーザーの応答を待ち、spec.md を更新してから、検証を再実行します。

  10. 完了を報告します。

  • ブランチ名。
  • spec.md のパス。
  • requirements.md のパスと合否の概要。
  • 推奨される次のステップ:
    • 影響の大きい曖昧さが残っている場合は spec-kit-clarify。
    • 準備ができている場合は spec-kit-plan。

出力

  • scripts/create-new-feature.sh からのアクティブな機能ブランチ
  • specs/<feature>/spec.md
  • specs/<feature>/checklists/requirements.md
  • spec-kit-clarify または spec-kit-plan への準備完了の引き渡し

よくある間違い

  • ユーザーに見える動作と結果の代わりに、実装設計を仕様に書き込むこと。
  • 受け入れテストできない曖昧な要件を残すこと。
  • 妥当なデフォルトを作成する代わりに、明確化の質問を多くしすぎること。
  • 1つのリクエストに対して機能ブートストラップスクリプトを複数回実行すること。

参考文献

  • references/spec-kit-workflow.dot
  • scripts/create-new-feature.sh
  • assets/spec-template.md
  • https://github.com/github/spec-kit/blob/9111699cd27879e3e6301651a03e502ecb6dd65d/templates/commands/specify.md
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Spec Kit Specify

Create or refresh the feature specification for the active Spec Kit feature.

When to Use

  • Start a new feature and create the first spec.md.
  • Convert free-form requirements into a structured, testable, implementation-agnostic specification.
  • Rework an existing spec draft so it is ready for spec-kit-clarify or spec-kit-plan.

When Not to Use

  • Clarify ambiguity in an already-written spec without redrafting it (spec-kit-clarify).
  • Generate design artifacts or tasks from an approved spec (spec-kit-plan, spec-kit-tasks).
  • Reconcile cross-artifact drift in an existing feature (spec-kit-reconcile).

Router Fit

  • Primary route from spec-kit when spec.md does not exist yet.
  • Downstream: hand off to spec-kit-clarify (if high-impact ambiguity remains) or spec-kit-plan (if spec is ready).

Preconditions

  • User provided a non-empty feature description.
  • Run from repository root (or a subdirectory inside the repository).

Workflow

  1. Normalize input:

    • Treat the full user request as the feature description.
    • If empty, stop: ERROR: No feature description provided.

  2. Generate a short branch suffix (2-4 words, kebab-case):

    • Preserve meaningful technical terms/acronyms.
    • Prefer action-noun phrasing (for example user-auth, bulk-export-audit-log).

  3. Bootstrap feature branch and spec exactly once:

    • Run scripts/create-new-feature.sh --json --short-name "<short-name>" "<feature description>".
    • Do not manually pre-compute branch numbers; let the script assign the next number.
    • Parse JSON output and capture:
      • BRANCH_NAME
      • SPEC_FILE
      • FEATURE_NUM
    • Derive FEATURE_DIR as dirname(SPEC_FILE).

  4. Load template context:

    • Preferred template: {REPO_ROOT}/templates/spec-template.md.
    • Fallback template: assets/spec-template.md.
    • Preserve heading order from the selected template.

  5. Draft spec.md content (focus on WHAT/WHY, not HOW):

    • Fill prioritized user stories with independent tests and acceptance scenarios.
    • Write testable functional requirements.
    • Add edge cases and scope boundaries.
    • Add measurable, technology-agnostic success criteria.
    • Include key entities when data is central.
    • Use reasonable defaults and document assumptions when needed.

  6. Clarification policy while drafting:

    • First, make informed defaults using domain norms.
    • Add [NEEDS CLARIFICATION: ...] only for high-impact uncertainty.
    • Hard limit: at most 3 clarification markers.
    • Prioritize by impact: scope > security/privacy > UX > technical detail.

  7. Write the spec to SPEC_FILE.

  8. Create and run requirements quality validation:

    • Create FEATURE_DIR/checklists/requirements.md.
    • Validate spec against this checklist:
      • No implementation details (frameworks, languages, APIs, internal architecture).
      • Mandatory sections are complete.
      • Requirements are unambiguous and testable.
      • Success criteria are measurable and technology-agnostic.
      • User scenarios and edge cases are covered.
      • Scope boundaries, dependencies, and assumptions are explicit.
      • No unresolved [NEEDS CLARIFICATION] markers for plan-ready specs.
    • If non-clarification issues fail, revise spec and re-validate (max 3 passes).

  9. If clarification markers remain after validation:

    • Ask up to 3 numbered clarification questions total.
    • For each question, present 2-3 concrete options plus a short custom answer path.
    • Wait for user responses, update spec.md, then re-run validation.

  10. Report completion:

  • Branch name.
  • spec.md path.
  • requirements.md path and pass/fail summary.
  • Recommended next step:
    • spec-kit-clarify if high-impact ambiguity remains.
    • spec-kit-plan if ready.

Output

  • Active feature branch from scripts/create-new-feature.sh
  • specs/<feature>/spec.md
  • specs/<feature>/checklists/requirements.md
  • readiness handoff for spec-kit-clarify or spec-kit-plan

Common Mistakes

  • Writing implementation design into the spec instead of user-visible behavior and outcomes.
  • Leaving vague requirements that cannot be acceptance-tested.
  • Asking too many clarification questions instead of making reasonable defaults.
  • Running feature bootstrap script multiple times for one request.

References

  • references/spec-kit-workflow.dot
  • scripts/create-new-feature.sh
  • assets/spec-template.md
  • https://github.com/github/spec-kit/blob/9111699cd27879e3e6301651a03e502ecb6dd65d/templates/commands/specify.md