Tworzenie kompleksowego planu strategicznego z uporządkowanym podziałem na zadania.
npx skills add https://github.com/AIBiz-Automatyzacje/claude-code-zasoby --skill dev-docsこのコマンドをClaude Codeにコピー＆ペーストしてスキルをインストール
Kontynuacja pracy nad zadaniem - wykonanie kolejnej fazy/etapu.
Planowanie techniczne implementacji z Implementation Units.
Code review wykonanej fazy/etapu przez multi-agent analysis.
Wytyczne UX/UI dla React 19 + Tailwind v4. Design system (OKLCH colors), dostępność (WCAG 2.2, ARIA), responsive design (mobile-first, container queries), animacje (Motion, View Transitions, prefers-reduced-motion), UI patterns (navigation, tables, search, onboarding), interface polish (concentric radius, optical alignment, tabular numbers, scale 0.96 on press, font smoothing, image outlines, interruptible animations, shadow-as-border). Używaj przy projektowaniu UI, dostępności, animacjach, mobile UX oraz micro-detalach polish — "feels off", "interface polish", "border radius polish", "stagger animations", "tabular numbers", "scale on press".
Przesłuchuje użytkownika o każdym aspekcie planu lub projektu aż do pełnego zrozumienia, rozwiązując każdą gałąź drzewa decyzyjnego. Używaj gdy user chce stress-testować plan, prosi o "roast", "zroastuj", chce przegadać temat, lub mówi "podważ to".
Automatyczny pipeline: execute->review->fix per faza, potem complete i compound. Uzywaj przy 'uruchom autopilot', 'wykonaj caly plan', 'autopilot', 'odpal pipeline'.
| name | dev-docs |
| description | Tworzenie kompleksowego planu strategicznego z uporządkowanym podziałem na zadania. |
| argument-hint | [opis zadania np. 'refaktoryzacja systemu uwierzytelniania'] — tworzy docs/active/[nazwa]/ |
Jesteś elitarnym specjalistą ds. planowania strategicznego. Stwórz kompleksowy, wykonalny plan dla: $ARGUMENTS
Sprawdź aktualny stan git:
Utwórz nowy branch:
feature/[nazwa-zadania] (np. feature/auth-refaktor)git checkout -b feature/[nazwa-zadania]Zapisz nazwę brancha — będzie potrzebna w dokumentacji
docs/brainstorms/*-requirements.md — requirements doc z /dev-brainstormdocs/plans/*-plan.md — plan techniczny z /dev-plan1b. Odczytaj kontekst designerski z planu technicznego:
design_md, figma_spec, figma_screenskontekst.md w sekcji "Designerski kontekst" (patrz Faza 3, struktura plików)figma_spec ≠ null, ale plik nie istnieje fizycznie → STOP, poinformuj usera "Plan deklaruje figma_spec: <ścieżka> ale plik nie istnieje. Wróć do /dev-plan i zregeneruj kontekst designerski."docs/plans/) zawiera w Implementation Units sekcje Scenariusze testowe i Weryfikacja — przenieś je jako checkboxy w checkliście zadań. Użyj prefixu Test: dla scenariuszy testowych i Weryfikacja: dla kryteriów weryfikacji. Te checkboxy MUSZĄ trafić do tego samego Unity/fazy co zadania implementacyjne, nie do osobnej sekcji. Jeśli plan techniczny nie istnieje lub nie zawiera scenariuszy testowych — nie dodawaj sztucznych testów.Utwórz katalog: docs/active/[nazwa-zadania]/
Wygeneruj trzy pliki:
[nazwa-zadania]-plan.md — Kompleksowy plan zawierający:
feature/[nazwa-zadania][nazwa-zadania]-kontekst.md — Kluczowe pliki, decyzje, zależności:
feature/[nazwa-zadania]W obu plikach ([nazwa-zadania]-plan.md i [nazwa-zadania]-kontekst.md) dodaj sekcję:
## Źródła
- Requirements doc: [ścieżka do docs/brainstorms/*.md jeśli użyty]
- Plan techniczny: [ścieżka do docs/plans/*.md jeśli użyty]
W [nazwa-zadania]-kontekst.md dodaj sekcję "Designerski kontekst" (przepisana 1:1 z frontmatera planu technicznego, sekcja 1b Fazy 1):
## Designerski kontekst
- **DESIGN.md (projekt-wide):** [ścieżka z `design_md` z frontmatera planu, lub `null` jeśli brak/pure-data]
- **SPEC.md (per-feature, pomiary z Figmy):** [ścieżka z `figma_spec`, lub `null`]
- **Screeny referencyjne:** [lista ścieżek z `figma_screens`, lub pusta jeśli brak]
- `<name-1>`: `<ścieżka PNG>`
- `<name-2>`: `<ścieżka PNG>`
> Te pliki są MANDATORY context dla subagentów buildujących UI. `dev-docs-execute` wstrzykuje je do promptu Agent tool.
Jeśli wszystkie trzy pola są null/puste — pomiń sekcję "Designerski kontekst" (feature pure-data lub brak Figmy).
[nazwa-zadania]-zadania.md — Format checklisty do śledzenia postępów.
Dla każdego Unity/fazy checklist powinien zawierać:
Test: (przeniesione z sekcji Scenariusze testowe planu technicznego)Weryfikacja: (przeniesione z sekcji Weryfikacja planu technicznego)Jeśli plan techniczny nie istnieje lub nie zawiera scenariuszy testowych — pomiń punkty 2 i 3.
Dodaj w każdym pliku:
feature/[nazwa-zadania]"git add docs/active/[nazwa-zadania]/docs: inicjalizacja planu dla [nazwa-zadania]CLAUDE.md dla przeglądu architektury (jeśli istnieje).claude/rules/best-practices.md dla standardów kodowania (jeśli istnieje).claude/rules/troubleshooting.md dla typowych problemów do uniknięcia (jeśli istnieje)docs/README.md dla wytycznych zarządzania zadaniami (jeśli istnieje)docs/brainstorms/ dla dokumentów wymagań z /dev-brainstormdocs/plans/ dla planów technicznych z /dev-plan✅ Plan utworzony dla "$ARGUMENTS"
🔀 Branch: feature/[nazwa-zadania]
📁 Struktura:
- docs/active/[nazwa-zadania]/
- [nazwa-zadania]-plan.md
- [nazwa-zadania]-kontekst.md
- [nazwa-zadania]-zadania.md
📝 Commit: docs: inicjalizacja planu dla [nazwa-zadania]
➡️ Następny krok: /dev-docs-execute docs/active/[nazwa-zadania]
Uwaga: Ta komenda jest idealna do użycia PO wyjściu z trybu planowania, gdy masz jasną wizję tego, co trzeba zrobić. Stworzy trwałą strukturę zadań, która przetrwa resety kontekstu.