Commandes

Voici la référence des commandes slash d'OpenSpec. Ces commandes sont invoquées dans l'interface de chat de votre assistant de codage IA (par exemple, Claude Code, Cursor, Devin Desktop).

Pour les modèles de flux de travail et le moment où utiliser chaque commande, consultez Workflows. Pour les commandes CLI, consultez CLI.

Ces pages utilisent /opsx:<command> comme nom canonique. Certains outils l'épellent différemment — Cursor et GitHub Copilot enregistrent /opsx-propose, Codex utilise $openspec-propose — consultez donc How To Invoke pour votre outil. Les fichiers générés par OpenSpec utilisent déjà la forme correcte.

Référence rapide

Chemin rapide par défaut (profil `core`)

Commande	Objectif
`/opsx:propose`	Créer un changement et générer les artefacts de planification en une seule étape
`/opsx:explore`	Réfléchir aux idées avant de s'engager sur un changement
`/opsx:apply`	Implémenter les tâches du changement
`/opsx:update`	Réviser les artefacts de planification d'un changement et les garder cohérents
`/opsx:sync`	Fusionner les spécifications delta dans les spécifications principales
`/opsx:archive`	Archiver un changement terminé

Commandes de flux de travail étendu (sélection de flux de travail personnalisé)

Commande	Objectif
`/opsx:new`	Démarrer une nouvelle structure de changement
`/opsx:continue`	Créer l'artefact suivant en fonction des dépendances
`/opsx:ff`	Avance rapide : créer tous les artefacts de planification d'un coup
`/opsx:verify`	Valider que l'implémentation correspond aux artefacts
`/opsx:bulk-archive`	Archiver plusieurs changements d'un coup
`/opsx:onboard`	Tutoriel guidé à travers le flux de travail complet

Le profil global par défaut est core. Pour activer les commandes de flux de travail étendu, exécutez openspec config profile, sélectionnez les flux de travail, puis exécutez openspec update dans votre projet.

Référence des commandes

`/opsx:propose`

Créer un nouveau changement et générer les artefacts de planification en une seule étape. C'est la commande de démarrage par défaut dans le profil core.

Syntaxe :

text

/opsx:propose [nom-ou-description-du-changement]

Arguments :

Argument	Requis	Description
`nom-ou-description-du-changement`	Non	Nom en kebab-case ou description du changement en langage naturel

Ce qu'il fait :

Crée openspec/changes/<nom-du-changement>/
Génère les artefacts nécessaires avant l'implémentation (pour spec-driven : proposition, specs, conception, tâches)
S'arrête lorsque le changement est prêt pour /opsx:apply

Exemple :

text

Vous : /opsx:propose add-dark-mode

IA :  Créé openspec/changes/add-dark-mode/
     ✓ proposal.md
     ✓ specs/ui/spec.md
     ✓ design.md
     ✓ tasks.md
     Prêt pour l'implémentation. Exécutez /opsx:apply.

Conseils :

Utilisez cette commande pour le chemin le plus rapide de bout en bout
Si vous souhaitez un contrôle étape par étape des artefacts, activez les workflows étendus et utilisez /opsx:new + /opsx:continue

`/opsx:explore`

Commencez ici lorsque vous n'êtes pas sûr. Explorer est un partenaire de réflexion sans risque : il lit votre base de code, compare les options et affine une idée floue en un plan concret avant qu'un changement n'existe. Il est inclus dans le profil par défaut. Pour le cas complet et plus d'exemples, consultez le guide Explorer d'abord.

Réfléchir à des idées, enquêter sur des problèmes et clarifier les exigences avant de s'engager dans un changement.

Syntaxe :

/opsx:explore [sujet]

Arguments :

Argument	Requis	Description
`sujet`	Non	Ce que vous voulez explorer ou investiguer

Ce qu'il fait :

Ouvre une conversation exploratoire sans structure requise
Enquête sur la base de code pour répondre à des questions
Compare les options et les approches
Crée des diagrammes visuels pour clarifier la réflexion
Peut passer à /opsx:propose (par défaut) ou /opsx:new (workflow étendu) lorsque des idées se concrétisent

Exemple :

text

Vous : /opsx:explore

IA :  Qu'aimeriez-vous explorer ?

Vous : Comment devrions-nous gérer l'authentification pour l'application mobile ?

IA :  Laissez-moi enquêter sur votre configuration d'authentification actuelle...
     [Analyse la base de code]

     Je vois que vous utilisez l'authentification par session pour l'application web.
     Pour mobile, nous avons trois options principales :

     1. Jetons JWT (sans état, fonctionne hors ligne)
     2. OAuth2 (si vous avez besoin d'une connexion tierce)
     3. Étendre les sessions actuelles (plus simple, mais nécessite une connexion)

     Votre API a déjà CORS configuré. Quelle direction vous intéresse ?

Vous : Allons avec JWT. Pouvez-vous démarrer un changement pour cela ?

IA :  Prêt quand vous l'êtes. Exécutez /opsx:propose add-jwt-auth pour commencer.

Conseils :

Utilisez cette commande lorsque les exigences sont floues ou que vous avez besoin d'enquêter
Aucun artefact n'est créé pendant l'exploration
Utile pour comparer plusieurs approches avant de décider
Peut lire des fichiers et rechercher dans la base de code

`/opsx:new`

Démarrer une nouvelle structure de changement. Crée le dossier de changement et attend que vous génériez les artefacts avec /opsx:continue ou /opsx:ff.

Cette commande fait partie de l'ensemble de workflows étendus (non inclus dans le profil core par défaut).

Syntaxe :

/opsx:new [nom-du-changement] [--schema <nom-schema>]

Arguments :

Argument	Requis	Description
`nom-du-changement`	Non	Nom du dossier de changement (invité si non fourni)
`--schema`	Non	Schéma de workflow à utiliser (défaut : depuis la configuration ou `spec-driven`)

Ce qu'il fait :

Crée le répertoire openspec/changes/<nom-du-changement>/
Crée le fichier de métadonnées .openspec.yaml dans le dossier de changement
Affiche le premier modèle d'artefact prêt à être créé
Invite à saisir le nom du changement et le schéma si non fournis

Ce qu'il crée :

openspec/changes/<nom-du-changement>/
└── .openspec.yaml    # Métadonnées du changement (schéma, date de création)

Exemple :

Vous : /opsx:new add-dark-mode

IA :  Créé openspec/changes/add-dark-mode/
     Schéma : spec-driven

     Prêt à créer : proposition
     Utilisez /opsx:continue pour le créer, ou /opsx:ff pour créer tous les artefacts.

Conseils :

Utilisez des noms descriptifs : add-feature, fix-bug, refactor-module
Évitez les noms génériques comme update, changes, wip
Le schéma peut également être défini dans la configuration du projet (openspec/config.yaml)

`/opsx:continue`

Créer l'artefact suivant dans la chaîne de dépendances. Il crée un artefact à la fois pour une progression incrémentale.

Syntaxe :

/opsx:continue [nom-du-changement]

Arguments :

Argument	Requis	Description
`nom-du-changement`	Non	Quel changement continuer (déduit du contexte si non fourni)

Ce qu'il fait :

Interroge le graphe de dépendances des artefacts
Affiche quels artefacts sont prêts vs bloqués
Crée le premier artefact prêt
Lit les fichiers de dépendances pour le contexte
Affiche ce qui devient disponible après la création

Exemple :

Vous : /opsx:continue

IA :  Changement : add-dark-mode

     Statut des artefacts :
     ✓ proposition    (terminé)
     ◆ specs          (prêt)
     ◆ conception     (prêt)
     ○ tâches         (bloqué - nécessite : specs, conception)

     Création des specs...

     [Lit proposal.md, crée les specs en fonction des exigences]

     ✓ Créé openspec/changes/add-dark-mode/specs/ui/spec.md

     Maintenant disponible : conception
     Exécutez /opsx:continue pour créer le prochain artefact.

Conseils :

Utilisez cette commande lorsque vous voulez examiner chaque artefact avant de continuer
Utile pour les changements complexes où vous voulez le contrôle
Plusieurs artefacts peuvent devenir prêts simultanément
Vous pouvez modifier les artefacts créés avant de continuer

`/opsx:ff`

Avance rapide dans la création des artefacts. Crée tous les artefacts de planification en une seule fois.

Syntaxe :

/opsx:ff [nom-du-changement]

Arguments :

Argument	Requis	Description
`nom-du-changement`	Non	Quel changement avancer rapidement (déduit du contexte si non fourni)

Ce qu'il fait :

Crée tous les artefacts dans l'ordre des dépendances
Suit la progression via une liste de tâches
S'arrête lorsque tous les artefacts apply-required sont terminés
Lit chaque dépendance avant de créer l'artefact suivant

Exemple :

Vous : /opsx:ff add-dark-mode

IA :  Avance rapide sur add-dark-mode...

     ✓ Création de proposal.md
     ✓ Création de specs/ui/spec.md
     ✓ Création de design.md
     ✓ Création de tasks.md

     Tous les artefacts de planification sont terminés !
     Prêt pour l'implémentation. Exécutez /opsx:apply pour commencer.

Conseils :

Utilisez cette commande lorsque vous avez une vision claire de ce que vous construisez
Plus rapide que /opsx:continue pour les changements simples
Vous pouvez toujours modifier les artefacts par la suite
Convient aux fonctionnalités petites à moyennes

`/opsx:apply`

Implémenter les tâches du changement. Parcourt la liste des tâches, écrit le code et coche les éléments.

Syntaxe :

/opsx:apply [nom-du-changement]

Arguments :

Argument	Requis	Description
`nom-du-changement`	Non	Quel changement implémenter (déduit du contexte si non fourni)

Ce qu'il fait :

Lit tasks.md et identifie les tâches incomplètes
Traite les tâches une par une
Écrit le code, crée des fichiers, exécute des tests si nécessaire
Marque les tâches comme terminées avec des cases à cocher [x]

Exemple :

Vous : /opsx:apply

IA :  Implémentation de add-dark-mode...

     Lecture de tasks.md :
     - [ ] 1.1 Créer ThemeContext
     - [ ] 1.2 Ajouter des propriétés CSS personnalisées
     - [ ] 1.3 Implémenter la persistance via localStorage

     Travail sur 1.1 : Créer ThemeContext...
     [Crée src/context/ThemeContext.tsx]

     ✓ 1.1 Terminé

     Travail sur 1.2 : Ajouter des propriétés CSS personnalisées...
     [Met à jour src/styles/globals.css]

     ✓ 1.2 Terminé
     ...

Conseils :

Peut reprendre là où vous vous êtes arrêté si interrompu
Utilisez-le pour des changements parallèles en spécifiant le nom du changement
L'état de complétion est suivi dans les cases à cocher de tasks.md

`/opsx:update`

Réviser les artefacts de planification existants d'un changement et les maintenir cohérents entre eux. Uniquement les artefacts de planification - ne modifie jamais le code.

Syntaxe :

text

/opsx:update [nom-du-changement]

Arguments :

Argument	Requis	Description
`nom-du-changement`	Non	Quel changement mettre à jour (déduit du contexte si non fourni)

Ce qu'il fait :

Lit les artefacts du changement via openspec status --change <nom> --json
Applique la révision demandée, ou examine les artefacts pour détecter des contradictions si vous n'en avez pas précisé
Réconcilie les autres artefacts existants dans n'importe quelle direction (une modification de conception peut se répercuter sur la proposition)
Confirme chaque modification avec vous avant d'écrire, un artefact à la fois
Termine en recommandant l'étape suivante : /opsx:continue (artefacts manquants), /opsx:apply (transposer un plan révisé dans le code), ou /opsx:archive (tout est terminé)

Exemple :

text

Vous : /opsx:update add-dark-mode - nous stockons maintenant le thème dans un cookie, plus dans localStorage

IA :  Lecture des artefacts de add-dark-mode...

     La conception référence localStorage à deux endroits ; la tâche 1.3
     couvre la persistance via localStorage ; la proposition ne mentionne pas le stockage.

     Révisions proposées :
     1. design.md - remplacer la décision localStorage par le stockage par cookie
     2. tasks.md - reformuler la tâche 1.3 pour la persistance par cookie

     Appliquer la révision 1 ? (design.md)

Conseils :

Il ne crée pas les artefacts manquants - c'est le rôle de /opsx:continue
Si le changement a déjà été implémenté, suivez avec /opsx:apply pour que le code corresponde au plan révisé
Si votre révision change l'intention du changement, commencez plutôt un nouveau changement (voir Quand mettre à jour vs. Commencer à nouveau)

`/opsx:verify`

Valider que l'implémentation correspond à vos artefacts de changement. Vérifie la complétude, l'exactitude et la cohérence.

Syntaxe :

/opsx:verify [nom-du-changement]

Arguments :

Argument	Requis	Description
`nom-du-changement`	Non	Quel changement vérifier (déduit du contexte si non fourni)

Ce qu'il fait :

Vérifie trois dimensions de la qualité de l'implémentation
Recherche des preuves d'implémentation dans la base de code
Signale les problèmes classés comme CRITIQUE, AVERTISSEMENT ou SUGGESTION
Ne bloque pas l'archivage, mais remonte les problèmes

Dimensions de vérification :

Dimension	Ce qu'elle valide
Complétude	Toutes les tâches terminées, toutes les exigences implémentées, scénarios couverts
Exactitude	L'implémentation correspond à l'intention des specs, cas limites traités
Cohérence	Les décisions de conception sont reflétées dans le code, modèles cohérents

Exemple :

Vous : /opsx:verify

IA :  Vérification de add-dark-mode...

     COMPLÉTUDE
     ✓ Toutes les 8 tâches dans tasks.md sont cochées
     ✓ Toutes les exigences dans les specs ont un code correspondant
     ⚠ Le scénario "Détection de préférence système" n'a pas de couverture de test

     EXACTITUDE
     ✓ L'implémentation correspond à l'intention des specs
     ✓ Les cas limites des scénarios sont traités
     ✓ Les états d'erreur correspondent aux définitions des specs

     COHÉRENCE
     ✓ Les décisions de conception sont reflétées dans la structure du code
     ✓ Les conventions de nommage sont cohérentes avec design.md
     ⚠ La conception mentionne "variables CSS" mais l'implémentation utilise des classes Tailwind

     RÉSUMÉ
     ─────────────────────────────
     Problèmes critiques : 0
     Avertissements : 2
     Prêt à archiver : Oui (avec avertissements)

     Recommandations :
     1. Ajouter un test pour la détection de préférence système
     2. Mettre à jour design.md pour refléter l'utilisation de Tailwind, ou refactoriser pour utiliser des variables CSS

Conseils :

Exécutez avant l'archivage pour détecter les écarts tôt
Les avertissements ne bloquent pas l'archivage mais indiquent des problèmes potentiels
Utile pour examiner le travail de l'IA avant de valider
Peut révéler une dérive entre les artefacts et l'implémentation

`/opsx:sync`

Commande facultative. Fusionner les specs delta d'un changement dans les specs principales. L'archivage demandera de synchroniser si nécessaire, donc vous n'avez généralement pas besoin de l'exécuter manuellement.

Syntaxe :

/opsx:sync [nom-du-changement]

Arguments :

Argument	Requis	Description
`nom-du-changement`	Non	Quel changement synchroniser (déduit du contexte si non fourni)

Ce qu'il fait :

Lit les specs delta du dossier de changement
Analyse les sections AJOUTÉ/MODIFIÉ/SUPPRIMÉ/RENOMMÉ
Fusionne les changements dans le répertoire principal openspec/specs/
Préserve le contenu existant non mentionné dans le delta
N'archive pas le changement (reste actif)

Exemple :

text

Vous : /opsx:sync

IA :  Synchronisation des specs delta de add-dark-mode...

     Lecture : openspec/changes/add-dark-mode/specs/ui/spec.md
     Cible :   openspec/specs/ui/spec.md

     Modifications à appliquer :
     ✓ AJOUTÉ : Exigence de sélection de thème (2 scénarios)
     ✓ AJOUTÉ : Exigence d'accessibilité (1 scénario)

     Fusion...
     ✓ openspec/specs/ui/spec.md mis à jour

     Le changement reste actif. Exécutez /opsx:archive lorsque vous êtes prêt à terminer.

Quand utiliser manuellement :

Scénario	Utiliser la synchronisation ?
Changement de longue durée, vous voulez les specs dans les specs principales avant l'archivage	Oui
Plusieurs changements parallèles nécessitent les specs de base mises à jour	Oui
Vous voulez prévisualiser/examiner la fusion séparément	Oui
Changement rapide, vous allez directement à l'archivage	Non (l'archivage s'en charge)

Conseils :

La synchronisation est intelligente, pas un copier-coller
Peut ajouter des scénarios à des exigences existantes sans duplication
Le changement reste actif après la synchronisation (non archivé)
La plupart des utilisateurs n'auront jamais besoin d'appeler directement cette commande - l'archivage propose si nécessaire

`/opsx:archive`

Archiver un changement terminé. Finalise le changement et le déplace dans le dossier d'archives.

Syntaxe :

/opsx:archive [nom-du-changement]

Arguments :

Argument	Requis	Description
`nom-du-changement`	Non	Quel changement archiver (déduit du contexte si non fourni)

Ce qu'il fait :

Vérifie l'état de complétion des artefacts
Vérifie la complétion des tâches (avertit si incomplet)
Propose de synchroniser les specs delta si ce n'est pas déjà fait
Déplace le dossier de changement vers openspec/changes/archive/AAAA-MM-JJ-<nom>/
Préserve tous les artefacts pour la traçabilité

Exemple :

text

Vous : /opsx:archive

IA :  Archivage de add-dark-mode...

     Statut des artefacts :
     ✓ proposal.md existe
     ✓ specs/ existe
     ✓ design.md existe
     ✓ tasks.md existe (8/8 tâches terminées)

     Specs delta : Pas encore synchronisées
     → Synchroniser maintenant ? (recommandé)

Vous : Oui

IA :  ✓ Specs synchronisées vers openspec/specs/ui/spec.md
     ✓ Déplacé vers openspec/changes/archive/2025-01-24-add-dark-mode/

     Changement archivé avec succès.

Conseils :

L'archivage ne bloque pas sur les tâches incomplètes, mais avertit
Les specs delta peuvent être synchronisées pendant l'archivage ou avant
Les changements archivés sont préservés pour l'historique
Utilisez /opsx:verify d'abord pour détecter les problèmes

`/opsx:bulk-archive`

Archiver plusieurs changements terminés en une seule fois. Gère les conflits de specs entre les changements.

Syntaxe :

/opsx:bulk-archive [noms-des-changements...]

Arguments :

Argument	Requis	Description
`noms-des-changements`	Non	Changements spécifiques à archiver (invite à sélectionner si non fournis)

Ce qu'il fait :

Liste tous les changements terminés
Valide chaque changement avant l'archivage
Détecte les conflits de specs entre les changements
Résout les conflits en vérifiant ce qui est réellement implémenté
Archive dans l'ordre chronologique

Exemple :

Vous : /opsx:bulk-archive

IA :  Trouvé 3 changements terminés :
     - add-dark-mode (8/8 tâches terminées)
     - fix-login-bug (3/3 tâches terminées)
     - update-footer (2/2 tâches terminées)

     Vérification des conflits de specs...
     ⚠ add-dark-mode et update-footer touchent tous deux specs/ui/

     Inspection de la base de code pour résoudre...
     Les deux changements sont implémentés. Fusion dans l'ordre chronologique :
     1. add-dark-mode (créé le 20 janvier)
     2. update-footer (créé le 22 janvier)

     Archiver les 3 changements ?

Vous : Oui

IA :  ✓ Archivé add-dark-mode
     ✓ Archivé fix-login-bug
     ✓ Archivé update-footer
     Specs fusionnées : add-dark-mode → update-footer

Conseils :

Utile pour les flux de travail parallèles
La résolution des conflits est agentique (vérifie la base de code)
Les changements sont archivés dans l'ordre de création
Invite avant d'écraser le contenu des specs

`/opsx:onboard`

Intégration guidée à travers le workflow complet OpenSpec. Un tutoriel interactif utilisant votre base de code réelle.

Syntaxe :

/opsx:onboard

Ce qu'il fait :

Parcourt un cycle de workflow complet avec narration
Analyse votre base de code pour trouver de réelles opportunités d'amélioration
Crée un changement réel avec de vrais artefacts
Implémente du travail réel (changements petits et sûrs)
Archive le changement terminé
Explique chaque étape au fur et à mesure

Phases :

Accueil et analyse de la base de code
Recherche d'une opportunité d'amélioration
Création d'un changement (/opsx:new)
Rédaction de la proposition
Création des specs
Rédaction de la conception
Création des tâches
Implémentation des tâches (/opsx:apply)
Vérification de l'implémentation
Archivage du changement
Résumé et prochaines étapes

Exemple :

Vous : /opsx:onboard

IA :  Bienvenue dans OpenSpec !

     Je vais vous guider à travers le workflow complet en utilisant votre base de code réelle.
     Nous allons trouver quelque chose de petit à améliorer, créer un changement approprié pour cela,
     l'implémenter, puis l'archiver.

     Laissez-moi analyser votre base de code pour trouver des opportunités...

     [Analyse la base de code]

     J'ai trouvé quelques choses sur lesquelles nous pourrions travailler :
     1. Ajouter la validation des entrées au formulaire de contact
     2. Améliorer les messages d'erreur dans le flux d'authentification
     3. Ajouter des états de chargement aux boutons asynchrones

     Qu'est-ce qui vous intéresse ? (ou suggérez autre chose)

Conseils :

Idéal pour les nouveaux utilisateurs qui apprennent le workflow
Utilise du code réel, pas des exemples jouets
Crée un vrai changement que vous pouvez conserver ou supprimer
Prend 15 à 30 minutes à compléter

Syntax des commandes par outil d'IA

Différents outils d'IA utilisent des syntaxes de commande légèrement différentes. Utilisez le format qui correspond à votre outil :

Fichier de commande de votre outil	Exemple de syntaxe	Outils exemples
`.../commands/opsx/<id>.*`	`/opsx:propose`, `/opsx:apply`	Claude Code, Gemini CLI, Crush
`.../opsx-<id>.*`	`/opsx-propose`, `/opsx-apply`	Cursor, Devin Desktop, Copilot (IDE), Trae, Oh My Pi
aucun — uniquement les compétences	`/openspec-propose`, `/openspec-apply-change`	CodeArts, ForgeCode, Hermes, MiniMax Code, Mistral Vibe, Zed Agent, `.agents` partagés
aucun — Kimi Code	`/skill:openspec-propose`	Kimi Code
aucun — Codex CLI	`$openspec-propose`	Codex

Devin Desktop vs Devin Local : les fichiers .devin/workflows/opsx-*.md fournissent à Devin Desktop /opsx-propose. Devin Local n'a pas de workflows — utilisez les compétences OpenSpec écrites dans .devin/skills/, par exemple /openspec-propose, qui fonctionnent sur les deux agents.

L'intention est la même pour tous les outils, mais la manière dont les commandes sont exposées peut varier selon l'intégration. Comment invoquer liste tous les outils pris en charge ; ce tableau ne montre que des exemples de chaque forme.

Remarque : Les commandes GitHub Copilot (.github/prompts/*.prompt.md) sont uniquement disponibles dans les extensions IDE (VS Code, JetBrains, Visual Studio). GitHub Copilot CLI ne prend actuellement pas en charge les fichiers de prompt personnalisés — voir Outils pris en charge pour plus de détails et des solutions de contournement.

Commandes héritées

Ces commandes utilisent l'ancien flux de travail « tout en une fois ». Elles fonctionnent toujours, mais les commandes OPSX sont recommandées.

Commande	Ce qu'elle fait
`/openspec:proposal`	Créer tous les artefacts en une seule fois (proposition, spécifications, conception, tâches)
`/openspec:apply`	Implémenter le changement
`/openspec:archive`	Archiver le changement

Quand utiliser les commandes héritées :

Projets existants utilisant l'ancien flux de travail
Changements simples où vous n'avez pas besoin de création incrémentale d'artefacts
Préférence pour l'approche tout ou rien

Migration vers OPSX : Les changements hérités peuvent être poursuivis avec les commandes OPSX. La structure des artefacts est compatible.

Dépannage

"Changement introuvable"

La commande n'a pas pu identifier quel changement traiter.

Solutions :

Spécifiez explicitement le nom du changement : /opsx:apply add-dark-mode
Vérifiez que le dossier du changement existe : openspec list
Vérifiez que vous êtes dans le bon répertoire de projet

"Aucun artefact prêt"

Tous les artefacts sont soit terminés, soit bloqués par des dépendances manquantes.

Solutions :

Exécutez openspec status --change <name> pour voir ce qui bloque
Vérifiez si les artefacts requis existent
Créez d'abord les artefacts de dépendance manquants

"Schéma introuvable"

Le schéma spécifié n'existe pas.

Solutions :

Liste des schémas disponibles : openspec schemas
Vérifiez l'orthographe du nom du schéma
Créez le schéma s'il est personnalisé : openspec schema init <name>

Commandes non reconnues

L'outil d'IA ne reconnaît pas les commandes OpenSpec.

Solutions :

Assurez-vous qu'OpenSpec est initialisé : openspec init
Régénérez les compétences : openspec update
Vérifiez que le répertoire .claude/skills/ existe (pour Claude Code)
Redémarrez votre outil d'IA pour prendre en compte les nouvelles compétences

Artefacts générés incorrectement

L'IA crée des artefacts incomplets ou incorrects.

Solutions :

Ajoutez du contexte de projet dans openspec/config.yaml
Ajoutez des règles par artefact pour des instructions spécifiques
Fournissez plus de détails dans votre description de changement
Utilisez /opsx:continue au lieu de /opsx:ff pour plus de contrôle

Prochaines étapes

Flux de travail - Modèles courants et moments appropriés pour utiliser chaque commande
CLI - Commandes terminal pour la gestion et la validation
Personnalisation - Créer des schémas et des flux de travail personnalisés

Commandes ​

Référence rapide ​

Chemin rapide par défaut (profil core) ​

Commandes de flux de travail étendu (sélection de flux de travail personnalisé) ​

Référence des commandes ​

/opsx:propose ​

/opsx:explore ​

/opsx:new ​

/opsx:continue ​

/opsx:ff ​

/opsx:apply ​

/opsx:update ​

/opsx:verify ​

/opsx:sync ​

/opsx:archive ​

/opsx:bulk-archive ​

/opsx:onboard ​

Syntax des commandes par outil d'IA ​

Commandes héritées ​

Dépannage ​

"Changement introuvable" ​

"Aucun artefact prêt" ​

"Schéma introuvable" ​

Commandes non reconnues ​

Artefacts générés incorrectement ​

Prochaines étapes ​

Commandes

Référence rapide

Chemin rapide par défaut (profil `core`)

Commandes de flux de travail étendu (sélection de flux de travail personnalisé)

Référence des commandes

`/opsx:propose`

`/opsx:explore`

`/opsx:new`

`/opsx:continue`

`/opsx:ff`

`/opsx:apply`

`/opsx:update`

`/opsx:verify`

`/opsx:sync`

`/opsx:archive`

`/opsx:bulk-archive`

`/opsx:onboard`

Syntax des commandes par outil d'IA

Commandes héritées

Dépannage

"Changement introuvable"

"Aucun artefact prêt"

"Schéma introuvable"

Commandes non reconnues

Artefacts générés incorrectement

Prochaines étapes