OPSX Workflow

Zapraszamy do dzielenia się opiniami na Discord.

Czym jest?

OPSX jest teraz standardowym workflow dla OpenSpec.

To płynny, iteracyjny workflow dla zmian w OpenSpec. Koniec z sztywnymi fazami — to po prostu akcje, które możesz wykonać w dowolnym momencie.

Dlaczego to istnieje

Dziedziczny przepływ pracy OpenSpec działa, ale jest zamknięty:

• Instrukcje są zaszyte w kodzie — ukryte w TypeScript, nie można ich zmienić
• Wszystko lub nic — jedna duża komenda tworzy wszystko, nie można testować poszczególnych elementów
• Sztywna struktura — ten sam przepływ pracy dla wszystkich, bez możliwości dostosowania
• Czarna skrzynka — gdy wynik AI jest słaby, nie można dostosować promptów

OPSX to otwiera. Teraz każdy może:

1. Eksperymentować z instrukcjami — edytować szablon i sprawdzić, czy AI daje lepsze wyniki
2. Testować szczegółowo — zweryfikować instrukcje każdego artefaktu niezależnie
3. Dostosowywać przepływy pracy — definiować własne artefakty i zależności
4. Szybko iterować — zmienić szablon, przetestować natychmiast, bez ponownej kompilacji

Legacy workflow:                      OPSX:
┌────────────────────────┐           ┌────────────────────────┐
│  Hardcoded in package  │           │  schema.yaml           │◄── You edit this
│  (can't change)        │           │  templates/*.md        │◄── Or this
│        ↓               │           │        ↓               │
│  Wait for new release  │           │  Instant effect        │
│        ↓               │           │        ↓               │
│  Hope it's better      │           │  Test it yourself      │
└────────────────────────┘           └────────────────────────┘

To jest dla każdego:

• Zespoły — twórzcie przepływy pracy dopasowane do tego, jak naprawdę pracujecie
• Zaawansowani użytkownicy — dostosowujcie prompty, aby uzyskać lepsze wyniki AI dla swojej bazy kodu
• Kontrybutorzy OpenSpec — eksperymentujcie z nowymi podejściami bez konieczności wydawania wersji

Wszyscy wciąż uczymy się, co działa najlepiej. OPSX pozwala nam się uczyć razem.

Doświadczenie użytkownika

Problem z liniowymi przepływami pracy: Jesteś „w fazie planowania", potem „w fazie implementacji", a potem „gotowe". Ale prawdziwa praca nie wygląda tak. Implementujesz coś, zauważasz, że projekt był błędny, musisz zaktualizować specyfikacje, kontynuować implementację. Liniowe fazy działają przeciwko temu, jak praca naprawdę przebiega.

Podejście OPSX:

• Akcje, nie fazy — twórz, implementuj, aktualizuj, archiwizuj — rób dowolną z nich w dowolnym momencie
• Zależności to ułatwienia — pokazują, co jest możliwe, a nie co jest wymagane jako następny krok

  proposal ──→ specs ──→ design ──→ tasks ──→ implement

Konfiguracja

# Make sure you have openspec installed — skills are automatically generated
openspec init

Tworzy to umiejętności w .claude/skills/ (lub odpowiedniku), które asystenci AI do kodowania wykrywają automatycznie.

Domyślnie OpenSpec używa profilu przepływu pracy core (propose, explore, apply, update, sync, archive). Jeśli chcesz rozszerzone komendy przepływu pracy (new, continue, ff, verify, bulk-archive, onboard), skonfiguruj je za pomocą openspec config profile i zastosuj przez openspec update.

Podczas konfiguracji zostaniesz poproszony o utworzenie konfiguracji projektu (openspec/config.yaml). Jest to opcjonalne, ale zalecane.

Konfiguracja projektu

Konfiguracja projektu pozwala ustawić wartości domyślne i wstrzykiwać kontekst specyficzny dla projektu do wszystkich artefaktów.

Tworzenie konfiguracji

Konfiguracja jest tworzona podczas openspec init, lub ręcznie:

# 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 flows

Pola konfiguracji

Pole	Typ	Opis
schema	string	Domyślny schemat dla nowych zmian (np. spec-driven)
context	string	Kontekst projektu wstrzykiwany do instrukcji wszystkich artefaktów
rules	object	Zasady per artefakt, kluczowane przez ID artefaktu

Jak to działa

Priorytet schematu (od najwyższego do najniższego):

1. Parametr CLI (--schema <name>)
2. Metadane zmiany (.openspec.yaml w katalogu zmiany)
3. Konfiguracja projektu (openspec/config.yaml)
4. Domyślny (spec-driven)

Wstrzykiwanie kontekstu:

• Kontekst jest dodawany na początku instrukcji każdego artefaktu
• Obejmowany znacznikami <context>...</context>
• Pomaga AI zrozumieć konwencje Twojego projektu

Wstrzykiwanie zasad:

• Zasady są wstrzykiwane tylko dla pasujących artefaktów
• Obejmowane znacznikami <rules>...</rules>
• Pojawiają się po kontekście, przed szablonem

ID artefaktów według schematu

spec-driven (domyślny):

• proposal — Propozycja zmiany
• specs — Specyfikacje
• design — Projekt techniczny
• tasks — Zadania implementacyjne

Walidacja konfiguracji

• Nieznane ID artefaktów w rules generują ostrzeżenia
• Nazwy schematów są walidowane względem dostępnych schematów
• Kontekst ma limit rozmiaru 50 KB
• Nieprawidłowy YAML jest raportowany z numerami linii

Rozwiązywanie problemów

„Unknown artifact ID in rules: X"

• Sprawdź, czy ID artefaktów odpowiadają Twojemu schematowi (patrz lista powyżej)
• Uruchom openspec schemas --json, aby zobaczyć ID artefaktów dla każdego schematu

Konfiguracja nie jest stosowana:

• Upewnij się, że plik znajduje się w openspec/config.yaml (nie .yml)
• Sprawdź składnię YAML za pomocą walidatora
• Zmiany konfiguracji wchodzą w życie natychmiast (nie wymaga to restartu)

Kontekst zbyt duży:

• Kontekst jest ograniczony do 50 KB
• Podsumuj lub odwołaj się do zewnętrznych dokumentów

Komendy

Komenda	Co robi
/opsx:propose	Tworzy zmianę i generuje artefakty planistyczne w jednym kroku (domyślna szybka ścieżka)
/opsx:explore	Rozważa pomysły, bada problemy, doprecyzowuje wymagania
/opsx:new	Rozpoczyna nowy szkielet zmiany (rozszerzony przepływ pracy)
/opsx:continue	Tworzy następny artefakt (rozszerzony przepływ pracy)
/opsx:ff	Szybko generuje wszystkie artefakty planistyczne (rozszerzony przepływ pracy)
/opsx:apply	Implementuje zadania, aktualizując artefakty w razie potrzeby
/opsx:update	Rewiduje artefakty planistyczne zmiany i utrzymuje ich spójność
/opsx:verify	Waliduje implementację względem artefaktów (rozszerzony przepływ pracy)
/opsx:sync	Scalają specyfikacje delta z głównymi specyfikacjami (opcjonalnie)
/opsx:archive	Archiwizuje po zakończeniu
/opsx:bulk-archive	Archiwizuje wiele zakończonych zmian (rozszerzony przepływ pracy)
/opsx:onboard	Prowadzony przewodnik po zmianie end-to-end (rozszerzony przepływ pracy)

Użycie

Eksploracja pomysłu

/opsx:explore

Rozważaj pomysły, badaj problemy, porównuj opcje. Brak wymaganego formatu — to po prostu partner do myślenia. Gdy wnioski się wyklarują, przejdź do /opsx:propose (domyślnie) lub /opsx:new//opsx:ff (rozszerzony).

Rozpoczęcie nowej zmiany

/opsx:propose

Tworzy zmianę i generuje artefakty planistyczne potrzebne przed implementacją.

Jeśli włączyłeś rozszerzone przepływy pracy, możesz zamiast tego użyć:

/opsx:new        # tylko szkielet
/opsx:continue   # twórz po jednym artefakcie
/opsx:ff         # twórz wszystkie artefakty planistyczne naraz

Tworzenie artefaktów

/opsx:continue

Pokazuje, co jest gotowe do utworzenia na podstawie zależności, a następnie tworzy jeden artefakt. Używaj wielokrotnie, aby stopniowo budować swoją zmianę.

/opsx:ff add-dark-mode

Tworzy wszystkie artefakty planistyczne naraz. Używaj, gdy masz jasny obraz tego, co budujesz.

Implementacja (część płynna)

/opsx:apply

Przechodzi przez zadania, odhaczając je w miarę postępu. Jeśli pracujesz nad wieloma zmianami jednocześnie, możesz uruchomić /opsx:apply <name>; w przeciwnym razie powinien wywnioskować z rozmowy i poprosić o wybór, jeśli nie może się zdecydować.

Aktualizacja zmiany

/opsx:update add-dark-mode - we're storing the theme in a cookie now

Rewiduje istniejące artefakty planistyczne zmiany i utrzymuje ich spójność — w dowolnym kierunku (zmiana projektu może odbić się na propozycji). Tylko artefakty planistyczne: nigdy nie edytuje kodu i nigdy nie tworzy brakujących artefaktów (to robi /opsx:continue). Każda edycja jest najpierw potwierdzana z Tobą. Jeśli zmiana została już zaimplementowana, poleca /opsx:apply, aby kod nadążył za zrewidowanym planem. Jeśli Twoja rewizja zmienia intencję zmiany, zacznij od nowa — zobacz Kiedy aktualizować vs. zaczynać od nowa.

Synchronizacja specyfikacji delta

/opsx:sync

Scala specyfikacje delta bieżącej zmiany z głównymi openspec/specs/ bez archiwizacji — zmiana pozostaje aktywna. Stosuje całą deltę: wymaganie pod ## REMOVED jest usuwane z głównej specyfikacji, a przemianowane jest retitulowane na miejscu, podczas gdy treść, której delta nie wspomina, pozostaje nietknięta. Synchronizacja jest opcjonalna — archiwizacja poprosi Cię o synchronizację, jeśli jej jeszcze nie wykonałeś. Sięgnij po nią, gdy chcesz zaktualizować główne specyfikacje przed archiwizacją, gdy równoległa zmiana musi budować na specyfikacjach dodanych przez tę zmianę, lub gdy chcesz przejrzeć scaloną główną specyfikację przed archiwizacją.

Zakończenie

/opsx:archive   # Przenieś do archiwum po zakończeniu (poprosi o synchronizację specyfikacji, jeśli to konieczne)

Kiedy aktualizować vs. zaczynać od nowa

Możesz zawsze edytować swoją propozycję lub specyfikacje przed implementacją. Ale kiedy dopracowywanie staje się „to jest inna praca"?

Co definiuje propozycja

Propozycja definiuje trzy rzeczy:

1. Intencja — Jaki problem rozwiązujesz?
2. Zakres — Co jest w/nie w granicach?
3. Podejście — Jak go rozwiążesz?

Pytanie brzmi: co się zmieniło i o ile?

Aktualizuj istniejącą zmianę, gdy:

Ta sama intencja, dopracowane wykonanie

• Odkrywasz przypadki brzegowe, o których nie pomyślałeś
• Podejście wymaga drobnych zmian, ale cel pozostaje bez zmian
• Implementacja ujawnia, że projekt był nieco nietrafiony

Zakres się zawęża

• Uświadamiasz sobie, że pełny zakres jest zbyt duży, chcesz najpierw wydać MVP
• „Dodaj tryb ciemny" → "Dodaj przełącznik trybu ciemnego (preferencje systemowe w v2)"

Korekty wynikające z nauki

• Baza kodu nie jest zbudowana tak, jak myślałeś
• Zależność nie działa zgodnie z oczekiwaniami
• "Użyj zmiennych CSS" → "Użyj zamiast tego prefiksu dark: z Tailwinda"

Zacznij nową zmianę, gdy:

Intencja fundamentalnie się zmieniła

• Sam problem jest teraz inny
• "Dodaj tryb ciemny" → "Dodaj kompleksowy system motywów z niestandardowymi kolorami, fontami, odstępami"

Zakres eksplodował

• Zmiana urosła tak bardzo, że to zasadniczo inna praca
• Oryginalna propozycja byłaby nierozpoznawalna po aktualizacjach
• "Napraw błąd logowania" → "Przepisz system uwierzytelniania"

Oryginał jest ukończalny

• Oryginalną zmianę można oznaczyć jako „ukończoną"
• Nowa praca stoi samodzielnie, nie jest dopracowaniem
• Ukończ „Dodaj tryb ciemny MVP" → Archiwizuj → Nowa zmiana "Rozwiń tryb ciemny"

Heurystyki

                        ┌─────────────────────────────────────┐
                        │     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	Aktualizacja	Nowa zmiana
Tożsamość	"Ta sama rzecz, dopracowana"	"Inna praca"
Nakładanie się zakresu	>50% nakłada się	<50% nakłada się
Ukończenie	Nie można oznaczyć jako „ukończone" bez zmian	Można ukończyć oryginał, nowa praca stoi samodzielnie
Opowieść	Łańcuch aktualizacji opowiada spójną historię	Łatki wprowadziłyby więcej zamieszania niż jasności

Zasada

Aktualizacja zachowuje kontekst. Nowa zmiana zapewnia jasność.

Wybierz aktualizację, gdy historia Twojego myślenia jest cenna. Wybierz nową zmianę, gdy rozpoczęcie od nowa będzie jaśniejsze niż łatanie.

Traktuj to jak gałęzie w git:

• Kontynuuj commitowanie, pracując nad tą samą funkcją
• Zacznij nową gałąź, gdy to naprawdę nowa praca
• Czasem scal częściową funkcję i zacznij od nowa dla fazy 2

Różnice

	Legacy (/openspec:proposal)	OPSX (/opsx:*)
Struktura	Jeden duży dokument propozycji	Oddzielne artefakty z zależnościami
Przebieg pracy	Fazy liniowe: planowanie → implementacja → archiwizacja	Płynne działania – rób wszystko w dowolnym momencie
Iteracja	Niewygodne cofanie się	Aktualizuj artefakty w miarę zdobywania wiedzy
Dostosowywanie	Stała struktura	Oparte na schemacie (definiuj własne artefakty)

Kluczowe spostrzeżenie: praca nie jest liniowa. OPSX przestaje udawać, że jest.

Analiza architektury

Ta sekcja wyjaśnia, jak OPSX działa pod spodem oraz jak porównuje się z poprzednim przepływem pracy. Przykłady w tej sekcji używają rozszerzonego zestawu poleceń (new, continue itp.); użytkownicy domyślnego core mogą odwzorować ten sam przepływ na propose → apply → sync → archive.

Filozofia: Fazy vs Akcje

┌─────────────────────────────────────────────────────────────────────────────┐
│                         LEGACY WORKFLOW                                      │
│                    (Phase-Locked, All-or-Nothing)                           │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   ┌──────────────┐      ┌──────────────┐      ┌──────────────┐             │
│   │   PLANNING   │ ───► │ IMPLEMENTING │ ───► │   ARCHIVING  │             │
│   │    PHASE     │      │    PHASE     │      │    PHASE     │             │
│   └──────────────┘      └──────────────┘      └──────────────┘             │
│         │                     │                     │                       │
│         ▼                     ▼                     ▼                       │
│   /openspec:proposal   /openspec:apply      /openspec:archive              │
│                                                                             │
│   • Creates ALL artifacts at once                                          │
│   • Can't go back to update specs during implementation                    │
│   • Phase gates enforce linear progression                                  │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘


┌─────────────────────────────────────────────────────────────────────────────┐
│                            OPSX WORKFLOW                                     │
│                      (Fluid Actions, Iterative)                             │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│              ┌────────────────────────────────────────────┐                 │
│              │           ACTIONS (not phases)             │                 │
│              │                                            │                 │
│              │   new ◄──► continue ◄──► apply ◄──► archive │                 │
│              │    │          │           │           │    │                 │
│              │    └──────────┴───────────┴───────────┘    │                 │
│              │              any order                     │                 │
│              └────────────────────────────────────────────┘                 │
│                                                                             │
│   • Create artifacts one at a time OR fast-forward                         │
│   • Update specs/design/tasks during implementation                        │
│   • Dependencies enable progress, phases don't exist                       │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

Architektura komponentów

Poprzedni przepływ pracy używa zaszytych w kodzie szablonów w TypeScript:

┌─────────────────────────────────────────────────────────────────────────────┐
│                      LEGACY WORKFLOW COMPONENTS                              │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   Hardcoded Templates (TypeScript strings)                                  │
│                    │                                                        │
│                    ▼                                                        │
│   Tool-specific configurators/adapters                                      │
│                    │                                                        │
│                    ▼                                                        │
│   Generated Command Files (.claude/commands/openspec/*.md)                  │
│                                                                             │
│   • Fixed structure, no artifact awareness                                  │
│   • Change requires code modification + rebuild                             │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

OPSX używa zewnętrznych schematów i silnika grafu zależności:

┌─────────────────────────────────────────────────────────────────────────────┐
│                         OPSX COMPONENTS                                      │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   Schema Definitions (YAML)                                                 │
│   ┌─────────────────────────────────────────────────────────────────────┐   │
│   │  name: spec-driven                                                  │   │
│   │  artifacts:                                                         │   │
│   │    - id: proposal                                                   │   │
│   │      generates: proposal.md                                         │   │
│   │      requires: []              ◄── Dependencies                     │   │
│   │    - id: specs                                                      │   │
│   │      generates: specs/**/*.md  ◄── Glob patterns                    │   │
│   │      requires: [proposal]      ◄── Enables after proposal           │   │
│   └─────────────────────────────────────────────────────────────────────┘   │
│                    │                                                        │
│                    ▼                                                        │
│   Artifact Graph Engine                                                     │
│   ┌─────────────────────────────────────────────────────────────────────┐   │
│   │  • Topological sort (dependency ordering)                           │   │
│   │  • State detection (filesystem existence)                           │   │
│   │  • Rich instruction generation (templates + context)                │   │
│   └─────────────────────────────────────────────────────────────────────┘   │
│                    │                                                        │
│                    ▼                                                        │
│   Skill Files (.claude/skills/openspec-*/SKILL.md)                          │
│                                                                             │
│   • Cross-editor compatible (Claude Code, Cursor, Devin)                    │
│   • Skills query CLI for structured data                                    │
│   • Fully customizable via schema files                                     │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

Model grafu zależności

Artefakty tworzą skierowany graf bezcykliczny (DAG). Zależności są włącznikami, nie bramkami:

                              proposal
                             (root node)
                                  │
                    ┌─────────────┴─────────────┐
                    │                           │
                    ▼                           ▼
                 specs                       design
              (requires:                  (requires:
               proposal)                   proposal)
                    │                           │
                    └─────────────┬─────────────┘
                                  │
                                  ▼
                               tasks
                           (requires:
                           specs, design)
                                  │
                                  ▼
                          ┌──────────────┐
                          │ APPLY PHASE  │
                          │ (requires:   │
                          │  tasks)      │
                          └──────────────┘

Przejścia stanów:

   BLOCKED ────────────────► READY ────────────────► DONE
      │                        │                       │
   Missing                  All deps               File exists
   dependencies             are DONE               on filesystem

Przepływ informacji

Poprzedni przepływ pracy — agent otrzymuje statyczne instrukcje:

  User: "/openspec:proposal"
           │
           ▼
  ┌─────────────────────────────────────────┐
  │  Static instructions:                   │
  │  • Create proposal.md                   │
  │  • Create tasks.md                      │
  │  • Create design.md                     │
  │  • Create delta spec files              │
  │                                         │
  │  No awareness of what exists or         │
  │  dependencies between artifacts         │
  └─────────────────────────────────────────┘
           │
           ▼
  Agent creates ALL artifacts in one go

OPSX — agent zapytuje o bogaty kontekst:

  User: "/opsx:continue"
           │
           ▼
  ┌──────────────────────────────────────────────────────────────────────────┐
  │  Step 1: Query current state                                             │
  │  ┌────────────────────────────────────────────────────────────────────┐  │
  │  │  $ openspec status --change "add-auth" --json                      │  │
  │  │                                                                    │  │
  │  │  {                                                                 │  │
  │  │    "artifacts": [                                                  │  │
  │  │      {"id": "proposal", "status": "done"},                         │  │
  │  │      {"id": "specs", "status": "ready"},      ◄── First ready      │  │
  │  │      {"id": "design", "status": "ready"},                          │  │
  │  │      {"id": "tasks", "status": "blocked",                          │  │
  │  │       "missingDeps": ["specs", "design"]}                          │  │
  │  │    ]                                                               │  │
  │  │  }                                                                 │  │
  │  └────────────────────────────────────────────────────────────────────┘  │
  │                                                                          │
  │  Step 2: Get rich instructions for ready artifact                        │
  │  ┌────────────────────────────────────────────────────────────────────┐  │
  │  │  $ openspec instructions specs --change "add-auth" --json          │  │
  │  │                                                                    │  │
  │  │  {                                                                 │  │
  │  │    "template": "# Specification\n\n## ADDED Requirements...",      │  │
  │  │    "dependencies": [{"id": "proposal", "path": "...", "done": true}│  │
  │  │    "unlocks": ["tasks"]                                            │  │
  │  │  }                                                                 │  │
  │  └────────────────────────────────────────────────────────────────────┘  │
  │                                                                          │
  │  Step 3: Read dependencies → Create ONE artifact → Show what's unlocked  │
  └──────────────────────────────────────────────────────────────────────────┘

Model iteracji

Poprzedni przepływ pracy — iteracja jest niezręczna:

  ┌─────────┐     ┌─────────┐     ┌─────────┐
  │/proposal│ ──► │ /apply  │ ──► │/archive │
  └─────────┘     └─────────┘     └─────────┘
       │               │
       │               ├── "Wait, the design is wrong"
       │               │
       │               ├── Options:
       │               │   • Edit files manually (breaks context)
       │               │   • Abandon and start over
       │               │   • Push through and fix later
       │               │
       │               └── No official "go back" mechanism
       │
       └── Creates ALL artifacts at once

OPSX — naturalna iteracja:

  /opsx:new ───► /opsx:continue ───► /opsx:apply ───► /opsx:archive
      │                │                  │
      │                │                  ├── "The design is wrong"
      │                │                  │
      │                │                  ▼
      │                │            Just edit design.md
      │                │            and continue!
      │                │                  │
      │                │                  ▼
      │                │         /opsx:apply picks up
      │                │         where you left off
      │                │
      │                └── Creates ONE artifact, shows what's unlocked
      │
      └── Scaffolds change, waits for direction

Własne schematy

Twórz własne przepływy pracy za pomocą poleceń zarządzania schematami:

# Create a new schema from scratch (interactive)
openspec schema init my-workflow

# Or fork an existing schema as a starting point
openspec schema fork spec-driven my-workflow

# Validate your schema structure
openspec schema validate my-workflow

# See where a schema resolves from (useful for debugging)
openspec schema which my-workflow

Schematy są przechowywane w openspec/schemas/ (lokalne dla projektu, kontrolowane wersjami) lub ~/.local/share/openspec/schemas/ (globalne dla użytkownika).

Struktura schematu:

openspec/schemas/research-first/
├── schema.yaml
└── templates/
    ├── research.md
    ├── proposal.md
    └── tasks.md

Przykładowy schema.yaml:

name: research-first
artifacts:
  - id: research        # Added before proposal
    generates: research.md
    requires: []

  - id: proposal
    generates: proposal.md
    requires: [research]  # Now depends on research

  - id: tasks
    generates: tasks.md
    requires: [proposal]

Graf zależności:

   research ──► proposal ──► tasks

Podsumowanie

Aspekt	Poprzedni przepływ	OPSX
Szablony	Zaszyte w TypeScript	Zewnętrzne YAML + Markdown
Zależności	Brak (wszystko naraz)	DAG z sortowaniem topologicznym
Stan	Model mentalny oparty na fazach	Istnienie plików na systemie plików
Konfigurowalność	Edycja kodu źródłowego, przebudowa	Tworzenie schema.yaml
Iteracja	Zablokowana fazami	Płynna, edycja dowolnego elementu
Wsparcie edytorów	Konfigurator/adaptery specyficzne dla narzędzia	Jedna katalog skills

Schematy

Schematy definiują, jakie artefakty istnieją i jakie są ich zależności. Obecnie dostępne:

• spec-driven (domyślny): propozycja → specyfikacje → projekt → zadania

# Wyświetl dostępne schematy
openspec schemas

# Zobacz wszystkie schematy z ich źródłami rozwiązań
openspec schema which --all

# Utwórz nowy schemat interaktywnie
openspec schema init my-workflow

# Sforkuj istniejący schemat do dostosowania
openspec schema fork spec-driven my-workflow

# Zweryfikuj strukturę schematu przed użyciem
openspec schema validate my-workflow

Porady

• Użyj /opsx:explore, aby przemyśleć pomysł przed zatwierdzeniem zmiany
• /opsx:ff, gdy wiesz, czego chcesz, /opsx:continue podczas eksploracji
• Podczas /opsx:apply, jeśli coś jest nie tak — popraw artefakt, a następnie kontynuuj
• Zadania śledzą postęp za pomocą pól wyboru w tasks.md
• Sprawdź status w dowolnym momencie: openspec status --change "name"

Opinia

To jest surowe. To celowe — uczymy się, co działa.

Znalazłeś błąd? Masz pomysły? Dołącz do nas na Discord lub otwórz zgłoszenie na GitHub.