# 2026 年首選的規範驅動開發工具

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

SpecScore 是一種用於規格說明的開放、可 lint 的檔案格式，用 Markdown 和 YAML（YAML Ain't Markup Language）寫成。[規範驅動開發](https://specscore.md/zh-tw/spec-driven-development/)（SDD）指這樣一種實踐：寫下來的規範是可信依據，程式碼照它打造，也照它核對。規範驅動開發工具涵蓋格式、工作流程與產品，用來寫下這些規範、把它們留住，有時也拿來檢查。產品需求文件（PRD）是一段散文，在事情被拆成任務之前，先交代問題與範圍。[簡易需求語法](https://kiro.dev/docs/specs/feature-specs/)（EARS）是需求的一種句型，寫成「WHEN 有某件事發生，THE SYSTEM SHALL 做某件事」。[命令列介面](https://specscore.md/zh-tw/cli/)（CLI）是在終端機裡執行的一支程式。[持續整合](https://specscore.md/zh-tw/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/zh-tw/) 放進同一篇規範驅動開發工具對照。公開頁面與儲存庫的閱讀日是 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/zh-tw/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/zh-tw/vs/openspec/) | 變更各自一個資料夾，加上代理命令，寫程式碼前先說定 | 純 Markdown，目錄是 `openspec/changes/`：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/zh-tw/vs/kiro/) | AWS 的代理式 IDE、CLI 與網頁應用程式，會起草規範 | `requirements.md` 以 EARS 撰寫，一併放著 `design.md` 與 `tasks.md` | 設計開始前，在 Kiro 裡做需求檢視（Analyze Requirements）。功能規範那一頁描述的，就是這項做在產品裡的檢查。 | IDE 與 CLI 屬於 AWS 內容（AWS Content），依據是 [Kiro 授權](https://kiro.dev/license/)（AWS 客戶協議，AWS Customer Agreement）。 | 想請 Kiro 把需求、設計與任務起草出來的人 |
| [Tessl](https://specscore.md/zh-tw/vs/tessl/) | 讓代理載入技能的平台，另有一塊規範驅動開發 tile | 技能以檔案留在儲存庫裡。這塊 tile 會寫出 `.spec.md`，放在 `specs/` 底下。 | 這塊 tile 附上 `scripts/validate-specs.sh` 與 `scripts/check-spec-links.sh`。它的 GitHub Actions 負責 lint 這塊 tile 本身。 | tile 為 [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 的產品。 | 要把代理技能訂成團隊標準，或想用這塊 tile「先規範、後程式碼」的團隊 |
| [BMAD Method](https://specscore.md/zh-tw/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/zh-tw/vs/task-master-ai/) | 編碼代理的任務清單，由一份 PRD 解析而成 | PRD 以散文寫成，路徑常常是 `.taskmaster/docs/prd.txt`，其後再產生任務 | README 講的是把 PRD 解析成任務。它沒有描述一種用來檢查 PRD 的檢查器。 | [MIT 另附 Commons Clause](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/zh-tw/vs/codespeak/) | 代理式工具組：把聊天裡的意圖變成對應到程式碼的需求 | 結構化需求留在產品裡，並對應到程式碼 | 網站說，每一次變更都會在產品裡面強制這些需求。 | [服務條款](https://codespeak.dev/terms-of-service)（2026年3月3日生效）：CodeSpeak Ltd 保留該服務（Service），包含其原始碼。產品網站並未公布這套工具組的原始碼儲存庫。 | 想從聊天捕捉意圖，並讓它持續對應到程式碼的團隊 |
| [Datarim](https://specscore.md/zh-tw/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) | 想要分階段的命令，並在儲存庫裡留一份待辦的團隊 |
| [Plain Markdown](https://specscore.md/zh-tw/vs/plain-markdown/) | 你親手寫下、再提交的一份普通 Markdown 檔案 | 任何一份 `.md` 檔案，目錄由你決定 | 在你另外加上檢查器之前，審查就是讀過那份檔案 | 沒有產品，也沒有授權檔。這份檔案的條款，就是儲存庫的條款。 | 一篇短記、一回時間有限的試做，或你準備靠閱讀完成的審查 |
| [SpecScore](https://specscore.md/zh-tw/) | 開放的規範格式，另附一支檢查這些檔案的 CLI | Markdown 加上 YAML，放在一棵 `spec/` 目錄樹裡 | [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。Spec Kit 文件首頁所標日期為 2026年9月28日，寫明每一個階段都會產出 Markdown，下一個階段再去讀它。

那些檔案住在 `specs/` 底下的功能目錄。[升級指南](https://github.github.io/spec-kit/upgrade.html) 的閱讀日是 2026年10月30日，舉的路徑像 `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)。若團隊要的就是這條流程，也接受規範繼續以代理寫下的 Markdown 存在，Spec Kit 就對得上。與 SpecScore 並排的對照在 [SpecScore 對照 Spec Kit](https://specscore.md/zh-tw/vs/spec-kit/)。

## OpenSpec

[OpenSpec](https://github.com/Fission-AI/OpenSpec) 出自 Fission-AI。每一次變更單獨成一個資料夾，人和代理得以在程式碼寫下之前先講定。[README](https://github.com/Fission-AI/OpenSpec/blob/main/README.md) 的閱讀日是 2026年10月30日，裡面看得到 `openspec/changes/add-dark-mode/`，含有 `proposal.md`、一個 `specs/` 目錄、`design.md` 以及 `tasks.md`。需求用純 Markdown 來寫：一句 SHALL，再加上 WHEN / THEN 情境。同一份 README 寫它能配合的 AI 助理在 30 種以上。

`openspec validate` 會去看變更與規範有沒有結構上的問題。[CLI 參考](https://openspec.dev/docs/cli) 讀於 2026年10月30日，載明驗證失敗時以非零狀態結束，並附上一段 shell，CI 作業可以照著跑。那項檢查查的是 OpenSpec 自己的變更與規範結構。

授權是 [MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE)，公開儲存庫為 [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec)。若團隊要的是那個變更資料夾，再加上那道結構檢查，OpenSpec 就對得上。見 [SpecScore 對照 OpenSpec](https://specscore.md/zh-tw/vs/openspec/)。

## Kiro

[Kiro](https://kiro.dev/) 出自亞馬遜網路服務（AWS）。它是一套代理式開發環境，裡頭有編輯器、CLI 與網頁應用程式。[功能規範頁](https://kiro.dev/docs/specs/feature-specs/) 的更新日期是 2026年8月4日，帶著一項功能走完需求、設計與任務。`requirements.md` 採用 EARS。`design.md` 與 `tasks.md` 並排放著。快速規範（Quick Spec）一次把三步跑完，中間不設核准停點。

需求檢視（Analyze Requirements）在設計之前找出前後不一致、歧義、彼此衝突的約束，以及缺漏。這項分析是在 Kiro 裡面跑的。功能規範頁所描述的，就是這項做在產品裡的檢查。

[Kiro 授權](https://kiro.dev/license/) 讀於 2026年10月30日。它寫明：IDE 與 CLI 以 AWS 內容（AWS Content）授權，依據是 AWS 客戶協議（AWS Customer Agreement）或其他書面協議，再加上 AWS 智慧財產授權（AWS Intellectual Property License）。若你要的是由這項產品起草那三份檔案，Kiro 就對得上。見 [SpecScore 對照 Kiro](https://specscore.md/zh-tw/vs/kiro/)。句式見[EARS 需求語法](https://specscore.md/zh-tw/articles/ears-requirements/)。

## Tessl

[Tessl 的文件](https://docs.tessl.io/) 讀於 2026年10月30日，講的是一個管理代理技能的開放平台：登錄庫、治理、評測，以及相關的管控。技能、規則與說明文件，都是儲存庫裡的檔案。

另外還有一件產物，規範驅動開發 tile，發布自 [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile)，並出現在 [Tessl 登錄庫](https://tessl.io/registry/tessl-labs/spec-driven-development)。tile 的 README 寫道：代理會寫下 `.spec.md`，放進 `specs/` 目錄，帶著 YAML 前置資料、`targets` 以及 `[@test]` 連結。它也記載了 `scripts/validate-specs.sh` 與 `scripts/check-spec-links.sh`，還有專門 lint 這塊 tile 本身的 GitHub Actions。

這塊 tile 的授權是 [MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE)，就在該儲存庫。文件把登錄庫平台寫成 Tessl 的產品，並沒有指出整個平台的公開儲存庫。若團隊要把技能訂成標準，或想要這塊 tile 那種先寫規範再寫程式碼的引導，Tessl 就對得上。見 [SpecScore 對照 Tessl](https://specscore.md/zh-tw/vs/tessl/)。

## BMAD Method

[BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD) 儲存庫的 README 讀於 2026年10月30日，講的是一套給 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 對照 BMAD Method](https://specscore.md/zh-tw/vs/bmad-method/)。

## Task Master AI

[Task Master AI](https://github.com/eyaltoledano/claude-task-master) 是給 AI 編碼代理用的任務清單。README 讀於 2026年10月30日，建議備一份 PRD，路徑常常放在 `.taskmaster/docs/prd.txt`，再以 `task-master parse-prd` 把那段散文轉成任務。[文件](https://tryhamster.com/docs/taskmaster) 涵蓋任務結構、相依與標籤。

README 把 PRD 當成輸入，任務清單才是代理據以動手的東西。它沒有描述一種檢查器，能去查 PRD 的措辭或結構。

授權是 [MIT 另附 Commons Clause](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 對照 Task Master AI](https://specscore.md/zh-tw/vs/task-master-ai/)。

## CodeSpeak

[CodeSpeak](https://codespeak.dev/) 的網站讀於 2026年10月30日，講的是一套代理式工程工具組。它從代理的聊天裡捕捉意圖，把意圖轉成對應到程式碼的結構化需求，並說每一次變更都會強制這些需求。網站也說，完整產品上線之前，有一個網頁工具可以從聊天裡把意圖找回來。

[服務條款](https://codespeak.dev/terms-of-service) 自 2026年3月3日起生效，載明 CodeSpeak Ltd 保留該服務（Service），包含其軟體與原始碼。產品網站沒有公布這套工具組的原始碼儲存庫，所以本頁不替它指名一種軟體授權。

若團隊想在那項產品裡從對話捕捉需求，並讓需求一直對應到程式碼，CodeSpeak 就對得上。見 [SpecScore 對照 CodeSpeak](https://specscore.md/zh-tw/vs/codespeak/)。

## Datarim

[Datarim](https://github.com/Arcanada-one/datarim) 的 README 掛著 4.9.0 版本徽章，讀於 2026年10月30日，講的是一套給 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)。若團隊想在 README 點名的那些代理上使用這些分階段命令，Datarim 就對得上。見 [SpecScore 對照 Datarim](https://specscore.md/zh-tw/vs/datarim/)。

## Plain Markdown

純 Markdown 就是把規範寫成一份普通的 `.md` 檔案：一個標題、幾條項目，提交到你選的地方。沒有綱要。在你自己加上檢查器之前，審查就是有人去讀這份檔案。

沒有產品，也沒有可以連出去的授權檔。這份檔案的條款，就是你套在儲存庫上的那份授權。純 Markdown 適合一篇短記、一回時間有限的試做，或打算靠閱讀散文來審查的團隊。見 [SpecScore 對照純 Markdown](https://specscore.md/zh-tw/vs/plain-markdown/)。

## SpecScore

[SpecScore](https://specscore.md/zh-tw/) 是規範的一種格式——功能、需求與驗收標準，寫成帶 YAML 的 Markdown——另外附一支檢查這些檔案的 CLI。格式在 [specscore/specscore](https://github.com/specscore/specscore)。CLI 在 [specscore/specscore-cli](https://github.com/specscore/specscore-cli)。

怎樣寫出代理能夠核對的標準，見[如何撰寫驗收標準](https://specscore.md/zh-tw/articles/acceptance-criteria/)。

含需求、驗收標準、計畫和任務的 Markdown 功能規格範本見[Markdown PRD 範本](https://specscore.md/zh-tw/articles/feature-spec-template/)。

用 Claude Code 和 Cursor 做規範驅動開發：功能檔案、代理指令檔，以及迴圈中的 `specscore spec lint`，見 [用 Claude Code 和 Cursor 做規範驅動開發](https://specscore.md/zh-tw/articles/claude-code-specs/)。

如何在持續整合裡執行這個 linter，見[在 CI 中 lint 規格](https://specscore.md/zh-tw/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)。若團隊需要的是：標題、連結或狀態錯了，規範就得讓 CI 失敗，不論檔案出自哪一個代理，SpecScore 就對得上。`openspec validate` 是此處其他工具裡最接近的結構檢查；它查的是 OpenSpec 自己的變更形狀。個別對照從 [/vs/](https://specscore.md/zh-tw/vs/) 起頭。

## 怎麼挑。

想要一條有人帶路的流程，而且 Markdown 可以在拉取請求裡審查，就選 GitHub Spec Kit、OpenSpec、BMAD Method 或 Datarim。想請那項產品起草 EARS 需求，就選 Kiro。PRD 該變成任務清單時，選 Task Master AI。意圖該在那項產品裡從聊天捕捉時，選 CodeSpeak。問題落在代理技能、規範 tile 只是可選的引導時，選 Tessl。

規範檔本身必須讓 CI 失敗時，選 SpecScore。這個儲存庫裡的檢查，是 `specscore spec lint`，寫在 [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml)。上面那份清單裡的某一條工作流程，仍然可以是規範被寫下來的方式。

## 來源。

閱讀日是 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 規範驅動開發 tile——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——MIT 另附 Commons Clause](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)