レビュアーが実際に尋ねた質問。

spec-kitはメソドロジー — 仕様を書くためのプロセスです。SpecScoreはあなたが書く仕様のストレージ形式であり、 それを問い合わせ・編集するCLIです。両者は組み合わさります： spec-kitはSpecScoreファイルを生成でき、SpecScore形式を書き出す spec-kit拡張も進行中です。

プロセスが欲しいときはspec-kitを。リポジトリの全ファイルを 読まずにAIエージェントがリント・問い合わせ・変更できる仕様が 欲しいときはSpecScoreを。両方欲しいなら両方使えばいいのです。

精神は似ています。3つともAIエージェントをideate → specify → plan → implementへと導くスキルライブラリです。違いは 哲学ではなく、メカニックにあります。

SpecStudio Skillsは成果物をSpecScore形式で書き（Markdown + YAMLの定義された構造）、クエリ、リント、 ステータス変更にはspecscore CLIをディスパッチします。 Superpowersとagent-skillsは主にスキルのプロンプトを通じて ファイルを直接読み書きします。

トークン消費が気になるときはSpecStudio Skillsを選んでください — CLIは「未解決の問いを持つすべての開いた機能」への構造化された答えを1回の呼び出しで返しますが、 ファイルベースのスキルは同じ答えを得るためにN個のドキュメントを 読みます。

スキルはファイルを読み書きできます。ただし以下を確実には 行えません：

• 仕様ツリー全体での参照整合性の保証（リンクが解決し、IDが一意、インデックスが同期される）；
• すべてのファイルを読まずに「未解決の問いを持つ開いた機能」のフィルタ済みリストを返すこと；
• すべての成果物で、適切なタイミングで適切なステータスフィールドを書き換えること。

CLIはエージェントに、タスクごとに1回の綺麗な呼び出しを 与えます — jqがJSONへの綺麗な1回の呼び出しを あなたに与えるのと同じです。スキル単独だとトークンは多く、 ドリフトしやすく、インデックスの更新を忘れます。

「Score」は2通りに読め、両方とも意図したものです。

パルティトゥーラ。要件の構造化された総譜 — 楽譜がパート、声部、タイミングを構造化するのと同じ仕方です。 SpecScoreツリーを開いたとき、指揮者が総譜を読むように 読めるべきです：階層、パート、参照、すべてが一度に見える状態で。

文字通りの品質グレード。CLIリンターは 決定論的なスコアです（仕様の構造は保たれているか？）。/scoreスキルはAIが判定するスコア — 成果物ごとのA–Fレディネスグレードで、 著者向けの軸ごとフィードバック付きです。名前の「Score」の 半分が、単なる願望ではなくツールが生み出す機能となります。

実測の横並び比較はHabr投稿前に公開予定です — 同じタスク （「次は何をすべきか？」）を2回走らせます：1回は素の エージェントがドキュメントを読み、もう1回は同じエージェントが SpecScore CLIを呼び出します。両方のトークン数と回答までの 時間を出します。

数値が出るまでの主張は構造的なものです：開いた機能と 未解決の問いをCLIに尋ねるエージェントは、小さな構造化された 応答を得ます。CLIなしの同じエージェントはN個のドキュメントを 読みます — Nはしばしば数十です。CLIのインターフェイスは まさにその読み込みの扇形展開を避けるよう作られています。