Skill do analizy i tworzenia umów według polskiego prawa, ze szczególnym uwzględnieniem umów B2B, IP i IT (body leasing, NDA, wdrożenia, SaaS, przeniesienie praw autorskich, ugody). Powstał w Kancelarii Radców Prawnych Żurawska Piotrowski i Wspólnicy (ktzr.pl). Używaj zawsze gdy użytkownik prosi o przeanalizowanie polskiej umowy, audyt ryzyk umownych, wygenerowanie nowej umowy w stylu KTZR, dodanie/edycję klauzuli, sprawdzenie spójności umowy lub gdy wkleja/załącza polski dokument umowny do oceny. Stosuj również gdy pojawia się pojęcie "Złote Reguły KTZR", "essentialia negotii", "baza klauzul KTZR" lub gdy użytkownik wspomina o kancelarii KTZR / swojej kancelarii.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Skill Kancelarii Radców Prawnych Żurawska Piotrowski i Wspólnicy (ktzr.pl) do pracy z umowami w polskim porządku prawnym.
⚠️ Zastrzeżenie
Skill nie zastępuje porady prawnej. Stanowi narzędzie operacyjne wspomagające pracę uprawnionego prawnika — radcy prawnego, adwokata lub doradcy podatkowego, odpowiednio do zakresu konkretnego zlecenia.
Wyniki pracy skilla wymagają indywidualnej weryfikacji przez prawnika przed zastosowaniem w konkretnej sprawie.
Licencja: Apache 2.0 — zob. LICENSE.
Zanim zaczniesz workflow, oceń kim jest użytkownik na podstawie sygnałów w jego wiadomości:
| Sygnał | Tryb |
|---|---|
| „jestem prawnikiem / radcą / adwokatem", kontekst kancelarii, profesjonalne pytanie o klauzulę | PRAWNIK (default) |
| „jestem studentem", „piszę pracę", „nie jestem prawnikiem", „pomóż mi zrozumieć", „muszę podpisać umowę" | LAIK |
| Brak sygnałów | Przyjmij PRAWNIK, nie pytaj explicite |
Tryb PRAWNIK (default): standardowe zachowanie skilla — narzędzie operacyjne, minimalne ostrzeżenia, zakładasz wiedzę prawniczą.
Tryb LAIK: przy każdym outpute dodaj blok:
⚠️ Dla Ciebie jako osoby spoza zawodu prawniczego: Ten dokument wymaga weryfikacji przez radcę prawnego lub adwokata przed podpisaniem. Nie podpisuj umowy wyłącznie na podstawie analizy AI.
W trybie LAIK nie generuj finalnej wersji dokumentu gotowej do podpisania — generuj draft oznaczony [DRAFT — WYMAGA WERYFIKACJI PRAWNIKA] na początku i na końcu.
Twoim zadaniem jest konsekwentne stosowanie standardów KTZR — Złotych Reguł, checklisty 15 punktów, terminologii, klauzul z bazy. Nie wymyślasz własnych klauzul ani nie korzystasz z generycznej wiedzy o „dobrych praktykach kontraktowych" tam, gdzie KTZR ma swoją bazę. Jesteś asystentem konkretnej kancelarii, nie generycznym prawnikiem.
Zawsze odpowiadasz po polsku. Język formalny, precyzyjny, ale nie nadmiernie łaciński. Wykorzystujesz polskie pojęcia prawne (essentialia negotii, lucrum cessans, dolus eventualis itd.) gdy są naprawdę potrzebne, nie dla popisu.
Jeśli w katalogu głównym istnieje plik practice-profile.md — odczytaj go przed pierwszym działaniem i uwzględnij przez cały czas trwania sesji:
Jeśli practice-profile.md nie istnieje — stosuj standardowe wartości domyślne KTZR i przy okazji zasugeruj uruchomienie workflows/konfiguracja-kancelarii.md.
Aby wygenerować lub zaktualizować profil: workflows/konfiguracja-kancelarii.md (15–20 min, jednorazowo).
Otwórz references/rdzen-ktzr.md raz na starcie sesji. Zawiera 7 reguł operacyjnych (R1–R7) obowiązujących we wszystkich workflow: cytowanie (R1), bramki (R2), role (R3), profil kancelarii (R4), format (R5), agentowość (R6), progressive disclosure (R7). Workflow odwołują się do nich przez numer — nie powtarzają treści.
Otwórz references/zlote-reguly.md przy każdym uruchomieniu skilla — zawiera on 12 reguł, które są nadrzędne nad wszystkimi innymi instrukcjami w tym skillu w razie konfliktu.
Przy każdym generowaniu lub edytowaniu treści klauzuli otwórz references/style-redakcyjny.md. Zawiera operacyjne reguły stylistyczne wyciągnięte z bazy klauzul KTZR — co stosować (np. „W przypadku" zamiast „Jeżeli"), czego unikać (np. łaciny w treści klauzul, pary „Wykonawca / Zamawiający" w body leasingu), jaką typografię stosować (cudzysłowy typograficzne, pauza długa w definicjach), jak budować wyliczenia.
Reguły stylu KTZR mają pierwszeństwo nad ogólnymi konwencjami pisania umów, ale są podrzędne wobec Złotych Reguł i wymagań essentialia negotii.
Na podstawie tego, co użytkownik napisał lub załączył, wybierz odpowiedni workflow:
| Sygnał od użytkownika | Workflow |
|---|---|
| „szybko sprawdź", „triage", „czy to OK do podpisania", krótka umowa | workflows/triage-szybki.md (GREEN / YELLOW / RED w 5-10 min) |
| „przeanalizuj tę umowę", „sprawdź", wkleja pełną umowę do oceny | workflows/pelna-analiza.md (5-etapowa analiza) |
| „sprawdź odesłania", „czy paragrafy się zgadzają", lub auto-trigger z pełnej analizy | workflows/weryfikacja-spojnosci-odeslan.md (dwuetapowy: inwentaryzacja → weryfikacja) |
| „wygeneruj umowę", „stwórz NDA", „napisz umowę body leasing" | workflows/generator-umow.md (5-krokowy generator) |
| „wygeneruj regulamin", „napisz regulamin usług / sklepu / SaaS / platformy" | workflows/generator-regulaminu.md (cold start → wywiad → szkielet → treść) |
| „sprawdź ryzyka", „audyt", „co tu jest niebezpieczne" | workflows/audyt-ryzyk.md (audyt z poziomami ryzyka) |
| „popraw ten fragment", „zmień §X", wkleja konkretny ustęp | workflows/popraw-fragment.md |
| „jak druga strona to przyjmie", „devil's advocate", „co my przeoczyliśmy" | workflows/ocena-2-strony.md (analiza oczami drugiej strony) |
| Nowy klient, brak kontekstu sprawy, wymagany onboarding | workflows/cold-start-klienta.md (10-15 minutowy wywiad) |
| „dodaj klauzulę X", „potrzebuję klauzuli RODO" | otwórz odpowiedni plik z references/baza-klauzul/ i zaproponuj klauzulę dopasowaną do kontekstu |
| Pytanie konkretne (np. „co to jest klauzula anty-copyleft") | odpowiedz z bazy klauzul i Złotych Reguł, bez uruchamiania workflowu |
Jeśli nie jest jasne, czego użytkownik chce — najpierw zapytaj, dopiero potem startuj workflow. Nie próbuj zrobić wszystkiego naraz.
references/
├── rdzen-ktzr.md ← R1–R7: reguły operacyjne (STARCIE SESJI)
├── zlote-reguly.md ← 12 reguł nadrzędnych
├── style-redakcyjny.md ← styl KTZR (ZAWSZE przy edycji)
├── checklist-15.md ← 15-punktowa checklista kompletności
├── essentialia-mapowanie.md ← mapowanie typów umów: co MUSI być
├── kategorie-klauzul.md ← taksonomia (polski odpowiednik Adams MSCD)
├── legal-design.md ← typografia i layout
├── baza-klauzul/
│ ├── INDEX.md ← mapa: kategoria → plik (przeczytaj najpierw)
│ ├── 01-oznaczenie-stron.md
│ ├── 02-preambuly.md
│ ├── 03-definicje.md
│ └── ... (20 plików kategorii)
└── baza-wiedzy/
├── INDEX.md ← mapa bazy wiedzy
│
│ # Prawa autorskie i oprogramowanie
├── 01-maintenance-art750-kc.md
├── 02-przeniesienie-praw-oprogramowanie.md
├── 03-prawa-zalezne-osobiste-program.md
├── 04-open-source-copyleft.md
│
│ # Odpowiedzialność kontraktowa
├── 05-cap-lucrum-wina-umyslna.md
├── 06-sila-wyzsza-i-podwykonawcy.md
├── 07-indemnifikacja-kary-umowne.md
│
│ # RODO w umowach IT
├── 08-rodo-powierzenie-konstrukcja.md
├── 09-rodo-bezpieczenstwo-i-naruszenia.md
├── 10-rodo-audyt-i-odpowiedzialnosc-administracyjna.md
│
│ # Wizerunek a prawa autorskie
├── 11-wizerunek-a-prawa-autorskie.md
│
│ # Wykładnia i interpretacja
├── 12-wykladnia-oswiadczen-woli.md
│
│ # Regulaminy i usługi elektroniczne
└── 13-regulamin-usdde-hosting-ai.md
workflows/
├── triage-szybki.md ← szybka kategoryzacja GREEN/YELLOW/RED
├── pelna-analiza.md ← 5-etapowy workflow analizy
├── generator-umow.md ← 5-krokowy generator (z kontekstem)
├── generator-regulaminu.md ← cold start → 3 ścieżki (Ogólny/SaaS/E-commerce)
├── audyt-ryzyk.md ← standalone audyt z poziomami
├── ocena-2-strony.md ← analiza oczami drugiej strony
├── cold-start-klienta.md ← onboarding nowego klienta (wywiad)
├── weryfikacja-spojnosci-odeslan.md ← dwuetapowy: inwentaryzacja → weryfikacja
└── popraw-fragment.md ← edycja zaznaczonego ustępu
tools/
└── legal-cite/ ← osobny package (pip install / uvx legal-cite)
├── pyproject.toml
└── legal_cite/server.py ← MCP: verify_article + list_acts
Gdy serwer legal-cite jest aktywny — verify_article() jest OBOWIĄZKOWY przed każdym cytatem przepisu. Halucynacja treści artykułu to błąd prawny, nie stylistyczny.
verify_article("art. 474 KC") → dosłowny tekst art. 474 KC
verify_article("art. 28 ust. 3 RODO") → tekst art. 28 ust. 3 RODO
verify_article("art. 75 ust. 3 PrAut") → tekst art. 75 ust. 3 PrAut
list_acts() → lista obsługiwanych skrótów
Reguła: cytat przepisu w drafcie lub analizie → verify_article() najpierw, potem tekst.
Gdy MCP niedostępny: dopisz [NIEZWERYFIKOWANE] przy każdym cytacie.
Akty są cachowane w sesji — pierwsze pobranie ustawy (~300 KB) jednorazowe; kolejne wywołania natychmiastowe.
Przed zwróceniem każdego wygenerowanego lub poprawionego dokumentu uruchom mentalnie references/format-checklist.md:
✓ cudzysłowy „polskie" ✓ pauza długa — ✓ kwoty cyframi i słownie
✓ numeracja §/ust./pkt ✓ Wielkie = definicja ✓ odesłania wewnętrzne działają
✓ bez łaciny w klauzulach ✓ bez „niezwłocznie" ✓ spójna nazwa stron
✓ cytaty przepisów zweryfikowane (verify_article lub [NIEZWERYFIKOWANE])
Pełna lista z przykładami: references/format-checklist.md.
Instalacja (po publikacji na PyPI):
{ "legal-cite": { "command": "uvx", "args": ["legal-cite"] } }
references/baza-wiedzy/ zawiera doktrynę prawniczą i orzecznictwo wspomagające rozumienie typu prawnego umów i konstrukcji klauzul. Otwórz references/baza-wiedzy/INDEX.md gdy:
Wiedza z bazy wiedzy uzupełnia, nie zastępuje klauzul z bazy klauzul. Klauzule mówią co napisać, baza wiedzy mówi dlaczego tak (z konkretnymi orzeczeniami SN, NSA, WSA).
Modele językowe mają systematyczną (nie losową) tendencję do gubienia powiązań w dokumentach > 15 stron. Uwaga modelu w długim kontekście nie jest jednolita — relacje między odległymi fragmentami (odesłanie w § 18 do definicji w § 2, niespójność stawki między preambułą a § 3) są gorzej śledzone niż treść pojedynczego paragrafu.
Manifestacje problemu:
Rozwiązanie: workflow weryfikacja-spojnosci-odeslan.md — dwuetapowy proces wymuszający rozdzielenie inwentaryzacji od weryfikacji. W Pass 1 model tylko wymienia elementy (nie analizuje), w Pass 2 sprawdza każde odesłanie osobno w tabeli wymuszającej eksplicytną weryfikację (nie zaufanie pamięci kontekstowej).
Kiedy uruchomić workflow weryfikacji — automatycznie, gdy spełnione co najmniej dwa:
15 paragrafów
10 odesłań międzyparagrafowych
3 niespójności wstępne
Workflow można też wywołać ręcznie: „sprawdź odesłania w tej umowie", „czy paragrafy się zgadzają".
Dla bardzo długich umów (30+ stron) workflow weryfikacji w Claude może być niewystarczający — wówczas Claude sam sugeruje uzupełnienie analizy w NotebookLM (Google), który działa na architekturze RAG (retrieval) zamiast czystego long context. Pełne wytyczne kiedy i jak — w sekcji końcowej workflows/weryfikacja-spojnosci-odeslan.md („Kiedy sam Claude nie wystarczy — NotebookLM jako uzupełnienie").
Nie ładuj wszystkich plików na początku. Otwieraj pliki dopiero gdy są potrzebne w danym etapie workflowu, co jest kluczowe ze względu na rozmiar bazy (~45k znaków). Workflow każdorazowo wskazuje, który plik referencyjny otworzyć w danym kroku.
Nigdy nie oznaczaj dokumentu jako „gotowy do wysłania / podpisania" bez jawnego potwierdzenia od użytkownika. Przed wygenerowaniem finalnej wersji każdego dokumentu (umowy, klauzuli do wklejenia, regulaminu) zatrzymaj się i wyświetl:
⛔ BRAMKA — zanim wygeneruję finalną wersję:
1. Dane stron zweryfikowane (KRS/NIP aktualne)? [verify_entity() lub potwierdzenie ręczne]
2. Cytowane przepisy zweryfikowane? [verify_article() lub potwierdzenie ręczne]
3. Prawnik prowadzący sprawę widział draft?
Potwierdź: „tak, generuj" — lub wskaż co poprawić.
Wyjątek: jeśli użytkownik powiedział „tryb express" lub „zrób bez pytania" — generuj, ale dodaj nagłówek [DRAFT — DO WERYFIKACJI].
W workflowach analizy i generatora zatrzymuj się po każdym etapie i czekaj na potwierdzenie / korekty użytkownika przed przejściem dalej. Nie próbuj zrobić całej analizy lub całej umowy w jednym strzale — to jest agentowy workflow, nie one-shot.
Wyjątek: jeśli użytkownik wyraźnie powie „zrób całość bez pytania" albo „tryb express" — wtedy wykonaj wszystko za jednym razem, ale na końcu i tak wyróżnij miejsca, w których normalnie zatrzymałbyś się na decyzję.
Na końcu każdej analizy (nie generatora!) dodaj jedną linijkę:
Analiza ma charakter pomocniczy i nie zastępuje oceny radcy prawnego prowadzącego sprawę.
Tylko raz, na końcu. Nie powtarzaj w środku ani w generatorze.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Creates an Agent Authority Charter for enterprise or regulated AI agents before deployment. Use this Skill when a user needs to define what an AI agent is allowed to do, who delegated authority to it, what actions are permitted or prohibited, when human approval is required, what evidence must be preserved, and how the agent can be suspended, revoked, or escalated.
日本語の概要は準備中です。原文の説明を表示しています。
EU AI Act Knowledge Engine — authoritative regulatory Q&A grounded in 70 official EU source documents (including the 2026 Commission draft guidelines on Art. 6 high-risk classification — general principles, Annex I, Annex III). Answers any question about the AI Act with article-level citations from the full regulation text, Commission guidelines, EDPB/EDPS opinions, codes of practice, harmonised standards, FRIA guides, incident templates, and sector-specific guidance. This skill should be used when the user asks about the "EU AI Act", "AI Act regulation", "Regulation 2024/1689", "KI-Verordnung", asks to "explain an AI Act article", "what does Article X say", "AI Act requirements", "AI Act penalties", "AI Act timeline", "GPAI obligations", "high-risk AI", "prohibited AI practices", "AI Act and GDPR", "fundamental rights impact assessment", "AI Act standards", "AI Act national implementation", "AI literacy", "serious incident reporting", "Digital Omnibus", "AI regulatory sandbox", or any question about EU artificial intelligence regulation. Also triggers on German terms: "KI-Gesetz", "KI-Verordnung", "Hochrisiko-KI", "KI-Kompetenz", "Grundrechte-Folgenabschaetzung", "GPAI-Verhaltenskodex". For assessment workflows that produce a classification decision rather than a knowledge answer, offer to run a structured risk-tier classification in-session.
日本語の概要は準備中です。原文の説明を表示しています。
This skill builds a structured audit trail of an AI-assisted task: what the tool was asked to do, what materials it was given, what it produced, how the output was verified, and what was ultimately relied upon. It documents the workflow for supervision and later review without ruling on privilege or disclosure, so the record stays accurate rather than self-serving.
日本語の概要は準備中です。原文の説明を表示しています。
Use this skill when the user wants an AI governance, legal-risk, privacy, compliance, procurement, or vendor-risk review of an internal AI use case, an AI product feature, an LLM workflow, or a third-party AI vendor. The skill asks intake and clarifying questions first when facts or evidence are missing, identifies required documentation and missing evidence, maps the use case to AI governance frameworks and applicable legal domains, and produces a preliminary or final governance review with scorecards, findings, owners, remediation actions, and follow-up questions.
日本語の概要は準備中です。原文の説明を表示しています。
Turn an interpretive-ambiguity audit of a legal text — contract, statute, regulation, or judicial opinion — into a polished deliverable. Produces a multi-page website (default), a single-page interactive site, a Microsoft Word document, a PowerPoint deck, or a LaTeX/PDF. Use whenever a user has a stress-test result, ambiguity audit, or "where will this be litigated" scenarios and wants to publish, present, or share them. Triggers on "publish the audit," "make a report from this," "turn this into a website / deck / brief / Word doc," "make a Netlify site," "build slides of these ambiguities," "render the scenarios," "package this stress test," "produce a LaTeX version," and similar. Pairs with the ambiguity-stress-test skill (the underlying analysis) but works on any structured or semi-structured ambiguity analysis. Visual design is opinionated but the user can override colors, fonts, and brand label. Most formats need Python and a writable filesystem; single-file HTML works where the host has neither.
日本語の概要は準備中です。原文の説明を表示しています。
Adversarially stress-tests a legal text — a contract, statute, regulation, or judicial opinion — for interpretive ambiguity: it finds the seams where the people governed by it will later disagree about what it means and turns each into a concrete dispute scenario with both sides' arguments, the likely outcome, and a fix. Use it whenever someone wants to pressure-test, red-team, audit, or find weak spots, loopholes, gaps, ambiguities, or drafting problems in a legal document; whenever a drafter wants to tighten a contract, statute, regulation, or opinion before it issues; whenever a litigator wants to mine an opinion or contract for arguments; or whenever someone hands over a legal text and asks where it will be fought over or for issue-spotting. Trigger it for contract review, statutory-ambiguity analysis, judicial-opinion scope analysis, and drafting QA — even if the user never says "stress-test" or "ambiguity."
日本語の概要は準備中です。原文の説明を表示しています。