symfonia-ai-tools 1.0.0

package/templates/base/_ai/_guidelines_header.md

@@ -0,0 +1,70 @@
+# {{PROJECT_NAME}} - Guidelines
+
+## Project Overview
+
+**{{PROJECT_NAME}}** — {{PROJECT_DESCRIPTION}}
+
+**Tech Stack**: {{TECH_STACK}}
+
+## Commands
+
+- Test: `{{TEST_COMMAND}}`
+- Build: `{{BUILD_COMMAND}}`
+- Lint: `{{LINT_COMMAND}}`
+- CI (all checks): `{{CI_COMMAND}}`
+
+## Commits & Branches
+
+- Follow commit conventions from `commit-instructions.md`
+- JIRA prefix: **{{JIRA_PREFIX}}**
+- Extract issue number from branch name: `feature/{{JIRA_PREFIX}}-1234-name` → `{{JIRA_PREFIX}}-1234: description`
+- Never add `Co-Authored-By` or AI attribution lines to commit messages
+- Do not commit without developer approval
+
+### Branch Naming
+
+| Type | Pattern | Example |
+|------|---------|---------|
+| Feature | `feature/{{JIRA_PREFIX}}-XXXX-short-name` | `feature/{{JIRA_PREFIX}}-1234-user-auth` |
+| Bugfix | `bugfix/{{JIRA_PREFIX}}-XXXX-short-name` | `bugfix/{{JIRA_PREFIX}}-567-login-fix` |
+| Hotfix | `hotfix/{{JIRA_PREFIX}}-XXXX-short-name` | `hotfix/{{JIRA_PREFIX}}-890-crash-fix` |
+| Release | `release/vX.Y.Z` | `release/v2.1.0` |
+
+## CI Pipeline
+
+Every PR must pass: `{{CI_COMMAND}}`
+
+## Forbidden
+
+**Never do these without explicit developer approval:**
+
+- Delete files or directories outside the current task scope
+- Modify `.env`, `.env.*`, or any file containing secrets
+- Change CI/CD configuration (`.github/workflows/`, `Jenkinsfile`, etc.)
+- Force push, reset --hard, or rewrite git history
+- Install or remove dependencies (only suggest, let developer decide)
+- Modify database schemas or run migrations in non-dev environments
+- Change authentication/authorization logic without review
+- Disable tests, linters, or security checks
+- Commit generated files (build artifacts, lock files) without asking
+
+## Testing Strategy
+
+- **Unit tests**: Every new function/method, every bug fix (regression test)
+- **Integration tests**: API endpoints, database operations, external service calls
+- **E2E tests**: Critical user flows (if Playwright pack is installed)
+- Write the test FIRST when fixing a bug — it should fail before the fix
+- Test edge cases: empty input, null, boundary values, error scenarios
+- Mock external dependencies in unit tests, use real services in integration
+
+## Skills
+
+Before working on any task, check `.ai/skills/` for a matching step-by-step workflow.
+
+## Instructions
+
+Context-specific instructions are in `.ai/instructions/` — they apply automatically based on file type (`applyTo` glob patterns).
+
+## Context
+
+Project-specific context (architecture, API spec, glossary) is in `.ai/context/`.

package/templates/base/_ai/context/README.md

@@ -0,0 +1,20 @@
+# Context
+
+This directory holds project-specific context files that AI agents should read for deeper understanding.
+
+## What to put here
+
+- **architecture.md** — system architecture, service boundaries, data flow
+- **api-spec.md** — API endpoints, request/response formats, error codes
+- **domain-glossary.md** — business terms and their meaning in code
+- **decisions.md** — key architectural decisions and their reasoning
+- **environment.md** — environment setup, required services, ports
+
+## Usage
+
+Tell the AI agent:
+```
+Read .ai/context/architecture.md before working on this task.
+```
+
+Or reference in skills/instructions that need this context.

package/templates/base/_ai/prompts/codereview.prompt.md

@@ -0,0 +1,324 @@
+# Code Review - AI Agent Prompt
+
+## Cel
+Wykonaj **kompleksowy code review** porownujac aktualny branch `{{CURRENT_BRANCH}}` z branchem bazowym `{{BASE_BRANCH}}` (domyslnie `develop` lub `main`), weryfikujac zgodnosc wszystkich zmian z zasadami projektu, dokumentacja techniczna oraz best practices.
+
+---
+
+## Krok 1: Analiza zmian (Git Diff + lokalne zmiany)
+
+### Zadania:
+1. **Pobierz roznice miedzy branchami**:
+   ```bash
+   git diff {{BASE_BRANCH}}...{{CURRENT_BRANCH}}
+   ```
+
+2. **Uwzglednij lokalne zmiany (niezacommitowane)**:
+    - Pobierz takze zmiany z:
+      ```bash
+      git diff
+      ```
+    - Zidentyfikuj pliki zmodyfikowane, dodane, usuniete, ktore nie zostaly jeszcze wkomitowane.
+
+3. **Zidentyfikuj wszystkie pliki**:
+    - **Dodane** - nowe pliki w projekcie
+    - **Zmodyfikowane** - pliki ze zmianami
+    - **Usuniete** - pliki usuniete z projektu
+
+4. **Kategoryzuj zmiany wedlug typu**:
+    - **Komponenty** (`*.vue`, `*.tsx`, `*.jsx`)
+    - **Composables / Hooks** (`composables/*.ts`, `hooks/*.ts`)
+    - **Stores** (`*.store.ts`, `*.slice.ts`)
+    - **Services** (`services/*.ts`)
+    - **Typy TypeScript** (`types/*.ts`)
+    - **Testy** (`*.test.ts`, `*.spec.ts`)
+    - **i18n / Tlumaczenia** (`lang/`, `locales/`, `messages/*.json`)
+    - **Dokumentacja** (`*.md`)
+    - **Konfiguracja** (`*.config.ts`, `*.json`)
+
+5. **Przeanalizuj szczegoly kazdej zmiany**:
+    - Ile linii dodano/usunieto?
+    - Jaki jest kontekst biznesowy zmiany?
+    - Czy zmiany sa spojne logicznie?
+    - Czy zmiany wplywaja na inne moduly?
+
+---
+
+## Krok 2: Weryfikacja zgodnosci z zasadami projektu
+
+### Architektura i Struktura Projektu
+- [ ] **Modularnosc**: Czy kod jest umieszczony w odpowiednim module `{{MODULE_PATH}}`?
+- [ ] **Separacja warstw**:
+    - Komponenty = tylko UI (brak logiki biznesowej)
+    - Composables / Hooks = cala logika biznesowa
+    - Stores = zarzadzanie stanem
+    - Services = wywolania API
+- [ ] **Struktura folderow**: `components/`, `composables/`, `store/`, `service/`, `types/`, `views/`
+- [ ] **Nazewnictwo plikow**: Zgodnosc z konwencja projektu (np. `UserManagement.store.ts`)
+
+### Komponenty i UI
+- [ ] **Props i events**: Czy komponenty maja poprawnie zdefiniowane interfejsy?
+- [ ] **Kompozycja**: Czy komponenty sa male, reuzywalne i jednozadaniowe?
+- [ ] **Warstwa wizualna**: Czy nie naruszono CSS/stylow niepowiazanych elementow?
+
+### Naming Conventions
+- [ ] **Variables i properties**: Czy uzywaja `camelCase` (np. `dataTestId`, `isLoading`)?
+- [ ] **CSS classes**: Czy uzywaja konwencji ustalonej w projekcie?
+  - Przyklad poprawny: `.notification-item-content`, `.bell-notifications-dropdown`
+  - Przyklad bledny: `.notification-item__content`, `.bell-notifications__dropdown`
+- [ ] **Data test IDs**: Czy wartosci sa w `camelCase`?
+  - Przyklad poprawny: `dataTestId: 'bellNotifications'`, `'notificationItem'`
+  - Przyklad bledny: `dataTestId: 'bell-notifications'`, `'notification-item'`
+
+### TypeScript i Typy
+- [ ] **Strict typing**: Brak uzycia `any` type
+- [ ] **Konwencje nazewnictwa**:
+    - Interfaces -> `I` prefix (np. `IUserForm`)
+    - Enums -> `E` prefix (np. `EUserRole`)
+    - Stores -> `*.store.ts` suffix
+- [ ] **Definicje typow**: Czy wszystkie props, API responses, state maja interfejsy?
+- [ ] **Import/Export**: Poprawne importy typow i wartosci
+
+### Internationalization (i18n)
+- [ ] **Brak hardcoded strings**: Wszystkie teksty uzywaja `$t('key')` lub `t('key')`
+- [ ] **Klucze tlumaczen**: Czy nowe klucze dodano do plikow jezykowych?
+- [ ] **Spojnosc kluczy**: Czy klucze sa opisowe i zgrupowane logicznie?
+- [ ] **Fallback**: Czy brakujace tlumaczenia maja fallback?
+
+### API i Services
+- [ ] **Uzywanie dedykowanego composable/service do wywolan API**
+- [ ] **Brak hardcoded URLs**: Nie ma bezposrednich URL w kodzie
+- [ ] **Prefix API**: Nie dodawano recznie prefixu API (jesli jest automatyczny)
+- [ ] **Obsluga bledow**: Uzywanie dedykowanego mechanizmu obslugi bledow (np. error handler, toast notifications)
+- [ ] **Try-catch**: Poprawna obsluga wyjatkow w async operacjach
+- [ ] **Loading states**: Czy sa zaimplementowane stany ladowania?
+
+### Stores (Pinia / Redux / Zustand / inne)
+- [ ] **Struktura store**: Uzywanie zalecanego wzorca definicji
+- [ ] **Reaktywnosc**: Poprawne uzycie mechanizmow reaktywnosci
+- [ ] **Mutacje**: Czy stan jest mutowany tylko wewnatrz store?
+- [ ] **Logika biznesowa**: Czy store zawiera tylko zarzadzanie stanem (logika w composables)?
+
+### Composables / Hooks
+- [ ] **Pattern `useXxx`**: Nazewnictwo zgodne z konwencja
+- [ ] **Tylko logika**: Brak elementow UI w composables
+- [ ] **Return pattern**: Zwracanie reactive values i functions
+- [ ] **Reuzywalnosc**: Czy composable jest generyczny i reuzywalny?
+
+### Testy
+- [ ] **Pokrycie testami**: Czy nowe komponenty/composables maja testy?
+- [ ] **Struktura testow**: Zgodnosc z instrukcjami testowania w projekcie
+- [ ] **Kategorie testow**:
+    - Basic Rendering
+    - Props Testing
+    - States
+    - Event Handling
+    - Accessibility
+    - Edge Cases
+- [ ] **Naming**: Czy testy maja opisowe nazwy (`should ...`)?
+- [ ] **Coverage**: Minimum wymagany prog pokrycia testami
+- [ ] **Mocking**: Poprawne mockowanie dependencies
+- [ ] **Async**: Uzycie `async/await` i odpowiednich mechanizmow oczekiwania gdzie potrzeba
+
+### Dokumentacja
+- [ ] **Plan zmian**: Czy istnieje plik `.md` z planem (np. `module-plan.md`)?
+- [ ] **Aktualizacja**: Czy dokumentacja jest zaktualizowana po zmianach?
+- [ ] **Test cases**: Czy dodano dokumentacje testow?
+- [ ] **README**: Czy zaktualizowano README jesli dodano nowy modul?
+
+### Code Quality
+- [ ] **Linter**: Brak bledow lint (ESLint / inne)
+- [ ] **Formatter**: Kod sformatowany zgodnie z Prettier / ustawieniami projektu
+- [ ] **Nieuzywane importy**: Brak nieuzywanych importow
+- [ ] **Console methods**: Usuniecie WSZYSTKICH `console.log`, `console.warn`, `console.error`, `console.info`
+- [ ] **Error handling**: Uzywanie dedykowanego mechanizmu obslugi bledow zamiast console.*
+- [ ] **Komentarze**: Brak niepotrzebnych komentarzy (kod self-documenting)
+- [ ] **CSS comments**: Brak komentarzy w CSS - style powinny byc oczywiste
+- [ ] **JSDoc**: Czy dodano JSDoc tylko dla publicznych API i zlozonych funkcji?
+- [ ] **Cyclomatic complexity**: Poziom 5-15 (nie za skomplikowane funkcje)
+
+### Performance
+- [ ] **Lazy loading**: Czy komponenty sa lazy-loaded gdzie to mozliwe?
+- [ ] **Memoizacja**: Uzycie memoizacji dla ciezkich operacji
+- [ ] **Keys w iteracjach**: Poprawne uzycie `:key` / `key` w petlach renderujacych
+- [ ] **Computed vs methods**: Czy uzywane sa computed properties / useMemo zamiast methods?
+
+### Accessibility
+- [ ] **ARIA attributes**: Poprawne uzycie aria-* atrybutow
+- [ ] **Keyboard navigation**: Obsluga klawiatury
+- [ ] **Focus management**: Zarzadzanie focusem
+- [ ] **Semantic HTML**: Uzycie semantycznych tagow
+
+---
+
+## Krok 3: Identyfikacja naruszen i rekomendacje
+
+### Format dla kazdego naruszenia:
+```markdown
+### Naruszenie #N: [Tytul naruszenia]
+
+**Plik**: `{{FILE_PATH}}`
+**Linia**: {{LINE_NUMBER}}
+**Kategoria**: [Architektura/TypeScript/i18n/API/Testy/etc.]
+**Priorytet**: KRYTYCZNY / WAZNY / SUGESTIA
+
+**Problem**:
+[Opis co jest nie tak]
+
+**Aktualny kod**:
+```typescript
+// Fragment problematycznego kodu
+```
+
+**Proponowana poprawka**:
+```typescript
+// Poprawiony kod
+```
+
+**Uzasadnienie**:
+[Dlaczego to naruszenie i dlaczego proponowane rozwiazanie jest lepsze]
+
+**Dokumentacja referencyjna**:
+- Odniesienie do zasad projektu
+- Odniesienie do dokumentacji technicznej
+```
+
+### Kategoryzacja naruszen:
+1. **KRYTYCZNY** - blokuje merge (np. `any` type, brak testow, hardcoded API URLs)
+2. **WAZNY** - powinien byc poprawiony przed merge (np. brak i18n, slaba struktura)
+3. **SUGESTIA** - ulepszenia, refactoring, optymalizacje (mozna merge i poprawic pozniej)
+
+---
+
+## Krok 4: Analiza testow
+
+### Weryfikacja testow:
+1. **Czy wszystkie nowe komponenty maja testy?**
+2. **Czy testy pokrywaja wszystkie przypadki**:
+   - Basic Rendering
+   - Props (wszystkie props + default values)
+   - States (disabled, error, loading, required)
+   - Events (emitowanie i handling)
+   - Accessibility (aria-*, keyboard)
+   - Edge cases (null, undefined, boundary values)
+3. **Czy testy sa niezalezne i izolowane?**
+4. **Czy mockowanie jest poprawne?**
+5. **Czy coverage >= wymagany prog?**
+
+### Sugestie testow:
+Jesli brakuje testow, zaproponuj konkretne test cases do dodania.
+
+---
+
+## Krok 5: Podsumowanie i decyzja
+
+### Statystyki zmian:
+- **Branch**: `{{CURRENT_BRANCH}}` vs `{{BASE_BRANCH}}`
+- **Data review**: {{REVIEW_DATE}}
+- **Pliki zmienione**: {{FILES_CHANGED}}
+- **Linie dodane**: +{{LINES_ADDED}}
+- **Linie usuniete**: -{{LINES_DELETED}}
+- **Komponenty**: {{COMPONENTS_COUNT}}
+- **Testy**: {{TESTS_COUNT}}
+- **Pokrycie testami**: {{TEST_COVERAGE}}%
+
+### Checklist zgodnosci:
+| Kategoria | Status | Komentarz |
+|-----------|--------|-----------|
+| Architektura | OK/WARN/FAIL | ... |
+| TypeScript | OK/WARN/FAIL | ... |
+| i18n | OK/WARN/FAIL | ... |
+| API/Services | OK/WARN/FAIL | ... |
+| Testy | OK/WARN/FAIL | ... |
+| Dokumentacja | OK/WARN/FAIL | ... |
+| Code Quality | OK/WARN/FAIL | ... |
+| Performance | OK/WARN/FAIL | ... |
+| Accessibility | OK/WARN/FAIL | ... |
+
+### Ocena koncowa:
+- **Liczba naruszen krytycznych**: {{CRITICAL_COUNT}}
+- **Liczba naruszen waznych**: {{IMPORTANT_COUNT}}
+- **Liczba sugestii**: {{SUGGESTION_COUNT}}
+
+### Decyzja:
+- **APPROVED** - Zmiany moga zostac zmergowane do `{{BASE_BRANCH}}`
+- **APPROVED WITH COMMENTS** - Mozna zmergowac, ale sugerowane poprawki
+- **CHANGES REQUESTED** - Wymagane poprawki przed merge
+
+**Uzasadnienie decyzji**:
+[Krotkie podsumowanie dlaczego taka decyzja]
+
+### Lista plikow wymagajacych poprawy:
+1. `{{FILE_PATH_1}}` - [powod]
+2. `{{FILE_PATH_2}}` - [powod]
+...
+
+### Najlepsze praktyki zastosowane w review:
+- [Lista dobrych praktyk, ktore zostaly zachowane]
+
+### Sugestie na przyszlosc:
+- [Ogolne rekomendacje dla dalszego rozwoju]
+
+---
+
+## Dokumentacja referencyjna
+
+### Glowne pliki instrukcji:
+- **Zasady projektu**: plik instrukcji AI w repozytorium (np. `copilot-instructions.md`, `CLAUDE.md`)
+- **Testy**: instrukcje testowania w projekcie
+- **Stores**: instrukcje zarzadzania stanem
+- **Komponenty**: instrukcje tworzenia komponentow
+
+### Dokumentacja techniczna projektu:
+- Overview projektu
+- Stack technologiczny
+- Struktura folderow
+- Architektura aplikacji
+- Komponenty
+- API i services
+
+---
+
+## Zmienne do uzycia:
+
+- `{{CURRENT_BRANCH}}` - aktualny branch (domyslnie: branch z ktorego wywolano review)
+- `{{BASE_BRANCH}}` - branch bazowy do porownania (domyslnie: `develop` lub `main`)
+- `{{MODULE_PATH}}` - sciezka do modulu (np. `src/modules/[feature]/`)
+- `{{COMPONENT_LIB_IMPORT}}` - import biblioteki komponentow (np. `@/components`)
+- `{{REVIEW_DATE}}` - data wykonania review
+- `{{FILES_CHANGED}}` - liczba zmienionych plikow
+- `{{LINES_ADDED}}` - liczba dodanych linii
+- `{{LINES_DELETED}}` - liczba usunietych linii
+- `{{COMPONENTS_COUNT}}` - liczba zmienionych komponentow
+- `{{TESTS_COUNT}}` - liczba plikow testowych
+- `{{TEST_COVERAGE}}` - procent pokrycia testami
+- `{{FILE_PATH}}` - sciezka do pliku w naruszeniu
+- `{{LINE_NUMBER}}` - numer linii w naruszeniu
+- `{{CRITICAL_COUNT}}` - liczba krytycznych naruszen
+- `{{IMPORTANT_COUNT}}` - liczba waznych naruszen
+- `{{SUGGESTION_COUNT}}` - liczba sugestii
+
+---
+
+## Jezyk odpowiedzi: **Polski**
+
+---
+
+## Jak uzywac tego prompta:
+
+1. Skopiuj cala zawartosc tego pliku
+2. Wklej do AI agenta (GitHub Copilot Chat / Claude / GPT)
+3. Agent automatycznie:
+   - Pobierze zmiany z git diff
+   - Przeanalizuje wszystkie pliki
+   - Zweryfikuje zgodnosc z zasadami
+   - Wygeneruje szczegolowy raport
+   - Podejmie decyzje o merge
+
+**Przykladowe wywolanie**:
+```
+@workspace Wykonaj code review mojego brancha zgodnie z promptem codereview.prompt.md
+```
+
+---
+**Uwaga:** Recenzja musi byc szczegolowa, oparta o konkretne zasady i dokumentacje projektu. Nie pomijaj zadnych naruszen.

package/templates/base/_ai/prompts/duplicate-code-analysis.prompt.md

@@ -0,0 +1,128 @@
+# Prompt: Analiza Duplikatow Kodu (Clone Detection)
+
+## Cel
+Przeprowadz kompleksowa analize kodu w repozytorium w celu identyfikacji powtarzajacych sie fragmentow (duplikatow), zarowno dokladnych jak i czesciowych (tzw. code clones poziomu 1-3). Wynik ma pomoc w redukcji dlugu technicznego, poprawie utrzymania i ograniczeniu ryzyka bledow.
+
+## Zakres Analizy
+Uwzglednij wszystkie pliki zrodlowe TypeScript, JavaScript, oraz komponenty UI, z wylaczeniem:
+- Plikow generowanych lub build artefaktow (`dist/`, `build/`, `node_modules/`)
+- Plikow konfiguracyjnych (np. `vite.config.ts`, `webpack.config.js`, `vitest.config.ts`)
+- Tresci dokumentacji (`doc/`, `docs/`)
+- Plikow jezykowych / tlumaczen - analizuj tylko ewentualne powtarzajace sie klucze jesli proszone, domyslnie pomin
+- Testow snapshotowych (jesli istnieja)
+
+Skup sie na:
+- `{{MODULE_PATH}}/components/**` (szczegolnie powtarzalne wzorce w Button, Inputs, Modals, Table)
+- `{{MODULE_PATH}}/composables/**` (powielone logiki async, obsluga bledow, loading)
+- `{{MODULE_PATH}}/modules/**` (powtarzalne fragmenty miedzy modulami - np. fetch, mapowanie danych, walidacje)
+- `{{MODULE_PATH}}/services/**` (podobne wywolania API z roznica w endpointach)
+- `{{MODULE_PATH}}/stores/**` (powtarzajace sie schematy definicji i mutacji state)
+
+## Typy Duplikacji Do Wykrycia
+1. Dokladne duplikaty (identyczny kod lub roznice w bialych znakach / nazwach zmiennych).
+2. Strukturalne podobienstwo (te same bloki kontrolne, rozne nazwy, te same operacje).
+3. Powtarzalne wzorce funkcji (np. async function z try/catch/finally ustawiajace loading i uzywajace dedykowanego error handlera).
+4. Powtarzalne interfejsy lub typy rozniace sie minimalnie (warto rozwazyc uogolnienie).
+5. Zduplikowane selektory i struktury template w komponentach (np. identyczne konfiguracje przyciskow / komponentow UI).
+6. Duplikaty walidacji (np. regex email, obsluga pustych pol, mapowanie statusow).
+7. Powtarzajace sie konfiguracje kolumn tabel / gridow.
+
+## Kontekst Architektoniczny (wazne dla rekomendacji)
+- Biznesowa logika powinna byc w composables (`useXxx`). Jesli podobne fragmenty istnieja w wielu composables - rozwazyc ekstrakcje do wspolnego utila.
+- Serwisy powinny byc cienkie i nie duplikowac logiki transformacji danych - jesli wystepuja, zaproponuj przeniesienie do dedykowanego mappera.
+- Store'y nie powinny powielac identycznych operacji mutujacych - rozwaz wspolne helpery (np. `createAsyncStateHandler`).
+- Kazdy user-facing text musi uzywac i18n - jesli duplikacja polega na wielu komponentach trzymajacych ten sam klucz + logike, rozwazyc wspolny wrapper komponent.
+
+## Format Wyniku
+Zwroc wynik w ponizszej strukturze (Markdown):
+
+```
+## Podsumowanie
+- Liczba zidentyfikowanych grup duplikatow: X
+- Priorytet wysokich (refaktoryzacja konieczna): Y
+- Szacowany % redukcji linii po refaktoryzacji: Z%
+
+## Grupy Duplikatow
+### Grupa {id} (Poziom: {1|2|3}, Priorytet: {wysoki|sredni|niski})
+Pliki:
+- path/to/fileA.ts: [linia start-linia end]
+- path/to/fileB.ts: [linia start-linia end]
+... (minimum 2)
+
+Wspolny wzorzec:
+```
+(kod/wzorzec uproszczony)
+```
+
+Roznice:
+- fileA: nazwa zmiennej userId vs fileB: id
+- fileC: dodatkowy catch branch
+
+Rekomendacja refaktoryzacji:
+- Zaproponuj: np. "Ekstrakcja do composable useAsyncLoader(fn)" / "Uogolnienie interfejsu IUserDetail -> IBaseUser".
+Szacowany zysk: -N linii, +spojnosc obslugi bledow.
+
+### Grupa ...
+
+## Potencjalne Wspolne Abstrakcje
+- Lista proponowanych nowych utili / composables / typow / fabryk.
+
+## Szybkie Wygrane (Quick Wins)
+- Wymien 3-5 prostych refaktoryzacji mozliwych w < 15 min.
+
+## Ryzyka / Uwaga
+- Wskaz gdzie refaktoryzacja moze naruszyc kontrakty API / testy.
+
+## Nastepne Kroki
+1. Zatwierdzenie listy priorytetow.
+2. Utworzenie planu refaktoryzacji w odpowiednim module `*-plan.md`.
+3. Dodanie testow zabezpieczajacych przed regresja.
+```
+
+## Kryteria Priorytetyzacji
+Wysoki priorytet jesli:
+- Fragmenty wystepuja w >=3 plikach.
+- Zawieraja logike biznesowa (walidacje, transformacje danych, obsluga bledow) lub wplywaja na UX.
+- Powoduja zwiekszone ryzyko niespojnosci (np. rozne wersje walidacji e-mail).
+
+Sredni priorytet:
+- Duplikacja struktur template bez powaznej logiki.
+
+Niski priorytet:
+- Male powtorzenia (<5 linii) lub tylko podobne nazwy.
+
+## Heurystyki Wykrywania (dla AI)
+- Szukaj ciagow: `try {` + `loading.value = true` / `setLoading(true)` + `catch (error)` + error handler + `finally`.
+- Szukaj powtarzajacych sie definicji interfejsow rozniacych sie pojedynczym polem.
+- Szukaj identycznych tablic `columnDefs` / `headers`.
+- Szukaj wielokrotnego uzycia podobnego regexu.
+- Szukaj komponentow UI z identycznym ukladem (np. powtarzajace sie konfiguracje przyciskow, inputow, modali).
+
+## Wykluczenia Specjalne
+- Ignoruj bootstrap i inicjalizacje aplikacji (`main.ts`, `App.vue`, `index.tsx`) jesli nie ma powtarzalnej logiki.
+- Ignoruj definicje typow oczywiscie rozne semantycznie (np. `IUser` vs `IRole`).
+
+## Jezyk Odpowiedzi
+- Odpowiedz w jezyku polskim.
+- Uzywaj zwiezlych zdan, bez wodolejstwa.
+
+## Styl Rekomendacji
+- Konkret: "Polacz funkcje fetchUsers i fetchUserList w services/userService.ts".
+- Unikaj ogolnikow typu: "Popraw jakosc kodu".
+
+## Kontrola Jakosci
+Na koncu dodaj sekcje:
+```
+## Walidacja
+- Czy pominieto pliki konfiguracyjne: TAK/NIE
+- Czy uwzgledniono composables: TAK/NIE
+- Czy zaproponowano min. 3 abstrakcje: TAK/NIE
+- Czy wskazano quick wins: TAK/NIE
+```
+
+## Zmienne
+
+- `{{MODULE_PATH}}` - sciezka bazowa do zrodel (np. `src/`)
+
+---
+Uzyj tego promptu aby uruchomic analize duplikatow i wygenerowac raport do dalszego planowania refaktoryzacji.

package/templates/base/_ai/prompts/figma-analysis.prompt.md

@@ -0,0 +1,155 @@
+```prompt
+
+# Figma View Analysis Prompt (for MCP & Copilot)
+
+## Purpose
+Perform a **full analysis of the Figma view**. Only identify components to use, describe the graphic layout and UI in detail. **Do not create or describe any implementation plan for our system.**
+
+## Scope
+- Focus exclusively on UI/UX analysis:
+  - Identify all UI components
+  - Describe layout, hierarchy, and visual structure
+  - List all states, interactions, and accessibility requirements
+  - Map mockup labels (e.g. Polish) to English technical names
+- **DO NOT include implementation steps, code plans, or system architecture.**
+
+## Language and Naming
+- All files, folders, modules, and components must be named in English
+- Mockup labels must be mapped to English technical names
+- Keep translations in i18n keys
+
+## Instructions
+1. **Extract Figma selection links**
+2. **Take screenshot via MCP and analyze** (do not save image)
+3. **List used components**
+4. **Describe the view in detail**:
+   - Layout, hierarchy, grid/flex structure
+   - States (loading, error, success, empty)
+   - Interactions (click, hover, modal, dropdown)
+   - Texts (with i18n key suggestions, keep original translations)
+   - Accessibility (ARIA, focus, keyboard navigation)
+   - Responsiveness (desktop/tablet/mobile)
+   - Validation rules (for forms)
+5. **Save analysis to .md file** in `{{MODULE_PATH}}/analysis/[view-name]-figma-analysis.md` (English names only)
+
+## Example Analysis File Structure
+
+```markdown
+# Figma Analysis: User List View
+
+**Analysis date**: 2025-10-15
+**Module**: `users`
+**View name**: `user-list`
+
+## Mockup Label to English Mapping (Translation)
+- "Lista uzytkownikow" -> User List
+- "Uzytkownicy" -> Users
+- "Dodaj uzytkownika" -> Add User
+- "Filtruj" -> Filter
+- "Szukaj" -> Search
+- "Status" -> Status
+- "Akcje" -> Actions
+
+## Figma Selection Links
+- https://www.figma.com/file/abc123?node-id=456:789
+
+## UI Components List
+
+### Main components (from {{COMPONENT_LIB_PATH}})
+- **Button**
+  - Variant: `primary`, `secondary`, `success`, `danger`
+  - Props: `disabled`, `loading`, `icon`
+
+- **InputText**
+  - Type: `text`, `email`, `password`, `search`
+  - Props: `placeholder`, `modelValue`, `error`, `required`
+
+- **Table**
+  - Props: `data`, `columns`, `loading`, `pagination`
+  - Columns: First Name, Last Name, Email, Status, Actions
+
+- **Loader**
+  - Props: `size`, `variant`
+
+### Custom components
+- **Statistics Chart** - Custom component
+
+## Detailed View Description
+
+### Structure and Layout
+- **Header** (top): View title + action button (Button primary)
+- **Filters Section** (middle-top):
+  - Search field (InputText search)
+  - Filter dropdown (Dropdown)
+  - "Filter" button (Button secondary)
+- **Main Content** (center):
+  - Users table (Table)
+  - Pagination (Pagination)
+- **Side Panel** (right): Statistics chart (custom)
+
+### View States
+- **Loading**: Full-screen Loader while loading data
+- **Error**: Alert/Notification type="error" with error message
+- **Empty**: EmptyState when no search results
+- **Success**: Display table with data
+
+### Interactions
+- **Search**: Input with 300ms debounce, search by name/email
+- **Filtering**: Dropdown with user status options
+- **Sorting**: Click on table column header
+- **Pagination**: Change page, change items per page
+- **Row Actions**: Edit, Delete (confirmation modal)
+
+### Texts and i18n
+- `user.list.title` - "Lista uzytkownikow"
+- `user.list.search.placeholder` - "Szukaj po nazwie lub email"
+- `user.list.filter.status` - "Filtruj po statusie"
+- `user.list.button.filter` - "Filtruj"
+- `user.list.button.add` - "Dodaj uzytkownika"
+- `user.list.table.firstName` - "Imie"
+- `user.list.table.lastName` - "Nazwisko"
+- `user.list.table.email` - "Email"
+- `user.list.table.status` - "Status"
+- `user.list.table.actions` - "Akcje"
+- `user.list.empty.title` - "Brak uzytkownikow"
+- `user.list.empty.description` - "Nie znaleziono uzytkownikow spelniajacych kryteria"
+
+### Accessibility (A11y)
+- Focus on search field after view loads
+- Aria-label on all action buttons
+- Keyboard navigation: Tab, Enter, Escape
+- Screen reader: aria-live for search results
+- Contrast ratio: WCAG AA (min 4.5:1)
+
+### Responsiveness
+- **Desktop (>1200px)**: Full layout with side panel
+- **Tablet (768-1200px)**: Side panel below table
+- **Mobile (<768px)**: Vertical stack, table with horizontal scroll
+
+### Validation
+- Describe any form validation rules present in the view
+
+```
+
+---
+
+## Important Reminders
+- **All files and folders in English** (e.g., `user-list-figma-analysis.md`, not localized names)
+- **All module names in English** (e.g., `{{MODULE_PATH}}/users/`, not localized module names)
+- **All component names in English** (e.g., `UserListView.vue`, not localized component names)
+- **Translate mockup labels** to English technical names (e.g., "Uzytkownicy" -> `users`)
+- **Keep translations in i18n keys** (e.g., `user.list.title` - "Lista uzytkownikow")
+- **Analysis file location**: `{{MODULE_PATH}}/analysis/[view-name]-figma-analysis.md`
+
+---
+
+## Variables
+
+- `{{MODULE_PATH}}` - path to the module directory (e.g., `src/modules/[module-name]`)
+- `{{COMPONENT_LIB_PATH}}` - path to the shared component library (e.g., `src/components`)
+
+---
+
+This prompt enables automatic analysis of Figma views via MCP screenshot, without saving images to the repository. Analysis is performed directly on the image, resulting in a detailed .md file with complete technical specification of the view, all in English for code structure while preserving original language for user-facing translations.
+
+---