Flusso di lavoro OPSX
Feedback benvenuti su Discord.
Cos'è?
OPSX è ora l'flusso di lavoro standard per OpenSpec.
È un flusso di lavoro fluido e iterativo per le modifiche di OpenSpec. Niente più fasi rigide — solo azioni che puoi eseguire in qualsiasi momento.
Perché esiste questo strumento
Il flusso di lavoro legacy di OpenSpec funziona, ma è bloccato:
- Le istruzioni sono hardcoded — nascoste nel codice TypeScript, non puoi modificarle
- Tutto o nulla — un unico comando grande crea tutto, non è possibile testare i singoli componenti
- Struttura fissa — lo stesso flusso di lavoro per tutti, nessuna personalizzazione
- Scatola nera — quando l'output dell'IA è scadente, non puoi modificare i prompt
OPSX apre le porte. Ora chiunque può:
- Sperimentare con le istruzioni — modificare un template e vedere se l'IA performa meglio
- Testare in modo granulare — convalidare le istruzioni di ogni artefatto indipendentemente
- Personalizzare i flussi di lavoro — definire i propri artefatti e dipendenze
- Iterare rapidamente — cambiare un template, testare immediatamente, senza ricompilazione
Flusso di lavoro legacy: OPSX:
┌────────────────────────┐ ┌────────────────────────┐
│ Hardcoded nel package │ │ schema.yaml │◄── Modifichi questo
│ (non modificabile) │ │ templates/*.md │◄── O questo
│ ↓ │ │ ↓ │
│ Attendi nuova release │ │ Effetto immediato │
│ ↓ │ │ ↓ │
│ Sperare che sia │ │ Testalo tu stesso │
│ migliore │ │ │
└────────────────────────┘ └────────────────────────┘Questo è per tutti:
- Team — creare flussi di lavoro che corrispondano al vostro modo effettivo di lavorare
- Utenti avanzati — ottimizzare i prompt per ottenere output migliori dall'IA per il vostro codebase
- Contributori di OpenSpec — sperimentare nuovi approcci senza dover attendere nuove release
Stiamo ancora imparando tutti cosa funziona meglio. OPSX ci permette di imparare insieme.
L'esperienza utente
Il problema dei flussi di lavoro lineari: Ti trovi "in fase di pianificazione", poi "in fase di implementazione", infine "finito". Ma il lavoro reale non funziona così. Implementi qualcosa, ti rendi conto che il tuo design era sbagliato, devi aggiornare le specifiche, continui a implementare. Le fasi lineari vanno contro il modo in cui il lavoro avviene realmente.
Approccio OPSX:
- Azioni, non fasi — creare, implementare, aggiornare, archiviare — esegui qualsiasi azione in qualsiasi momento
- Le dipendenze sono abilitatori — mostrano cosa è possibile, non cosa è richiesto come prossimo passo
proposal ──→ specs ──→ design ──→ tasks ──→ implementInstallazione
# Assicurati di avere openspec installato — le skills vengono generate automaticamente
openspec initQuesto crea le skills in .claude/skills/ (o equivalente) che gli assistenti di codifica IA rilevano automaticamente.
Di default, OpenSpec utilizza il profilo del flusso di lavoro core (propose, explore, apply, update, sync, archive). Se desideri i comandi del flusso di lavoro esteso (new, continue, ff, verify, bulk-archive, onboard), configurali con openspec config profile e applicali con openspec update.
Durante la configurazione, ti verrà chiesto di creare una configurazione del progetto (openspec/config.yaml). È opzionale ma raccomandata.
Configurazione del Progetto
La configurazione del progetto ti permette di impostare valori predefiniti e iniettare contesto specifico del progetto in tutti gli artefatti.
Creazione della Configurazione
La configurazione viene creata durante openspec init, oppure manualmente:
# openspec/config.yaml
schema: spec-driven
context: |
Tech stack: TypeScript, React, Node.js
API conventions: RESTful, JSON responses
Testing: Vitest for unit tests, Playwright for e2e
Style: ESLint with Prettier, strict TypeScript
rules:
proposal:
- Include rollback plan
- Identify affected teams
specs:
- Use Given/When/Then format for scenarios
design:
- Include sequence diagrams for complex flowsCampi della Configurazione
| Campo | Tipo | Descrizione |
|---|---|---|
schema | stringa | Schema predefinito per le nuove modifiche (es. spec-driven) |
context | stringa | Contesto del progetto iniettato nelle istruzioni di tutti gli artefatti |
rules | oggetto | Regole per artefatto, indicizzate per ID dell'artefatto |
Come Funziona
Precedenza dello schema (dal più alto al più basso):
- Flag CLI (
--schema <nome>) - Metadati della modifica (
.openspec.yamlnella directory della modifica) - Configurazione del progetto (
openspec/config.yaml) - Predefinito (
spec-driven)
Iniezione del contesto:
- Il contesto viene aggiunto all'inizio delle istruzioni di ogni artefatto
- Avvolto nei tag
<context>...</context> - Aiuta l'IA a comprendere le convenzioni del tuo progetto
Iniezione delle regole:
- Le regole vengono iniettate solo per gli artefatti corrispondenti
- Avvolte nei tag
<rules>...</rules> - Appaiono dopo il contesto, prima del template
ID degli Artefatti per Schema
spec-driven (predefinito):
proposal— Proposta di modificaspecs— Specifichedesign— Design tecnicotasks— Attività di implementazione
Validazione della Configurazione
- Gli ID degli artefatti sconosciuti in
rulesgenerano avvisi - I nomi degli schema vengono validati rispetto agli schema disponibili
- Il contesto ha un limite di dimensione di 50KB
- YAML non valido viene segnalato con i numeri di riga
Risoluzione dei Problemi
"Unknown artifact ID in rules: X"
- Verifica che gli ID degli artefatti corrispondano al tuo schema (vedi lista sopra)
- Esegui
openspec schemas --jsonper vedere gli ID degli artefatti per ogni schema
Configurazione non applicata:
- Assicurati che il file si trovi in
openspec/config.yaml(non.yml) - Controlla la sintassi YAML con un validatore
- Le modifiche alla configurazione hanno effetto immediato (nessun riavvio necessario)
Contesto troppo grande:
- Il contesto è limitato a 50KB
- Riassumi o fai riferimento a documenti esterni invece di includerli direttamente
Comandi
| Comando | Cosa fa |
|---|---|
/opsx:propose | Crea una modifica e genera gli artefatti di pianificazione in un unico passaggio (percorso rapido predefinito) |
/opsx:explore | Analizza idee, indaga problemi, chiarisce i requisiti |
/opsx:new | Avvia un nuovo scaffold di modifica (flusso di lavoro esteso) |
/opsx:continue | Crea l'artefatto successivo (flusso di lavoro esteso) |
/opsx:ff | Avanza rapidamente gli artefatti di pianificazione (flusso di lavoro esteso) |
/opsx:apply | Implementa le attività, aggiornando gli artefatti se necessario |
/opsx:update | Rivede gli artefatti di pianificazione di una modifica e li mantiene coerenti |
/opsx:verify | Convalida l'implementazione contro gli artefatti (flusso di lavoro esteso) |
/opsx:sync | Unisce le delta specs nelle specs principali (opzionale) |
/opsx:archive | Archivia quando hai finito |
/opsx:bulk-archive | Archivia multiple modifiche completate (flusso di lavoro esteso) |
/opsx:onboard | Guida attraverso un ciclo completo di modifica (flusso di lavoro esteso) |
Utilizzo
Esplorare un'idea
/opsx:exploreAnalizza idee, indaga problemi, confronta opzioni. Non richiede struttura — funge semplicemente da partner di pensiero. Quando le intuizioni si cristallizzano, passa a /opsx:propose (predefinito) o /opsx:new//opsx:ff (esteso).
Avviare una nuova modifica
/opsx:proposeCrea la modifica e genera gli artefatti di pianificazione necessari prima dell'implementazione.
Se hai abilitato i flussi di lavoro estesi, puoi invece utilizzare:
/opsx:new # solo scaffold
/opsx:continue # crea un artefatto alla volta
/opsx:ff # crea tutti gli artefatti di pianificazione contemporaneamenteCreare artefatti
/opsx:continueMostra cosa è pronto per essere creato in base alle dipendenze, quindi crea un singolo artefatto. Utilizzalo ripetutamente per costruire la tua modifica in modo incrementale.
/opsx:ff add-dark-modeCrea tutti gli artefatti di pianificazione contemporaneamente. Utilizzalo quando hai un quadro chiaro di ciò che stai costruendo.
Implementare (la parte fluida)
/opsx:applyLavora attraverso le attività, spuntandole man mano che procedi. Se stai gestendo più modifiche contemporaneamente, puoi eseguire /opsx:apply <nome>; altrimenti dovrebbe inferire dal contesto della conversazione e chiederti di scegliere se non riesce a determinare quale modifica intendi.
Aggiornare una modifica
/opsx:update add-dark-mode - we're storing the theme in a cookie nowRivede gli artefatti di pianificazione esistenti della modifica e li mantiene coerenti — in qualsiasi direzione (una modifica al design potrebbe ripercuotersi sulla proposta). Solo artefatti di pianificazione: non modifica mai il codice e non crea mai artefatti mancanti (questo è compito di /opsx:continue). Ogni modifica viene confermata da te prima. Se la modifica era già stata implementata, consiglia /opsx:apply affinché il codice si allinei con il piano rivisto. Se la tua revisione cambia l'intento della modifica, inizia da zero — vedi Quando aggiornare vs. iniziare da zero.
Sincronizzare le delta specs
/opsx:syncUnisce le delta specs della modifica corrente nelle tue openspec/specs/ principali senza archiviare — la modifica rimane attiva. Applica l'intera delta: un requisito sotto ## REMOVED viene eliminato dalla specifica principale e uno rinominato viene rititolato sul posto, mentre il contenuto non menzionato dalla delta viene lasciato intatto. La sincronizzazione è opzionale — l'archiviazione ti chiede di sincronizzare prima se non l'hai fatto. Utilizzala quando vuoi che le specifiche principali vengano aggiornate prima dell'archiviazione, quando una modifica parallela deve basarsi sulle specifiche appena aggiunte da questa, o quando vuoi rivedere la specifica principale unita prima dell'archiviazione.
Conclusione
/opsx:archive # Sposta nell'archivio quando hai finito (chiede di sincronizzare le specs se necessario)Quando aggiornare vs. iniziare da zero
Puoi sempre modificare la tua proposta o le specifiche prima dell'implementazione. Ma quando il raffinamento diventa "questo è lavoro diverso"?
Cosa Cattura una Proposta
Una definizione propone tre cose:
- Intento — Quale problema stai risolvendo?
- Ambito — Cosa rientra/esce dai confini?
- Approccio — Come lo risolverai?
La domanda è: cosa è cambiato, e in che misura?
Aggiorna la Modifica Esistente Quando:
Stesso intento, esecuzione raffinata
- Scopri casi limite che non avevi considerato
- L'approccio necessita di regolazioni ma l'obiettivo rimane invariato
- L'implementazione rivela che il design era leggermente errato
L'ambito si restringe
- Ti rendi conto che l'ambito completo è troppo ampio e vuoi rilasciare prima l'MVP
- "Aggiungi modalità scura" → "Aggiungi interruttore modalità scura (preferenze di sistema nella v2)"
Correzioni guidate dall'apprendimento
- Il codebase non è strutturato come pensavi
- Una dipendenza non funziona come previsto
- "Usa variabili CSS" → "Usa invece il prefisso dark: di Tailwind"
Inizia una Nuova Modifica Quando:
L'intento è cambiato fondamentalmente
- Il problema stesso è diverso ora
- "Aggiungi modalità scura" → "Aggiungi sistema di temi completo con colori personalizzati, font, spaziatura"
L'ambito è esploso
- La modifica è cresciuta talmente tanto da essere essenzialmente lavoro diverso
- La proposta originale sarebbe irriconoscibile dopo gli aggiornamenti
- "Correggi bug login" → "Riscrivi sistema di autenticazione"
L'originale è completabile
- La modifica originale può essere marcata come "fatta"
- Il nuovo lavoro sta in piedi da solo, non è un raffinamento
- Completa "Aggiungi MVP modalità scura" → Archivia → Nuova modifica "Migliora modalità scura"
Le Euristiche
┌─────────────────────────────────────┐
│ È lo stesso lavoro? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Stesso intento? >50% sovrapposizione? L'originale
Stesso problema? Stesso ambito? può essere "fatto" senza
│ │ questi cambiamenti?
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
SI NO SI NO NO SI
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
AGGIORNA NUOVO AGGIORNA NUOVO AGGIORNA NUOVO| Test | Aggiorna | Nuova Modifica |
|---|---|---|
| Identità | "La stessa cosa, raffinata" | "Lavoro diverso" |
| Sovrapposizione dell'ambito | >50% sovrapposizione | <50% sovrapposizione |
| Completamento | Non può essere "fatto" senza i cambiamenti | Può finire l'originale, il nuovo lavoro sta in piedi da solo |
| Storia | La catena di aggiornamenti racconta una storia coerente | I patch confonderebbero più di quanto chiarirebbero |
Il Principio
Aggiornare preserva il contesto. Una nuova modifica fornisce chiarezza.
Scegli di aggiornare quando la storia del tuo pensiero è preziosa. Scegli di iniziare da zero quando ricominciare sarebbe più chiaro che applicare patch.
Pensala come i branch di git:
- Continua a fare commit mentre lavori sulla stessa funzionalità
- Inizia un nuovo branch quando si tratta di lavoro genuinamente nuovo
- A volte unisci una funzionalità parziale e ricomincia da zero per la fase 2
Cosa c'è di diverso?
Legacy (/openspec:proposal) | OPSX (/opsx:*) | |
|---|---|---|
| Struttura | Un unico grande documento di proposta | Artefatti discreti con dipendenze |
| Flusso di lavoro | Fasi lineari: pianificazione → implementazione → archiviazione | Azioni fluide — fai qualsiasi cosa in qualsiasi momento |
| Iterazione | Scomodo tornare indietro | Aggiorna gli artefatti man mano che impari |
| Personalizzazione | Struttura fissa | Guidato da schema (definisci i tuoi artefatti) |
Il punto chiave: il lavoro non è lineare. OPSX smette di fingere che lo sia.
Approfondimento sull'Architettura
Questa sezione spiega come funziona OPSX dietro le quinte e come si confronta con il flusso di lavoro legacy. Gli esempi in questa sezione utilizzano il set di comandi esteso (new, continue, ecc.); gli utenti core predefiniti possono mappare lo stesso flusso su propose → apply → sync → archive.
Filosofia: Fasi vs Azioni
┌─────────────────────────────────────────────────────────────────────────────────┐
│ FLUSSO DI LAVORO LEGACY │
│ (Bloccato per fasi, tutto o niente) │
├─────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ PIANIFICAZIONE│ ───► │ IMPLEMENTAZIONE│ ───► │ ARCHIVIAZIONE│ │
│ │ FASE │ │ FASE │ │ FASE │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ /openspec:proposal /openspec:apply /openspec:archive │
│ │
│ • Crea TUTTI gli artefatti in una volta │
│ • Non si può tornare indietro per aggiornare le specifiche durante l'implementazione│
│ • I gate di fase impongono una progressione lineare │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────────┐
│ FLUSSO DI LAVORO OPSX │
│ (Azioni fluide, Iterativo) │
├─────────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ AZIONI (non fasi) │ │
│ │ │ │
│ │ new ◄──► continue ◄──► apply ◄──► archive│ │
│ │ │ │ │ │ │ │
│ │ └──────────┴───────────┴───────────┘ │ │
│ │ qualsiasi ordine │ │
│ └────────────────────────────────────────────┘ │
│ │
│ • Crea artefatti uno alla volta OPPURE avanza velocemente │
│ • Aggiorna specifiche/design/attività durante l'implementazione │
│ • Le dipendenze abilitano il progresso, le fasi non esistono │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘Architettura dei Componenti
Il flusso di lavoro legacy utilizza template cablati in TypeScript:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ COMPONENTI LEGACY WORKFLOW │
├─────────────────────────────────────────────────────────────────────────────────┤
│ │
│ Template cablati (stringhe TypeScript) │
│ │ │
│ ▼ │
│ Configuratori/adattatori specifici per lo strumento │
│ │ │
│ ▼ │
│ File di comandi generati (.claude/commands/openspec/*.md) │
│ │
│ • Struttura fissa, nessuna consapevolezza degli artefatti │
│ • Le modifiche richiedono modifica del codice + rebuild │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘OPSX utilizza schemi esterni e un motore a grafo delle dipendenze:
┌─────────────────────────────────────────────────────────────────────────────────┐
│ COMPONENTI OPSX │
├─────────────────────────────────────────────────────────────────────────────────┤
│ │
│ Definizioni Schema (YAML) │
│ ┌─────────────────────────────────────────────────────────────────────────┐ │
│ │ name: spec-driven │ │
│ │ artifacts: │ │
│ │ - id: proposal │ │
│ │ generates: proposal.md │ │
│ │ requires: [] ◄── Dipendenze │ │
│ │ - id: specs │ │
│ │ generates: specs/**/*.md ◄── Pattern glob │ │
│ │ requires: [proposal] ◄── Abilita dopo la proposta │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Motore del Grafo degli Artefatti │
│ ┌─────────────────────────────────────────────────────────────────────────┐ │
│ │ • Ordinamento topologico (ordinamento delle dipendenze) │ │
│ │ • Rilevamento stato (esistenza nel filesystem) │ │
│ │ • Generazione di istruzioni ricche (template + contesto) │ │
│ └─────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ File Skill (.claude/skills/openspec-*/SKILL.md) │
│ │
│ • Compatibile con più editor (Claude Code, Cursor, Devin) │
│ • Le skill interrogano la CLI per dati strutturati │
│ • Completamente personalizzabile tramite file di schema │
│ │
└─────────────────────────────────────────────────────────────────────────────────┘Modello del Grafo delle Dipendenze
Gli artefatti formano un grafo aciclico diretto (DAG). Le dipendenze sono abilitanti, non cancelli:
proposal
(nodo radice)
│
┌─────────────┴─────────────┐
│ │
▼ ▼
specs design
(richiede: (richiede:
proposal) proposal)
│ │
└─────────────┬─────────────┘
│
▼
tasks
(richiede:
specs, design)
│
▼
┌──────────────┐
│ FASE APPLY │
│ (richiede: │
│ tasks) │
└──────────────┘Transizioni di stato:
BLOCCATO ────────────────► PRONTO ────────────────► COMPLETATO
│ │ │
│ │ │
Dipendenze Tutte le dip. Il file esiste
mancanti sono COMPLETATE nel filesystemFlusso delle Informazioni
Flusso di lavoro legacy — l'agente riceve istruzioni statiche:
Utente: "/openspec:proposal"
│
▼
┌─────────────────────────────────────────┐
│ Istruzioni statiche: │
│ • Crea proposal.md │
│ • Crea tasks.md │
│ • Crea design.md │
│ • Crea file di specifiche delta │
│ │
│ Nessuna consapevolezza di ciò che esiste│
│ o delle dipendenze tra artefatti │
└─────────────────────────────────────────┘
│
▼
L'agente crea TUTTI gli artefatti in una voltaOPSX — l'agente interroga per ottenere un contesto ricco:
Utente: "/opsx:continue"
│
▼
┌──────────────────────────────────────────────────────────────────────────┐
│ Passaggio 1: Interroga lo stato corrente │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec status --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "artifacts": [ │ │
│ │ {"id": "proposal", "status": "done"}, │ │
│ │ {"id": "specs", "status": "ready"}, ◄── Primo pronto │ │
│ │ {"id": "design", "status": "ready"}, │ │
│ │ {"id": "tasks", "status": "blocked", │ │
│ │ "missingDeps": ["specs", "design"]} │ │
│ │ ] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ Passaggio 2: Ottieni istruzioni ricche per l'artefatto pronto │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec instructions specs --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "template": "# Specifica\n\n## REQUISITI AGGIUNTI...", │ │
│ │ "dependencies": [{"id": "proposal", "path": "...", "done": true}│ │
│ │ "unlocks": ["tasks"] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ Passaggio 3: Leggi le dipendenze → Crea UN artefatto → Mostra cosa viene│
│ sbloccato │
└──────────────────────────────────────────────────────────────────────────┘Modello di Iterazione
Flusso di lavoro legacy — scomodo per iterare:
┌─────────┐ ┌─────────┐ ┌─────────┐
│/proposal│ ──► │ /apply │ ──► │/archive │
└─────────┘ └─────────┘ └─────────┘
│ │
│ ├── "Aspetta, il design è sbagliato"
│ │
│ ├── Opzioni:
│ │ • Modifica manualmente i file (rompe il contesto)
│ │ • Abbandona e ricomincia
│ │ • Vai avanti e sistema dopo
│ │
│ └── Nessun meccanismo ufficiale per "tornare indietro"
│
└── Crea TUTTI gli artefatti in una voltaOPSX — iterazione naturale:
/opsx:new ───► /opsx:continue ───► /opsx:apply ───► /opsx:archive
│ │ │
│ │ ├── "Il design è sbagliato"
│ │ │
│ │ ▼
│ │ Basta modificare design.md
│ │ e continuare!
│ │ │
│ │ ▼
│ │ /opsx:apply riprende
│ │ da dove hai lasciato
│ │
│ └── Crea UN artefatto, mostra cosa viene sbloccato
│
└── Predispone la modifica, attende indicazioniSchemi Personalizzati
Crea flussi di lavoro personalizzati usando i comandi di gestione schema:
# Crea un nuovo schema da zero (interattivo)
openspec schema init my-workflow
# Oppure deriva uno schema esistente come punto di partenza
openspec schema fork spec-driven my-workflow
# Convalida la struttura del tuo schema
openspec schema validate my-workflow
# Vedi da dove viene risolto uno schema (utile per il debug)
openspec schema which my-workflowGli schemi sono memorizzati in openspec/schemas/ (locale al progetto, versionato) o in ~/.local/share/openspec/schemas/ (globale per l'utente).
Struttura dello schema:
openspec/schemas/research-first/
├── schema.yaml
└── templates/
├── research.md
├── proposal.md
└── tasks.mdEsempio di schema.yaml:
name: research-first
artifacts:
- id: research # Aggiunto prima del proposal
generates: research.md
requires: []
- id: proposal
generates: proposal.md
requires: [research] # Ora dipende da research
- id: tasks
generates: tasks.md
requires: [proposal]Grafo delle dipendenze:
research ──► proposal ──► tasksRiepilogo
| Aspetto | Legacy | OPSX |
|---|---|---|
| Template | TypeScript cablato | YAML + Markdown esterni |
| Dipendenze | Nessuna (tutto insieme) | DAG con ordinamento topologico |
| Stato | Modello mentale basato su fasi | Esistenza su filesystem |
| Personalizzazione | Modifica sorgente, rebuild | Crea schema.yaml |
| Iterazione | Bloccato per fasi | Fluida, modifica qualsiasi cosa |
| Supporto editor | Configuratore/adattatori specifici per lo strumento | Singola directory skills |
Schemi
Gli schemi definiscono quali artefatti esistono e le loro dipendenze. Attualmente disponibili:
- spec-driven (predefinito): proposal → specs → design → tasks
# Elenca gli schemi disponibili
openspec schemas
# Visualizza tutti gli schemi con le rispettive fonti di risoluzione
openspec schema which --all
# Crea un nuovo schema in modo interattivo
openspec schema init my-workflow
# Fork di uno schema esistente per personalizzazione
openspec schema fork spec-driven my-workflow
# Convalida l struttura dello schema prima dell'uso
openspec schema validate my-workflowSuggerimenti
- Usa
/opsx:exploreper riflettere su un'idea prima di impegnarti in una modifica /opsx:ffquando sai cosa vuoi,/opsx:continuequando stai esplorando- Durante l'esecuzione di
/opsx:apply, se qualcosa non va — correggi l'artefatto, poi continua - I task tracciano i progressi tramite caselle di controllo in
tasks.md - Controlla lo stato in qualsiasi momento:
openspec status --change "name"
Feedback
Questo è ancora grezzo. È intenzionale — stiamo imparando cosa funziona.
Hai trovato un bug? Hai idee? Unisciti a noi su Discord o apri un issue su GitHub.