Pierwsze kroki
Ten przewodnik wyjaśnia, jak działa OpenSpec po jego zainstalowaniu i zainicjowaniu. Instrukcje dotyczące instalacji znajdziesz w głównym README lub w przewodniku instalacyjnym. Nowy w całej dokumentacji? Strona główna dokumentacji mapuje wszystko.
Gdzie wpisywać te polecenia? Dwa miejsca, a ich pomylenie to najczęstszy początkowy problem.
- Polecenia
openspec ...(np.openspec init) wykonujesz w terminalu.- Polecenia
/opsx:...(np./opsx:propose) wykonujesz w czacie asystenta AI, w tym samym oknie, w którym poprosisz go o napisanie kodu.Nie ma osobnego „trybu interaktywnego" do uruchomienia. Wystarczy wpisać polecenie z ukośnikiem w czacie, a asystent przejmuje resztę. Pełne wyjaśnienie: Jak działają polecenia.
Twoje pierwsze pięć minut
Cały cykl, z każdym krokiem oznaczonym miejscem, w którym się odbywa:
TERMINAL $ npm install -g @fission-ai/openspec@latest
TERMINAL $ cd your-project && openspec init
AI CHAT /opsx:explore (opcjonalnie: najpierw przemyśl to)
AI CHAT /opsx:propose add-dark-mode (AI tworzy szkic planu; Ty go przeglądasz)
AI CHAT /opsx:apply (AI buduje implementację)
AI CHAT /opsx:archive (specyfikacje zaktualizowane, zmiana archiwizowana)Dwa kroki w terminalu na konfigurację, a potem pracujesz w czacie. Reszta tego przewodnika wyjaśnia, co robi każdy krok i co zobaczysz.
Nie chcesz sam wykonywać części terminalowej? Wklej prompt instalacyjny do swojego asystenta, a on wykona oba wiersze i zgłosi, co utworzył.
Nie wiesz jeszcze, co zbudować? Zacznij od
/opsx:explore. To partner do myślenia bez ryzyka, który czyta Twoją bazę kodu, waży opcje i dopracowuje niejasny pomysł w konkretny plan, zanim powstanie jakikolwiek artefakt lub kod. Gdy obraz jest jasny, przekazuje sprawę do/opsx:propose. To najlepszy nawyk przy pracy z AI, które inaczej z pewnością zbuduje coś niewłaściwego. Zobacz przewodnik Explore.
Jak to działa
OpenSpec pomaga Tobie i Twojemu asystentowi AI do kodowania uzgodnić, co ma zostać zbudowane, zanim napisze się jakikolwiek kod.
Domyślna szybka ścieżka (profil core):
/opsx:explore ──► /opsx:propose ──► /opsx:apply ──► /opsx:sync ──► /opsx:archive
(opcjonalnie)Zacznij od /opsx:explore, gdy zastanawiasz się, co zrobić, lub przejdź od razu do /opsx:propose, jeśli już wiesz. Explore jest w domyślnym profilu, więc zawsze jest dostępny, gdy go potrzebujesz.
Rozszerzona ścieżka (wybór niestandardowego przepływu pracy):
/opsx:new ──► /opsx:ff or /opsx:continue ──► /opsx:apply ──► /opsx:verify ──► /opsx:archiveDomyślny globalny profil to core, który obejmuje propose, explore, apply, update, sync i archive. Możesz włączyć rozszerzone polecenia przepływu pracy za pomocą openspec config profile, a następnie openspec update.
Co tworzy OpenSpec
Po uruchomieniu openspec init Twój projekt ma następującą strukturę:
openspec/
├── specs/ # Źródło prawdy (zachowanie Twojego systemu)
│ └── <domain>/
│ └── spec.md
├── changes/ # Propozycje aktualizacji (jeden folder na zmianę)
│ └── <change-name>/
│ ├── proposal.md
│ ├── design.md
│ ├── tasks.md
│ └── specs/ # Specyfikacje delta (co się zmienia)
│ └── <domain>/
│ └── spec.md
└── config.yaml # Konfiguracja projektu (opcjonalnie)Dwa kluczowe katalogi:
specs/– Źródło prawdy. Te specyfikacje opisują, jak Twój system aktualnie działa. Organizowane według domen (np.specs/auth/,specs/payments/).changes/– Propozycje modyfikacji. Każda zmiana otrzymuje własny folder z wszystkimi powiązanymi artefaktami. Gdy zmiana jest ukończona, jej specyfikacje są scalane z głównym katalogiemspecs/.
Zrozumienie artefaktów
Każdy folder zmian zawiera artefakty, które kierują pracą:
| Artefakt | Cel |
|---|---|
proposal.md | „Dlaczego" i „co" – zapisuje intencję, zakres i podejście |
specs/ | Specyfikacje delta pokazujące DODANE/ZMODYFIKOWANE/USUNIĘTE wymagania |
design.md | „Jak" – podejście techniczne i decyzje architektoniczne |
tasks.md | Lista zadań implementacyjnych z checkboxami |
Artefakty budują się na sobie:
proposal ──► specs ──► design ──► tasks ──► implement
▲ ▲ ▲ │
└───────────┴──────────┴────────────────────┘
aktualizuj w miarę zdobywania wiedzyZawsze możesz wrócić i dopracować wcześniejsze artefakty, gdy zdobędziesz więcej wiedzy podczas implementacji.
Jak działają specyfikacje delta
Specyfikacje delta to kluczowe pojęcie w OpenSpec. Pokazują, co się zmienia w stosunku do Twoich obecnych specyfikacji.
Format
Specyfikacje delta używają sekcji do oznaczenia typu zmiany:
# Delta for Auth
## ADDED Requirements
### Requirement: Two-Factor Authentication
The system MUST require a second factor during login.
#### Scenario: OTP required
- GIVEN a user with 2FA enabled
- WHEN the user submits valid credentials
- THEN an OTP challenge is presented
## MODIFIED Requirements
### Requirement: Session Timeout
The system SHALL expire sessions after 30 minutes of inactivity.
(Previously: 60 minutes)
#### Scenario: Idle timeout
- GIVEN an authenticated session
- WHEN 30 minutes pass without activity
- THEN the session is invalidated
## REMOVED Requirements
### Requirement: Remember Me
(Deprecated in favor of 2FA)Co się dzieje przy archiwizacji
Gdy archiwizujesz zmianę:
- Wymagania ADDED są dodawane do głównej specyfikacji
- Wymagania MODIFIED zastępują istniejącą wersję
- Wymagania REMOVED są usuwane z głównej specyfikacji
Folder zmiany przenoszony jest do openspec/changes/archive/ dla historii audytu.
Przykład: Twoja pierwsza zmiana
Przejdźmy przez dodanie trybu ciemnego do aplikacji.
1. Rozpoczęcie zmiany (domyślnie)
You: /opsx:propose add-dark-mode
AI: Created openspec/changes/add-dark-mode/
✓ proposal.md — why we're doing this, what's changing
✓ specs/ — requirements and scenarios
✓ design.md — technical approach
✓ tasks.md — implementation checklist
Ready for implementation!Jeśli włączyłeś rozszerzony profil przepływu pracy, możesz to zrobić również w dwóch krokach: /opsx:new, a następnie /opsx:ff (lub /opsx:continue inkrementalnie).
2. Co zostaje utworzone
proposal.md – Zapisuje intencję:
# Proposal: Add Dark Mode
## Intent
Users have requested a dark mode option to reduce eye strain
during nighttime usage.
## Scope
- Add theme toggle in settings
- Support system preference detection
- Persist preference in localStorage
## Approach
Use CSS custom properties for theming with a React context
for state management.specs/ui/spec.md – Delta pokazująca nowe wymagania:
# Delta for UI
## ADDED Requirements
### Requirement: Theme Selection
The system SHALL allow users to choose between light and dark themes.
#### Scenario: Manual toggle
- GIVEN a user on any page
- WHEN the user clicks the theme toggle
- THEN the theme switches immediately
- AND the preference persists across sessions
#### Scenario: System preference
- GIVEN a user with no saved preference
- WHEN the application loads
- THEN the system's preferred color scheme is usedtasks.md – Lista zadań implementacyjnych:
# Tasks
## 1. Theme Infrastructure
- [ ] 1.1 Create ThemeContext with light/dark state
- [ ] 1.2 Add CSS custom properties for colors
- [ ] 1.3 Implement localStorage persistence
## 2. UI Components
- [ ] 2.1 Create ThemeToggle component
- [ ] 2.2 Add toggle to settings page
- [ ] 2.3 Update Header to include quick toggle
## 3. Styling
- [ ] 3.1 Define dark theme color palette
- [ ] 3.2 Update components to use CSS variables3. Implementacja
You: /opsx:apply
AI: Working through tasks...
✓ 1.1 Created ThemeContext with light/dark state
✓ 1.2 Added CSS custom properties to globals.css
✓ 1.3 Implemented localStorage persistence
✓ 2.1 Created ThemeToggle component
...
All tasks complete!Podczas implementacji, jeśli odkryjesz, że projekt wymaga korekty, po prostu zaktualizuj artefakt i kontynuuj.
4. Archiwizacja
You: /opsx:archive
AI: Archiving add-dark-mode...
✓ Merged specs into openspec/specs/ui/spec.md
✓ Moved to openspec/changes/archive/2025-01-24-add-dark-mode/
Done! Ready for the next feature.Twoje specyfikacje delta są teraz częścią głównych specyfikacji, dokumentując, jak działa Twój system.
Weryfikacja i przegląd
Użyj CLI, aby sprawdzić swoje zmiany:
# List active changes
openspec list
# View change details
openspec show add-dark-mode
# Validate spec formatting
openspec validate add-dark-mode
# Interactive dashboard
openspec viewKolejne kroki
- Explore First – Użyj
/opsx:explore, aby przemyśleć pomysł, zanim się na niego zdecydujesz - Reviewing a Change – Co sprawdzić w planie, który tworzy AI, zanim powstanie jakikolwiek kod
- Writing Good Specs – Jak wygląda silne wymaganie i scenariusz
- Using OpenSpec in an Existing Project – Zacznij na dużej istniejącej bazie kodu
- Editing & Iterating on a Change – Aktualizuj artefakty, wracaj, synchronizuj ręczne edycje
- Core Concepts at a Glance – Cały model mentalny na jednej stronie
- Examples & Recipes – Prawdziwe zmiany, od początku do końca
- Workflows – Wspólne wzorce i kiedy używać każdego polecenia
- Commands – Pełna referencja wszystkich poleceń z ukośnikiem
- Concepts – Głębsze zrozumienie specyfikacji, zmian i schematów
- Customization – Dostosuj OpenSpec do swoich potrzeb
- Stores – Planowanie obejmujące wiele repozytoriów lub zespołów? Trzymaj je w osobnym repo (beta)
- FAQ i Troubleshooting – Gdy utkniesz