| name | intake-sufficiency-pl |
| description | Ocena wystarczalnosci zlecenia/briefu na WEJSCIU - zanim zaczniesz prace prawna, sprawdza czy masz dosc kontekstu: jasny cel, zdefiniowany zakres, zidentyfikowany podmiot, fakty/dokumenty, ograniczenia. Wypisuje luki i niejednoznacznosci, generuje pytania uzupelniajace do zadania klientowi, sklada szkielet karty zlecenia. Lustro legal-request-router-pl: router ocenia jaka kontrole dac OUTPUTOWI, ten skill ocenia czy WEJSCIE wystarcza, by w ogole zaczac. Uzywaj gdy: "czy mam dosc zeby zaczac", "ocen brief", "czego brakuje w zleceniu", "jakie pytania zadac klientowi", "czy to zlecenie jest kompletne", "luki w brief", "doprecyzuj zlecenie", "intake", na poczatku nowej sprawy / po pierwszym kontakcie / po bookingu spotkania.
|
| license | Apache-2.0 |
| allowed-tools | ["Read"] |
| data-residency | local |
| requires-human-approval | false |
| pii-egress | none |
| attribution | [{"source":"AnttiHero/lavern","license":"Apache-2.0","relationship":"pattern-only","note":"Wzorzec analizy wystarczalności zlecenia przed przyjęciem sprawy. Schemat i rubryka napisane od zera.\n"},{"source":"akunikkola/claude-for-legal-finland","license":"MIT","relationship":"adaptation","note":"Weryfikacja premis prawnych klienta („premissien tarkistus”) dodana w v1.1.\n"}] |
| metadata | {"author":"Wiesław Mazur / MateMatic","version":"1.1.0","companion_skills":"legal-request-router-pl, let-it-be, citation-grounding-pl"} |
Intake Sufficiency PL - ocena wystarczalnosci zlecenia
Filozofia
Polowa zlych opinii prawnych to nie blad analizy, tylko zbyt cienkie wejscie. Klient pisze
"sprawdzcie te umowe", po czym okazuje sie, ze nie wiadomo wobec jakiego ryzyka, kto jest druga
strona ani jaki jest cel. Ten skill nazywa to, czego brakuje, ZANIM zacznie sie praca - i zamienia
luki w konkretne pytania do klienta, zamiast w domysly wpisane do deliverable.
Skill nie wykonuje pracy prawnej. Ocenia kompletnosc wejscia i generuje pytania.
Lustro routera
legal-request-router-pl patrzy na zadanie i decyduje, jaka kontrole dac outputowi (grounding / debata / paczka).intake-sufficiency-pl patrzy na zlecenie i decyduje, czy wejscie wystarcza, by zaczac.
Naturalna kolejnosc: najpierw intake-sufficiency (czy mam dosc), potem praca, potem router (jak skontrolowac wynik).
Rubryka wystarczalnosci (6 wymiarow, 0-100)
| Wymiar | Pytanie kontrolne | Waga |
|---|
| Cel | Czy wiadomo, po co klient przychodzi (opinia / audyt / pismo / negocjacja)? | 20 |
| Zakres | Czy zakres jest zdefiniowany (co wchodzi, co nie)? | 20 |
| Podmiot | Czy strony / podmiot sa zidentyfikowane (nazwa, NIP/KRS, rola)? | 15 |
| Fakty | Czy sa dokumenty albo stan faktyczny do oparcia analizy? | 20 |
| Ograniczenia | Czy znane sa twarde ograniczenia (deadline, budzet, poufnosc, jurysdykcja)? | 15 |
| Kryteria sukcesu | Czy wiadomo, co dla klienta znaczy dobry wynik? | 10 |
Werdykt: strong >= 80, adequate >= 50, insufficient < 50.
Workflow
- Pseudonimizuj wejscie przez
let-it-be, jesli zawiera dane objete tajemnica.
- Oceń zlecenie wg 6 wymiarow rubryki - kazdy wymiar ma fakty na poparcie oceny, nie ogolnik.
- Wypisz luki i niejednoznacznosci - co konkretnie jest nieobecne lub niejasne.
- Wyodrebnij premisy prawne klienta - kazde twierdzenie PRAWNE w zleceniu ("termin juz minal",
"umowa jest niewazna, bo brak formy", "przepis X tego zakazuje", "mamy 14 dni na odpowiedz")
to . Klient moze sie mylic co do prawa, a analiza zbudowana
na blednej premisie jest bledna w calosci, nawet gdy rozumowanie jest poprawne. Kazda premise:
