AI přímo v editoru: Copilot a spol. pro vývojáře

Chystám se na tenhle úkol v našem projektu:
[popis úkolu, např. přidat podporu částečných refundací do
objednávkového modulu]

Stack: [jazyk, framework, verze]. Velikost projektu: [řádově].
Testy: [jednotkové ano, integrační částečně, pokrytí asi 40 %].
Termín: [2 dny].

Nepiš zatím žádný kód. Rozsekej úkol na kroky a u každého napiš:
1. co je potřeba udělat, jedna věta,
2. jestli je to rozhodnutí (musím ho udělat já), nebo mechanika
   (může to napsat AI a já to zreviduju),
3. co se musí ověřit, než se půjde dál,
4. co může tenhle krok rozbít jinde v systému.

Na konci vypiš tři otázky, které bych si měl zodpovědět, než začnu,
a jednu věc, kterou na tomhle zadání považuješ za nedomyšlenou.

Projdi tenhle projekt a napiš mi návrh souboru s pravidly pro AI
asistenta, který v něm bude pracovat. Vycházej z toho, co v kódu
skutečně vidíš, ne z obecných doporučení.

Zahrň:
- jazyk, verze, správce balíčků, jak se projekt spouští a testuje
- členění adresářů a co kam patří
- konvence pojmenování, které v kódu skutečně platí (i když se liší
  od obvyklých doporučení pro tenhle jazyk)
- jak se v projektu pracuje s chybami, logováním a konfigurací
- jak vypadá typický test a jaké knihovny se používají
- co se v tomhle projektu NEDĚLÁ (zakázané knihovny, vzory, kterých
  jsme se zbavili a nechceme je zpátky)
- oblasti, kde se nesmí nic měnit bez konzultace (autentizace,
  platby, migrace databáze)

U každého bodu uveď soubor, ze kterého jsi to odvodil.
Kde v projektu vidíš dva různé styly, napiš oba a označ, že je to
k rozhodnutí — nevybírej za mě.

Vysvětli mi tenhle modul. Jsem zkušený vývojář, ale tenhle projekt
vidím poprvé.

Nechci převyprávěný kód řádek po řádku. Chci:
1. K čemu modul slouží a jaký problém řeší — 3 věty.
2. Veřejné rozhraní: co odsud volají ostatní části systému a co
   od toho čekají.
3. Datový tok: co přijde na vstupu, jak se to postupně mění,
   co odchází ven a kam.
4. Stav a vedlejší efekty: co si to pamatuje, co zapisuje do
   databáze, co posílá do dalších služeb.
5. Tři místa, kde je logika nejzamotanější, a proč — u každého
   soubor a řádky.
6. Předpoklady, které kód mlčky dělá (co musí platit o vstupech,
   aby to fungovalo) — hlavně ty, které nikde nejsou zkontrolované.
7. Co bych rozbil, kdybych tady něco změnil.

Kde si nejsi jistý, napiš to místo dohadu. Netvrď nic o kódu,
který nevidíš.

[přilož modul nebo adresář]

Projdi tenhle repozitář a popiš mi celou cestu, kterou v systému
projde [konkrétní požadavek, např. objednávka od odeslání formuláře
po e-mailové potvrzení].

Pro každý krok uveď:
- soubor a funkci, kde se to děje,
- co se s daty v tom kroku stane,
- kde se rozhoduje o větvení (validace, oprávnění, feature flag),
- kde se to může nezdařit a co se pak stane s rozpracovaným stavem.

Na konci mi napiš:
- které kroky nejsou pokryté testy,
- kde se ta cesta liší od toho, co bych čekal podle názvů souborů,
- tři místa, kde bych při zásahu nejspíš něco rozbil.

Chci konkrétní odkazy na soubory a řádky, ne obecný popis architektury.

Tady je funkce [název], ke které potřebuju testy:
[vlož funkci a související typy]

Její zamýšlené chování podle byznysu:
[3–6 vět vlastními slovy, včetně toho, co má dělat v okrajových
případech — prázdný vstup, záporná částka, chybějící údaj]

Napiš testy v [framework], stylem, jaký používáme tady:
[přilož jeden existující testovací soubor jako vzor]

Pravidla:
- testuj chování popsané výše, ne to, co vidíš v implementaci,
- ke každému testu jednou větou, co ověřuje a proč na tom záleží,
- pokrytí okrajových případů: hranice, prázdné a chybějící hodnoty,
  chybové stavy — u každého napiš, proč je zrovna tenhle případ
  zajímavý,
- nemockuj vnitřnosti testované funkce, jen vnější závislosti,
- na konec vypiš zvlášť: případy, kde se zamýšlené chování podle
  popisu ROZCHÁZÍ s tím, co implementace dělá.

Ten poslední seznam je pro mě nejdůležitější, nevynechávej ho.

Našel jsem chybu: [popis, co se stane a co se stát mělo].
Reprodukce: [kroky nebo vstup, u kterého to nastane].
Podezřelé místo: [soubor, funkce].

Napiš mi jeden test, který tuhle chybu zachytí — tedy test,
který teď MUSÍ spadnout a po opravě projde.

- pojmenuj ho tak, aby z názvu bylo poznat, jaký případ hlídá,
- do komentáře napiš odkaz na hlášení a stručně, o co šlo,
- používej jen ta data, která jsou pro chybu podstatná,
  žádná náhodná výplň,
- neopravuj zatím kód, chci vidět, jak test spadne.

Až test spadne, teprve pak mi navrhni opravu — a k ní napiš,
proč chyba vznikala a co jiného mohlo být stejnou příčinou zasažené.

Tahle funkce mi přerostla přes hlavu:
[vlož kód]

Kontext: [k čemu slouží, jak často se volá, co ji volá].
Testy: [existují / neexistují]. Výkon je [/není] kritický.

Nepiš zatím výsledek. Nejdřív mi napiš:
1. Co konkrétně je na téhle funkci špatně — očíslovaný seznam
   problémů, u každého proč to vadí v praxi (čitelnost, testovatelnost,
   riziko chyby), ne odkaz na obecný princip.
2. Tři různé varianty refaktoringu, od nejmenší po nejradikálnější.
   U každé: co se zlepší, co se zhorší, kolik souborů se dotkne
   a jestli mění veřejné rozhraní.
3. Kterou bys zvolil ty a proč — s ohledem na to, že [kontext výše].

Vyberu si a teprve pak mi napiš kód. Chování se nesmí změnit;
kde by se změnit muselo, upozorni na to předem.

Tady je diff, který se chystám commitnout. Část kódu vznikla
s pomocí AI a chci ho projít, jako by ho psal někdo cizí.

Kontext: [co změna dělá a proč]. Projekt: [stack].

Projdi diff a vrať nálezy roztříděné do skupin:
1. CHYBY: co je špatně a projeví se to (chybné chování, neošetřený
   okrajový případ, změna chování oproti původnímu kódu).
2. BEZPEČNOST: vstupy bez validace, chybějící kontrola oprávnění,
   práce s tajemstvími, riziko injektáže, logování citlivých údajů.
3. NEEXISTUJÍCÍ API: volání funkcí, metod nebo parametrů, které
   v uvedených verzích knihoven nemusí existovat — vypiš je,
   ať si je ověřím v dokumentaci.
4. NAVÍC: kód, který řeší problém, co nemám — abstrakce, parametry
   a větve, které nikdo nevolá.
5. NESOULAD S PROJEKTEM: kde se to liší od konvencí v přiloženém
   souboru s pravidly.

U každého nálezu: soubor, řádek, co s tím. Neopravuj nic sám.
Na konec napiš tři otázky, na které bych měl umět odpovědět
při obhajobě téhle změny.

Tady je diff mého commitu:
[vlož diff]

Kontext, který z diffu není vidět:
[proč to dělám, číslo ticketu, co tomu předcházelo]

Napiš commit zprávu podle konvence [například Conventional Commits],
v [češtině / angličtině] podle zvyklostí repozitáře:
- první řádek do 72 znaků, v rozkazovacím způsobu, bez tečky,
- prázdný řádek,
- tělo: PROČ ta změna vzniká a jaké mělo alternativy, ne převyprávěný
  seznam změněných souborů,
- pokud se mění chování nebo rozhraní, uveď to výslovně,
- odkaz na ticket na konec.

Pokud v diffu vidíš dvě nesouvisející změny, neschovávej to do
jedné zprávy — napiš mi, kde je rozdělit na samostatné commity.

Připrav popis pull requestu z tohohle diffu a z těchhle commitů:
[vlož diff a seznam commitů]

Kontext: [ticket, zadání, na čem jsme se dohodli].

Struktura:
- Co se mění a proč — 3 věty, srozumitelné i pro kolegu z jiného týmu.
- Jak jsem to řešil a jaké alternativy jsem zvažoval a zamítl.
- Co si má reviewer projít pozorně a proč zrovna to.
- Jak to otestovat ručně — konkrétní kroky, ne „spusťte aplikaci“.
- Rizika a co dělat, kdyby se to muselo vrátit zpět.
- Co záměrně NENÍ součástí téhle změny.

Piš stručně, bez marketingu. Kde ti chybí informace, napiš
DOPLNIT: [co] místo domýšlení.

Pracuj v tomhle repozitáři.

ÚKOL: [např. nahradit zastaralé volání knihovny X novým API napříč
projektem — je jich asi 40].

ROZSAH: pouze adresáře [src/, tests/]. Nesahej na [migrace/, infra/,
konfiguraci nasazení] ani na závislosti v manifestu.

POSTUP, po každém kroku se zastav a počkej na mé schválení:
1. Najdi všechna dotčená místa a vypiš je do tabulky: soubor, řádek,
   typ použití. Roztřiď je na přímočará a na ta, která vyžadují
   rozhodnutí.
2. U třech nejsložitějších případů mi ukaž návrh změny a vysvětli ho.
3. Proveď změnu v jednom souboru, spusť testy, ukaž mi diff.
4. Teprve po schválení zpracuj zbytek přímočarých případů,
   ve dvou dávkách, ke každé samostatný commit.
5. Případy vyžadující rozhodnutí nech beze změny a vypiš mi je
   na konec se svým doporučením.

HOTOVO ZNAMENÁ: projdou všechny existující testy, chování se nemění,
diff neobsahuje nesouvisející úpravy formátování.

ZÁKAZY: nemazat testy, neupravovat je jinak než kvůli změněnému
rozhraní, neaktualizovat verze závislostí, nepřepisovat kód,
který s úkolem nesouvisí, nedělat commit bez mého schválení.