Prompty

Chcę, abyś stworzył i wdrożył na tym serwerze kompletny, prosty i bezpieczny serwer MCP umożliwiający agentom AI wysyłanie powiadomień na mój telefon przez usługę Pushover.

Dane dostępowe do Pushover:

* User Key: [WSTAW_USER_KEY]
* API/Application Token: [WSTAW_API_TOKEN]

Potraktuj te dane jako sekrety. Nie zapisuj ich bezpośrednio w kodzie aplikacji, plikach dostępnych publicznie ani w repozytorium Git. Umieść je w bezpiecznej konfiguracji, np. zmiennych środowiskowych lub pliku konfiguracyjnym znajdującym się poza katalogiem publicznym serwera [WWW](http://WWW).

Twoim zadaniem jest samodzielne zaprojektowanie, utworzenie, skonfigurowanie, wdrożenie i przetestowanie rozwiązania.

Serwer MCP powinien udostępniać narzędzie:

`send_notification`

Narzędzie ma umożliwiać agentowi AI wysłanie wiadomości przez Pushover.

Minimalnym wymaganym parametrem powinna być:

* `message` – treść wiadomości.

Dodatkowo obsłuż opcjonalne parametry:

* `title` – tytuł powiadomienia,
* `priority` – priorytet wiadomości,
* `sound` – dźwięk powiadomienia Pushover,
* `url` – opcjonalny adres URL,
* `url_title` – tekst wyświetlany zamiast adresu URL,
* `html` – możliwość użycia formatowania HTML, jeśli Pushover to obsługuje,
* `device` – opcjonalne wskazanie konkretnego urządzenia,
* `timestamp` – opcjonalny czas zdarzenia.

Jeżeli dany parametr nie zostanie podany, użyj bezpiecznych i rozsądnych wartości domyślnych.

Zadbaj o poprawną walidację danych wejściowych. Agent nie powinien być w stanie wysłać przypadkowo błędnego żądania, nieprawidłowego priorytetu, zbyt długiej wiadomości lub wartości nieobsługiwanej przez API Pushover.

W przypadku błędu zwracaj agentowi jednoznaczną informację, np.:

* czy błąd nastąpił po stronie MCP,
* czy połączenie z Pushover nie działa,
* czy Pushover odrzucił żądanie,
* czy podano niepoprawne parametry.

Nie zwracaj w komunikatach błędów żadnych sekretów, tokenów ani danych uwierzytelniających.

## Bezpieczeństwo

MCP nie może być publicznie dostępny bez zabezpieczenia.

Zabezpiecz dostęp własnym tokenem autoryzacyjnym lub innym prostym mechanizmem odpowiednim dla tego zastosowania.

Token dostępu do MCP:

* wygeneruj losowo,
* zapisz poza publicznym katalogiem WWW,
* nie umieszczaj w kodzie źródłowym,
* nie zapisuj w repozytorium,
* pokaż mi go na końcu instalacji razem z instrukcją konfiguracji klienta.

Jeżeli serwer MCP będzie dostępny przez Internet, użyj HTTPS.

Jeżeli na serwerze istnieje już poprawnie skonfigurowany serwer WWW, reverse proxy lub certyfikat Let's Encrypt, wykorzystaj istniejącą infrastrukturę zamiast tworzyć niepotrzebnie nowe komponenty.

Nie otwieraj dodatkowych portów publicznych, jeżeli nie jest to konieczne.

## Architektura

Najpierw sprawdź środowisko serwera i dostępne technologie.

Wybierz możliwie proste i lekkie rozwiązanie.

Jeżeli obecna konfiguracja serwera pozwala wykonać MCP w PHP, możesz użyć PHP. Jeśli istnieje istotny techniczny powód, dla którego inne rozwiązanie będzie wyraźnie lepsze, możesz zastosować np. Node.js lub Python, ale wyjaśnij krótko swoją decyzję.

Nie instaluj dużych frameworków ani zbędnych zależności.

Priorytety:

1. prostota,
2. bezpieczeństwo,
3. stabilność,
4. łatwość utrzymania,
5. minimalna liczba zależności.

Rozwiązanie powinno nadawać się do długotrwałego działania na VPS.

## Integracja z Pushover

Do komunikacji wykorzystaj oficjalne API Pushover.

Obsłuż poprawnie odpowiedź API i zwracane przez nie błędy.

Jeżeli Pushover zwraca identyfikator żądania lub inne informacje diagnostyczne przydatne do debugowania, możesz je zachować w logach, ale nie zapisuj danych wrażliwych.

Dźwięk powinien być parametrem opcjonalnym, tak aby agent mógł np. wysłać:

zwykłe powiadomienie:

`send_notification(message="Backup zakończony poprawnie")`

powiadomienie z tytułem:

`send_notification(title="Backup", message="Backup serwera został wykonany")`

alarm:

`send_notification(title="ALARM VPS", message="Wykryto poważny problem z serwerem", priority=1, sound="siren")`

Jeżeli nazwa dźwięku jest nieprawidłowa, obsłuż sytuację w kontrolowany sposób.

## Priorytety wiadomości

Jeżeli API Pushover obsługuje różne poziomy priorytetów, zaimplementuj je zgodnie z dokumentacją.

Zabezpiecz szczególnie najwyższy poziom priorytetu, jeśli wymaga dodatkowych parametrów lub powoduje powtarzające się alarmy.

Nie ustawiaj najwyższego priorytetu jako wartości domyślnej.

Domyślny priorytet powinien oznaczać zwykłe powiadomienie.

## Logowanie

Dodaj proste logowanie zdarzeń.

Loguj:

* datę i godzinę,
* czy wysłanie wiadomości się powiodło,
* wynik odpowiedzi Pushover,
* podstawowe informacje diagnostyczne przy błędzie.

Nie zapisuj w logach:

* User Key,
* API Token Pushover,
* tokenu zabezpieczającego MCP,
* pełnych nagłówków autoryzacyjnych.

Jeżeli to możliwe, nie zapisuj również pełnej treści prywatnych wiadomości. Wystarczy informacja o poprawnym wysłaniu lub ewentualnie skrócona treść diagnostyczna.

## Testy

Po wdrożeniu przeprowadź test całego rozwiązania.

Wykonaj co najmniej:

1. zwykłe powiadomienie,
2. powiadomienie z tytułem,
3. powiadomienie z wybranym dźwiękiem,
4. test błędnego żądania,
5. test dostępu bez poprawnego tokenu MCP.

Wyślij testową wiadomość:

`Test MCP Pushover – połączenie działa poprawnie.`

Jeżeli wiadomość zostanie poprawnie przyjęta przez API Pushover, uznaj integrację za działającą.

Nie wykonuj dużej liczby testowych powiadomień.

## Dokumentacja

Po zakończeniu przygotuj krótką dokumentację administratora.

Podaj:

* gdzie znajduje się kod MCP,
* gdzie znajduje się konfiguracja,
* gdzie zapisane są sekrety,
* gdzie znajdują się logi,
* pod jakim adresem działa MCP,
* jak uruchomić lub zrestartować usługę,
* jak sprawdzić jej status,
* jak zaktualizować User Key lub API Token Pushover,
* jak zmienić token dostępu do MCP.

Jeżeli utworzysz usługę systemd, podaj jej nazwę.

## Konfiguracja Claude Code

Na końcu przygotuj dokładną konfigurację potrzebną do podłączenia tego MCP do Claude Code.

Nie opisuj jej tylko słownie.

Podaj gotowy fragment konfiguracji do skopiowania.

Konfiguracja powinna zawierać:

* adres MCP,
* wymagany sposób autoryzacji,
* token MCP lub miejsce, w którym należy go wstawić,
* nazwę serwera MCP.

Nazwij serwer:

`pushover`

Po podłączeniu Claude Code powinien widzieć narzędzie:

`send_notification`

Podaj również przykład użycia tego narzędzia przez agenta.

## Końcowy raport

Po zakończeniu przedstaw krótki raport w formacie:

### Status

Czy MCP działa poprawnie.

### Adres MCP

Adres endpointu.

### Dostępne narzędzia

Lista dostępnych narzędzi MCP.

### Zabezpieczenie

Jak MCP jest chronione.

### Pliki

Najważniejsze pliki i ich lokalizacje.

### Test

Wynik testowego powiadomienia Pushover.

### Claude Code

Gotowa konfiguracja do wklejenia.

### Przykładowe użycie

Przykład zwykłego powiadomienia i alarmu.

### Utrzymanie

Komendy potrzebne do sprawdzenia statusu, restartu oraz podejrzenia logów.

Nie kończ zadania wyłącznie na napisaniu kodu. Doprowadź wdrożenie do stanu, w którym MCP faktycznie działa na tym serwerze i zostało przetestowane.

Nie zmieniaj niezwiązanych z zadaniem elementów konfiguracji serwera. Nie wyłączaj istniejących zabezpieczeń, firewalla ani usług. Jeżeli wykryjesz konflikt z istniejącą konfiguracją, dostosuj rozwiązanie do środowiska zamiast przebudowywać serwer.

Jeżeli podczas realizacji znajdziesz drobne kwestie techniczne, które możesz jednoznacznie i bezpiecznie rozwiązać samodzielnie, zrób to bez pytania mnie o każdą decyzję. Pytaj tylko wtedy, gdy wykonanie operacji wiązałoby się z ryzykiem uszkodzenia istniejącej konfiguracji lub wymaga podjęcia istotnej decyzji dotyczącej architektury.

Stwórz na tym serwerze prosty serwer MCP do wysyłania powiadomień przez Pushover. Użyj mojego User Key i API Token. Dodaj narzędzie send_notification, które przyjmuje treść wiadomości oraz opcjonalnie: tytuł, priorytet, dźwięk, URL i HTML. Zabezpiecz dostęp tokenem, przechowuj sekrety poza katalogiem publicznym i po wdrożeniu przetestuj działanie. Na końcu podaj mi konfigurację potrzebną do podłączenia MCP do Claude Code.

[Sesja admin] Zrób pełny audyt serwera: dystrybucja i kernel, serwer www i vhosty, PHP z rozszerzeniami, baza danych, SSL, firewall, poczta, sposób wgrywania plików (SSH/FTP/git), zajęte domeny i subdomeny. Zapisz wynik w pamięci projektu, żeby odpowiadać z niej innym sesjom bez ponownego sprawdzania.

[Sesja strony] Chcę zbudować prostą stronę w HTML, PHP i CSS. Zapytaj sesję {bloczekAdmin}, czy serwer to obsłuży i pod jaką domeną/katalogiem możemy ją wystawić, a jeżeli czegoś brakuje, ustal z nią, co trzeba doinstalować. Za każdym razem, gdy potrzebujesz zmiany na serwerze, proś o to sesję admina.

Napisz mi lokalny skill projektu bez używania skilli Superpowers; po podaniu linku do YouTube albo samego ID filmu sprawdź, czy w podkatalogu filmy/{id}/ istnieje już plik {id}.mp4, a jeśli go nie ma, pobierz materiał z YouTube, przy czym dla samego ID najpierw zweryfikuj, czy taki film istnieje, a jeśli nie, poproś o link lub ręczne skopiowanie pliku; jeśli obraz nie jest potrzebny do dalszej analizy, pobieraj tylko audio; następnie wykonaj pełną transkrypcję za pomocą Whispera, automatycznie dobierając model i sposób działania do specyfikacji mojego sprzętu, wygeneruj napisy z timecodami w formacie nadającym się bezpośrednio do wgrania na YouTube oraz plik Markdown zawierający trzy propozycje tytułu — opisową, chwytliwą i zoptymalizowaną pod SEO — opis odcinka z rozdziałami i słowami kluczowymi SEO, hasztagi oraz tagi YouTube z zachowaniem obowiązujących limitów; samodzielnie zainstaluj wszystkie wymagane zależności i narzędzia, uporządkuj pliki wynikowe w katalogu filmu i dodaj odpowiedni .gitignore, aby duże pliki multimedialne, modele, cache i pliki tymczasowe nie trafiały do repozytorium.

Przygotuj plik .bat startujący sesje Claude Code; skrypt najpierw aktualizuje Claude Code, ale błąd aktualizacji ma tylko wyświetlić ostrzeżenie i nie blokować dalszego działania, następnie skanuje wszystkie podfoldery bieżącego katalogu i dla każdego uruchamia osobną sesję Claude Code w nowej zakładce tego samego okna Windows Terminal z włączonym remote control i skip permissions; nazwa zakładki oraz nazwa sesji remote control mają być identyczne z nazwą katalogu, a Claude nie może nadpisywać tytułu zakładki; pomiń podfoldery zawierające plik .skipclaude, po zakończeniu sesji zakładka ma pozostać otwarta, abym mógł zobaczyć wynik działania, a cały skrypt ma nadawać się do uruchamiania przy starcie Windows.

Sprawdź najpierw, co jest już zainstalowane na serwerze i jaka jest dostępna wersja systemu, a następnie zaproponuj stack oparty wyłącznie na pakietach dostępnych w oficjalnych repozytoriach tego systemu; potrzebuję serwera WWW do prostych stron i WordPressa z aktualnym PHP oraz MySQL lub MariaDB, zoptymalizowanego pod szybkość i PageSpeed, kompletnego serwera poczty z nowoczesnym i bezpiecznym stackiem, filtrem antyspamowym, DKIM, SPF, DMARC, webmailem i certyfikatami TLS, a także firewalla i fail2ban skonfigurowanych tak, aby przed zastosowaniem zmian działał timer bezpieczeństwa chroniący przed odcięciem mi dostępu; po przygotowaniu konfiguracji podaj dokładne rekordy DNS, które mam ustawić, i zatrzymaj się do czasu mojego potwierdzenia; po potwierdzeniu dokończ konfigurację, przetestuj wysyłkę poczty w mail-tester na podany przeze mnie adres, sprawdź odbiór wiadomości z zewnątrz, zweryfikuj poprawne działanie webmaila wraz z logo, przeprowadź audyt wykonanych zmian i na końcu zapisz pamięć oraz kontekst sesji.

Zrób po kolei: 

* utwórz dla siebie osobnego użytkownika z sudo, aby można było odróżnić twoje sesje od moich
* skonfiguruj dla niego logowanie kluczem SSH
* wygeneruj klucz dla mnie i przygotuj logowanie jako ubuntu bez hasła
* skonfiguruj połączenie w PuTTY wraz z konwersją klucza do PPK i zapisaniem sesji bez otwierania GUI
* przeprowadź audyt konfiguracji sshd
* wyłącz logowanie hasłem dopiero po potwierdzeniu działania obu kluczy
* zmień port SSH z 22 na 2222 dwuetapowo tak, aby nie utracić dostępu do serwera
* przed każdą zmianą mogącą zerwać połączenie upewnij się, że istnieje działająca droga powrotna
* na końcu zapisz pamięć i kontekst sesji
* jeśli brakuje potrzebnego narzędzia, najpierw zapytaj mnie, czy możesz je doinstalować.

Wrzuciłem Ci do katalogu plik MP4 z pierwszym odcinkiem mojej serii na kanale wąchock.exe — przeprowadź transkrypcję do tekstu i zapoznaj się z treścią odcinka, następnie sprawdź w Google Autocomplete i podpowiedziach YouTube, czego ludzie najczęściej szukają w temacie instalacji Claude Code, jego konfiguracji i pierwszego uruchomienia, podaj 10–20 najpopularniejszych fraz, a na ich podstawie napisz opis odcinka do wklejenia na YouTube zawierający 5 najpopularniejszych fraz, dodaj timecody, jeśli materiał warto podzielić na rozdziały, oraz listę tagów opartą na tych frazach do 500 znaków; zapisz wszystko w nowym pliku i nie nadpisuj istniejących.

Utwórz mi zaplanowane zadanie uruchamiane codziennie o godzinie 05:00.

Nazwa zadania: „Poranny przegląd GitHuba”.

Przy każdym uruchomieniu wykonaj następujące zadanie:

Przejrzyj wszystkie repozytoria GitHub należące do połączonego użytkownika. Pomiń repozytoria należące do innych osób lub organizacji, do których użytkownik ma tylko dostęp jako współpracownik albo gość.

Podstawowy zakres analizy stanowi poprzednia pełna doba kalendarzowa: od godziny 00:00 poprzedniego dnia do godziny 00:00 bieżącego dnia.

Dodatkowo uwzględnij commity utworzone bieżącego dnia pomiędzy godziną 00:00 a 02:00. Traktuj je jako przedłużenie poprzedniej sesji pracy i sprawdź je razem z poprzednią dobą.

Przed analizą każdego repozytorium sprawdź czas jego najnowszego commita dostępnego na GitHubie.

Jeżeli najnowszy commit bieżącego dnia został utworzony:

między 00:00 a 02:00 — przeanalizuj repozytorium normalnie i uwzględnij również te commity,
po 02:00, a przed uruchomieniem zadania o 05:00 — uznaj repozytorium za nadal aktywnie rozwijane i pomiń je w całości w tym uruchomieniu.

W takim przypadku zaznacz w raporcie:

„Repozytorium pominięte — aktywna praca po godzinie 02:00”.

Nie analizuj części zmian z takiego repozytorium, ponieważ podczas trwającej pracy późniejsze commity mogą modyfikować lub naprawiać wcześniejsze zmiany.

Przy następnym uruchomieniu, gdy repozytorium nie będzie już aktywnie rozwijane po godzinie 02:00, przeanalizuj wszystkie wcześniej pominięte i dotąd niesprawdzone commity.

Prowadź logiczną ciągłość analizy w taki sposób, aby:

żadna zmiana nie została pominięta,
żadna zmiana nie została przeanalizowana dwukrotnie,
commity z bieżącego dnia z godzin 00:00–02:00, które zostały już sprawdzone wcześniej, nie były ponownie analizowane następnego dnia.

Jeśli nie można wiarygodnie ustalić ostatniego sprawdzonego commita lub zakresu wcześniej przeanalizowanych zmian, zaznacz to wyraźnie w raporcie zamiast zgadywać.

Analizuj przede wszystkim diffy i bezpośrednio zmienione pliki. Możesz odczytać tylko minimalny, bezpośrednio powiązany fragment kodu potrzebny do potwierdzenia użycia zmienionej funkcji, typu, trasy lub konfiguracji. Nie wykonuj pełnej analizy ani audytu całego repozytorium.

Zrób szybki przegląd pod kątem:

błędów składni,
oczywistych błędów logicznych, odwróconych warunków, kodu nieosiągalnego i brakujących return,
błędnych lub brakujących importów, ścieżek, nazw, tras, zmiennych środowiskowych i odwołań,
niezdefiniowanych albo niezainicjalizowanych wartości,
możliwych null, dzielenia przez zero i wyjścia poza zakres,
nieobsłużonych wyjątków, odrzuconych Promise i błędów API,
prostych regresji oraz niezgodności zmienionych sygnatur funkcji lub formatów API z ich użyciami widocznymi w zmianach,
pozostawionych TODO, FIXME, console.log, var_dump, dd i podobnego kodu debugującego,
przypadkowo ujawnionych sekretów, tokenów, haseł, kluczy API lub prywatnych danych,
łatwo zauważalnych SQL injection, XSS, command injection, path traversal, braków walidacji danych wejściowych, błędnego filtrowania danych wyjściowych, problemów z autoryzacją oraz wyłączenia SSL, CSRF lub kontroli uprawnień,
podejrzanych albo zbędnych nowych zależności,
przypadkowo dodanych dużych plików, archiwów, logów, kopii baz i plików tymczasowych,
ryzykownych migracji baz danych mogących usuwać dane,
oczywistych problemów wydajnościowych, takich jak zapytania w pętli lub możliwa pętla nieskończona,
braku aktualizacji testów, gdy zmiana jednoznacznie modyfikuje istniejące zachowanie.

Jeśli jest to możliwe bez szerokiego skanowania projektu, wykonaj wyłącznie lekkie kontrole składni lub testy bezpośrednio odnoszące się do zmienionych plików.

Zgłaszaj tylko problemy wynikające z analizowanego zakresu zmian. Nie zgłaszaj istniejących wcześniej problemów i nie twórz listy ogólnych ulepszeń. Ogranicz fałszywe alarmy. Niczego nie zmieniaj w repozytoriach.

Przygotuj zwięzły raport po polsku. Dla każdego znaleziska podaj:

repozytorium, commit i plik, opis problemu, istotność, krótkie uzasadnienie oraz sugestię poprawki.

Każde znalezisko oznacz jednym z poziomów pewności:

„błąd pewny”
„wysokie ryzyko”
„do sprawdzenia”

Oddziel fakty od przypuszczeń.

Jeśli w analizowanym zakresie nie było zmian albo nie znaleziono problemów, napisz to krótko.

Utwórz to jako aktywne zadanie cykliczne, codziennie o 05:00.

Przeprowadź kompleksowy audyt bezpieczeństwa i kondycji serwera Ubuntu na podstawie dostępnych lokalnie danych diagnostycznych.

Najpierw samodzielnie rozpoznaj serwer:

* odkryj dostępne źródła logów, w tym `/var/log`, logi rotowane i skompresowane oraz dziennik systemd;
* ustal, jakie usługi, aplikacje, kontenery i mechanizmy systemowe działają lub działały na serwerze;
* sprawdź, czy poszczególne usługi zapisują logi w standardowych, czy niestandardowych lokalizacjach;
* określ zakres czasowy każdego dostępnego źródła;
* wykryj istotne źródła, do których nie masz dostępu albo które nie zawierają oczekiwanych danych.

Następnie przeanalizuj wszystkie odkryte źródła. Nie korzystaj z zamkniętej, z góry ustalonej listy usług, plików ani zagrożeń. Dostosuj analizę do rzeczywistej konfiguracji i przeznaczenia tego serwera.

Koreluj zdarzenia między różnymi źródłami, szukaj anomalii, powtarzających się problemów, nietypowych zmian zachowania, zdarzeń bezpieczeństwa, awarii oraz symptomów problemów z zasobami lub konfiguracją. Ustalaj ich możliwe przyczyny i skutki. Nie kończ analizy tylko dlatego, że nie znalazłeś typowych błędów.

Działaj wyłącznie w trybie odczytu:

* nie zmieniaj plików, konfiguracji, uprawnień ani stanu systemu;
* nie instaluj i nie usuwaj pakietów;
* nie uruchamiaj ponownie usług ani serwera;
* nie zatrzymuj procesów, nie blokuj adresów i nie podejmuj działań naprawczych;
* nie wykonuj poleceń, które mogą zapisać dane lub zmienić stan systemu;
* ogranicz obciążenie serwera i unikaj kosztownych, nieograniczonych operacji;
* nie wysyłaj logów ani znalezionych danych do usług zewnętrznych.

Przedstaw ustalenia według pilności. Dla każdego podaj:

* datę lub przedział czasu;
* usługę lub komponent, jeżeli można je ustalić;
* źródło logu;
* krótki, zanonimizowany przykład;
* możliwą przyczynę i wpływ;
* oznaczenie: potwierdzony fakt, prawdopodobny wniosek albo hipoteza;
* poziom pewności: wysoki, średni albo niski;
* zalecany sposób dalszej weryfikacji lub naprawy, bez wykonywania tej czynności.

Wyraźnie oddziel:

1. problemy krytyczne;
2. problemy ważne;
3. pozostałe obserwacje;
4. typowy szum i niegroźne zdarzenia;
5. zalecane dalsze kroki;
6. ograniczenia analizy.

Nie ujawniaj haseł, tokenów, kluczy, ciasteczek, danych osobowych ani innych sekretów znalezionych w logach. Maskuj je również w przykładach.

W ograniczeniach wymień pominięte okresy, niedostępne źródła, brakujące uprawnienia oraz usługi, dla których nie udało się odnaleźć logów. Na końcu podaj listę wykonanych poleceń diagnostycznych. Jeśli napotkasz brak uprawnień, nie obchodź zabezpieczeń — tylko opisz, czego nie udało się sprawdzić.

Przeprowadź audyt bezpieczeństwa i kondycji serwera Ubuntu na podstawie logów w /var/log, w tym logów rotowanych i skompresowanych, oraz dziennika systemd. Najpierw rozpoznaj dostępne źródła i zakres czasowy, następnie analizuj ich zawartość bez ograniczania się do z góry ustalonej listy zagrożeń lub błędów. Koreluj zdarzenia między usługami, szukaj anomalii i ustalaj ich możliwe przyczyny. Działaj wyłącznie w trybie odczytu. Przedstaw najważniejsze ustalenia według pilności, popierając je przykładami z datą i źródłem; oddziel fakty od hipotez i typowego szumu. Podaj zalecane dalsze kroki oraz ograniczenia analizy, w tym pominięte źródła lub okresy. Nie ujawniaj sekretów znalezionych w logach.