Flux de travail OPSX
Vos retours sont les bienvenus sur Discord.
Qu'est-ce que c'est ?
OPSX est désormais le flux de travail standard pour OpenSpec.
Il s'agit d'un flux de travail fluide et itératif pour les modifications d'OpenSpec. Plus de phases rigides — uniquement des actions que vous pouvez effectuer à tout moment.
Pourquoi cet outil existe
Le flux de travail OpenSpec legacy fonctionne, mais il est verrouillé :
- Les instructions sont codées en dur — enfouies dans le TypeScript, vous ne pouvez pas les modifier
- Tout ou rien — une seule commande crée tout, impossible de tester des éléments individuels
- Structure fixe — le même flux de travail pour tout le monde, aucune personnalisation
- Boîte noire — quand la sortie de l'IA est mauvaise, vous ne pouvez pas ajuster les prompts
OPSX l'ouvre. Désormais, n'importe qui peut :
- Expérimenter avec les instructions — modifier un modèle, voir si l'IA fait mieux
- Tester de manière granulaire — valider les instructions de chaque artefact indépendamment
- Personnaliser les flux de travail — définir vos propres artefacts et dépendances
- Itérer rapidement — modifier un modèle, tester immédiatement, sans recompiler
Legacy workflow: OPSX:
┌────────────────────────┐ ┌────────────────────────┐
│ Hardcoded in package │ │ schema.yaml │◄── Vous éditez ceci
│ (can't change) │ │ templates/*.md │◄── Ou ceci
│ ↓ │ │ ↓ │
│ Wait for new release │ │ Instant effect │
│ ↓ │ │ ↓ │
│ Hope it's better │ │ Test it yourself │
└────────────────────────┘ └────────────────────────┘C'est pour tout le monde :
- Équipes — créez des flux de travail adaptés à votre façon de travailler
- Utilisateurs avancés — ajustez les prompts pour obtenir de meilleures sorties IA pour votre base de code
- Contributeurs OpenSpec — expérimentez de nouvelles approches sans attendre de nouvelles versions
Nous sommes tous en train d'apprendre ce qui fonctionne le mieux. OPSX nous permet d'apprendre ensemble.
L'expérience utilisateur
Le problème des flux de travail linéaires : Vous êtes « en phase de planification », puis « en phase d'implémentation », puis « terminé ». Mais le travail réel ne fonctionne pas ainsi. Vous implémentez quelque chose, vous réalisez que votre conception était erronée, vous devez mettre à jour les spécifications, puis continuer l'implémentation. Les phases linéaires vont à l'encontre de la façon dont le travail se déroule réellement.
L'approche OPSX :
- Des actions, pas des phases — créer, implémenter, mettre à jour, archiver — faites n'importe laquelle à tout moment
- Les dépendances sont des facilitateurs — elles montrent ce qui est possible, pas ce qui est requis ensuite
proposal ──→ specs ──→ design ──→ tasks ──→ implementConfiguration
# Make sure you have openspec installed — skills are automatically generated
openspec initCela crée des compétences dans .claude/skills/ (ou équivalent) que les assistants de codage IA détectent automatiquement.
Par défaut, OpenSpec utilise le profil de flux de travail core (propose, explore, apply, update, sync, archive). Si vous souhaitez les commandes de flux de travail étendues (new, continue, ff, verify, bulk-archive, onboard), configurez-les avec openspec config profile et appliquez-les avec openspec update.
Pendant la configuration, on vous demandera de créer une configuration de projet (openspec/config.yaml). C'est facultatif mais recommandé.
Configuration du projet
La configuration du projet vous permet de définir des valeurs par défaut et d'injecter un contexte spécifique au projet dans tous les artefacts.
Création de la configuration
La configuration est créée pendant openspec init, ou manuellement :
# 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 flowsChamps de configuration
| Champ | Type | Description |
|---|---|---|
schema | string | Schéma par défaut pour les nouvelles modifications (ex. : spec-driven) |
context | string | Contexte du projet injecté dans toutes les instructions des artefacts |
rules | object | Règles par artefact, indexées par identifiant d'artefact |
Fonctionnement
Priorité des schémas (de la plus haute à la plus basse) :
- Option CLI (
--schema <name>) - Métadonnées de la modification (
.openspec.yamldans le répertoire de la modification) - Configuration du projet (
openspec/config.yaml) - Valeur par défaut (
spec-driven)
Injection du contexte :
- Le contexte est préfixé à toutes les instructions des artefacts
- Encapsulé dans des balises
<context>...</context> - Aide l'IA à comprendre les conventions de votre projet
Injection des règles :
- Les règles ne sont injectées que pour les artefacts correspondants
- Encapsulées dans des balises
<rules>...</rules> - Apparaissent après le contexte, avant le modèle
Identifiants d'artefacts par schéma
spec-driven (par défaut) :
proposal— Proposition de modificationspecs— Spécificationsdesign— Conception techniquetasks— Tâches d'implémentation
Validation de la configuration
- Les identifiants d'artefacts inconnus dans
rulesgénèrent des avertissements - Les noms de schémas sont validés par rapport aux schémas disponibles
- Le contexte a une limite de taille de 50 Ko
- Un YAML invalide est signalé avec les numéros de ligne
Dépannage
« Unknown artifact ID in rules: X »
- Vérifiez que les identifiants d'artefacts correspondent à votre schéma (voir la liste ci-dessus)
- Exécutez
openspec schemas --jsonpour voir les identifiants d'artefacts de chaque schéma
La configuration n'est pas appliquée :
- Assurez-vous que le fichier est situé à
openspec/config.yaml(et non.yml) - Vérifiez la syntaxe YAML avec un validateur
- Les modifications de configuration prennent effet immédiatement (aucun redémarrage nécessaire)
Contexte trop volumineux :
- Le contexte est limité à 50 Ko
- Résumez ou faites référence à des documents externes plutôt que de tout inclure
Commandes
| Commande | Fonction |
|---|---|
/opsx:propose | Crée une modification et génère les artefacts de planification en une étape (chemin rapide par défaut) |
/opsx:explore | Réfléchit à des idées, investigate des problèmes, clarifie les exigences |
/opsx:new | Démarre un nouveau squelette de modification (flux de travail étendu) |
/opsx:continue | Crée l'artefact suivant (flux de travail étendu) |
/opsx:ff | Fait avancer rapidement les artefacts de planification (flux de travail étendu) |
/opsx:apply | Implémente les tâches, en mettant à jour les artefacts au besoin |
/opsx:update | Révise les artefacts de planification d'une modification et les maintient cohérents |
/opsx:verify | Valide l'implémentation par rapport aux artefacts (flux de travail étendu) |
/opsx:sync | Fusionne les spécifications delta dans les spécifications principales (facultatif) |
/opsx:archive | Archive quand c'est terminé |
/opsx:bulk-archive | Archive plusieurs modifications terminées (flux de travail étendu) |
/opsx:onboard | Parcours guidé d'une modification de bout en bout (flux de travail étendu) |
Utilisation
Explorer une idée
/opsx:exploreRéfléchissez à des idées, investigatez des problèmes, comparez des options. Aucune structure requise — juste un partenaire de réflexion. Quand les insights se cristallisent, passez à /opsx:propose (par défaut) ou /opsx:new//opsx:ff (étendu).
Démarrer une nouvelle modification
/opsx:proposeCrée la modification et génère les artefacts de planification nécessaires avant l'implémentation.
Si vous avez activé les flux de travail étendus, vous pouvez utiliser à la place :
/opsx:new # squelette uniquement
/opsx:continue # créer un artefact à la fois
/opsx:ff # créer tous les artefacts de planification d'un coupCréer des artefacts
/opsx:continueAffiche ce qui est prêt à être créé en fonction des dépendances, puis crée un artefact. Utilisez-le de manière répétée pour construire votre modification progressivement.
/opsx:ff add-dark-modeCrée tous les artefacts de planification d'un coup. Utilisez-le quand vous avez une vision claire de ce que vous construisez.
Implémenter (la partie fluide)
/opsx:applyTraite les tâches en les cochant au fur et à mesure. Si vous gérez plusieurs modifications simultanément, vous pouvez exécuter /opsx:apply <name> ; sinon, il devrait l'inférer à partir de la conversation et vous demander de choisir s'il ne peut pas le déterminer.
Mettre à jour une modification
/opsx:update add-dark-mode - we're storing the theme in a cookie nowRévise les artefacts de planification existants de la modification et les maintient cohérents — dans n'importe quelle direction (une modification de conception peut remonter jusqu'à la proposition). Artefacts de planification uniquement : il ne modifie jamais le code, et il ne crée jamais d'artefacts manquants (c'est le rôle de /opsx:continue). Chaque modification est confirmée avec vous au préalable. Si la modification a déjà été implémentée, il recommande /opsx:apply pour que le code suive le plan révisé. Si votre révision change l'intention de la modification, commencez à neuf à la place — voir Quand mettre à jour vs. commencer à neuf.
Synchroniser les spécifications delta
/opsx:syncFusionne les spécifications delta de la modification actuelle dans vos openspec/specs/ principaux sans archiver — la modification reste active. Elle applique tout le delta : une exigence sous ## REMOVED est supprimée de la spécification principale et une renommée est retitrée sur place, tandis que le contenu que le delta ne mentionne pas reste inchangé. La synchronisation est facultative — l'archivage vous demande de synchroniser d'abord si vous ne l'avez pas fait. Utilisez-la quand vous voulez mettre à jour les spécifications principales avant l'archivage, quand une modification parallèle doit se baser sur des spécifications que celle-ci vient d'ajouter, ou quand vous voulez examiner la spécification principale fusionnée avant l'archivage.
Finaliser
/opsx:archive # Déplacer vers l'archive quand c'est terminé (demande de synchroniser les specs si nécessaire)Quand mettre à jour vs. commencer à neuf
Vous pouvez toujours modifier votre proposition ou vos spécifications avant l'implémentation. Mais quand le raffinement devient « c'est un travail différent » ?
Ce qu'une proposition capture
Une proposition définit trois choses :
- Intention — Quel problème résolvez-vous ?
- Portée — Qu'est-ce qui est inclus/exclu ?
- Approche — Comment allez-vous le résoudre ?
La question est : qu'est-ce qui a changé, et dans quelle mesure ?
Mettre à jour la modification existante quand :
Même intention, exécution raffinée
- Vous découvrez des cas limites que vous n'aviez pas considérés
- L'approche nécessite des ajustements mais l'objectif reste inchangé
- L'implémentation révèle que la conception était légèrement erronée
La portée se resserre
- Vous réalisez que la portée complète est trop grande, vous voulez livrer un MVP d'abord
- « Ajouter le mode sombre » → « Ajouter un bascule mode sombre (préférence système en v2) »
Corrections basées sur l'apprentissage
- La base de code n'est pas structurée comme vous le pensiez
- Une dépendance ne fonctionne pas comme prévu
- « Utiliser des variables CSS » → « Utiliser le préfixe dark: de Tailwind à la place »
Commencer une nouvelle modification quand :
L'intention a fondamentalement changé
- Le problème lui-même est différent maintenant
- « Ajouter le mode sombre » → « Ajouter un système de thèmes complet avec couleurs personnalisées, polices, espacements »
La portée a explosé
- La modification a tellement grandi qu'elle est essentiellement un travail différent
- La proposition originale serait méconnaissable après les mises à jour
- « Corriger le bug de connexion » → « Réécrire le système d'authentification »
L'original est complétable
- La modification originale peut être marquée « terminée »
- Le nouveau travail se tient seul, ce n'est pas un raffinement
- Terminer « Ajouter le mode sombre MVP » → Archiver → Nouvelle modification « Améliorer le mode sombre »
Les heuristiques
┌─────────────────────────────────────┐
│ Is this the same work? │
└──────────────┬──────────────────────┘
│
┌──────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Same intent? >50% overlap? Can original
Same problem? Same scope? be "done" without
│ │ these changes?
│ │ │
┌────────┴────────┐ ┌──────┴──────┐ ┌───────┴───────┐
│ │ │ │ │ │
YES NO YES NO NO YES
│ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼
UPDATE NEW UPDATE NEW UPDATE NEW| Test | Mettre à jour | Nouvelle modification |
|---|---|---|
| Identité | « Même chose, raffinée » | « Travail différent » |
| Chevauchement de portée | >50 % de chevauchement | <50 % de chevauchement |
| Complétion | Ne peut pas être « terminé » sans ces modifications | Peut terminer l'original, le nouveau travail se tient seul |
| Récit | La chaîne de mises à jour raconte une histoire cohérente | Les correctifs confondraient plus qu'ils n'éclairciraient |
Le principe
Mettre à jour préserve le contexte. Une nouvelle modification apporte de la clarté.
Choisissez la mise à jour quand l'historique de votre réflexion est précieux. Choisissez le neuf quand recommencer serait plus clair que de patcher.
Pensez-y comme aux branches git :
- Continuez à committer en travaillant sur la même fonctionnalité
- Démarrez une nouvelle branche quand c'est un travail réellement nouveau
- Parfois, fusionnez une fonctionnalité partielle et recommencez à neuf pour la phase 2
Qu'est-ce qui est différent ?
Legacy (/openspec:proposal) | OPSX (/opsx:*) | |
|---|---|---|
| Structure | Un seul document de proposition | Artefacts discrets avec dépendances |
| Workflow | Phases linéaires : planifier → implémenter → archiver | Actions fluides — faites n'importe quoi, à tout moment |
| Itération | Difficile de revenir en arrière | Mettez à jour les artefacts au fur et à mesure de vos apprentissages |
| Personnalisation | Structure fixe | Piloté par schéma (définissez vos propres artefacts) |
L'idée clé : le travail n'est pas linéaire. OPSX cesse de faire semblant qu'il l'est.
Analyse approfondie de l'architecture
Cette section explique le fonctionnement interne d'OPSX et la manière dont il se compare au flux de travail hérité (legacy). Les exemples de cette section utilisent l'ensemble de commandes étendu (new, continue, etc.) ; les utilisateurs par défaut de core peuvent mapper le même flux sur propose → apply → sync → archive.
Philosophie : Phases vs Actions
┌─────────────────────────────────────────────────────────────────────────────┐
│ FLUX DE TRAVAIL HÉRITÉ │
│ (Verrouillé par phase, Tout ou Rien) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ PLANIFICATION│ ───► │ IMPLÉMENTATION│ ───► │ ARCHIVAGE │ │
│ │ PHASE │ │ PHASE │ │ PHASE │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ /openspec:proposal /openspec:apply /openspec:archive │
│ │
│ • Crée TOUS les artefacts en une seule fois │
│ • Impossible de revenir en arrière pour mettre à jour les spécifications │
│ pendant l'implémentation │
│ • Les portes de phase imposent une progression linéaire │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ FLUX DE TRAVAIL OPSX │
│ (Actions fluides, Itératif) │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ ACTIONS (pas des phases) │ │
│ │ │ │
│ │ new ◄──► continue ◄──► apply ◄──► archive │ │
│ │ │ │ │ │ │ │
│ │ └──────────┴───────────┴───────────┘ │ │
│ │ dans n'importe quel ordre │ │
│ └────────────────────────────────────────────┘ │
│ │
│ • Créer les artefacts un par un ou accélérer le processus │
│ • Mettre à jour les spécifications/conception/tâches pendant │
│ l'implémentation │
│ • Les dépendances permettent la progression, les phases n'existent pas │
│ │
└─────────────────────────────────────────────────────────────────────────────┘Architecture des composants
Le flux de travail hérité utilise des modèles codés en dur en TypeScript :
┌─────────────────────────────────────────────────────────────────────────────┐
│ COMPOSANTS DU FLUX HÉRITÉ │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Modèles codés en dur (chaînes TypeScript) │
│ │ │
│ ▼ │
│ Configurateurs/adaptateurs spécifiques aux outils │
│ │ │
│ ▼ │
│ Fichiers de commande générés (.claude/commands/openspec/*.md) │
│ │
│ • Structure fixe, aucune conscience des artefacts │
│ • La modification nécessite une modification du code + recompilation │
│ │
└─────────────────────────────────────────────────────────────────────────────┘OPSX utilise des schémas externes et un moteur de graphe de dépendances :
┌─────────────────────────────────────────────────────────────────────────────┐
│ COMPOSANTS OPSX │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Définitions de schéma (YAML) │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ name: spec-driven │ │
│ │ artifacts: │ │
│ │ - id: proposal │ │
│ │ generates: proposal.md │ │
│ │ requires: [] ◄── Dépendances │ │
│ │ - id: specs │ │
│ │ generates: specs/**/*.md ◄── Motifs glob │ │
│ │ requires: [proposal] ◄── Activé après proposal │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Moteur de graphe d'artefacts │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ • Tri topologique (ordre des dépendances) │ │
│ │ • Détection d'état (existence sur le système de fichiers) │ │
│ │ • Génération riche d'instructions (modèles + contexte) │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Fichiers de compétences (.claude/skills/openspec-*/SKILL.md) │
│ │
│ • Compatibles multi-éditeurs (Claude Code, Cursor, Devin) │
│ • Les compétences interrogent l'CLI pour des données structurées │
│ • Entièrement personnalisable via les fichiers de schéma │
│ │
└─────────────────────────────────────────────────────────────────────────────┘Modèle de graphe de dépendances
Les artefacts forment un graphe acyclique dirigé (DAG). Les dépendances sont des activateurs, pas des portes :
proposal
(nœud racine)
│
┌─────────────┴─────────────┐
│ │
▼ ▼
specs design
(requiert: (requiert:
proposal) proposal)
│ │
└─────────────┬─────────────┘
│
▼
tasks
(requiert:
specs, design)
│
▼
┌──────────────┐
│ PHASE APPLY │
│ (requiert: │
│ tasks) │
└──────────────┘Transitions d'état :
BLOQUÉ ────────────────► PRÊT ────────────────► TERMINÉ
│ │ │
Dépendances Toutes les deps Le fichier existe
manquantes sont TERMINÉES sur le système de fichiersFlux d'information
Flux de travail hérité — l'agent reçoit des instructions statiques :
Utilisateur : "/openspec:proposal"
│
▼
┌─────────────────────────────────────────┐
│ Instructions statiques : │
│ • Créer proposal.md │
│ • Créer tasks.md │
│ • Créer design.md │
│ • Créer les fichiers delta spec │
│ │
│ Aucune conscience de ce qui existe ou │
│ des dépendances entre les artefacts │
└─────────────────────────────────────────┘
│
▼
L'agent crée TOUS les artefacts en une seule foisOPSX — l'agent interroge pour obtenir un contexte riche :
Utilisateur : "/opsx:continue"
│
▼
┌──────────────────────────────────────────────────────────────────────────┐
│ Étape 1 : Interroger l'état actuel │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec status --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "artifacts": [ │ │
│ │ {"id": "proposal", "status": "done"}, │ │
│ │ {"id": "specs", "status": "ready"}, ◄── Premier prêt │ │
│ │ {"id": "design", "status": "ready"}, │ │
│ │ {"id": "tasks", "status": "blocked", │ │
│ │ "missingDeps": ["specs", "design"]} │ │
│ │ ] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ Étape 2 : Obtenir des instructions riches pour l'artefact prêt │
│ ┌────────────────────────────────────────────────────────────────────┐ │
│ │ $ openspec instructions specs --change "add-auth" --json │ │
│ │ │ │
│ │ { │ │
│ │ "template": "# Spécification\n\n## Exigences AJOUTÉES...", │ │
│ │ "dependencies": [{"id": "proposal", "path": "...", "done": true}│ │
│ │ "unlocks": ["tasks"] │ │
│ │ } │ │
│ └────────────────────────────────────────────────────────────────────┘ │
│ │
│ Étape 3 : Lire les dépendances → Créer UN seul artefact → Afficher ce │
│ qui est débloqué │
└──────────────────────────────────────────────────────────────────────────┘Modèle d'itération
Flux de travail hérité — itération maladroite :
┌─────────┐ ┌─────────┐ ┌─────────┐
│/proposal│ ──► │ /apply │ ──► │/archive │
└─────────┘ └─────────┘ └─────────┘
│ │
│ ├── "Attendez, la conception est fausse"
│ │
│ ├── Options :
│ │ • Modifier les fichiers manuellement (brise le contexte)
│ │ • Abandonner et recommencer
│ │ • Continuer et corriger plus tard
│ │
│ └── Aucun mécanisme officiel pour "revenir en arrière"
│
└── Crée TOUS les artefacts en une seule foisOPSX — itération naturelle :
/opsx:new ───► /opsx:continue ───► /opsx:apply ───► /opsx:archive
│ │ │
│ │ ├── "La conception est fausse"
│ │ │
│ │ ▼
│ │ Il suffit de modifier design.md
│ │ et de continuer !
│ │ │
│ │ ▼
│ │ /opsx:apply reprend là où vous vous êtes arrêté
│ │
│ └── Crée UN seul artefact, montre ce qui est débloqué
│
└── Échafaude le changement, attend les directivesSchémas personnalisés
Créez des flux de travail personnalisés à l'aide des commandes de gestion des schémas :
# Créer un nouveau schéma à partir de zéro (interactif)
openspec schema init my-workflow
# Ou forker un schéma existant comme point de départ
openspec schema fork spec-driven my-workflow
# Valider la structure de votre schéma
openspec schema validate my-workflow
# Voir d'où provient la résolution d'un schéma (utile pour le débogage)
openspec schema which my-workflowLes schémas sont stockés dans openspec/schemas/ (local au projet, sous contrôle de version) ou ~/.local/share/openspec/schemas/ (global à l'utilisateur).
Structure du schéma :
openspec/schemas/research-first/
├── schema.yaml
└── templates/
├── research.md
├── proposal.md
└── tasks.mdExemple de schema.yaml :
name: research-first
artifacts:
- id: research # Ajouté avant proposal
generates: research.md
requires: []
- id: proposal
generates: proposal.md
requires: [research] # Dépend maintenant de research
- id: tasks
generates: tasks.md
requires: [proposal]Graphe de dépendances :
research ──► proposal ──► tasksRésumé
| Aspect | Hérité | OPSX |
|---|---|---|
| Modèles | TypeScript codé en dur | YAML externe + Markdown |
| Dépendances | Aucune (tout en une fois) | DAG avec tri topologique |
| État | Modèle mental basé sur les phases | Existence sur le système de fichiers |
| Personnalisation | Modifier la source, recompiler | Créer schema.yaml |
| Itération | Verrouillé par phase | Fluide, modifier n'importe quoi |
| Support éditeur | Configurateur/adaptateur spécifique à l'outil | Répertoire de compétences unique |
Schémas
Les schémas définissent les artefacts existants et leurs dépendances. Actuellement disponibles :
- spec-driven (par défaut) : proposal → specs → design → tasks
# Lister les schémas disponibles
openspec schemas
# Afficher tous les schémas avec leurs sources de résolution
openspec schema which --all
# Créer un nouveau schéma de manière interactive
openspec schema init my-workflow
# Cloner un schéma existant pour personnalisation
openspec schema fork spec-driven my-workflow
# Valider la structure du schéma avant utilisation
openspec schema validate my-workflowConseils
- Utilisez
/opsx:explorepour réfléchir à une idée avant de vous engager sur un changement /opsx:ffquand vous savez ce que vous voulez,/opsx:continuequand vous explorez- Pendant
/opsx:apply, si quelque chose ne va pas — corrigez l'artefact, puis continuez - Les tâches suivent les progrès via des cases à cocher dans
tasks.md - Vérifiez l'état à tout moment :
openspec status --change "name"
Retours
C'est encore brut. C'est volontaire — nous apprenons ce qui fonctionne.
Vous avez trouvé un bug ? Des idées ? Rejoignez-nous sur Discord ou ouvrez un ticket sur GitHub.