SpecScore.md

比較一覧

SpecScore vs Spec Kit

両者は異なるレイヤーで動作します。Spec Kit は ワークフロー — エージェントをアイデアから実装まで導くガイド付きプロセスです。 SpecScore はスペックを書く フォーマット であり、それを lint・クエリ・ トレースする CLI です。Spec Kit は SpecScore ファイルを生成できます。

共通点。

  • 同じ北極星 — コードの前にスペックを、AI エージェントを第一級の読者として。
  • スペックは Markdown としてリポジトリに配置されます — バージョン管理され、PR レビュー可能。
  • どちらも MIT ライセンスのオープンソースです。
  • どちらも Claude Code、Cursor、Copilot、その他の AI コーディングエージェントを対象としています。

Spec Kit の優れた点。

Spec Kitは GitHub Next によるスペック駆動開発ワークフローです。

完結した、意見を持つプロセス

Spec Kit は全行程を提供します：constitution → specify → plan → tasks → implement。 各ステップにはスラッシュコマンドと、エージェントをレールに乗せ続けるよう設計された プロンプトがあります。プロセスが欲しいなら、Spec Kit がひとつ用意してくれます。

強力な流通と認知度

GitHub Next の後ろ盾を持ち、大きなコミュニティと拡張機能の充実したライブラリがあります。 多くの開発者にとって、Spec Kit は最初に出会うスペック駆動ワークフローです。

エージェント非依存のコマンド

Spec Kit のコマンドは Claude Code、Cursor、Copilot などにまたがって動作します — どれを実行していても、ワークフローがエージェントを駆動します。

機能比較。

これらのツールは異なる問いに答えるため、この表は勝者ではなく役割を比較します。

機能Spec KitSpecScore
主な役割ワークフロー / 方法論ストレージフォーマット + CLI
スペック出力自由形式の MarkdownMarkdown + YAML frontmatter（構造化）
スペック lintingなしコンテンツ品質 — 曖昧な動詞、欠落した AC、未解決の参照
要件 / AC IDなし機械可読な ID（REQ: slug）
ライフサイクルステータス暗黙的（ワークフローのステップ）強制 — Draft → Approved → Implementing → Stable → Deprecated
コードからスペックへのトレーサビリティなしspecscore: アノテーション + Verifies: コミットトレーラー
CLI からのスペッククエリスキャフォールディング（specify、plan、tasks）クエリ API — feature list / show / deps、lint、code refs
ランタイム依存Pythonなし — 単一の Go バイナリ
CI 統合ワークフローを実行specscore lint がゼロ以外で終了、pre-commit フック
関係性組み合わせられる — Spec Kit は SpecScore ファイルを生成できる
ライセンスMITMIT

SpecScore が加えるもの。

出力が lint 可能

Spec Kit は自由形式の Markdown を生成します — 良くても悪くても、それがリリースされます。 SpecScore は結果を2つの層で検査します：lint は、すべての要件に 受け入れ基準があるか、相互参照が解決するか、ステータス遷移が妥当かを決定論的に検証し — AI レビュー（/review、/score）が曖昧な基準や漠然とした動詞を 捉えます。

$ specscore lint checkout/apply-discount.md
  ✗ R3  no acceptance criteria
  ✗ link  "Related Feature: discount-tiers" not found

出力がクエリ可能

Spec Kit はファイルを書きます。それを読み返すには開く必要があります。SpecScore の スペックは CLI から問いに答えます：specscore feature list、feature deps、code refs — エージェントはリポジトリの全ファイルを 読むことなくスペックグラフをナビゲートします。

すべての要件に ID

Spec Kit は散文で要件を参照します。SpecScore はスラッグベースの ID （REQ: slug-format）と、名前変更、リファクタリング、エージェント間の 引き継ぎにも耐える AC ID を割り当てます。

ライフサイクルが強制される

Spec Kit では、スペックの段階はワークフロー上の位置によって決まります。 SpecScore では、ライフサイクルは強制されるステータスフィールドです — Draft → Approved → Implementing → Stable → Deprecated — lint で検証され、git フックや CI からspecscore change-status で遷移します。

コードがスペックまでトレースできる

Spec Kit にはトレーサビリティの仕組みがありません。SpecScore にはspecscore: ソースアノテーションと Verifies:コミットトレーラーがあります — specscore code refs を実行すれば 「この要件を実装しているコードはどれか？」に確定的な答えが得られます。

ランタイム依存なし

SpecScore は単一の Go バイナリです — インストールするランタイムはありません。 Go、Rust、Python、Java、JavaScript のプロジェクトで、ツールチェーンに何も追加することなく 動作します。

使い分けの指針。

Spec Kit を選ぶべきなのは…

  • アイデアから実装まで、ガイド付きで意見を持ったプロセスが欲しい場合。
  • チームに明示的な specify / plan / tasks ステップの規律が必要な場合。
  • チーム全体でエージェントの駆動方法を標準化している場合。

SpecScore を使うべきなのは…

  • 全ファイルを読まずにエージェントが lint・クエリ・変更できるスペックが必要な場合。
  • 確定的な答えを返すコードからスペックへのトレーサビリティが必要な場合。
  • 多くのフィーチャーとライフサイクル遷移を持つ大規模システムを構築する場合。
  • ランタイム依存をゼロにしたい場合 — 1つのバイナリ、言語ツールチェーン不要。
  • ESLint や go vet のようにゼロ以外で終了するスペック品質ゲートが CI に必要な場合。

SpecScore は Spec Kit を拡張します — 置き換えではありません。

Spec Kit はスペックを生み出すプロセスであり、SpecScore はそのスペックを書くフォーマットです。 SpecScore フォーマットを出力する Spec Kit 拡張が進行中です — Spec Kit ワークフローを実行すれば、 その先で lint・クエリ・トレースできるスペックが得られます。

プロセスには Spec Kit を。アーティファクトには SpecScore を。両方が欲しいときは両方を実行してください。

フィードバック

合格するスペックを。

CLI をインストールエージェント用 AI スキルを入手GitHub でオープンソース公開中

翻訳の誤りやこのページの改善案がありますか？ お知らせください.