# 2026年のおすすめ仕様駆動開発ツール

Canonical: https://specscore.md/ja/spec-driven-development/tools/

SpecScoreは、仕様のためのオープンでリント可能なファイル形式で、MarkdownとYAML（YAML Ain't Markup Language）で書かれています。[仕様駆動開発](https://specscore.md/ja/spec-driven-development/)（SDD）とは、書かれた仕様を正本とし、コードをその仕様に沿って作り、その仕様に照らして確かめるやり方です。仕様駆動開発ツールとは、その仕様を書き、保存し、ときには検査するために使うフォーマット、ワークフロー、製品です。プロダクト要求文書（PRD）とは、誰かがそれをタスクに分ける前に、課題と範囲を散文で述べる文書です。[要件構文への平易なアプローチ](https://kiro.dev/docs/specs/feature-specs/)（EARS）とは、「WHEN 何かが起きたとき、THE SYSTEM SHALL 何かをする」という形の要求文です。[コマンドラインインターフェース](https://specscore.md/ja/cli/)（CLI）とは、ターミナルで実行するプログラムです。[継続的インテグレーション](https://specscore.md/ja/validators/)（CI）とは、提案された変更のたびに走る自動検査です。

この仕様駆動開発ツールの比較では、[GitHub Spec Kit](https://github.com/github/spec-kit)、[OpenSpec](https://github.com/Fission-AI/OpenSpec)、[Kiro](https://kiro.dev/)、[Tessl](https://docs.tessl.io/)、[BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD)、[Task Master AI](https://github.com/eyaltoledano/claude-task-master)、[CodeSpeak](https://codespeak.dev/)、[Datarim](https://github.com/Arcanada-one/datarim)、プレーンな Markdown、[SpecScore](https://specscore.md/ja/)を扱います。公開されているページとリポジトリは 2026年10月30日に読みました。コマンド、ファイルの置き方、製品が何を検査するかは変わり得ます。末尾の出典が、各記述の元になったページを示します。

リポジトリで分かれる点は、仕様そのものが CI で失敗し得るかどうかです。SpecScore のウェブサイトのリポジトリでは、[dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) が SpecScore CLI を導入し、プルリクエストと main へのプッシュで `specscore spec lint` を実行します。specstudio-skills の [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) スキルは、成果物に対する手作業の AI 採点です。呼び出すのは人です。あのワークフローは呼び出しません。

## 仕様駆動開発ツールを並べて。

各行は役割であり、点数ではありません。名前からは SpecScore の比較へ、セルの根拠は下の見出しへ進んでください。

| ツール | 何か | 仕様の書き方と保存場所 | 仕様の自動検査 | ライセンス | 向いている人 |
| --- | --- | --- | --- | --- | --- |
| [GitHub Spec Kit](https://specscore.md/ja/vs/spec-kit/) | Markdown の成果物を作る、エージェントのワークフロー | `specs/` の下の機能ディレクトリ: `spec.md`、`plan.md`、`tasks.md` | `/speckit.analyze` は、エージェントのセッションの中で成果物をまたぐ抜けを報告します。コミュニティの拡張でゲートを足せます。 | [MIT](https://github.com/github/spec-kit/blob/main/LICENSE)。リポジトリは [github/spec-kit](https://github.com/github/spec-kit) | エージェントに、共通の手順を一つ持たせたいチーム |
| [OpenSpec](https://specscore.md/ja/vs/openspec/) | コードの前に合意するための、変更フォルダとエージェントコマンド | `openspec/changes/` の下のプレーンな Markdown: proposal、specs、design、tasks | `openspec validate` は変更と仕様の構造を検査し、ゼロ以外で終了できます。CI のスクリプトからでも実行できます。 | [MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE)。リポジトリは [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec) | 軽い変更フォルダと、構造の検査が欲しいチーム |
| [Kiro](https://specscore.md/ja/vs/kiro/) | 仕様の草案を作る、AWS のエージェント型 IDE、CLI、ウェブアプリ | EARS の `requirements.md` に加え、`design.md` と `tasks.md` | 設計の前に、Kiro の中で Analyze Requirements。機能仕様のページが、その製品内の検査を説明しています。 | IDE と CLI は、[Kiro のライセンス](https://kiro.dev/license/) の下で AWS Content です（AWS Customer Agreement）。 | 要件、設計、タスクの草案を Kiro に書かせたい人 |
| [Tessl](https://specscore.md/ja/vs/tessl/) | エージェントスキルのプラットフォームと、仕様駆動開発のタイル | スキルはリポジトリ内のファイルです。タイルは `.spec.md` を `specs/` の下に書きます。 | タイルには `scripts/validate-specs.sh` と `scripts/check-spec-links.sh` が付きます。GitHub Actions がタイル自身を検査します。 | タイルは [MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE)。リポジトリは [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile)。プラットフォームは Tessl の製品です。 | エージェントスキルを揃えるチーム、またはタイルの「コードより先に仕様」という規則を使うチーム |
| [BMAD Method](https://specscore.md/ja/vs/bmad-method/) | AI 駆動開発のためのアジャイルな方法 | 別のワークフローへ持ち出せるブリーフ、仕様、アーキテクチャ | README は、方法の成果物とエージェントのワークフローを説明しています。CI 向けのフォーマットリンターは記していません。 | [MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE)。リポジトリは [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD)。そのファイルに商標の注意書きがあります。 | 変更の大きさに合わせた、アジャイルなエージェントの方法が欲しいチーム |
| [Task Master AI](https://specscore.md/ja/vs/task-master-ai/) | PRD から分解する、コーディングエージェント向けのタスク一覧 | PRD の散文。多くは `.taskmaster/docs/prd.txt`。その後に生成されるタスク | README は、PRD をタスクへ分解することを説明しています。PRD のリンターは説明していません。 | [Commons Clause 付きの MIT](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE)。リポジトリは [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master) | すでに PRD があり、それをタスクに分けたいチーム |
| [CodeSpeak](https://specscore.md/ja/vs/codespeak/) | チャットの意図を、コードに対応づけた要件へ変えるエージェント型ツールキット | 製品の中にあり、コードへ対応づけられた構造化要件 | サイトは、要件が変更のたびに、製品の中で強制される、と述べています。 | [利用規約](https://codespeak.dev/terms-of-service)（2026年3月3日発効）。CodeSpeak Ltd は、ソースコードを含む Service を保持します。製品サイトは、ツールキットのソースリポジトリを公開していません。 | チャットから意図を取り、コードへの対応を保ちたいチーム |
| [Datarim](https://specscore.md/ja/vs/datarim/) | Claude Code、Codex CLI、Cursor、Antigravity 向けの反復ワークフロー | `/dr-prd` が PRD を書きます。進行中のタスクは `backlog.md` にあります。 | `/dr-compliance` と `/dr-dream lint` は、それらのコマンドを呼び出したときに動きます。 | [MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE)。リポジトリは [Arcanada-one/datarim](https://github.com/Arcanada-one/datarim) | 段階のあるコマンドと、リポジトリ内のバックログが欲しいチーム |
| [プレーンな Markdown](https://specscore.md/ja/vs/plain-markdown/) | 自分で書いてコミットする、普通の Markdown ファイル | 好きなディレクトリにある、任意の `.md` ファイル | 自分で検査を足すまでは、読んで行うレビュー | 製品もなく、ライセンスファイルもありません。ファイルの条件は、リポジトリの条件です。 | 短いメモ、スパイク、または読んで行うレビュー |
| [SpecScore](https://specscore.md/ja/) | オープンな仕様フォーマットと、ファイルを検査する CLI | `spec/` ツリーの Markdown と YAML | [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) が、プルリクエストと main へのプッシュで `specscore spec lint` を実行します。[/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) は手作業の AI 採点であり、そのワークフローはそれを実行しません。 | フォーマットは [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE)。リポジトリは [specscore/specscore](https://github.com/specscore/specscore)。CLI は [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE)。リポジトリは [specscore/specscore-cli](https://github.com/specscore/specscore-cli)。 | フォーマットが壊れたとき、仕様ファイルを CI で失敗させたいチーム |

## GitHub Spec Kit

[GitHub Spec Kit](https://github.github.io/spec-kit/) は、コーディングエージェントに手順を渡すオープンなツールキットです。Specify、Plan、Tasks、Implement、Converge と進みます。2026年9月28日付けの Spec Kit ドキュメントのホームは、各段階が Markdown の成果物を作り、次の段階がそれを読む、と述べています。

ファイルは `specs/` の下の機能ディレクトリに置きます。2026年10月30日に読んだ[アップグレードガイド](https://github.github.io/spec-kit/upgrade.html)は、`specs/001-my-feature/spec.md` のようなパスを示し、横に `plan.md` と `tasks.md` を置きます。[エージェント型 SDD のリファレンス](https://github.github.io/spec-kit/reference/agentic-sdd.html)は `/speckit.analyze` を、ファイルを編集せずに、仕様と計画とタスクのあいだの食い違いを報告するもの、と説明しています。`/speckit.clarify` と `/speckit.checklist` は、エージェントの中で実行する別のコマンドです。ドキュメントのホームは、準拠のゲートを足すコミュニティ拡張にも名前を挙げ、その一つが CI Guard です。

ライセンスは [MIT](https://github.com/github/spec-kit/blob/main/LICENSE) で、公開リポジトリは [github/spec-kit](https://github.com/github/spec-kit) です。Spec Kit は、その手順が欲しく、仕様はエージェントが書いた Markdown のままでよい、というチームに向きます。SpecScore との並べ方は [SpecScore vs Spec Kit](https://specscore.md/ja/vs/spec-kit/) にあります。

## OpenSpec

Fission-AI の [OpenSpec](https://github.com/Fission-AI/OpenSpec) は、変更ごとにフォルダを分け、人とエージェントがコードを書く前に合意できるようにします。2026年10月30日に読んだ [README](https://github.com/Fission-AI/OpenSpec/blob/main/README.md) は、`openspec/changes/add-dark-mode/` に `proposal.md`、`specs/` ディレクトリ、`design.md`、`tasks.md` がある例を示します。要件はプレーンな Markdown です。SHALL の文と、WHEN / THEN のシナリオです。同じ README は、30+ の AI アシスタントに対応する、と述べています。

`openspec validate` は、変更と仕様の構造上の問題を検査します。2026年10月30日に読んだ[CLI リファレンス](https://openspec.dev/docs/cli)は、検査が失敗したときのゼロ以外の終了と、CI ジョブが実行できるシェルの断片を記しています。この検査が見るのは、OpenSpec の変更と仕様の構造です。

ライセンスは [MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE) で、リポジトリは [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec) です。OpenSpec は、その変更フォルダと構造の検査が欲しいチームに向きます。[SpecScore vs OpenSpec](https://specscore.md/ja/vs/openspec/) を参照してください。

## Kiro

Amazon Web Services（AWS）の [Kiro](https://kiro.dev/) は、エージェント型の開発環境です。エディタ、CLI、ウェブアプリからなります。2026年8月4日に更新された[機能仕様のページ](https://kiro.dev/docs/specs/feature-specs/)は、一つの機能を要件、設計、タスクと進めていきます。`requirements.md` は EARS を使います。`design.md` と `tasks.md` がその横にあります。Quick Spec は三つを、あいだに承認で止まらず通せます。

Analyze Requirements は、設計の前に、矛盾、あいまいさ、衝突する制約、抜けを探します。その分析は Kiro の中で動きます。機能仕様のページが、製品内の検査を説明しています。

2026年10月30日に読んだ[Kiro のライセンス](https://kiro.dev/license/)は、IDE と CLI が AWS Content として、AWS Customer Agreement または別の書面による合意と、AWS Intellectual Property License の下でライセンスされる、と述べています。Kiro は、その三つのファイルの草案をこの製品に任せる人に向きます。[SpecScore vs Kiro](https://specscore.md/ja/vs/kiro/) を参照してください。文型は[EARS要件構文](https://specscore.md/ja/articles/ears-requirements/)です。

## Tessl

2026年10月30日に読んだ[Tessl のドキュメント](https://docs.tessl.io/)は、エージェントスキルを扱うオープンなプラットフォームを説明しています。レジストリ、ガバナンス、evals、関連するコントロールです。スキル、ルール、ドキュメントはリポジトリ内のファイルです。

別の成果物である仕様駆動開発のタイルは、[tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile) から公開され、[Tessl のレジストリ](https://tessl.io/registry/tessl-labs/spec-driven-development) に載っています。タイルの README は、エージェントが `.spec.md` を `specs/` ディレクトリに、YAML のフロントマター、`targets`、`[@test]` のリンク付きで書く、と述べています。`scripts/validate-specs.sh` と `scripts/check-spec-links.sh`、そしてタイル自身を検査する GitHub Actions も記しています。

タイルのライセンスは [MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE) で、そのリポジトリにあります。ドキュメントはレジストリのプラットフォームを Tessl の製品と説明し、プラットフォーム全体の公開リポジトリは示していません。Tessl は、スキルを揃えるチーム、またはタイルの「コードより先に仕様」という誘導が欲しいチームに向きます。[SpecScore vs Tessl](https://specscore.md/ja/vs/tessl/) を参照してください。

## BMAD Method

2026年10月30日に読んだ [BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD) リポジトリの README は、AI 駆動開発のためのアジャイルな方法を説明しています。方法を端から端まで使うことも、ブリーフ、仕様、アーキテクチャを今あるワークフローへ持ち出すこともできる、と述べています。そこで名指しされている安定ラインは v6.12 です。v7 は main ブランチのプレビューと説明されています。プロジェクトは名前を BMad と綴り、リポジトリは BMAD-METHOD です。

README の中心は、それらの計画の成果物と、それを作るエージェントスキルです。決まった仕様スキーマを CI で検査するコマンドは記していません。

ライセンスは [MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE) で、リポジトリは [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD) です。そのライセンスファイルには、BMad の商標に関する注意書きもあります。この方法は、アジャイルの循環が欲しく、仕様をそれらのブリーフと仕様に残すチームに向きます。[SpecScore vs BMAD Method](https://specscore.md/ja/vs/bmad-method/) を参照してください。

## Task Master AI

[Task Master AI](https://github.com/eyaltoledano/claude-task-master) は、AI のコーディングエージェント向けのタスク一覧です。2026年10月30日に読んだ README は PRD を勧め、置き場所は多くの場合 `.taskmaster/docs/prd.txt` です。`task-master parse-prd` がその散文をタスクに変えます。[ドキュメント](https://tryhamster.com/docs/taskmaster)は、タスクの構造、依存関係、タグを扱います。

README は、PRD を入力とし、タスク一覧をエージェントが作業する対象として扱います。PRD の文言や構造を検査するリンターは説明していません。

ライセンスは [Commons Clause 付きの MIT](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE) で、リポジトリは [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master) です。README は、Task Master を使って製品を作ることはできる、Task Master そのものを売ることやホストされたサービスとして提供することはその許諾の外だ、と述べています。PRD をタスクに分けたいチームに向きます。[SpecScore vs Task Master AI](https://specscore.md/ja/vs/task-master-ai/) を参照してください。

## CodeSpeak

2026年10月30日に読んだ [CodeSpeak](https://codespeak.dev/) のサイトは、エージェント型のエンジニアリング・ツールキットを説明しています。エージェントのチャットから意図を取り、その意図をコードに対応づけた構造化要件へ変え、変更のたびにその要件を強制する、と述べています。サイトは、製品全体が出るまでのあいだ、ウェブのツールがチャットから意図を回収する、とも述べています。

2026年3月3日発効の[利用規約](https://codespeak.dev/terms-of-service)は、CodeSpeak Ltd がソフトウェアとソースコードを含む Service を保持する、と定めています。製品サイトはそのツールキットのソースリポジトリを公開していないため、このページはそのソフトウェアライセンスを名指ししません。

CodeSpeak は、会話から要件を取り、その製品の中でコードへの対応を保ちたいチームに向きます。[SpecScore vs CodeSpeak](https://specscore.md/ja/vs/codespeak/) を参照してください。

## Datarim

4.9.0 のバージョンバッジが付き、2026年10月30日に読んだ [Datarim](https://github.com/Arcanada-one/datarim) の README は、Claude Code、Codex CLI、Cursor、Google Antigravity 向けの反復ワークフローを説明しています。`/dr-prd` が PRD を生成します。進行中のタスクは `backlog.md` に、完了した履歴は `backlog-archive.md` にあります。

`/dr-compliance` は、そのコマンドを実行したとき、実装を PRD と照合します。`/dr-dream lint` はナレッジベースを、矛盾、孤立した項目、リンク切れ、古い内容、重複について点検します。これらはワークフローの中のコマンドです。

ライセンスは [MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE) で、リポジトリは [Arcanada-one/datarim](https://github.com/Arcanada-one/datarim) です。Datarim は、README が名指しするエージェントで、その段階のあるコマンドが欲しいチームに向きます。[SpecScore vs Datarim](https://specscore.md/ja/vs/datarim/) を参照してください。

## プレーンな Markdown

プレーンな Markdown とは、仕様を普通の `.md` ファイルにすることです。見出しと箇条書きを、コミットする場所に置きます。スキーマはありません。自分で検査を足すまでは、レビューは誰かがファイルを読むことです。

リンクすべき製品もライセンスファイルもありません。ファイルの条件は、リポジトリに適用するライセンスそのものです。プレーンな Markdown は、短いメモ、スパイク、または散文を読んでレビューするチームに向きます。[SpecScore vs plain Markdown](https://specscore.md/ja/vs/plain-markdown/) を参照してください。

## SpecScore

[SpecScore](https://specscore.md/ja/) は仕様のフォーマットです。機能、要件、受け入れ基準を、YAML を伴う Markdown で書き、CLI がファイルを検査します。フォーマットは [specscore/specscore](https://github.com/specscore/specscore) にあります。CLI は [specscore/specscore-cli](https://github.com/specscore/specscore-cli) にあります。

エージェントが検査できる基準の書き方は、[受け入れ基準の書き方](https://specscore.md/ja/articles/acceptance-criteria/)にあります。

要件、受け入れ基準、プラン、タスクを含む Markdown の機能仕様テンプレートは[Markdown の PRD テンプレート](https://specscore.md/ja/articles/feature-spec-template/)にあります。

Claude Code と Cursor での仕様駆動開発。機能ファイル、エージェント向け指示ファイル、そしてループの中の `specscore spec lint` については [Claude Code と Cursor での仕様駆動開発](https://specscore.md/ja/articles/claude-code-specs/)。

その linter を継続的インテグレーションで実行する手順は[CI で仕様を lint する](https://specscore.md/ja/articles/lint-specs-in-ci/)にあります。

このウェブサイトのリポジトリでは、[dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) がその CLI を導入し、プルリクエストと main へのプッシュで `specscore spec lint` を実行します。フォーマットを壊した仕様は、そのジョブを失敗させます。[/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) スキルは手作業の AI 採点です。頼んだときに、設定されたレビュアーを再実行します。dogfood のワークフローはそれを呼びません。

フォーマットのライセンスは [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) で、リポジトリは [specscore/specscore](https://github.com/specscore/specscore) です。CLI のライセンスは [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE) で、リポジトリは [specscore/specscore-cli](https://github.com/specscore/specscore-cli) です。SpecScore は、見出し、リンク、ステータスが誤っているときに仕様を CI で失敗させたいチームに向きます。ファイルを書いたエージェントは問いません。`openspec validate` は、ここにある他のツールのうち、構造の検査として最も近いものです。検査するのは OpenSpec 自身の変更の形です。個別の比較は [/vs/](https://specscore.md/ja/vs/) から始まります。

## 選び方。

手順が案内され、プルリクエストでレビューできる Markdown が欲しいなら、GitHub Spec Kit、OpenSpec、BMAD Method、Datarim を選んでください。EARS の要件の草案をその製品に書かせるなら Kiro です。PRD をタスク一覧にしたいなら Task Master AI です。意図をその製品の中でチャットから取りたいなら CodeSpeak です。課題がエージェントスキルなら Tessl で、仕様のタイルは任意の誘導です。

仕様ファイルそのものが CI で失敗しなければならないなら、SpecScore を選んでください。このリポジトリの検査は、[dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) の中の `specscore spec lint` です。上の一覧にあるワークフローは、仕様を書く手順として併用できます。

## 出典。

ページ自身が更新日を掲げている場合を除き、2026年10月30日に読みました。価格とプラン名は動くため、ここには書いていません。

- [GitHub Spec Kit ドキュメント（ページの日付は 2026年9月28日）](https://github.github.io/spec-kit/)
- [Spec Kit — エージェント型 SDD のリファレンス](https://github.github.io/spec-kit/reference/agentic-sdd.html)
- [Spec Kit — アップグレードガイド（specs/ のパス）](https://github.github.io/spec-kit/upgrade.html)
- [github/spec-kit — MIT ライセンス](https://github.com/github/spec-kit/blob/main/LICENSE)
- [Fission-AI/OpenSpec — README](https://github.com/Fission-AI/OpenSpec/blob/main/README.md)
- [OpenSpec CLI リファレンス — openspec validate](https://openspec.dev/docs/cli)
- [Fission-AI/OpenSpec — MIT ライセンス](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE)
- [Kiro ドキュメント — 機能仕様と EARS（2026年8月4日更新）](https://kiro.dev/docs/specs/feature-specs/)
- [Kiro — ライセンス](https://kiro.dev/license/)
- [Tessl ドキュメント — Tessl とは](https://docs.tessl.io/)
- [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile)
- [Tessl の仕様駆動開発タイル — MIT ライセンス](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE)
- [bmad-code-org/BMAD-METHOD — README](https://github.com/bmad-code-org/BMAD-METHOD)
- [BMAD-METHOD — MIT ライセンス](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE)
- [eyaltoledano/claude-task-master — README](https://github.com/eyaltoledano/claude-task-master)
- [Task Master — Commons Clause 付きの MIT](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE)
- [CodeSpeak](https://codespeak.dev/)
- [CodeSpeak — 利用規約（2026年3月3日発効）](https://codespeak.dev/terms-of-service)
- [Arcanada-one/datarim — README（4.9.0 のバッジ）](https://github.com/Arcanada-one/datarim)
- [Datarim — MIT ライセンス](https://github.com/Arcanada-one/datarim/blob/main/LICENSE)
- [specscore/specscore — dogfood.yml（specscore spec lint）](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml)
- [specstudio-skills — /score スキル（手作業の AI 採点）](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md)
- [specscore/specscore — CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE)
- [specscore/specscore-cli — Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE)
