# Zadani > Z neuspořádaných poznámek připraví projektové zadání „tak akorát" — promyslí téma, doplní nedomyšlené (označené k ověření), krátký interview (stack, repo, umístění, vystavení na web), volitelná základní rešerše, plán testování (testy, které ověří funkčnost a odhalí chyby). Výstup jako nový soubor zadani-final.md vedle poznámek. Lehčí než PRD. Trigger: "/zadani", "připrav zadání", "zpracuj zadání", "udělej z poznámek zadání". - Skill: `jmech-pepa/zadani` (Agent Skill) - Install (CLI): `npx skillmds@latest add jmech-pepa/zadani` - Raw SKILL.md: https://api.skillmd.com/api/skills/jmech-pepa/zadani/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: jmech-pepa (https://skillmd.com/u/jmech-pepa) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/jmech-pepa/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): ```markdown # ## 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í.