Dzielenie się wiedzą — wersjonuj dowody, nie triki

Wiedza operacyjna o AI powinna pochodzić z dowodów: zaakceptowanych zmian, nieudanych przebiegów, ustaleń review, incydentów i mierzonych eksperymentów. Trzymaj wielokrotnego użytku instrukcje, skills, konfiguracje narzędzi, fixtures i decyzje w version control z ownerami oraz datami review. Kanały dyskusji i demo pomagają odkrywać, ale trwałe źródło musi być testowalne i wymienne przy zmianie narzędzi.

Q20 · Enablement organizacji Dowód na maksymalny wynik: wersjonowane wzorce z ownerami i dowodami, aktualizowane po review oraz incydentach i ćwiczone na regularnych sesjach zespołu.

Rozdziel trwałe warstwy

• Prawda repo: polecenia, architektura, chronione zasoby, bramki workflow i ownership.
• Reusable capability: przetestowane skills, wąskie konfiguracje tools, hooks i fixtures.
• Zapis decyzji: co sprawdzono, baseline, dowody, ryzyka, wynik i powód wycofania.
• Strumień nauki: demo, office hours i dyskusje linkujące do trwałych artefaktów.

1. Złap realny sygnał. Zacznij od powtarzanego pytania, failed run, escaped defect, wzorca review, blokady onboardingu albo wyniku eksperymentu.
2. Wybierz jeden kanoniczny artefakt. Zaktualizuj instrukcję repo, skill, fixture testowy, runbook albo decision record. Nie kopiuj tej samej reguły do plików każdego toola.
3. Dołącz dowód. Dodaj reproducer, zaakceptowany przykład, przypadek negatywny, link źródłowy albo referencję do incydentu.
4. Zrób review i dystrybucję. Nazwij ownera, expiry lub trigger review oraz środowiska, w których artefakt przetestowano.
5. Ćwicz i wycofuj. Testuj discovery w onboardingu i sesjach cyklicznych; usuwaj wzorce zastąpione oraz redirecty.

Prompty do utrzymania wiedzy

Zamień ten failed run lub finding review w najmniejszy trwały artefakt. Wybierz repository instruction, skill, fixture, runbook albo decision record i uzasadnij. Nie duplikuj istniejącego guidance.

Zaudytuj wzorzec pod kątem aktualnych faktów o vendorze, ukrytych prerequisites, nadmiernej władzy, brakujących przypadków negatywnych, braku ownera i niejasnego triggera wycofania.

Sprawdź, czy świeża sesja agenta i nowy engineer potrafią znaleźć oraz zastosować artefakt. Zapisz błędne ścieżki, brakujące linki, konflikty i wyprodukowane dowody.

Dowody akceptacyjne

• Każdy artefakt ma ownera, provenance, ostatnią weryfikację i trigger review.
• Aktualne komendy i capabilities vendorów linkują do źródeł pierwotnych i są sprawdzane przed istotnym update.
• Skills i hooks zawierają fixtures pozytywne, negatywne, boundary i failure.
• Testy search oraz onboardingu potwierdzają discoverability bez prywatnego kontekstu Slacka.
• Zastąpione instrukcje są usuwane albo kierują do jednego kanonicznego miejsca.

Wzorzec awarii: wewnętrzne archiwum tips

Duże repo promptów i kopiowanych konfiguracji staje się źródłem driftu, gdy nikt nie wie, co nadal działa. Preferuj mniej wzorców z ownerami, testuj je w świeżych sesjach i archiwizuj elementy, których dowód lub cel już nie obowiązuje.

Dalej: pętla feedbacku

Użyj Maintain, by zmieniać incydenty w nowy intent, oraz Onboardingu developera, by ćwiczyć ścieżkę wiedzy.

Maintain Kieruj dowody produkcyjne z powrotem do cyklu.

Q19 · Onboarding developera Sprawdź, czy system naprawdę da się odkryć.