Kódovací prompty pro Grok

Používám [jazyk nebo framework a verze]. Vysvětlete tuto chybu jednoduše vlastními slovy, seřaďte tři nejpravděpodobnější příčiny podle pravděpodobnosti a u každé uveďte, co zkontrolovat jako první: [vložte celou chybu a stack trace]

Tato funkce při volání se vstupem [vstup] vrací [skutečný výsledek], ale očekávám [očekávaný výsledek]. Projděte provádění kód po řádku pro tento vstup, sledujte každou proměnnou a zastavte se na prvním řádku, kde se stav liší od očekávaného: [vložte kód]

Tento kód v [jazyk] při zátěži občas způsobuje [projev chyby], ale při samostatném testování nikdy: [vložte kód]. Zaměřte se na souběh vláken (race conditions), sdílený stav a předpoklady o pořadí provádění. U každého podezřelého místa popište přesné prolnutí operací, které by chybu způsobilo, a navrhněte řešení.

Zkontrolujte tento diff z pozice náročného senior vývojáře pro codebase v [jazyk]. Připomínky rozdělte na chyby, rizika, čitelnost a testy, uveďte reference na řádky a zakončete verdiktem: schválit, schválit se změnami nebo vyžádat změny, včetně jednovětého odůvodnění: [vložte diff]

U níže uvedené funkce vypište všechny okrajové případy, které byste testovali, a uveďte proč. Poté napište testy pro [testovací framework]. Zahrňte alespoň jeden test, u kterého očekáváte, že se současným kódem selže, a uveďte, který to je: [vložte funkci]

Vytvořte realistická testovací data (fixtures) pro tento datový model ve formátu [formát, např. JSON nebo factory funkce]: [vložte model]. Zahrňte deset běžných záznamů a pět záludných (např. prázdné řetězce, velmi dlouhá jména, nelatinkové znaky a hraniční data) a označte, které jsou které.

Na základě tohoto schématu: [vložte schéma] napište dotaz pro [databáze], který vrátí [co potřebujete]. Vysvětlete dotaz klauzuli po klauzuli a poté ukažte variantu, která ošetřuje i [okrajový případ, např. zákazníci bez objednávek].

Tento regulární výraz by měl [zamýšlené chování] v [jazyk nebo nástroj], ale [co nefunguje]: [vložte regex]. Rozložte jej na části a každou vysvětlete, ukažte vstup, na kterém se problém projeví, a navrhněte opravenou verzi spolu se třemi řetězci, které musí odmítnout.

Napište skript pro [bash nebo PowerShell], který [úkol, např. archivuje logy starší než 30 dní do zipu]. Zajistěte maximální bezpečnost: režim cvičného běhu (dry-run), který pouze vypíše plánované akce, srozumitelné chybové hlášky a komentář u každého řádku, který maže nebo přepisuje soubory.

Napište referenční dokumentaci pro tento endpoint: [vložte kód obslužné rutiny nebo route]. Uveďte metodu a cestu, parametry včetně typů a informace, zda jsou povinné, ukázkový požadavek, příklady úspěšných i chybových odpovědí a všechny stavové kódy, které může vrátit.

Můj Git repozitář je v tomto stavu: [vložte git status a posledních několik řádků git log]. Mým cílem bylo [cíl]. Jednoduše vysvětlete, co se stalo, a uveďte přesné příkazy k nápravě – začněte příkazem, který zazálohuje mou aktuální práci. Před jakýmkoli příkazem, který přepisuje historii, mě výslovně varujte.

Plynule ovládám [jazyk, který znám] a začínám se učit [nový jazyk]. Vezměte tuto ukázku napsanou v mém obvyklém stylu: [vložte kód], a přepište ji tak, jak by to udělal zkušený vývojář v [nový jazyk]. Poté vysvětlete použité idiomy, které v mém původním jazyce nemají přímý ekvivalent.

Přikládám screenshot své stránky. Problém: [co vypadá špatně]. Zde je HTML a CSS dané sekce: [vložte kód]. Najděte příčinu, navrhněte minimální opravu v CSS a vysvětlete, proč k tomu došlo, abych stejnou chybu neopakoval/a.

Přikládám fotku náčrtu datového modelu na tabuli pro [aplikace]. Převeďte jej na definice tabulek pro [databáze] s primárními klíči, cizími klíči a vhodnými datovými typy. Vypište všechny vztahy, které jsou v náčrtu nejednoznačné, a zeptejte se na ně dříve, než uděláte vlastní předpoklad.

Jaká je časová a paměťová složitost této funkce a proč? [vložte kód] Pokud existuje rychlejší přístup pro vstupy o velikosti zhruba [velikost], ukažte jej a vysvětlete, jaký vliv má na čitelnost kódu.

Zrefaktorujte tuto funkci tak, aby byla lépe čitelná, beze změny jejího chování: [vložte kód]. Postupujte v malých, pojmenovaných krocích, každou změnu popište v jednom řádku a uveďte jakékoli chování, kterým jste si nebyli jistí, abych si ho mohl/a před mergem ověřit.

Napište README pro můj projekt [název], který [co dělá]. Sekce: o projektu, rychlý start s příkazy k okamžitému zkopírování, možnosti konfigurace v přehledné tabulce, časté problémy a jak přispět. Zde jsou klíčové soubory a příkazy: [vložte podrobnosti]

Vysvětlete, co dělá tento kód v jazyce [jazyk], někomu, kdo umí programovat, ale nezná tento codebase. Začněte shrnutím ve dvou větách, projděte jej blok po bloku a upozorněte na cokoli, co vypadá jako chyba nebo dočasný hack: [vložte kód]

Plánuji vytvořit [funkce] tímto způsobem: [popište přístup]. Buďte ďáblův advokát. Uveďte tři nejpravděpodobnější způsoby, jak tento návrh v produkci selže, jaké symptomy se projeví a jaká levnější alternativa případně existuje. Buďte nekompromisní – raději to uslyším teď než ve tři ráno.

Převeďte tento kód z jazyka [výchozí jazyk] do idiomatického kódu v [cílový jazyk], nikoli doslovným přepisem řádek po řádku: [vložte kód]. Kde je to možné, použijte standardní knihovnu cílového jazyka, zachovejte původní chování a upozorněte na všechna místa, kde se oba jazyky chovají odlišně (např. celočíselné dělení nebo kódování řetězců).