mcpField
S
spec-driven-apply

spec-driven-apply

github.com/kw12121212開発137 回インストール26 週間前に更新
リポジトリ

spec-driven-apply について

spec-driven-applyは、既存の仕様駆動型プロジェクト資料に沿って変更を実装するスキルです。開発者やコーディングエージェント向けに、未解決の質問を確認し、タスクを順に進めて仕様を更新する手順を示します。

主な機能

  1. 01進行中の変更を選択
  2. 02プロジェクト資料から文脈を再構築
  3. 03未解決の質問があれば停止
  4. 04タスクを順番に実装
  5. 05差分仕様とマッピングを更新

活用シーン

  1. 01計画済み機能変更の実装
  2. 02実装前の要件確認
  3. 03仕様とコードの整合維持

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/kw12121212/auto-spec-driven --skill spec-driven-apply

インストール後、Claude Code で/spec-driven-applyを入力して読み込まれたか確認します。

詳細

ユーザーによる仕様駆動の変更の実装を支援します。

このスキルのコマンド

このスキルで使う正確なコマンドを思い出せない場合は、何かを実行する前にここで確認してください。 推測してはいけません。

modify: node {{SKILL_DIR}}/scripts/spec-driven.js modify
apply: node {{SKILL_DIR}}/scripts/spec-driven.js apply <name>

前提条件

.spec-driven/ ディレクトリがプロジェクトのルートに存在している必要があります。先に進む前に、次のコマンドで確認してください。

ls .spec-driven/

失敗した場合、プロジェクトは初期化されていません。まず /spec-driven-init を実行してください。

手順

  1. 変更を選択する — node {{SKILL_DIR}}/scripts/spec-driven.js modify を実行して、アクティブな変更を一覧表示します。適用する変更をユーザーに尋ねてください。すでに指定されている場合は、それを使用してください。

  2. コンテキストを読み込む — すべての成果物を読みます。

    • それまでの会話コンテキストはすべて古く、信頼できず、権威のない情報として扱わなければなりません。
    • 要件、タスクの状態、実装の詳細、完了状況について、以前のチャットコンテキストを情報源として使用してはいけません。
    • 実装作業を始める前に、現在の変更の成果物、関連するベース仕様、現在のリポジトリの状態から、作業に必要なコンテキストを再構築しなければなりません。
    • 以前のチャットコンテキストがファイルまたはリポジトリの状態と少しでも異なる場合は、以前のチャットコンテキストを破棄し、ファイルとリポジトリの状態のみを参照しなければなりません。
    • 現在のファイルとリポジトリの状態に照らして明示的に再検証されていない限り、以前のチャットコンテキストを使用してはいけません。
    • .spec-driven/changes/<name>/proposal.md — 変更の内容と理由。「変更しない動作」セクションに記載された動作は、実装時に壊してはいけません。
    • .spec-driven/changes/<name>/specs/ — 差分仕様ファイル(メインの specs/ 構成を反映)
    • .spec-driven/changes/<name>/design.md — 方針と決定事項
    • .spec-driven/changes/<name>/tasks.md — チェックリスト
    • .spec-driven/changes/<name>/questions.md — 未解決および解決済みの質問 以下も読みます。
    • .spec-driven/config.yaml — プロジェクトのコンテキスト。rules は拘束力のある制約として扱ってください。fileMatch エントリがある場合は、パスがグロブパターンに一致するファイルを編集する際に、該当するルールを適用してください。
    • .spec-driven/specs/INDEX.md — 既存の仕様ファイルをすべて確認します。
    • INDEX.md に記載された、この変更に関連するすべての仕様ファイル — コードを書く前に、現在の要件を把握できるよう、全文を読んでください。
    • 関連するメイン仕様ファイルと差分仕様ファイルのマッピングフロントマター。確認対象のファイルを特定する際の手がかりとして、mapping.implementation と mapping.tests を使用してください。
  3. タスクの状態を確認する — 次を実行します。

    node {{SKILL_DIR}}/scripts/spec-driven.js apply <name>
    

タスクの概要(合計、完了、残り)をユーザーに示してください。

  1. 未解決の質問でゲートする — questions.md を読み、- [ ] Q: エントリがないか確認します。

    • 未解決の質問がある場合は、各質問を列挙し、実装に進まず停止してください。
    • 未解決の質問ごとに、次の項目を含む、構造化されたユーザー向けブロックを提示してください。
      • 質問
      • 説明
      • 影響
      • 推奨事項
    • 説明 では、変更の成果物、関連するメイン仕様、現在のリポジトリの状態を確認した後も、なぜ質問が未解決なのかを明確にしてください。
    • 影響 では、回答によって決まる実装上の選択、タスク、動作、または変更しない動作に関する保証を説明してください。
    • 推奨事項 では、あくまで提案として、望ましい回答を提示してもかまいません。
    • ユーザーが明示的に回答または決定を確認するまで、タスクを実装したり、実装ファイルを編集したり、質問を解決済みにしたりしてはいけません。
    • ## Resolved に A: の回答とともにすべての質問が記録された場合にのみ、続行してください。
  2. タスクを実装する — 各 - [ ] タスクを順番に進めます。

    • 変更を加える前に、関連するコードを読みます。
    • タスクを実装します。
    • 変更が proposal.md に記載された「変更しない動作」に違反しないことを確認します。
    • ## Testing タスクでは、テスト(lint、単体テスト)を実際に実行し、成功を確認してから完了として記録します。
    • tasks.md の - [ ] を - [x] に変更して、タスクを完了済みにします。
    • 次のタスクに進む前に、実施内容を簡潔に伝えます。
  3. 差分仕様を更新する — すべてのタスクが完了したら、changes/<name>/specs/ 内の各ファイルを再度読み、実際に実装された内容を正確に反映していることを確認します。

    • 実装が当初の計画と異なる場合は、該当するファイルを更新します
    • 追加の仕様ファイルの作成または変更が必要な場合は、この時点で行います
    • 差分仕様のマッピング用フロントマターを更新し、mapping.implementation と mapping.tests に、変更または参照した実際の実装ファイルとテストファイルを 記載します
  4. 完了時 — すべてのタスクが完了し、差分仕様が正確になったら、次の操作を行います。

    • node {{SKILL_DIR}}/scripts/spec-driven.js apply <name> を再度実行し、残りが 0 件であることを確認します
    • 実装を検証するために /spec-driven-verify <name> の実行を提案します

ルール

  • 変更する前に既存のコードを読みます
  • 明確な依存関係上の理由で順序を入れ替える必要がない限り、タスクを順番に完了します
  • タスクは実装後すぐに完了としてマークし、最後にまとめてマークしません
  • タスクが曖昧な場合は、ユーザーに尋ねる前に proposal.md と design.md を読みます
  • すでに - [x] とマークされているタスクは実装しません
  • 未解決の質問は、実装を開始する前にユーザーによる明示的な解決が必要です
  • 推奨事項は、ユーザーが確認するまでは解決済みの回答として扱いません
  • 実装とテストのマッピングは要件の本文ではなく、フロントマターに記載します

コメント