Jak nauczyć Claude'a pisać Twoim głosem

Ile to realnie trwało i ile musi trwać u Ciebie

• Cztery i pół miesiąca kalendarzowo — ale większość tego czasu poszła na odkrywanie struktury, którą teraz masz gotową.
• 108 wywołań /internalize w 43 dniach — od 14 maja do 12 sierpnia 2026, licząc własne wiadomości Piotra, w których pada „/internalize"; dokładna reguła liczenia jest w sekcji Źródła. To wszystkie wywołania tej komendy, także po postach, dokumentach i innych skillach, a nie tylko rundy po wysłanym mailu. Strukturę i prompty, które z tych rund wyszły, dziedziczysz gotowe.
• Nieskracalna zostaje tylko jedna rzecz: liczba prawdziwych wysyłek. Pętla karmi się realnymi wiadomościami, więc tempo wyznacza to, jak często piszesz, a nie jak szybko konfigurujesz.

Realistyczny plan dla Ciebie: dwie sesje na start, potem 8–12 wysyłek z pętlą. Przy normalnej korespondencji to dwa, trzy tygodnie do momentu, w którym poprawki wyraźnie rzedną. To nie jest ten sam punkt, w którym jest dziś skill Piotra po ponad stu rundach — na klasy wiadomości, których jeszcze nie wysłałaś, zasad po prostu nie ma i pojawią się dopiero z kolejnych wysyłek.

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. If you cannot reach my mailbox, read them instead from the .mbox file at the path I give you, or from the messages I pasted above — everything below is the same on all three paths. 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), whether Polish diacritics are written in full or dropped when I write fast, 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. Then save the whole result — the table and the verbatim examples, nothing summarised away — to ~/.claude/skills/writing-style/_corpus-measurement.md, creating the folder if it does not exist, and tell me the path you wrote.

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. Save the full table to ~/.claude/skills/writing-style/_corpus-pairs.md and tell me the path you wrote.

Prompt 3 — zbuduj skill z tego, co zmierzyłeś

First read ~/.claude/skills/writing-style/_corpus-measurement.md. If it is missing or empty, stop and tell me to rerun prompt 1 — do not work from memory and do not fill the gap with general knowledge. Then read ~/.claude/skills/writing-style/_corpus-pairs.md as well; if that one is missing, do not stop — say so and continue from the measurement alone, because on a mailbox you could not reach there are no draft/sent pairs to extract. Then check whether ~/.claude/skills/writing-style/ already holds a SKILL.md or references files. If it does, copy the whole folder to ~/.claude/writing-style-backup-<today's date>/ before touching anything — that path is deliberately outside ~/.claude/skills/, because any folder there containing a SKILL.md becomes a second live skill competing for the same trigger phrases — and merge instead of overwriting: keep every rule that is already there, add the measured ones, and at the end report what you kept, what you merged and what you dropped, with the reason for each drop.

Create the personal skill at ~/.claude/skills/writing-style/SKILL.md plus one references file per channel or class of message I actually use, based only on those two files. 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; and, if the measurement in _corpus-measurement.md shows that I skip Polish diacritics when writing fast, rule number two being: write full Polish diacritics in every Polish message, even where my own sent messages skip them, because I never want them missing in what goes out. 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

First check whether ~/.claude/skills/internalize/ already exists. If it does, copy the whole folder to ~/.claude/internalize-backup-<today's date>/ before touching anything — that path is deliberately outside ~/.claude/skills/, because any folder there containing a SKILL.md becomes a second live skill competing for the same trigger phrases — and merge instead of overwriting: keep every instruction that is already there, add the ones below, and at the end report what you kept, what you merged and what you dropped, with the reason for each drop.

Now create a second skill at ~/.claude/skills/internalize/SKILL.md that I will run after sending a message. Its job: fetch from my mailbox the version that actually went out — and if it cannot reach my mailbox, ask me to paste the sent version and work from that, never inferring or reconstructing what went out — then diff that against the draft you produced, and for each difference that qualifies under the filter below, infer the general rule that would have produced my version first time.

The draft side of that diff must be a draft you actually wrote. The skill looks for it in the current conversation. It does not look in my Gmail drafts: Gmail deletes a draft the moment it is sent and creates a new message with a different id, so after sending there is nothing there to recover. If the draft is not in the conversation, the skill tells me to reopen the session it was written in with claude --resume and run internalize there, and only if that session is gone does it ask me to paste the draft — it never reconstructs, rewrites or guesses what the draft probably said, because a diff against an invented draft produces invented rules. If several of my messages went out since the last run, it asks once which one we are learning from. If several drafts of that same message exist in the conversation, it asks once which of them we are learning from, listing two or three candidates, and defaults to the first draft it produced for that message, counting every revision I asked for in between as a difference too. The never-ask rule below covers writing rules, not identifying the draft.

Not every difference is a rule. A one-off factual correction — a number, a date, a name, a fact I added or removed — is reported to me as a tactical note and never written into the skill. Only differences about form, tone, structure, length or register get generalised into rules. If nothing qualifies, the skill says "nothing new to internalize" and writes nothing; a run that produces zero rules is a correct run, not a failure.

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 no existing references file fits the rule, it creates one named after the channel or the class of message and adds its row to the routing table in SKILL.md in the same run — a references file with no routing row never gets loaded again, so creating the file without the row is a silent failure. Before writing any rule it checks that the rule statement names no person, company, address or date — if one appears, it raises the rule to the class of recipient or class of message and keeps the name underneath as an example. It keeps SKILL.md under 200 lines, and if a references 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ść".

Prompt 5 — treść jednej rundy pętli

I just sent that one. Fetch the version that actually went out; if you cannot reach my mailbox, ask me to paste the sent version and work from that instead of inferring what went out. Diff it against the draft you produced — look for that draft in this conversation. Do not look for it in my Gmail drafts: Gmail deletes a draft the moment it is sent, so it is no longer there. If it is not in this conversation, tell me to reopen the session it was written in with claude --resume and run this there; only if that session is gone, ask me to paste it instead of reconstructing it. If several of my messages went out since the last run, ask which one. If several drafts of that same message exist in this conversation, ask once which one and default to the first draft you produced for it, counting every revision I asked for in between as a difference too. For every difference that is about form, tone, structure, length or register, infer the general rule that would have produced my version first time. A one-off factual correction — a number, a date, a name, a fact I added or removed — is not a rule: report it to me as a note and do not write it. If nothing qualifies, say "nothing new" and write nothing. Write the rules that do qualify into the matching references file, merging where a close rule already exists; if no file fits, create one and add its row to the routing table in the same run. Then list one line per rule: what changed and why.

Gdy masz już zainstalowany skill z promptu 4, wystarczy napisać „internalize" — reszta jest w skillu. Rób to w tej samej sesji, w której powstał draft, bo tylko tam Claude go jeszcze widzi. Cała sekcja Pętla jest o tym, jak z tego zrobić nawyk.

Prompt dodatkowy — reguły techniczne Gmail API

Ten prompt i lista pod nim dotyczą jednego przypadku: Claude sam składa wiadomość i zapisuje ją przez Gmail API, tak jak u Piotra. Konektor Gmaila z claude.ai to inna droga: tam wiadomość składa konektor, a nie Claude, więc nie masz gdzie tych reguł zastosować i możesz cały dodatek pominąć. Dokumentacja konektora wymienia jako jego możliwości wyszukiwanie i czytanie maili, tworzenie wersji roboczych, dostęp do metadanych, etykiety i wątki oraz listę zapisanych wersji roboczych, a jako ograniczenie podaje brak wysyłki, brak treści załączników i część zaawansowanych filtrów. O edycji istniejącej wersji roboczej ani o kontroli nad strukturą MIME czy formatowaniem HTML nie mówi nic w żadną stronę — ta strona po prostu nie wie, czy to działa. Wracasz tu dopiero, gdy podłączysz własną integrację.

If references/gmail-api.md already exists in the writing-style skill, copy it to ~/.claude/writing-style-backup-<today's date>/ first — outside ~/.claude/skills/, so the copy cannot turn into a second live skill — and merge into it rather than replacing it, keeping every rule that is already there and reporting what you kept and what you added. Otherwise create references/gmail-api.md in the writing-style skill and put the technical rules listed below in this prompt 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.

Gotowiec techniczny — te same reguły po polsku, do sprawdzenia po fakcie

• 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.

Jedna z tych reguł obowiązuje niezależnie od tego, czym Claude pisze do skrzynki, więc warto ją mieć zawsze: wersja robocza tak, wysyłka nigdy bez Twojej decyzji. Dochodzi do niej jedna spoza tej listy — diakrytyki uzupełniane za Ciebie w każdym mailu, jeśli piszesz szybko i gubisz ogonki; prompt 3 dopisuje ją sam, na każdej ścieżce, ale tylko wtedy, gdy pomiar z promptu 1 rzeczywiście to u Ciebie pokaże. Tanie zasady, a widać je w pierwszym zdaniu.

Czym uruchamiasz jedną rundę

Treść jest w prompcie 5 w sekcji Start. Gdy masz już zainstalowany skill z promptu 4, nie musisz go wklejać — wystarczy napisać „internalize" po wysłaniu wiadomości, a reszta jest w skillu.

Uruchamiaj rundę w tej samej sesji, w której powstał draft. Gmail kasuje wersję roboczą w chwili wysłania, więc draftu nie da się już odzyskać ze skrzynki. Jeśli sesja jest zamknięta, otwórz ją z powrotem: Claude Code zapisuje każdą sesję na dysk, więc komenda claude --resume pozwala wybrać tę właściwą z listy i uruchomić rundę w niej, z draftem nadal na miejscu. Wklejanie draftu ręcznie zostaje dopiero wtedy, gdy tej sesji już nie ma — a na ścieżce z zasady numer 6, gdzie draftu nie widziałaś w czacie, jedyną kopią jest to, co sama skopiujesz do notatki przed wysłaniem.

Bez podłączonej skrzynki ta sama runda wymaga wklejenia także wysłanej wersji, zaraz po słowie „internalize". Działa, tylko kosztuje jeden ruch więcej za każdym razem — i to jest ten ruch, na którym pętle najczęściej umierają.

Higiena, bez której to się rozpada po kilkudziesięciu zasadach

• Limit na plik — 200 linii dla SKILL.md, 250 dla pliku tematycznego. To są własne, ostrzejsze limity Piotra, nie liczby z dokumentacji: dokumentacja skilli mówi „trzymaj SKILL.md poniżej 500 linii", a próg 200 linii pada w dokumentacji pamięci projektowej, przy plikach instrukcji CLAUDE.md, wraz z powodem — dłuższe pliki zużywają więcej kontekstu i obniżają stosowanie się do nich. Ten sam powód wystarczy, żeby zejść niżej niż 500: SKILL.md wczytuje się zawsze, więc dostaje ostrzejsze 200. Plik tematyczny może być o pięćdziesiąt linii dłuższy, bo w jednym zadaniu wczytuje się tylko jeden z nich.
• Scalanie zamiast dopisywania — jeśli nowa zasada jest bliska istniejącej, dochodzi jako kolejny przykład pod nią. Dwie prawie identyczne zasady to gwarancja, że któraś zostanie zignorowana.
• Podział w tej samej sesji — przekroczony limit dzieli się od razu, nie „kiedyś". Odłożony podział nigdy się nie odbywa.
• Filtr nazw własnych przed zapisem — przed dopisaniem zasady sprawdzenie, czy nie wpadło nazwisko, firma, adres albo data.

Wszystkie cztery są wpisane w prompt 4, więc od pierwszego dnia pilnują się same — łącznie z filtrem nazw własnych i limitem 200 linii, które muszą być właśnie tam, a nie tylko w prompcie budującym skill. Powód jest prosty: po pierwszej wysyłce każdą kolejną zasadę pisze już pętla, a nie Ty. Warto jednak wiedzieć, po co te reguły są, bo pierwszy odruch przy każdej z nich jest odwrotny.

Czego nie da się wyciągnąć z korpusu i trzeba dopisać ręcznie

• Rzeczy, których nigdy nie wysłałaś — pierwszy kontakt z nowym typem odbiorcy, twarda odmowa, negocjacja. Nie ma ich w skrzynce, więc pojawią się dopiero z pętli.
• Świadome zmiany stylu — jeśli chcesz pisać inaczej niż dotąd, korpus tego nie wie. To dopisujesz sama, jako zwykłą zasadę w tym samym formacie.
• Strategia, nie forma — komu odpowiadać w kopii, czego nie stawiać na piśmie, kiedy nie odpisywać od razu. To osobne pliki, dokładnie tak samo zbudowane.