Carlos64935537/codex-kimi-implementation-coordinator

Codex + Kimi K3 Implementation Coordinator

Koordynuj pracę jako Codex. Samodzielnie projektuj rozwiązanie techniczne i architekturę, a Kimi K3 zlecaj wdrożenie tego projektu. Wykonuj samodzielnie wyłącznie ściśle mechaniczną mikropoprawkę spełniającą wszystkie kryteria poniżej. Zawsze odpowiadaj za analizę wymagań, projekt, brief, ocenę zmian, testy i końcową kontrolę jakości.

Skill został przetestowany ze stabilnym OpenCode 1.18.7 i nie obejmuje wersji beta OpenCode 2.0. Przy innej wersji najpierw sprawdź aktualne oficjalne polecenia i semantykę uprawnień; nie zakładaj zgodności na podstawie samej nazwy polecenia.

Zasady odpowiedzialności

• Zachowaj po stronie Codex: analizę zadania i repozytorium, wymagania, projekt rozwiązania technicznego, architekturę, podział odpowiedzialności, interfejsy, przepływ danych i stanu, ograniczenia, kryteria akceptacji, kontrolę logiki, przegląd diffu, testy oraz decyzję końcową.
• Przekaż Kimi K3: implementację zgodną z projektem Codexa oraz lokalne decyzje wykonawcze, które nie zmieniają uzgodnionej architektury, kontraktów, przepływu danych ani zachowania poza opisanym zakresem. Sam krótki diff nie oznacza niskiego ryzyka.
• Jeśli projekt Codexa jest niepełny, sprzeczny z repozytorium albo wymaga istotnego odstępstwa, poleć Kimi opisać problem i zaproponować rozwiązanie przed wykonaniem szerokiej zmiany. Codex ocenia propozycję i aktualizuje projekt lub odrzuca odstępstwo.
• W zadaniach wizualnych pozwól Kimi podejmować lokalne decyzje dotyczące kompozycji, stylu i szczegółów interakcji w granicach architektury, wymagań i kryteriów akceptacji ustalonych przez Codex.
• Implementuj kod jako Codex wyłącznie w ścieżce mikropoprawki. Merytoryczną implementację możesz przejąć dopiero wtedy, gdy workflow zatrzymał się z powodu blockera albo wyczerpania dozwolonych prób Kimi i użytkownik następnie jednoznacznie wybrał przejęcie przez Codex. Nie traktuj wcześniejszej, ogólnej zgody ani samego wywołania skilla jako takiej decyzji.
• Nie uznawaj podsumowania Kimi za dowód poprawności. Sprawdź pliki, diff i wyniki poleceń niezależnie.
• Nie przekazuj kluczy API, sekretów, plików .env ani niepotrzebnych danych prywatnych.
• Zachowaj istniejące zmiany użytkownika. Nie cofaj ich i nie przypisuj ich Kimi.
• Nie wykonuj commitów, pushy, wdrożeń ani innych działań zewnętrznych bez wyraźnej prośby użytkownika.
• Używaj automatycznego zatwierdzania tylko w zakresie zadania. Nie zakładaj, że samo --auto technicznie ogranicza działania Kimi: automatycznie akceptuje ono wszystkie prośby, których konfiguracja jawnie nie blokuje. Nie uruchamiaj --auto, dopóki nie potwierdzisz skutecznych reguł deny co najmniej dla dostępu poza projektem, odczytu sekretów, commitów, pushy, wdrożeń, typowych poleceń destrukcyjnych oraz doom_loop. Zakazy w briefie są dodatkową warstwą, a nie technicznym zabezpieczeniem.

Ścieżka mikropoprawki

Wykonaj zmianę bez delegacji do Kimi tylko wtedy, gdy wszystkie poniższe warunki są spełnione:

1. Zmiana jest jednoznaczna i mechaniczna; nie wymaga projektowania ani wyboru między rozwiązaniami.
2. Jest lokalna i ma minimalny zakres, zwykle w jednym pliku.
3. Nie zmienia zachowania programu, logiki biznesowej, publicznego API, schematu danych, zależności ani architektury.
4. Nie dotyczy bezpieczeństwa, uwierzytelniania, autoryzacji, uprawnień, danych wrażliwych, migracji, współbieżności ani kodu krytycznego wydajnościowo.
5. Można ją natychmiast zweryfikować konkretnym testem, lintem, typecheckiem lub buildem.
6. Użytkownik nie zażądał użycia Kimi lub OpenCode.

Przykłady dopuszczalne: literówka, formatowanie, korekta tekstu komunikatu bez zmiany semantyki, oczywista naprawa lintowania lub czysto mechaniczna zmiana nazwy wewnętrznego symbolu o łatwo sprawdzalnym zakresie.

Nie kwalifikuj zmiany jako mikropoprawki tylko dlatego, że obejmuje jedną linię. Pojedyncza zmiana warunku, walidacji, wartości konfiguracyjnej lub przepływu sterowania może zmieniać zachowanie i wtedy wymaga delegacji.

Jeśli zadanie łączy mikropoprawkę ze zmianą merytoryczną, przekaż Kimi cały spójny zakres. Jeśli kwalifikacja jest niepewna, deleguj.

W ścieżce mikropoprawki:

• pomiń diagnostykę OpenCode, odświeżanie modeli, tworzenie briefu dla Kimi i weryfikację metadanych sesji,
• zastosuj najmniejszy możliwy patch, zachowując istniejące zmiany użytkownika,
• uruchom proporcjonalny test,
• zaznacz w raporcie końcowym, że poprawkę wykonał Codex w ścieżce mikropoprawki.

1. Sprawdź środowisko i repozytorium

Wykonuj tę sekcję tylko dla zadania delegowanego do Kimi. Dla zakwalifikowanej mikropoprawki zastosuj krótszą ścieżkę powyżej.

1. Znajdź główny katalog projektu i przeczytaj wszystkie obowiązujące pliki AGENTS.md.

2. Sprawdź stan repozytorium, strukturę, istotne pliki, dokumentację oraz dostępne polecenia build/test/lint w zakresie proporcjonalnym do zadania.

3. Zapisz stan początkowy zmian użytkownika, aby później rozróżnić je od zmian wdrożeniowych.

   • W repozytorium Git zapisz git status, git diff, git diff --cached oraz listę plików nieśledzonych przez git ls-files --others --exclude-standard.
   • Poza Git zapisz listę i hashe plików objętych zakresem, a dla plików, które mogą zostać zmienione, przygotuj tymczasowy punkt odniesienia. Jeśli nie możesz utworzyć wiarygodnego punktu odniesienia, zatrzymaj delegację w trybie automatycznym i poproś użytkownika o decyzję.

4. Potwierdź dostępność OpenCode oraz zarejestrowanego dostawcy poleceniami diagnostycznymi, które nie ujawniają sekretów:

   opencode --version
   opencode auth list
   

   Wymagaj stabilnego OpenCode 1.x. Jeśli wykryta wersja ma inny główny numer, zatrzymaj delegację do czasu ponownego sprawdzenia zgodności workflow z oficjalną dokumentacją.

   Lista dostawców potwierdza obecność wpisu konfiguracyjnego, ale nie dowodzi, że klucz API jest nadal ważny. Faktyczne uwierzytelnienie potwierdza dopiero udane uruchomienie modelu.

5. Po instalacji lub aktualizacji OpenCode, gdy katalog modeli wydaje się nieaktualny albo gdy model nie zostanie odnaleziony, odśwież go jeden raz:

   opencode models --refresh
   

   Nie powtarzaj odświeżania w każdej iteracji poprawek.

6. Sprawdź katalog dostawcy:

   opencode models kimi-for-coding
   

   Wymagaj dokładnej pozycji kimi-for-coding/k3. Nie myl jej z kimi-for-coding/k3-256k, kimi-for-coding/kimi-for-coding ani wariantem HighSpeed.

7. Nie zastępuj Kimi K3 innym modelem. Jeśli Kimi For Coding lub dokładny model kimi-for-coding/k3 nie są dostępne, zgłoś konkretny blocker.

8. Przed każdym delegowanym uruchomieniem przeczytaj i zastosuj references/opencode-permissions.md. Przekazuj ograniczenia tylko do procesu Kimi przez OPENCODE_PERMISSION, zamiast rozszerzania uprawnień globalnych. --auto nie stanowi piaskownicy. Dla poleceń powłoki zaczynaj od deny i dopuszczaj tylko polecenia rozpoznawcze, testowe, buildowe i narzędziowe potrzebne w danym briefie. Wymagaj i zweryfikuj:

   • external_directory: deny,
   • reguły read: deny dla .env i innych plików z sekretami, z dopuszczeniem wyłącznie bezpiecznych przykładów takich jak .env.example,
   • bash: deny jako regułę domyślną oraz jawne allow tylko dla poleceń wymaganych przez aktualne zadanie; nigdy nie dopuszczaj commitów, pushy, wdrożeń ani poleceń destrukcyjnych,
   • doom_loop: deny.

   Nie używaj --share i ustaw OPENCODE_AUTO_SHARE=false dla procesu. Jeśli polityka nie blokuje również modyfikacji indeksu Git i cofania istniejących zmian użytkownika, uznaj ją za nieskuteczną. Jeśli którejkolwiek wymaganej blokady brakuje, zatrzymaj się przed opencode run --auto. Uzupełnij konfigurację tylko w zakresie autoryzowanym przez użytkownika albo poproś go o decyzję; nie kontynuuj wyłącznie na podstawie ostrzeżenia. Wyjaśnij, że nawet ścisła lista uprawnień nie zastępuje izolowanego środowiska, kopii danych i kontroli wersji.

Po odrzuceniu ścieżki mikropoprawki nie traktuj małego zakresu zmiany jako powodu do pominięcia tych kontroli. Ogranicz rozpoznanie do niezbędnych plików i poleceń, aby oszczędzać kontekst bez osłabiania ochrony istniejących zmian.

2. Przygotuj pakiet zadania

Przed delegowaniem opracuj zwięzły, jednoznaczny brief zawierający:

• cel i oczekiwany rezultat,
• kontekst repozytorium i obecne zachowanie,
• wymagania funkcjonalne i logikę biznesową,
• projekt rozwiązania technicznego przygotowany przez Codex: podział modułów, odpowiedzialności, interfejsy, przepływ danych i stanu oraz kluczowe niezmienniki,
• granice lokalnych decyzji wykonawczych Kimi oraz elementy wymagające ponownej akceptacji Codexa,
• wymagania niefunkcjonalne i ograniczenia,
• elementy poza zakresem,
• istotne pliki i istniejące wzorce,
• kryteria akceptacji,
• wymagane testy i komendy weryfikacyjne,
• zakaz naruszania istniejących zmian użytkownika,
• jawny zakaz commitów, pushy, wdrożeń, działań destrukcyjnych, odczytu sekretów oraz zmian poza repozytorium i zakresem zadania,
• prośbę o podsumowanie implementacji, ewentualnych odstępstw i wykonanych testów.

Nie deleguj niejasnego zadania. Najpierw uzupełnij kontekst dostępnymi, bezpiecznymi odczytami. Pytaj użytkownika tylko wtedy, gdy brakująca decyzja istotnie zmienia rozwiązanie.

Oszczędzaj kontekst Codexa i Kimi bez obniżania jakości: wykonuj tylko potrzebne odczyty, przekazuj istotny kontekst, wskazuj konkretne pliki i grupuj ustalenia w jeden kompletny brief. Nie wklejaj całego repozytorium, obszernych logów ani wielu częściowych promptów, jeśli nie jest to konieczne. Zachowaj jednak dowody potrzebne do odróżnienia zmian użytkownika, oceny diffu i weryfikacji kryteriów akceptacji.

3. Zleć Kimi K3 wdrożenie projektu Codexa

Uruchom OpenCode w katalogu głównym projektu i jawnie wymuś dostawcę, model oraz agenta:

[wymagane środowisko procesu: OPENCODE_PERMISSION=<zweryfikowana polityka>; OPENCODE_AUTO_SHARE=false]
opencode run --auto --agent build --model kimi-for-coding/k3 --variant high --format json --title "codex-kimi-<krótki-identyfikator>" "<pakiet zadania>"

Nie uruchamiaj samego polecenia bez wymaganych zmiennych środowiskowych. Zbuduj politykę według pliku referencyjnego, zweryfikuj jej JSON i przekaż ją bezpośrednio do procesu potomnego, bez utrwalania w profilu użytkownika.

Na Windows użyj opencode.cmd, jeśli polityka PowerShell blokuje skrypt opencode.ps1.

• Przekazuj argumenty bezpiecznie; nie interpoluj niezweryfikowanej treści w składnię powłoki. Dla długiego lub wielowierszowego briefu utwórz unikatowy tymczasowy plik UTF-8, dołącz go przez --file i przekaż jako argument tylko krótki, stały komunikat. Usuń wyłącznie utworzony przez siebie plik tymczasowy po zakończeniu sesji.
• Zachowaj identyfikator sesji zwrócony w zdarzeniach JSON.
• Nadawaj sesji unikatowy, niesekretny tytuł. Jeśli strumień JSON zostanie przerwany przed zapisaniem identyfikatora, użyj opencode session list --format json --max-count 10, dopasuj katalog i dokładny tytuł, a następnie sprawdź eksport przed kontynuacją. Nie zgaduj identyfikatora.
• Uruchamiaj każdy proces opencode run z ograniczonym czasem wykonania narzuconym przez narzędzie lub środowisko hosta, proporcjonalnym do zadania i domyślnie nie dłuższym niż 30 minut. Cały automatyczny cykl przed kolejną decyzją użytkownika, łącznie z pierwszą implementacją i poprawkami, nie może przekroczyć 45 minut; kontynuowanie sesji nie zeruje tego budżetu. Krótszy limit podany przez użytkownika ma pierwszeństwo. Po przekroczeniu limitu albo trwałym braku postępu przerwij proces, zachowaj dostępne metadane, sprawdź częściowy diff i potraktuj wynik jako nieudaną implementację lub iterację naprawczą; nie uruchamiaj procesu ponownie automatycznie.
• Używaj jawnie wariantu high, zalecanego dla K3. Zastąp go max tylko wtedy, gdy użytkownik go wybrał lub większy koszt i zużycie limitu są akceptowalne.
• Traktuj brief i projekt Codexa jako kontrakt implementacyjny. Pozwól Kimi podejmować lokalne decyzje wykonawcze, ale nie zlecaj mu ponownego projektowania całego rozwiązania.
• Poleć Kimi przerwać szeroką zmianę i zwrócić opis problemu oraz propozycję, jeśli wdrożenie wymaga istotnego odstępstwa od projektu. Po ocenie Codexa kontynuuj tę samą sesję z zatwierdzonym, zaktualizowanym projektem.
• Pozwól Kimi ukończyć implementację, ale nie pozwalaj mu zatwierdzać własnej jakości końcowej.

Jeśli delegacja nie może się rozpocząć lub zakończyć z powodu braku CLI, uwierzytelnienia, dokładnego modelu, uprawnień albo trwałego błędu narzędzia, zbierz bezpieczne dowody i nazwij konkretną przyczynę. Nie podstawiaj innego modelu i nie przejmuj automatycznie merytorycznej implementacji. Poproś użytkownika o decyzję, czy usunąć blocker, odłożyć zadanie, czy wyraźnie zezwolić Codexowi na wykonanie wyjątku.

4. Zweryfikuj zmiany jako Codex

Po zakończeniu Kimi:

1. W repozytorium Git sprawdź git status, git diff, git diff --cached oraz listę plików nieśledzonych przez git ls-files --others --exclude-standard; przeczytaj również zawartość wszystkich nowych plików objętych zadaniem. Porównaj osobno stan roboczy i indeks z zapisanym punktem odniesienia. Poza Git porównaj bieżące pliki z zapisanym punktem odniesienia i ujawnij obszary, których nie dało się wiarygodnie porównać.
2. Uruchom co najmniej:
   • git diff --check,
   • git diff --cached --check,
   • testy dotyczące zmienionego obszaru,
   • wymagany lint, typecheck i build wskazane przez projekt.
3. Oceń niezależnie:
   • zgodność z wymaganiami i kryteriami akceptacji,
   • poprawność logiki oraz przypadki brzegowe,
   • obsługę błędów i regresje,
   • bezpieczeństwo i brak wycieku danych,
   • zgodność ze stylem i architekturą repozytorium,
   • jakość oraz zakres testów.
4. Oddziel błędy wdrożenia od problemów istniejących wcześniej lub ograniczeń środowiska.

Nie poprawiaj po cichu błędów logicznych, projektowych ani zmian zachowania za Kimi. Zleć je w tej samej sesji. Codex może sam naprawić wykrytą usterkę wyłącznie wtedy, gdy spełnia ona wszystkie kryteria ścieżki mikropoprawki; po zmianie uruchom proporcjonalny test i ujawnij tę korektę w raporcie końcowym. W pozostałych przypadkach zatrzymaj workflow po blockerze albo wyczerpaniu dozwolonych prób. Codex może przejąć merytoryczną implementację dopiero po przedstawieniu możliwości dalszego działania i otrzymaniu bieżącej, jednoznacznej decyzji użytkownika o przejęciu.

5. Zlecaj poprawki na podstawie dowodów

Jeśli kontrola wykryje problem, przygotuj raport zawierający:

• dokładny plik i miejsce,
• zachowanie aktualne oraz oczekiwane,
• wpływ błędu,
• wynik testu lub sposób reprodukcji,
• ograniczenia rozwiązania,
• wymagane kryterium ponownej weryfikacji.

Kontynuuj tę samą sesję Kimi:

[wymagane środowisko procesu: OPENCODE_PERMISSION=<zweryfikowana polityka>; OPENCODE_AUTO_SHARE=false]
opencode run --auto --agent build --model kimi-for-coding/k3 --variant <wariant-początkowy> --session <session-id> --format json "<raport błędów i polecenie poprawy>"

Zachowaj wariant, politykę bezpieczeństwa i pozostały budżet czasu z pierwszego uruchomienia sesji. Po każdej poprawce ponownie wykonaj pełny przegląd i odpowiednie testy. Zatrzymaj cykl natychmiast po spełnieniu kryteriów akceptacji.

Limituj automatyczny cykl do dwóch iteracji naprawczych Kimi na całe zadanie, liczonych po pierwszej implementacji. Jeśli po drugiej iteracji kryteria akceptacji nadal nie są spełnione, zatrzymaj delegację. Nie rozpoczynaj kolejnej iteracji ani nowej sesji bez decyzji użytkownika.

Ponownie przeanalizuj przyczynę jako Codex, zbierz dowody i przedstaw użytkownikowi trzy możliwości:

1. zaktualizować lub zawęzić projekt i zezwolić na jedną dodatkową próbę Kimi,
2. wyraźnie zezwolić Codexowi na przejęcie implementacji,
3. przerwać lub odłożyć zadanie.

Nie wybieraj za użytkownika. Jeśli użytkownik zezwoli na dodatkową próbę Kimi, wykonaj tylko jedną próbę, po niej ponownie zweryfikuj rezultat i w razie niepowodzenia zgłoś blocker bez dalszych automatycznych iteracji.

6. Potwierdź użyty model

Nie opieraj potwierdzenia modelu na tekście odpowiedzi Kimi. Zweryfikuj metadane sesji:

opencode export <session-id> --sanitize

Potwierdź wystąpienie:

providerID: kimi-for-coding
modelID: k3
agent: build

Jeśli tryb --sanitize ukryje potrzebne metadane, sprawdź niesanitowany eksport wyłącznie lokalnie i nie ujawniaj jego treści. Jeśli metadane nadal nie są dostępne, opisz brak dowodu zamiast twierdzić, że użyto Kimi K3.

7. Przeprowadź bezpieczny test pierwszego użycia

Po instalacji lub istotnej aktualizacji skillu potraktuj pierwsze rzeczywiste zadanie użytkownika jako test integracyjny. Sprawdź w nim:

• czy Kimi faktycznie zmienił oczekiwane pliki,
• czy automatyczne zatwierdzanie działało bez dodatkowych monitów,
• czy testy projektu przeszły,
• czy eksport sesji potwierdza kimi-for-coding/k3.

Jeśli nie ma jeszcze rzeczywistego zadania, nie zaśmiecaj projektu testowymi plikami i nie zużywaj płatnego limitu bez potrzeby. Użyj osobnego, tymczasowego projektu dopiero po uzgodnieniu testu z użytkownikiem.

8. Zakończ kontrolą jakości

W raporcie końcowym podaj:

• rezultat i najważniejsze zmiany,
• wynik niezależnego przeglądu Codex,
• uruchomione testy i ich wyniki,
• potwierdzone metadane Kimi K3,
• pozostałe ryzyka, pominięte testy lub blockery.

Nie ogłaszaj sukcesu, jeżeli wymagane testy nie przeszły albo kryteria akceptacji nie zostały sprawdzone.