# Migliori strumenti di sviluppo guidato dalle specifiche nel 2026

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

SpecScore è un formato di file aperto e verificabile con un linter per le specifiche, scritto in Markdown e YAML (YAML Ain't Markup Language). [Lo sviluppo guidato dalle specifiche](https://specscore.md/it/spec-driven-development/) (SDD) è una pratica in cui una specifica scritta è la fonte di verità rispetto alla quale il codice viene costruito e verificato. Gli strumenti di sviluppo guidato dalle specifiche sono i formati, i workflow e i prodotti usati per scrivere, conservare e a volte controllare quelle specifiche. Un documento dei requisiti di prodotto (PRD) è prosa che espone il problema e l’ambito prima che qualcuno lo divida in attività. L’[approccio semplice alla sintassi dei requisiti](https://kiro.dev/docs/specs/feature-specs/) (EARS) è una frase di requisito della forma «WHEN accade qualcosa, THE SYSTEM SHALL fare qualcosa». Un’[interfaccia a riga di comando](https://specscore.md/it/cli/) (CLI) è un programma che esegui in un terminale. L’[integrazione continua](https://specscore.md/it/validators/) (CI) è un controllo automatico su ogni modifica proposta.

Questo confronto di strumenti di sviluppo guidato dalle specifiche copre [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/), il [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), il Markdown semplice e [SpecScore](https://specscore.md/it/). Pagine e repository pubblici sono stati letti il 30 ottobre 2026. Comandi, disposizione dei file e ciò che un prodotto controlla possono cambiare; le fonti in fondo nominano la pagina da cui proviene ogni affermazione.

La distinzione che conta per un repository è se la specifica può far fallire la CI da sola. Nel repository del sito web SpecScore, [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) installa la CLI SpecScore ed esegue `specscore spec lint` sulle pull request e sui push verso main. La skill [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) in specstudio-skills è una valutazione manuale di IA di un artefatto. La invochi tu. Quel workflow no.

## Strumenti di sviluppo guidato dalle specifiche, affiancati.

Ogni riga è un ruolo, non un punteggio. Segui il nome fino al confronto SpecScore, oppure il titolo più sotto per la fonte dietro la cella.

| Strumento | Che cos’è | Come si scrivono e si conservano le specifiche | Validazione automatica della specifica | Licenza | A chi è adatto |
| --- | --- | --- | --- | --- | --- |
| [GitHub Spec Kit](https://specscore.md/it/vs/spec-kit/) | Workflow di agente che produce artefatti Markdown | Directory di funzionalità sotto `specs/`: `spec.md`, `plan.md`, `tasks.md` | `/speckit.analyze` segnala lacune tra gli artefatti nella sessione dell’agente. Le estensioni della community possono aggiungere controlli. | [MIT](https://github.com/github/spec-kit/blob/main/LICENSE) in [github/spec-kit](https://github.com/github/spec-kit) | Un team che vuole un processo condiviso per l’agente |
| [OpenSpec](https://specscore.md/it/vs/openspec/) | Cartelle di modifica e comandi di agente per accordarsi prima del codice | Markdown semplice sotto `openspec/changes/`: proposta, specifiche, progettazione, attività | `openspec validate` controlla la struttura della modifica e della specifica e può uscire con un codice diverso da zero, anche da uno script di CI. | [MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE) in [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec) | Un team che vuole una cartella di modifica leggera più un controllo di struttura |
| [Kiro](https://specscore.md/it/vs/kiro/) | IDE agentico, CLI e app web di AWS che redige le specifiche | `requirements.md` in EARS, più `design.md` e `tasks.md` | Analyze Requirements dentro Kiro, prima della progettazione. La pagina delle specifiche di funzionalità descrive quel controllo nel prodotto. | IDE e CLI sono AWS Content sotto la [licenza di Kiro](https://kiro.dev/license/) (AWS Customer Agreement). | Qualcuno che vuole che Kiro rediga i requisiti, la progettazione e le attività |
| [Tessl](https://specscore.md/it/vs/tessl/) | Piattaforma di skill per agenti, più un tile di sviluppo guidato dalle specifiche | Skill come file nel repository. Il tile scrive `.spec.md` sotto `specs/`. | Il tile fornisce `scripts/validate-specs.sh` e `scripts/check-spec-links.sh`. Le sue GitHub Actions fanno il lint del tile. | Il tile è [MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE) in [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile). La piattaforma è il prodotto di Tessl. | Un team che standardizza skill di agente, o che usa le regole specifica-prima-del-codice del tile |
| [BMAD Method](https://specscore.md/it/vs/bmad-method/) | Metodo agile per lo sviluppo guidato dall’IA | Brief, specifiche e architettura che puoi portare in un altro workflow | Il README descrive gli artefatti del metodo e i workflow dell’agente. Non documenta un linter di formato per la CI. | [MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE) in [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD), con un avviso di marchio in quel file. | Un team che vuole un metodo di agente agile dimensionato sul cambiamento |
| [Task Master AI](https://specscore.md/it/vs/task-master-ai/) | Elenco di attività per agenti di programmazione, ricavato analizzando un PRD | Prosa di PRD, spesso `.taskmaster/docs/prd.txt`, poi attività generate | Il README descrive l’analisi di un PRD in attività. Non descrive un linter per il PRD. | [MIT con una Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE) in [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master) | Un team che ha già un PRD e vuole dividerlo in attività |
| [CodeSpeak](https://specscore.md/it/vs/codespeak/) | Toolkit agentico che trasforma l’intento della chat in requisiti mappati sul codice | Requisiti strutturati dentro il prodotto, mappati sul codice | Il sito dice che i requisiti sono applicati a ogni modifica, dentro il prodotto. | [Termini di servizio](https://codespeak.dev/terms-of-service) (in vigore il 3 marzo 2026): CodeSpeak Ltd conserva il Service, compreso il suo codice sorgente. Il sito del prodotto non pubblica un repository del codice del toolkit. | Un team che vuole l’intento catturato dalle chat e tenuto mappato sul codice |
| [Datarim](https://specscore.md/it/vs/datarim/) | Workflow iterativo per Claude Code, Codex CLI, Cursor e Antigravity | `/dr-prd` scrive un PRD. Le attività attive stanno in `backlog.md`. | `/dr-compliance` e `/dr-dream lint` partono quando invochi quei comandi. | [MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE) in [Arcanada-one/datarim](https://github.com/Arcanada-one/datarim) | Un team che vuole comandi a fasi e un backlog nel repository |
| [Markdown semplice](https://specscore.md/it/vs/plain-markdown/) | Un file Markdown ordinario che scrivi e di cui fai il commit | Qualsiasi file `.md`, nella directory che scegli | La revisione che fai leggendo, finché non aggiungi un controllore | Nessun prodotto e nessun file di licenza. Le condizioni del file sono quelle del repository. | Una nota breve, uno spike o una revisione che farai leggendo |
| [SpecScore](https://specscore.md/it/) | Formato di specifica aperto più una CLI che fa il lint dei file | Markdown + YAML in un albero `spec/` | [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) esegue `specscore spec lint` sulle pull request e sui push verso main. [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) è una valutazione manuale di IA, e quel workflow non la esegue. | [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE), formato in [specscore/specscore](https://github.com/specscore/specscore). [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE), CLI in [specscore/specscore-cli](https://github.com/specscore/specscore-cli). | Un team che ha bisogno che il file di specifica faccia fallire la CI quando il formato si rompe |

## GitHub Spec Kit

[GitHub Spec Kit](https://github.github.io/spec-kit/) è un toolkit aperto che consegna a un agente di programmazione un processo: Specify, Plan, Tasks, Implement e Converge. La home della documentazione di Spec Kit, datata 28 settembre 2026, dice che ogni fase produce un artefatto Markdown che la fase successiva legge.

Quei file stanno in una directory di funzionalità sotto `specs/`. La [guida di aggiornamento](https://github.github.io/spec-kit/upgrade.html), letta il 30 ottobre 2026, indica percorsi come `specs/001-my-feature/spec.md`, con `plan.md` e `tasks.md` accanto. Il [riferimento SDD agentico](https://github.github.io/spec-kit/reference/agentic-sdd.html) descrive `/speckit.analyze` come un rapporto di incoerenze tra la specifica, il piano e le attività, senza modificare i file. `/speckit.clarify` e `/speckit.checklist` sono altri comandi che esegui nell’agente. La home della documentazione nomina anche estensioni della community, compresa una chiamata CI Guard, che aggiungono controlli di conformità.

La licenza è [MIT](https://github.com/github/spec-kit/blob/main/LICENSE), nel repository pubblico [github/spec-kit](https://github.com/github/spec-kit). Spec Kit è adatto a un team che vuole quel processo e si accontenta di tenere la specifica come il Markdown che l’agente ha scritto. Un confronto affiancato con SpecScore è su [SpecScore vs Spec Kit](https://specscore.md/it/vs/spec-kit/).

## OpenSpec

[OpenSpec](https://github.com/Fission-AI/OpenSpec), di Fission-AI, tiene ogni modifica nella propria cartella così una persona e un agente possono accordarsi prima che il codice sia scritto. Il [README](https://github.com/Fission-AI/OpenSpec/blob/main/README.md), letto il 30 ottobre 2026, mostra `openspec/changes/add-dark-mode/` con `proposal.md`, una directory `specs/`, `design.md` e `tasks.md`. I requisiti sono Markdown semplice: un’affermazione SHALL e uno scenario WHEN / THEN. Lo stesso README dice che supporta 30+ assistenti IA.

`openspec validate` controlla modifiche e specifiche alla ricerca di problemi strutturali. Il [riferimento della CLI](https://openspec.dev/docs/cli), letto il 30 ottobre 2026, documenta un’uscita diversa da zero quando la validazione fallisce, e un frammento di shell che un job di CI può eseguire. Quel controllo è la struttura di modifiche e specifiche di OpenSpec.

La licenza è [MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE), in [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec). OpenSpec è adatto a un team che vuole la cartella di modifica e quel controllo di struttura. Vedi [SpecScore vs OpenSpec](https://specscore.md/it/vs/openspec/).

## Kiro

[Kiro](https://kiro.dev/), di Amazon Web Services (AWS), è un ambiente di sviluppo agentico: un editor, una CLI e un’app web. La [pagina delle specifiche di funzionalità](https://kiro.dev/docs/specs/feature-specs/), aggiornata il 4 agosto 2026, accompagna una funzionalità attraverso requisiti, progettazione e attività. `requirements.md` usa EARS. `design.md` e `tasks.md` stanno accanto. Quick Spec può eseguire tutti e tre senza una sosta di approvazione tra loro.

Analyze Requirements cerca incoerenze, ambiguità, vincoli in conflitto e lacune prima della progettazione. Quell’analisi gira dentro Kiro. La pagina delle specifiche di funzionalità descrive il controllo nel prodotto.

La [licenza di Kiro](https://kiro.dev/license/), letta il 30 ottobre 2026, dice che l’IDE e la CLI sono concessi in licenza come AWS Content ai sensi dell’AWS Customer Agreement o di un altro accordo scritto, e dell’AWS Intellectual Property License. Kiro è adatto a qualcuno che vuole che quel prodotto rediga i tre file. Vedi [SpecScore vs Kiro](https://specscore.md/it/vs/kiro/). I modelli di frase sono in [la sintassi dei requisiti EARS](https://specscore.md/it/articles/ears-requirements/).

## Tessl

La [documentazione di Tessl](https://docs.tessl.io/), letta il 30 ottobre 2026, descrive una piattaforma aperta per gestire skill di agente: un registro, governance, evals e controlli collegati. Skill, regole e documenti sono file nel repository.

Un artefatto separato, il tile di sviluppo guidato dalle specifiche, è pubblicato da [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile) ed elencato nel [registro Tessl](https://tessl.io/registry/tessl-labs/spec-driven-development). Il README del tile dice che l’agente scrive file `.spec.md` in una directory `specs/`, con frontmatter YAML, `targets` e link `[@test]`. Documenta `scripts/validate-specs.sh` e `scripts/check-spec-links.sh`, e GitHub Actions che fanno il lint del tile stesso.

La licenza del tile è [MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE), in quel repository. La documentazione descrive la piattaforma del registro come il prodotto di Tessl e non indica un repository pubblico per l’intera piattaforma. Tessl è adatto a un team che standardizza le skill, o a un team che vuole la guida specifica-prima-del-codice del tile. Vedi [SpecScore vs Tessl](https://specscore.md/it/vs/tessl/).

## BMAD Method

Il README del repository [BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD), letto il 30 ottobre 2026, descrive un metodo agile per lo sviluppo guidato dall’IA. Dice che puoi usare il metodo dall’inizio alla fine, o portare i suoi brief, le specifiche e l’architettura in un workflow che hai già. La linea stabile indicata lì è v6.12. v7 è descritta come un’anteprima sul branch main. Il progetto scrive il nome BMad; il repository è BMAD-METHOD.

Il README mette al centro quegli artefatti di pianificazione e le skill di agente che li producono. Non documenta un comando che faccia il lint di uno schema di specifica fisso nella CI.

La licenza è [MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE), in [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD). Quel file di licenza porta anche un avviso di marchio per BMad. Il metodo è adatto a un team che vuole il ciclo agile e terrà la specifica in quei brief e in quelle specifiche. Vedi [SpecScore vs il BMAD Method](https://specscore.md/it/vs/bmad-method/).

## Task Master AI

[Task Master AI](https://github.com/eyaltoledano/claude-task-master) è un elenco di attività per agenti di programmazione IA. Il README, letto il 30 ottobre 2026, raccomanda un PRD, spesso in `.taskmaster/docs/prd.txt`, e `task-master parse-prd` per trasformare quella prosa in attività. [La documentazione](https://tryhamster.com/docs/taskmaster) copre la struttura delle attività, le dipendenze e i tag.

Il README tratta il PRD come input e l’elenco di attività come ciò da cui lavora l’agente. Non descrive un linter per la formulazione o la struttura del PRD.

La licenza è [MIT con una Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE), in [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master). Il README dice che puoi costruire prodotti con Task Master, e che vendere Task Master stesso o offrirlo come servizio ospitato è fuori da questa concessione. È adatto a un team che vuole il PRD diviso in attività. Vedi [SpecScore vs Task Master AI](https://specscore.md/it/vs/task-master-ai/).

## CodeSpeak

Il sito di [CodeSpeak](https://codespeak.dev/), letto il 30 ottobre 2026, descrive un toolkit di ingegneria agentica. Cattura l’intento dalle chat dell’agente, trasforma quell’intento in requisiti strutturati mappati sul codice e dice di applicare quei requisiti a ogni modifica. Il sito dice anche che uno strumento web recupera l’intento dalle chat finché il prodotto completo non viene lanciato.

I [termini di servizio](https://codespeak.dev/terms-of-service), in vigore il 3 marzo 2026, stabiliscono che CodeSpeak Ltd conserva il Service, compresi il suo software e il suo codice sorgente. Il sito del prodotto non pubblica un repository del codice per quel toolkit, perciò questa pagina non indica una licenza software per esso.

CodeSpeak è adatto a un team che vuole requisiti catturati dalla conversazione e tenuti mappati sul codice dentro quel prodotto. Vedi [SpecScore vs CodeSpeak](https://specscore.md/it/vs/codespeak/).

## Datarim

Il README di [Datarim](https://github.com/Arcanada-one/datarim), che porta un badge di versione 4.9.0 ed è stato letto il 30 ottobre 2026, descrive un workflow iterativo per Claude Code, Codex CLI, Cursor e Google Antigravity. `/dr-prd` genera un PRD. Le attività attive stanno in `backlog.md`, con la cronologia completata in `backlog-archive.md`.

`/dr-compliance` controlla un’implementazione rispetto al PRD quando esegui quel comando. `/dr-dream lint` controlla lo stato di una base di conoscenza alla ricerca di contraddizioni, orfani, link rotti, contenuto non aggiornato e duplicati. Sono comandi del workflow.

La licenza è [MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE), in [Arcanada-one/datarim](https://github.com/Arcanada-one/datarim). Datarim è adatto a un team che vuole quei comandi a fasi sugli agenti che il README nomina. Vedi [SpecScore vs Datarim](https://specscore.md/it/vs/datarim/).

## Markdown semplice

Il Markdown semplice è la specifica come un file `.md` ordinario: un’intestazione, alcuni punti elenco, ovunque tu ne faccia il commit. Non c’è uno schema. La revisione è qualcuno che legge il file, finché non aggiungi un controllore tuo.

Non c’è un prodotto e non c’è un file di licenza da collegare. Le condizioni del file sono la licenza che applichi al repository. Il Markdown semplice è adatto a una nota breve, a uno spike o a un team che revisionerà la prosa leggendola. Vedi [SpecScore vs Markdown semplice](https://specscore.md/it/vs/plain-markdown/).

## SpecScore

[SpecScore](https://specscore.md/it/) è un formato per la specifica — funzionalità, requisiti e criteri di accettazione come Markdown con YAML — e una CLI che controlla i file. Il formato sta in [specscore/specscore](https://github.com/specscore/specscore). La CLI sta in [specscore/specscore-cli](https://github.com/specscore/specscore-cli).

Come scrivere i criteri perché un agente possa verificarli è in [come scrivere i criteri di accettazione](https://specscore.md/it/articles/acceptance-criteria/).

Un modello di specifica di funzionalità in Markdown — requisiti, criteri di accettazione, un piano e task — è in [modello di PRD in Markdown](https://specscore.md/it/articles/feature-spec-template/).

Lo sviluppo guidato dalle specifiche con Claude Code e Cursor — il file di funzionalità, il file di istruzioni dell’agente e `specscore spec lint` nel ciclo sono descritti in [sviluppo guidato dalle specifiche con Claude Code e Cursor](https://specscore.md/it/articles/claude-code-specs/).

Come eseguire quel linter nell’integrazione continua è spiegato in [fare il lint delle specifiche in CI](https://specscore.md/it/articles/lint-specs-in-ci/).

Nel repository di questo sito web, [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) installa quella CLI ed esegue `specscore spec lint` sulle pull request e sui push verso main. Una specifica che rompe il formato fa fallire quel job. La skill [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) è una valutazione manuale di IA: riesegue i revisori configurati quando lo chiedi, e il workflow dogfood non la chiama.

La licenza del formato è [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE), in [specscore/specscore](https://github.com/specscore/specscore). La licenza della CLI è [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE), in [specscore/specscore-cli](https://github.com/specscore/specscore-cli). SpecScore è adatto a un team che ha bisogno che la specifica faccia fallire la CI quando un’intestazione, un collegamento o uno stato è sbagliato, qualunque agente abbia scritto il file. `openspec validate` è il controllo strutturale più vicino tra gli altri strumenti qui; controlla la forma di modifica propria di OpenSpec. I confronti singoli iniziano da [/vs/](https://specscore.md/it/vs/).

## Come scegliere.

Scegli GitHub Spec Kit, OpenSpec, il BMAD Method o Datarim quando vuoi un processo guidato e Markdown che puoi rivedere in una pull request. Scegli Kiro quando vuoi che quel prodotto rediga requisiti EARS. Scegli Task Master AI quando il PRD deve diventare un elenco di attività. Scegli CodeSpeak quando l’intento deve essere catturato dalle chat dentro quel prodotto. Scegli Tessl quando il problema sono le skill di agente, con il tile di specifica come guida facoltativa.

Scegli SpecScore quando il file di specifica stesso deve far fallire la CI. Il controllo in questo repository è `specscore spec lint` in [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml). Un workflow dell’elenco sopra può restare il modo in cui la specifica viene scritta.

## Fonti.

Letto il 30 ottobre 2026, salvo dove una pagina stampa la propria data di aggiornamento. Prezzi e nomi dei piani sono omessi perché cambiano.

- [Documentazione di GitHub Spec Kit (pagina datata 28 settembre 2026)](https://github.github.io/spec-kit/)
- [Spec Kit — Riferimento SDD agentico](https://github.github.io/spec-kit/reference/agentic-sdd.html)
- [Spec Kit — Guida di aggiornamento (percorsi specs/)](https://github.github.io/spec-kit/upgrade.html)
- [github/spec-kit — licenza MIT](https://github.com/github/spec-kit/blob/main/LICENSE)
- [Fission-AI/OpenSpec — README](https://github.com/Fission-AI/OpenSpec/blob/main/README.md)
- [Riferimento della CLI OpenSpec — openspec validate](https://openspec.dev/docs/cli)
- [Fission-AI/OpenSpec — licenza MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE)
- [Documentazione Kiro — specifiche di funzionalità ed EARS (aggiornata il 4 agosto 2026)](https://kiro.dev/docs/specs/feature-specs/)
- [Kiro — Licenza](https://kiro.dev/license/)
- [Documentazione Tessl — Che cos’è Tessl?](https://docs.tessl.io/)
- [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile)
- [Tile Tessl di sviluppo guidato dalle specifiche — licenza 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 — licenza 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 con Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE)
- [CodeSpeak](https://codespeak.dev/)
- [CodeSpeak — Termini di servizio (in vigore il 3 marzo 2026)](https://codespeak.dev/terms-of-service)
- [Arcanada-one/datarim — README (badge 4.9.0)](https://github.com/Arcanada-one/datarim)
- [Datarim — licenza 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 — skill /score (valutazione manuale di IA)](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)