Design: napisz spec.md

Etap designu zmienia zaakceptowany intent.md w commitowany spec.md z wymaganiami, architekturą, kryteriami akceptacji i oznaczonymi kwestiami polityk. Product owner akceptuje wynik, a właściciele techniczni lub polityk rozwiązują ryzykowne pytania, zanim wolno rozpocząć plan implementacji albo kod.

Tradycyjnie: Wymagania i design to osobne fazy prowadzone przez osobne zespoły. Analitycy formalizują pomysł; designerzy parsują to z powrotem na design. Rozdział istnieje dla accountability, ale jest wolny i stratny.

AI-native: Obie fazy dzieją się w jednej promptowanej sesji. Agent bierze intent.md i produkuje spec wymagań i designu, ograniczony skills organizacji, z oznaczonymi obszarami concern.

Dla pracy UI zrób mock z intent.md w zatwierdzonym design tool, skonfigurowanej integracji z Figmą albo przez image input. Iteruj, zapisz ludzką akceptację i przekaż wersjonowany artefakt agentowi kodującemu. Kompozycję opisuje Design pipeline.

Zanim zaczniesz

• Zaakceptowany intent.md
• Polityki brandu, security, compliance i UX zapisane jako skills
• Dostęp product ownera do Claude, Cursor lub Codex — skill engineeringowy nie jest wymagany

Prerequisites: Plan (intent.md) i co najmniej jeden skill polityki.

Wyprodukuj spec

1. Otwórz sesję z dostępnymi skills organizacji i dołącz intent.md.

2. Skieruj prompt na intent.md, nazwij ograniczenia i wymagaj oznaczonych concerns.

   Na początku uruchamiaj to ręcznie. Potem zakoduj jako organization-level slash command lub skill. Stamtąd spraw, by akceptacja intent.md była triggerem: nieinteraktywny job odpala się na merge, uruchamia przejście z załadowanymi skills i otwiera spec.md jako pull request. Pierwszym udziałem product ownera jest wtedy review.

3. Zrecenzuj spec względem pomysłu.

   Czy spec rozwiązuje postawiony problem? Czy otwarte pytania z intent.md są odpowiedzią albo przeniesione dalej?

4. Najpierw przepracuj oznaczone concerns.

   To punkty, które analityk by eskalował. Rozwiąż każdy z właścicielem polityki, zanim engineering zobaczy spec.

5. Commitnij spec.md obok intent.md.

   Para plików zapisuje, o co proszono i co zdecydowano.

6. Zdecyduj, czy spec i intent idą do builda.

   Skonsultuj tech leada przy wszystkim, co organizacja klasyfikuje jako wyższe ryzyko. Tę decyzję zawsze podejmuje ludzki teammate. Zaakceptowanie speca uruchamia plan mode w Build.

Użyj poniższego promptu (nie zastępuj niczego poza dołączonym plikiem):

Read the attached intent.md and produce a requirements and design spec
for integrating it into our existing codebase. Apply the skills available
to you so the plan conforms to our brand guidelines, security policies,
and UX standards. Document the spec fully as spec.md, ready to hand to
the engineering team. Describe clearly any areas of concern, especially
where you cannot satisfy contradicting policies.

Claude Code

Zostań w plan mode (Shift+Tab), aż spec zostanie zaakceptowany:

Read intent/FEATURE.md. Produce spec.md using our skills for brand,
security, and UX. Flag contradictions. Do not edit application code.

Cursor

Zostań w Ask lub Plan mode. Dołącz intent.md i pliki skills pod .cursor/skills/ (Cursor czyta też .claude/skills/).

Codex

Użyj /plan i dołącz intent.md. Zakoduj tę samą politykę jako skills pod .agents/skills/ lub ~/.agents/skills/.

Governance

Żywa polityka jest czytana i stosowana podczas pisania speca. Skills są ograniczeniami na spec. Spec, prompt, który go wyprodukował, oraz wersje skills obowiązujące w momencie są logowane w kontroli wersji. Product owner podpisuje spec i kieruje oznaczone concerns do nazwanych właścicieli polityk.

Skill jest doradczy. Polityka, która musi zawsze obowiązywać, potrzebuje też deterministycznego checka później (hook lub przejście review). Zobacz Build i Deploy.

Verify

• spec.md jest commitowany obok zaakceptowanego intent.md.
• Każdy oznaczony concern ma właściciela albo jest przeniesiony jako otwarte pytanie.
• Człowiek zaakceptował spec, zanim zacznie się jakikolwiek plan implementacji.

Wskaźnik wiodący: czas, który upłynął między commitowaniem intent.md a commitowaniem spec.md dla tej samej zmiany.

Wskaźnik opóźniony: rework wymagań po starcie builda — commity spec.md datowane po pierwszym commicie plan.md dla tej samej zmiany.

Zastosuj praktykę w swoim narzędziu

Adapter Claude Code Połącz kontekst CLAUDE.md ze skillami projektu w .claude/skills/.

Adapter Cursora Połącz reguły, skille projektu, obrazy i zatwierdzone narzędzia MCP.

Adapter Codex Połącz AGENTS.md, .agents/skills/, obrazy, MCP i inspekcję repo.

Przekaż zaakceptowaną specyfikację do budowy

Przekaż zaakceptowaną parę engineeringowi i kontynuuj z Build.