mcpField
S
spec

spec

github.com/juliusbrussee開発1.2k2.7k 回インストール11 週間前に更新
リポジトリ

spec について

spec は、アイデア、コード、関連スキルからの引き継ぎを基に、プロジェクトの SPEC.md を作成・保守するスキルです。対象セクションの編集やバグのバックプロパゲーションに対応し、書き込み前に変更を提示します。

主な機能

  1. 01アイデアから仕様を作成
  2. 02既存コードから仕様を抽出
  3. 03スキルの引き継ぎ内容を節ごとに反映
  4. 04指定した仕様セクションを修正
  5. 05バグを記録して不変条件を更新

活用シーン

  1. 01プロジェクトのアイデアをタスク仕様に整理
  2. 02コードベースを仕様として文書化
  3. 03レビューや調査の結果を反映
  4. 04バグ発生後に仕様を更新

インストール

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

$npx skills add https://github.com/juliusbrussee/cavekit --skill spec

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

詳細

spec — spec ミューテーター

まだ読み込んでいない場合は、リポジトリルートの FORMAT.md を読んでください。ここでの書き込みすべてに Caveman スキルが適用されます。

ディスパッチ

ユーザーのリクエストとプロジェクトの状態を確認します。

  1. リポジトリルートに SPEC.md がなく、引数にアイデアが記述されている → NEW
  2. SPEC.md がなく、引数に from-code がある → DISTILL
  3. SPEC.md があり、引数が bug: で始まる → BACKPROP
  4. SPEC.md があり、引数が amend で始まる → AMEND
  5. SPEC.md があり、引数がない → ユーザーにモードを尋ねます

入力 — spec が唯一のミューテーターです

ほかの動詞は素材を作成し、spec がそれを書き込みます。各引き継ぎブロックを適切なセクションに取り込み、差分を表示し、OK を得てから書き込みます。

  • grill → 明確化された §G + §C
  • research → §R の行(§R セクションがない場合は追加)
  • review → 作成された §V の行 + リスク判定
  • deepen → §I/§V/§T の修正

⊥ 引き継ぎで指定されていないセクションを書き換えてはいけません。セクションごとに担当範囲を分けます(FORMAT.md を参照)。

NEW — アイデア → spec

入力:ユーザーのアイデア。内容が曖昧な場合は、まず grill の実行を推奨します。

手順:

  1. 目標を抽出します(caveman 形式で1行)。→ §G。
  2. ユーザーが明示または暗示した制約を列挙します。→ §C。
  3. ユーザーが挙げた外部インターフェースを列挙します。→ §I。
  4. research を実行した場合のみ §R を追加します。実行していない場合はセクションを省略します(適切な規模に保つ)。
  5. 初期不変条件を提案します。→ §V(V1…の番号付き)。
  6. 目標を順序付きのタスクに分割します。→ §T パイプテーブル。ステータスはすべて .、ID は T1…。
  7. §B セクションはヘッダー行のみとします(id|date|cause|fix)。

SPEC.md に書き込みます。ファイル全体をユーザーに表示します。次のように尋ねます:「spec OK ですか? 影響範囲が大きい場合は /review、それ以外は /build を実行してください。」

DISTILL — コード → spec

リポジトリを調べます。§G(README/package.json/メインエントリから推定)、§C(スタックから推定)、§I(公開 API/CLI/設定を列挙)、§V(テストとアサーションから導出)、§T(既知の TODO または不足しているテストごとに1タスク)、§B(空)を作成します。

すべて Caveman 形式にします。不確かな項目には、ユーザーが確認できるようテキストに ? を付けます。

BACKPROP — バグ → §B + §V

入力:bug: <description>。

手順:

  1. バグの説明を解析します。
  2. 根本原因を特定します(関連コードを読みます)。
  3. 新しい不変条件によって再発を検出できるか判断します。可能な場合は V<next> を作成します。
  4. §B に行を追加します:B<next>|<date>|<cause>|V<N>。
  5. 新しい不変条件を §V に追加します。
  6. 修正によって動作も変わる場合は、§T の行を追加または更新します。
  7. 差分を表示します。ユーザーが OK した場合のみ適用します。

ルール:すべてのバグに §B のエントリーを作成します。不変条件は任意ですが、追加を推奨します。

AMEND — 対象を絞った編集

入力:amend §V.3 や amend §T など。

該当セクションを読みます。現在の内容を表示し、変更内容をユーザーに尋ねます。書き込んだ後、差分を表示します。

ユーザーが指定していないセクションを、黙って書き換えてはいけません。

出力ルール

  • FORMAT.md に従った Caveman 形式にします。
  • 識別子、パス、コードはそのまま保持します。
  • 番号は単調増加とし、§V.N または §B.N を再利用してはいけません。
  • §T の行に cites 列がある場合は、§V/§I の依存関係を列挙します:T5|.|impl auth mw|V2,I.api。

対象外

  • サブエージェントは使用しません。メインスレッドが書き込みます。
  • ダッシュボード、ログ、SPEC.md 以外の状態ファイルは作成しません。
  • spec の後に自動ビルドは行いません。ビルドはユーザーが明示的に実行します。

コメント