Start · dwie sesje
Dzień pierwszy: wyciągnij styl z własnej skrzynki, zamiast go opisywać.
Poniżej sześć gotowych promptów. Wklejasz je po kolei, jeden na raz, czekając na wynik. Prompty są po angielsku, bo pliki skilla piszemy po angielsku — Claude i tak pisze maile po polsku, dokładnie tak jak u Piotra. Przykłady zdań w tych plikach zostają po polsku, w oryginale.
Prompt 1 — zmierz mój styl na moich wysłanych mailach
Read the last 60 emails I sent, newest first, skipping one-line logistics replies. Do not ask me how I write, and do not use anything I have told you about my style — I want you to measure it from the messages themselves.
For each email record: recipient class (client, colleague, friend, vendor, institution), language, word count, number of paragraphs, the exact greeting, the exact sign-off, whether it ends with a question or an ask, punctuation habits (dashes, ellipses, exclamation marks, emoji), and any phrase that repeats. Then report the 3 to 5 recipient classes I actually write to, and for each one: median length, the greeting and sign-off inventory with frequencies, the sentence-length range, and 5 verbatim sentences that are most typical of me. Flag anything that varies too much to become a rule. Table plus verbatim examples. Write nothing to disk yet.
Prompt 2 — znajdź pary „wersja pierwsza kontra wersja wysłana"
Now find the pairs, which are the highest-signal training data I have. Search my mailbox for cases where a first version exists and a different final version went out: drafts written for me that I edited before sending, texts someone else wrote that I rewrote, and threads where I sent a corrected version of my own earlier message.
For each pair give me three columns: what the first version said, what I changed it to, and the smallest general rule that would have produced my version the first time. The rule must not name a person, a company, or a date — if it does, raise it one level until it is about a class of recipient or a class of message. Sort by how often the same change repeats, because a change I made once is noise and a change I made five times is a rule.
Prompt 3 — zbuduj skill z tego, co zmierzyłeś
Create the personal skill at ~/.claude/skills/writing-style/SKILL.md plus one references file per channel I actually use, based only on what you measured in the two previous steps. Nothing invented, nothing from general advice about business writing.
SKILL.md gets YAML frontmatter with name and a description listing my real trigger phrases in Polish and English, most important first. Then the iron rules that hold in every channel, with rule number one being: read this skill before drafting anything, every time. Then a routing table mapping each kind of message to its references file. Cap SKILL.md at 200 lines and every references file at 250. Every rule takes exactly this shape: a line saying do X instead of Y, then a Why line stating the reason at the level of a class of message, then a How to apply line stating the trigger. No person, company or date inside a rule statement — those go under it as examples. Put my own verbatim sentences under the rules they illustrate.
Prompt 4 — zainstaluj pętlę uczenia
Now create a second skill at ~/.claude/skills/internalize/SKILL.md that I will run after sending a message. Its job: fetch the version that actually went out from my mailbox, diff it against the draft you produced, and for each difference infer the general rule that would have produced my version first time.
It writes those rules into the matching references file, merging into an existing rule when one is close instead of appending a near-duplicate. If a file goes over 250 lines it splits the most self-contained topic into a new references file and fixes the routing table in the same run. It never asks for approval before writing, and it finishes by listing one line per rule: what changed and why. Give its description the trigger words "internalize", "ucz się z tego", "zapamiętaj na przyszłość".
Jeśli Claude nie ma dostępu do skrzynki
- Ścieżka zapasowa — pobierz swoją pocztę przez Google „Pobieranie danych", wskaż tylko Mail, i podaj Claude'owi ścieżkę do pliku z folderem Wysłane.
- Ścieżka minimalna — wklej 25-30 własnych wysłanych maili z różnych klas odbiorców. To wystarczy na pierwszą wersję, choć pary z promptu 2 są wtedy niedostępne.
Dostęp do skrzynki jest wart zachodu jednorazowo, bo bez niego pętla po wysyłce wymaga wklejania wysłanej wersji ręcznie za każdym razem.
Tego nie kopiuj od Piotra
Zasady głosu
Jak zaczyna maile, czym je kończy, jak stawia prośbę, kiedy pisze krótko. To jest jego głos zbudowany na jego korespondencji. Skopiowany daje drafty, które brzmią jak on — czyli dokładnie ten problem, który próbujesz rozwiązać.
To skopiuj w całości
Mechanika i zasady techniczne
Struktura skilla, limity plików, tabela routingu, cały mechanizm uczenia i reguły obsługi Gmaila. Nie mają nic wspólnego z tym, jak piszesz — a kosztowały kilkanaście rund poprawek, żeby je znaleźć.
Gotowiec techniczny — reguły Gmaila, które i tak będziesz chciała mieć
- Treść maila budowana jako HTML, nigdy jako czysty tekst — czysty tekst łamie się twardo co 76 znaków, więc w Gmailu wychodzi wąska, poszarpana kolumna z przerwami w środku zdań, a wątek pod spodem przestaje się zwijać. To najczęściej zgłaszany objaw „mail wygląda dziwnie".
- Zero własnego kroju, rozmiaru i interlinii — jeden blok tekstu, akapity rozdzielone pojedynczą pustą linią. Własne ustawienia czcionki nadpisują Twoje domyślne w Gmailu i mail wygląda jak wklejony z innego programu.
- Odpowiedź zawsze z pełną zacytowaną historią wątku, przeniesioną w oryginalnej postaci. Historia przepisywana ręcznie albo poprzedzana znakami większości rozjeżdża zagnieżdżone cytaty.
- Poprawka istniejącej wersji roboczej to podmiana samego fragmentu tekstu, nigdy zbudowanie wiadomości od nowa. Przebudowa po cichu gubi załączniki i cytowany wątek, a w podglądzie wszystko wygląda w porządku.
- Odpowiadaj na ostatnią prawdziwą wiadomość w wątku, pomijając wersje robocze. Odpowiedź podpięta pod wersję roboczą psuje wątek po stronie odbiorcy.
- Podpis tylko w mailach pisanych od zera, nigdy w odpowiedzi w wątku, gdzie i tak jest już niżej.
- Sprawdzenie po zapisaniu, że wersja robocza naprawdę zawiera część HTML z cytowanym wątkiem. Samo „tekst cytatu jest obecny" przechodzi także wtedy, gdy wątek się nie zwija.
- Wersja robocza tak, wysyłka nigdy bez Twojej decyzji — to jedyne miejsce, w którym potwierdzenie ma sens.
Jeśli piszesz szybko i gubisz ogonki, dołóż jeszcze jedną: w każdym mailu diakrytyki mają być uzupełnione za Ciebie. Tania zasada, a widać ją w pierwszym zdaniu.
Prompt 6 — wgraj gotowiec techniczny
Create references/gmail-api.md in the writing-style skill and put the technical rules below into it, each in the standard shape: the rule, then Why, then How to apply. These are mechanics, not voice, so take them as given rather than deriving them from my mailbox. Add a row for this file to the routing table with the trigger: any task that creates or updates an email draft through the API.
The rules: build every body as multipart HTML and never as plain text, because plain text hard-wraps at 76 columns and breaks both the rendering and the collapsing of quoted history. Set no font family, size or line height, and separate paragraphs with a single blank line. Include the full quoted thread in every reply, carried over in its original HTML rather than re-rendered. When editing an existing draft, replace only the new-content section and never rebuild the message from the body string, because a rebuild silently drops attachments and the quote. Select the reply target from real messages only, excluding drafts. Append the signature only to messages written from scratch, never to a reply. After writing a draft, assert that a text/html part exists and contains the quoted thread. Create and update drafts freely, never send.
