Zadani

Zadání v1.1

Kdy použít

• Uživatel má syrové / neuspořádané poznámky k projektu a chce z nich kvalitní zadání
• Trigger fráze: "/zadani", "připrav zadání", "zpracuj zadání", "udělej z poznámek zadání"
• Kdy NEpoužít:
  • Komplexní PRD s rozpadem na tasky → jiný, těžší skill (u velkých projektů nabídni handoff)
  • Hloubkový průzkum trhu → skill research

Vstup

• Volitelně cesta k souboru s poznámkami v $ARGUMENTS, nebo vložený text.
• Při prázdném $ARGUMENTS hledej v CWD soubory zadani.md, poznamky.md, notes.md; když nic nenajdeš, zeptej se.

Workflow

1. Načti a promysli

• Přečti poznámky. Extrahuj: cíl, motivaci, co je už rozhodnuté, co chybí.
• Urči velikost projektu a tomu odpovídající rozsah zadání:
  • S — nástroj / skript / jednoduchá stránka → zadání na ~1 stranu
  • M — aplikace / web s více funkcemi → 1–2 strany
  • L — komplexní systém → zadání udělej, ale nabídni handoff na PRD proces/nástroj podle stacku
• Sepiš seznam děr: nedomyšlené věci, skryté předpoklady, chybějící rozhodnutí.
• Identifikuj, co je kritické otestovat: hlavní funkčnost, rizikové vstupy, okrajové případy (edge cases, invalid inputs, chybové stavy) — půjde do sekce Testování (krok 5).

2. Interview (AskUserQuestion, max 2 kola po max 4 otázkách)

Povinná témata — ptej se jen na to, co neplyne z poznámek:

• Stack — technologie, jazyk, framework
• Repo & umístění — nové vs. existující repo, kam v adresářové struktuře
• Vystavení na web — veřejné/soukromé, Vercel / GitHub Pages / nic
• Success criteria — kdy je hotovo a jak se to ověří

Plus max 2–3 nejdůležitější díry z kroku 1. Co lze rozumně odvodit, neptej se — odvoď a označ k ověření (krok 5).

3. Základní rešerše (podmíněná)

• Spusť, jen pokud reálně zlepší zadání — typicky existující řešení, knihovny nebo API, o kterých uživatel nemusí vědět.
• 1–2 paralelní subagenti (model: sonnet), každý s konkrétní otázkou a instrukcí: „report do 200 slov, strukturovaně: název — co to je — proč relevantní — link".
• Když si nejsi jistý, zda rešerše dává smysl, přibal to jako otázku do interview.
• Tohle NENÍ průzkum trhu — na ten je skill research.

4. Hrubý plán ke schválení

• Před zápisem souboru ukaž v chatu stručný obrys: cíl, přístup, fáze.
• Finální soubor piš až po odsouhlasení (nebo zapracování úprav).

5. Výstup

Nový soubor zadani-final.md VEDLE vstupních poznámek. Pozor: ne ZADANI.md — macOS má case-insensitive filesystem, přepsal by originál zadani.md.

Struktura (sekce, které nedávají smysl, vynech — žádné prázdné kapitoly):

# <Název projektu>

## Cíl
1–3 věty: k čemu to je a pro koho.

## Kontext
Co už existuje, na co se navazuje.

## Scope / Non-scope
Co ano — a co výslovně ne.

## Stack & umístění
Technologie, repo, deploy / vystavení na web.

## Návrh řešení
Jak to postavit; klíčová rozhodnutí + zdůvodnění.

## Fáze
1. [krok] → verify: [ověřitelný check]
2. …

## Testování
Jak se ověří funkčnost — přiměřeně velikosti projektu (u S stačí pár testů kritické logiky, u M/L test suite).
- **Co testovat** — hlavní funkčnost + rizikové a okrajové vstupy (edge cases, invalid inputs, chybové stavy).
- **Typ testů** — unit / integration / e2e / smoke podle stacku.
- **Přístup** — testy aktivně hledají chyby; nalezená chyba → test, který ji reprodukuje → oprava → test prochází. Netestovat oslabením testů.
- **Hotovo, když** — všechny testy zelené a kritické cesty pokryté.

## Success criteria
Kdy je hotovo — konkrétní, ověřitelné (vč. zelených testů ze sekce Testování).

## Doplněno skillem — ověř
Co AI domyslela nad rámec poznámek; každá položka s důvodem.

## Otevřené otázky
Co zbývá rozhodnout.

Fixní pravidla (non-negotiables)

• Nikdy nepřepisuj původní poznámky — výstup je vždy nový soubor.
• Vše domyšlené označ v sekci „Doplněno skillem — ověř". Žádné tiché vymýšlení faktů a čísel.
• Rozsah tak akorát — zadání pro S-projekt je ~1 strana. Test: „Řekl by senior engineer, že je to overengineered?"
• Neztrať nic z poznámek — každý bod z originálu musí být ve výstupu zohledněn, nebo vědomě zařazen do non-scope.
• Success criteria ověřitelná — ne „funguje to dobře", ale konkrétní check.
• Testování je součást každého softwarového zadání — sekce Testování s testy, které ověří funkčnost a odhalí chyby (edge cases, invalid inputs, chybové stavy), přiměřeně velikosti projektu. Přístup: chyba → reprodukující test → oprava → zelené testy. Nikdy netestovat oslabením testů. U ne-softwarových výstupů sekci vynech (platí pravidlo „sekce, které nedávají smysl, vynech").
• Výstup spisovnou češtinou.

Output checklist

• Původní poznámky nedotčené
• zadani-final.md vytvořen vedle poznámek
• Stack, repo, umístění, web — zodpovězeno, nebo v Otevřených otázkách
• Každá fáze má verify krok
• Sekce „Testování" obsahuje testy ověřující funkčnost + odhalující chyby (přiměřeně velikosti); u ne-softwarového výstupu vědomě vynecháno
• Sekce „Doplněno skillem" odděluje domyšlené od zadaného
• Rozsah odpovídá velikosti projektu (S ≈ 1 strana)
• U L-projektu nabídnut handoff na těžší PRD proces

Changelog

• 2026-07-09 — v1.1: přidána povinná složka testování. Každé softwarové zadání nově obsahuje sekci Testování — testy, které ověří funkčnost a aktivně odhalí chyby (edge cases, invalid inputs, chybové stavy), s přístupem chyba → reprodukující test → oprava → zelené. Přiměřeně velikosti projektu (S = pár testů kritické logiky). Doplněno i do úvahy (krok 1), fixních pravidel a checklistu.
• 2026-07-09 — v1.0 založeno. Vzniklo z požadavku: neuspořádané poznámky → zadání „tak akorát", lehčí než komplexní PRD proces (ten zůstává pro velké projekty s tasky). Rešerše jen podmíněná, výstup vždy nový soubor, domyšlené věci vždy označené k ověření.