Konfiguracja projektu

Spraw, aby przepływy pracy planowały zmiany tak, jak chcesz, za pomocą kilku linii w config.yaml.

openspec/config.yaml informuje przepływy pracy, jak chcesz planować zmiany.

Na przykład poniższa konfiguracja aktualizuje zasady tworzenia artefaktu tasks.md:

rules:
  tasks:
    - End every task with a commit

Gdy agent działa, korzysta z tych zasad i zapewnia, że każde zadanie kończy się krokiem commit.

Utrzymuj zasady krótkie. Wszystko, co tu umieścisz, trafia do kontekstu agenta, a rozwlekłe zasady mogą pogorszyć wyniki.

Jak to działa

config.yaml zawiera instrukcje, które agent otrzymuje podczas tworzenia artefaktów lub pracy w ramach przepływu pracy.

Oto, co dzieje się przy każdym uruchomieniu:

1. Uruchamiasz przepływ pracy (np. /openspec-propose).
2. Agent wywołuje polecenie openspec instructions.
3. Polecenie odczytuje Twój kontekst i zasady z config.yaml.
4. Wbudowane instrukcje OpenSpec i Twoje modyfikacje są łączone w jeden prompt dla agenta.
5. Agent podąża za tym promptem, aby utworzyć artefakt.

Na przykład, z polem context i zasadą z góry tej strony, oto co openspec instructions zwraca dla tasks.md (przycięte i z adnotacjami):

<artifact id="tasks" change="add-dark-mode" schema="spec-driven">

  <!-- From your config.yaml: context -->
  <project_context>
    Designs and tasks must cover Windows, macOS, and Linux
    Write all artifacts in Spanish
  </project_context>

  <!-- From your config.yaml: rules for tasks -->
  <rules>
    - End every task with a commit
  </rules>

  <!-- From OpenSpec: the built-in guidance -->
  <instruction>
    ...how to write a good tasks.md...
  </instruction>

  <template>
    ...the tasks.md structure to fill in...
  </template>

</artifact>

Twoja konfiguracja pojawia się najpierw, potem wbudowana instrukcja i szablon OpenSpec. Zasady dodają się do wbudowanych i nigdy ich nie zastępują. Zmiany w config.yaml docierają do agenta przy następnym uruchomieniu.

Pola

Trzy pola kształtują to, co otrzymuje agent. Dokładny kontrakt każdego pola (typy, limity, walidacja) znajduje się w Konfiguracja projektu (config.yaml).

Pole	Co robi	Wstrzykiwane do
context	Instrukcje, które agent zawsze otrzymuje	Wszystko: każdy artefakt, apply, archive
rules	Dodatkowe instrukcje dla jednego artefaktu	Tylko tworzenie tego artefaktu
operations	Wskazówki dotyczące sposobu wykonania kroku przepływu pracy	Tylko apply i archive

Inne pola config.yaml (schema, store, references) wybierają, którego schematu i którego katalogu głównego OpenSpec używa projekt. Strona kontraktu je opisuje.

Ostatnia kolumna jest dokładna, więc pole dociera tylko do kroków tam wymienionych. W szczególności verify nigdy nie otrzymuje rules. Sprawdza implementację względem artefaktów tak, jak zostały zapisane.

context

context to tło, które agent otrzymuje podczas tworzenia artefaktu, stosowania zadań lub archiwizowania zmiany.

context: |
  We ship cross-platform. Designs and tasks must cover Windows, macOS, and Linux
  Write all artifacts in Spanish

Używaj context do faktów i ograniczeń, które powinny kształtować wyniki przepływu pracy. Trwałą dokumentację projektu przechowuj w plikach dokumentacji projektu i pomiń wszystko, czego agent może się dowiedzieć, czytając kod.

Inny język: ponieważ kontekst dociera do każdego artefaktu, możesz dodać Write all artifacts in Spanish., aby poinstruować agenta, by pisał artefakty proposal, spec, design i tasks po hiszpańsku.

rules

rules są przypisane do jednego artefaktu, kluczowane po identyfikatorze artefaktu. Każda linia jest dodawana do wbudowanych wskazówek tego artefaktu:

rules:
  proposal:
    - Keep proposals under 500 words
  tasks:
    - Every UI task includes a Playwright test

Propozycje pozostają teraz krótkie, a tasks.md zawsze planuje testy przeglądarkowe. Każdy inny artefakt pozostaje nietknięty.

operations

operations kieruje tym, jak agent wykonuje apply i archive, a nie tym, co mówią artefakty:

operations:
  apply:
    guidance:
      - Run the linter before marking a task complete
  archive:
    guidance:
      - Summarize what shipped before archiving

Podczas apply agent lintuje w miarę ukończania zadań. Podczas archive kończy podsumowaniem.

Kiedy config.yaml nie wystarcza

Konfiguracja dodaje instrukcje na wierzchu standardowego przepływu pracy, ale nie może zmienić tego, które artefakty istnieją ani jak są zorganizowane. Gdy chcesz takiego poziomu kontroli lub zasady nie kierują zachowaniem spójnie, sforkuj schemat.