Beyond LLM: Praktický průvodce agentními workflow, prompt engineeringem a RAG

##Beyond LLM: Jak se staví agentní AI systémy v praxi

„Cíl není za hodinu postavit produkt od A do Z. Cíl je, abyste po hodině měli rozhled — znali postupy, které AI inženýři právě rozlouskli — a uměli se rychle doučit, co zrovna budete potřebovat." — Kian Katanforoosh, Stanford CS230, Lecture 8

Článek je podrobný výtah z přednášky Agents, Prompts, and RAG ze Stanford CS230 (podzim 2025). Přednáší Kian Katanforoosh (zakladatel Workery, dlouholetý spolupracovník Andrewa Nga). Obsah je rozhledová mapa, ne hluboký ponor do jedné metody — přesně ten typ materiálu, který se vyplatí přečíst, než začnete stavět cokoli s „AI agent" v názvu.

Struktura kopíruje logiku přednášky:

1. Proč nestačí holý pre-trained LLM

2. Prompt engineering (zero-shot → few-shot → CoT → chaining)

3. Fine-tuning a proč se mu většinou vyhýbat

4. RAG (vanilla, chunking, HyDE)

5. Agentní workflow — paradigm shift, stavební bloky, MCP

6. Case study: customer support agent + evals

7. Multi-agent systémy

8. Kam AI směřuje

Všude, kde to dává smysl, najdete hotové promptové snippety.

---

##1. Proč nestačí „jen zavolat GPT-4"

Kian začíná otázkou na třídu: „S jakými limity vanilového pre-trained LLM jste se setkali?" Studenti postupně vyjmenují to, co potkáte v praxi:

###Dvě osy zlepšení

Kian rámuje problém jednoduchou maticí:

Výkon aplikace = f( který LLM použijete,  jak ho obalíte )
                      ^ horizontální osa     ^ vertikální osa
                        (GPT-3.5 → 4 → 5)     (prompty, RAG, agenti)

Přednáška je o té vertikální ose. Horizontální se posouvá sama každých pár měsíců.

---

##2. Prompt engineering — první linie optimalizace

###Jagged frontier, centauři a kyborgové

Než se dostaneme k postupům, stojí za zmínku studie BCG x HBS x Wharton x UPenn, kterou Kian cituje. Konzultanti byli rozděleni do tří skupin (bez AI / s AI / s AI + trénink na prompting) a pouštěni na reálné úlohy:

• Jagged frontier — existuje zubatá hranice mezi úlohami, kde AI výrazně pomáhá, a úlohami, kde zhoršuje výsledek, protože člověk „usne za volantem".

• Skupina s tréninkem na prompting dopadla nejlépe. Prompting není magický skill pro „prompt engineery" — je to základní gramotnost.

• Centauři vs. kyborgové — centauři delegují velké kusy práce (napíšou dlouhý prompt, odejdou na kafe, vrátí se pro výsledek). Kyborgové spolupracují s modelem rychle tam a zpět. Studenti bývají kyborgové, enterprise workflow zpravidla vyžaduje centaury.

###Základní šablona: od vágního po cílený prompt

Výchozí (špatný) prompt:

Summarize this document.

Lepší:

Summarize this 10-page scientific paper on renewable energy in
five bullet points, focusing on key findings and implications
for policymakers.

Proč je lepší: definujete rozsah, publikum, formát a důraz.

###„Act as ..." — prompt templates

Rozšířený vzor. Existují celé repozitáře (awesome-prompts apod.), odkud se dá čerpat:

Act as a Linux terminal. I will type commands and you will reply
with what the terminal should show. Do not write explanations.

Reálný use-case z Workery (personalizace podle HR systému):

# System prompt template (pseudo)
Act as a helpful AI career mentor.

User profile:
- name: {{user.first_name}}
- role: {{user.role_title}} (level {{user.role_level}})
- country: {{user.country}}
- preferred_language: {{user.preferred_language}}

Follow the mentee's preferred language. Tailor examples to their
role and seniority. Be concise.

Klíčová myšlenka: prompt template je kód. Dosazujete metadata z DB a škálujete na tisíce uživatelů.

###Zero-shot vs. few-shot

Klasický příklad — klasifikace tónu recenze. Věta „The product is fine, but I was expecting more." je subjektivně hraniční (positive / neutral / negative). Zero-shot tipuje, vy chcete jednotný výstup napříč zákazníky.

# Zero-shot
Classify the tone of the sentence as positive, negative, or neutral.

Sentence: "The product is fine, but I was expecting more."

# Few-shot — zarovná model na VAŠI definici
Classify the tone of the sentence as positive, negative, or neutral.

Here are examples of tone classifications:
- "These exceeded my expectation completely." → positive
- "It's OK, but I wish it had more features."  → negative
- "The service was adequate. Neither good nor bad." → neutral

Now classify the tone of this sentence:
Sentence: "The product is fine, but I was expecting more."

Kian poznamenává, že vyspělejší AI startupy si few-shot příklady udržují jako živý dataset v promptu. Kdykoli člověk něco označí, přidá se to jako nový příklad. Žádné doučení modelu — mění se jen text promptu.

Poznámka k limitům: Ve Workery měřili, že po zhruba 8 turnech konverzace se model začne ztrácet. Řešení: konverzaci rozsekáte na „kapitoly" — první zkomprimujete do shrnutí, vložíte do nového promptu a pokračujete.

###Chain of Thought (CoT)

CoT je explicitní instrukce „rozmysli si to po krocích". Studie z let 2022–2023 ukázala, že to výkon skutečně zlepšuje.

Summarize this 10-page paper on renewable energy in five bullets.

Approach the task step by step. Do not skip any step.
Step 1: Identify the three most important findings.
Step 2: Explain how each finding impacts renewable energy policy.
Step 3: Write the five-bullet summary, each bullet addressing a finding.

Paper: <<< ... >>>

###Prompt chaining (to nejdůležitější z promptingu)

CoT ≠ chaining. CoT je jeden prompt s kroky uvnitř. Chaining znamená N samostatných promptů, které se řetězí — výstup promptu N je vstup promptu N+1.

Naivní monolit:

# Single-shot — všechno v jednom promptu
Read this customer review and write a professional response that
acknowledges concerns, explains the issue, and offers a resolution.

Review: "I ordered a laptop. It arrived three days late. The
packaging was damaged. Very disappointing. I needed that urgently."

Chain (tři samostatné prompty):

# Prompt 1 — extrakce
Identify the key concerns mentioned in this customer review.
Review: {{review}}

# → output: concerns

# Prompt 2 — outline
Using these issues, draft an outline for a professional response
that acknowledges concerns, explains possible reasons, and offers
a resolution.

Issues: {{concerns}}

# → output: outline

# Prompt 3 — finalizace
Using the outline, write the full professional response email.

Outline: {{outline}}

# → output: email

Proč to dělat? Debuggability. Každý krok testujete a ladíte samostatně. Zjistíte, že outline je výborný, ale překlad do e-mailu je toporný → optimalizujete Prompt 3. Daň: vyšší latence a náklady (tři roundtripy místo jednoho).

###Testování promptů

Ručně: tabulka s baseline vs. refined vs. chain, testovací vstupy, lidské hodnocení 1–5. Škáluje špatně.

Automaticky — platformy typu Promptfoo (Workera ji používá):

• Spustit jeden prompt paralelně přes 5 LLM.

• LLM-as-a-judge — modely hodnotí výstupy jiných modelů:

- Pairwise comparison — „které z těchto dvou shrnutí je lepší?"

- Single-answer grading — známka 1–5

- Reference-guided / rubric-based — judge dostane rubric:

# Judge prompt (rubric-based)
You are evaluating summaries of research papers. Grade 0–5.

Rubric:
- 5: under 100 characters, mentions ≥3 distinct key points,
     opens with a clear overview sentence, then details.
- 4: minor deviation from the above.
- 3: covers most key points but weak structure.
- 2: partial coverage, verbose or off-topic.
- 1: fundamentally wrong focus.
- 0: failed to summarize at all.

Summary to grade:
<<< {{summary}} >>>

Return: { "score": <int>, "rationale": "<1–2 sentences>" }

Postupy se skládají. Few-shot příklady pro rubric, CoT uvnitř judge promptu — kombinujte je.

---

##3. Fine-tuning: proč se mu Kian vyhýbá

Kian říká otevřeně: „Nejsem příznivec fine-tuningu." Důvody:

1. Vyžaduje hodně labeled dat (i když moderní postupy to zmírňují).

2. Overfitting — ztratíte generalitu.

3. Časově i finančně nákladné.

4. Zastará dřív, než dokončíte. Než dotrénujete fine-tune nad GPT-X, vyjde GPT-(X+1) a poráží vás bez nákladů.

Prompt engineering má navíc výhodu, že model vyměníte jedním řádkem konfigurace a zdarma získáte zlepšení příštího foundation modelu.

###Kdy fine-tuning dává smysl

• Úlohy vyžadující opakovanou vysokou přesnost (právo, vědecké výklady).

• Když obecný LLM selhává na doménovém jazyce.

###Varovná historka: Slack fine-tune

Ross Lazerowitz kdysi fine-tunoval model na interních Slack zprávách, aby „mluvil jako jejich tým". Výsledek:

> User:    Write a 500-word blog post on prompt engineering.
> Model:   I shall work on that in the morning.
> User:    It's morning now.
> Model:   I'm writing right now.
> User:    It's 6:30 AM here. Write it now.
> Model:   OK, I shall write it now. Actually, I don't know what
>          you'd like me to say about prompt engineering.

Model se naučil chovat se jako kolega, který odkládá práci na Slacku, místo aby plnil instrukce. Přesně to Kian myslí ztrátou obecné použitelnosti.

---

##4. RAG — Retrieval-Augmented Generation

RAG je nejčastější otázka na pohovorech v oboru. Podstata jednou větou: embedujeme dokumenty, na dotaz vyhledáme relevantní chunky přes vektorový index a vložíme je do promptu.

###Vanilová architektura

┌─────────────┐      embed       ┌──────────────────┐
│ Knowledge   │ ───────────────▶ │ Vector DB        │
│ base (docs) │                  │ (pgvector,       │
└─────────────┘                  │  Pinecone, …)    │
                                 └────────▲─────────┘
                                          │ similarity
        ┌─────────────────┐   embed       │ search
        │ User query      │ ──────────────┘
        └──────┬──────────┘
               │                ┌────────────────────┐
               ▼                │ Retrieved docs     │
     ┌───────────────────┐      └──────────┬─────────┘
     │ Prompt template   │ ◀───────────────┘
     │  + query          │
     │  + retrieved docs │
     └──────┬────────────┘
            ▼
        LLM → answer (+ sources)

Šablona systémového promptu:

You are a helpful assistant for clinicians.

Answer the user query using ONLY the provided documents. If the
answer is not in the documents, say "I don't know." Always cite
the document name, chapter, and line range you used.

User query: {{query}}

Documents:
{{#each docs}}
--- {{name}} (chunk {{chunk_id}}) ---
{{content}}
{{/each}}

Return JSON:
{ "answer": "...", "citations": [{"doc":"...", "page":N, "lines":"A-B"}] }

###Pokročilejší postupy

Chunking — neukládejte jen embedding celého dokumentu. Ukládejte embedding dokument + kapitola + paragraf. Při retrievalu najdete dokument i konkrétní pasáž → přesnější zdrojování.

HyDE (Hypothetical Document Embeddings) — hlavní problém: dotaz uživatele nevypadá jako dokument. Krátký dotaz „What are the side effects of drug X?" má úplně jiné embedding než 5stránkový příbalový leták.

Řešení:

# Step 1 — vygenerujte FIKTIVNÍ dokument
Given this user query, generate a 5-page hypothetical medical
report that fully answers it. Match the style of professional
drug information leaflets.

Query: {{query}}

Fiktivní dokument pak embedujete a hledáte jeho embedding ve vector DB. Výsledek je často výrazně bližší skutečným dokumentům než holý dotaz.

Debata o budoucnosti RAGu: Když bude mít AI nekonečný compute, není RAG zbytečný? Kian tvrdí, že ne — i při stejné přesnosti má RAG výhodu latence a zdrojování. Analogie: i s rychlým compute webové vyhledávače stále používají indexy a ranking místo toho, aby při každém dotazu přečetly celý web.

---

##5. Agentní AI workflow

Andrew Ng razí termín „agentic workflow" místo „agent", protože slovo agent se používá pro cokoli od jednoho promptu po multi-agentní systém. Agentní workflow = vícekrokový proces, který kombinuje prompty + tooly + paměť + volání API.

###Od jednoho promptu k workflow

Naivní přístup: „What is your refund policy?" → RAG → odpověď.

Workflow:

User: "Can I get a refund for my order?"
 ├─ Agent retrieves refund policy via RAG
 ├─ Agent asks user: "Can you provide your order number?"
 ├─ Agent queries order API → checks dates, amount, status
 └─ Agent replies: "Your order qualifies for a refund. It will
                   be processed in 3–5 business days."

###Paradigm shift: deterministické vs. fuzzy inženýrství

Kian zdůrazňuje, že nejlepší inženýři, které zná, umějí plynule přepínat mezi deterministickým a fuzzy přístupem.

Příklad z Workery: deterministické typy úloh (multiple choice, drag-and-drop) vs. fuzzy (hlas, kód). Fuzzy úlohy vyžadují appeal feature — uživatel může napadnout hodnocení, člověk v cyklu opraví. Právě tento human-in-the-loop je návrhový vzor, který byste měli mít v hlavě, kdykoli stavíte fuzzy systém.

###Stavební bloky agenta

Kian vezme příklad travel booking agenta a rozebere jeho složky:

┌──────────────────── AGENT ────────────────────┐
│                                                │
│  ┌─────────────┐   ┌──────────────────────┐    │
│  │ Prompts     │   │ Context management   │    │
│  │ (system,    │   │  ├─ Working memory   │    │
│  │  chain,     │   │  │  (jméno, aktuální │    │
│  │  templates) │   │  │   konverzace)     │    │
│  └─────────────┘   │  └─ Archival memory  │    │
│                    │     (birthday, hist.)│    │
│                    └──────────────────────┘    │
│                                                │
│  ┌──────────────── Tools ────────────────┐     │
│  │  Flight API │ Hotel API │ Car API     │     │
│  │  Weather API │ Payment API            │     │
│  └───────────────────────────────────────┘     │
│                                                │
│  ┌──────────────── Resources ────────────┐     │
│  │  CRM data │ Knowledge base │ Files    │     │
│  └───────────────────────────────────────┘     │
└────────────────────────────────────────────────┘

Memory: working memory musí být rychlá (model ji čte každou interakci — 3s latence by byla neúnosná). Archival memory je pomalejší, ale levnější. Rozhodnout, co kam patří, je netriviální a zatím neřešený problém.

Tools: LLM překvapivě dobře čtou API dokumentaci. Dejte modelu JSON schema endpointu a on si ho zavolá. Příklad definice toolu (OpenAI style):

{
  "type": "function",
  "function": {
    "name": "search_flights",
    "description": "Search for flights between two cities on a given date.",
    "parameters": {
      "type": "object",
      "properties": {
        "origin":      { "type": "string", "description": "IATA code" },
        "destination": { "type": "string", "description": "IATA code" },
        "date":        { "type": "string", "format": "date" },
        "max_stops":   { "type": "integer", "default": 1 }
      },
      "required": ["origin", "destination", "date"]
    }
  }
}

###Stupně autonomie

┌────────────────────────────────────────────────────────────┐
│ Low autonomy                                  High autonomy│
├────────────────────────────────────────────────────────────┤
│ Hard-coded steps      │ Hard-coded tools     │ Agent picks │
│  + hard-coded tools   │  + agent picks steps │  steps AND  │
│                       │                      │  tools,     │
│                       │                      │  can write  │
│                       │                      │  code       │
└────────────────────────────────────────────────────────────┘

Nejautonomnější varianta znamená, že agent má přístup ke code editoru a může si na místě napsat Python/JS skript (výpočet vzdálenosti, parsování dat, vizualizace). Přesně to dělají moderní coding agenti.

###MCP (Model Context Protocol)

API přístup — musíte každé API ručně popsat, udržovat; škáluje špatně.

MCP (Anthropic, 2024) — standardizovaný protokol mezi agenty a datovými/nástrojovými endpoints. Agent se zeptá MCP serveru „co potřebuješ?", server odpoví „origin, destination, budget", agent dodá. Komunikace agent-to-agent místo ručního popisování každého API.

┌──────────┐   MCP protocol   ┌──────────────┐
│  LLM     │ ◀──────────────▶ │  MCP Server  │
│  agent   │  (JSON-RPC)      │  ├─ Flights  │
│  (client)│                  │  ├─ Hotels   │
└──────────┘                  │  └─ Payments │
                              └──────────────┘

Efficiency, ne přístup k datům. MCP neotevírá nic, k čemu byste jinak neměli přístup — jen usnadňuje objevování a komunikaci. Bezpečnostní hledisko: MCP server vidí vstupy z jakéhokoli LLM klienta → autentizace a autorizace jsou kritické.

###Reálný průběh travel agenta

1. User intent: „Plan a trip to Paris Dec 15–20, flights + hotel near Eiffel + must-visit itinerary."

2. Agent plánuje (vnitřní CoT): najít lety → vyhledat hotely → sestavit program → ověřit rozpočet → zarezervovat přes payment API.

3. Provedení: volá tooly, kombinuje výstupy.

4. Zpětná vazba: předloží uživateli návrh ke schválení, případně iteruje.

5. Aktualizace paměti: uloží preferenci („user prefers direct flights, OK with 3-star hotels").

---

##6. Case study: customer support agent + evals

Zadání od produktového manažera: „Udělej AI agenta pro customer support." První zpráva:

"I need to change my shipping address for order #12345.
 I moved to a new address."

###Krok 1: Dekompozice úlohy

Nežeňte se rovnou do technologie. Strávte den s reálným pracovníkem zákaznické podpory. Rozložte, co dělá:

1. Extrakce klíčových údajů (order ID, nová adresa, záměr)

2. Vyhledání zákazníka v DB

3. Ověření pravidel — povolujeme vůbec změnu adresy?

4. Příprava odpovědi

5. Odeslání e-mailu

###Krok 2: Mapování na architekturu agenta

###Krok 3: Evals

Kian tvrdí, že pokud děláte pohovor do AI startupu, měli byste se ptát, jestli mají LLM traces. Bez traces se agentní systémy ladí bídně.

Evals se klasifikují ve čtyřech nezávislých dimenzích:

             Component-based ─────┬───── End-to-end
                                  │
Objective ────────────────────────┼──────────────── Subjective
                                  │
Quantitative ─────────────────────┴──────────────── Qualitative

Příklady:

• Objective x component-based x quantitative: „Extrahoval LLM správné order ID z uživatelovy zprávy?" → Python assert nad parsed_id == user_mentioned_id.

• Objective x end-to-end: „Byl vybrán levnější ze dvou identických letů?" → deterministická kontrola.

• Subjective x component-based: „Je výsledný e-mail zdvořilý?" → LLM-as-a-judge s rubric.

• Subjective x end-to-end x qualitative: „Byl uživatel spokojený?" → thumbs up/down + otevřená zpětná vazba + analýza příčin.

Praktický postup:

1. Error analysis na 20 reálných interakcích — odhalíte třeba „LLM je strohý, žádný pozdrav, žádné ‚omlouváme se'".

2. Sestavte LLM judges s rubric na to, co jste objevili.

3. A/B testujte — zaměňte GPT-4 → Grok → Llama, nebo fixujte model a měňte prompt (act as travel agent vs. act as helpful travel agent).

4. Měřte po komponentách: tooly, přesnost RAG retrievalu, kvalitu odpovědi, latenci každého kroku.

Ukázka judge promptu na zdvořilost:

You are evaluating customer support emails. Grade politeness 1-5.

Rubric:
- 5: warm opening, empathetic acknowledgment, clear solution,
     polite closing. No jargon.
- 3: neutral, gets the job done, lacks warmth.
- 1: curt, no acknowledgment of the issue, robotic.

Email:
<<< {{email}} >>>

Return: { "score": <int>, "what_worked": "...", "what_to_fix": "..." }

---

##7. Multi-agent workflow

„Když už jeden workflow volá LLM mnohokrát s tooly, proč bych chtěl víc agentů?"

Dva hlavní důvody:

1. Paralelismus — pokud víc věcí může běžet nezávisle, rozbijte je.

2. Znovupoužitelnost — jeden design-agent slouží marketingu i produktu; optimalizujete jednou pro víc odběratelů.

###Vzory spolupráce

Flat (all-to-all):

   [A1]────[A2]
    │ ╲   ╱ │
    │  ╲ ╱  │
    │   X   │
    │  ╱ ╲  │
    │ ╱   ╲ │
   [A3]────[A4]

Hierarchický:

          [Orchestrator]
         /      |       \
     [A1]     [A2]      [A3]

Typicky jeden orchestrator mluví s uživatelem a rozděluje práci — lepší UX (uživatel má jedno rozhraní) a čistší oddělení odpovědností.

###Příklad: smart home

Přednáška brainstormuje s třídou. Výsledek:

• Security agent — kdo smí dovnitř, s jakými právy (rodič vs. dítě)

• Biometric / location agent — kde se lidé v domě nacházejí

• Climate agent — teplota, napojení na weather API

• Lighting agent

• Energy agent — optimalizace spotřeby, využití gridu, solár

• Fridge / grocery agent — kamera v lednici + Amazon API pro doobjednání

• Entertainment agent

• Notification agent — systémové zprávy, alerty

• Orchestrator — jediný hlas, který mluví s uživatelem

Klíčový poznatek: když necháte dva agenty mluvit přímo, je to de facto MCP vztah — jeden druhého vnímá jako tool s dokumentovaným rozhraním.

###Výhody multi-agent přístupu

• Jednodušší ladění — specializovaný agent má menší stavový prostor.

• Paralelizace → nižší celková latence.

• Vlastnictví po týmech — různé týmy spravují různé agenty (organizační výhoda).

---

##8. Kam to směřuje — Kianovy trendy

Závěr přednášky vyjmenovává témata, která stojí za sledování:

1. Plateau? Ilya Sutskever otevřel debatu, zda LLM přestávají škálovat. Kian: scaling laws platí, dokud je compute a energie. Pak přijde architecture search — někdo objeví „další transformer" a posune křivku o 10x.

2. Multi-modalita — text + obraz + audio + video v jednom modelu. Zisky z jedné modality se přenášejí do jiné. Finální forma = robotika, kde všechny modality splývají.

3. Metody v harmonii — supervised, unsupervised, self-supervised, RL, prompting, RAG. Analogie s učením dítěte: DNA = pretraining, rodiče = supervised, pády = RL reward, pozorování = unsupervised. Příští generace systémů bude kombinovat všechno najednou.

4. Human-centric vs. non-human-centric výzkum — backpropagation v mozku pravděpodobně neexistuje (možná jen forward propagation). Vyplatí se sledovat laboratoře, které staví systémy mimo analogii s mozkem.

5. Rychlost zastarávání dovedností — half-life dovednosti v AI je nízký. Šířka pohledu > hluboký ponor do dnešního state-of-the-art. Co budete potřebovat, doučíte se za víkend.

---

##TL;DR pro inženýry

• Než fine-tunujete, vyzkoušejte všechno v promptu. Prompt templates, few-shot, CoT, chaining, RAG. Fine-tuning je drahý, zastará a obvykle se mu vyhnete.

• Rozložte úlohu, než navrhujete architekturu. Strávte den s doménovým expertem. Pak mapujte krok → vanilla LLM / tool / RAG / memory.

• LLM traces jsou nutná podmínka ladění agentních systémů. Pokud je váš stack nemá, zaveďte je hned.

• Evals na 4 osách: objective/subjective x component/end-to-end x quantitative/qualitative. Začněte error analysis na 20 reálných případech.

• Fuzzy systémy potřebují guardrails a human-in-the-loop. Appeal feature, záložní scénáře, rate limits, autorizace na MCP.

• Multi-agent jen pro paralelismus nebo znovupoužitelnost. Jinak je monolitický workflow jednodušší.

• Sledujte horizontální osu (nové modely), ale investujte do vertikální (prompty, RAG, agenti). Vaše aplikace se sama zlepší s každým příštím modelem.

---

###Zdroje zmíněné v přednášce

• Chain-of-Thought Prompting paper (Wei et al., 2022)

• awesome-chatgpt-prompts — repozitář promptů na GitHubu

• Promptfoo — A/B testing platforma pro prompty

• HyDE paper (Hypothetical Document Embeddings)

• Anthropic Model Context Protocol (MCP) — seminal article

• BCG × HBS × Wharton × UPenn studie o „jagged frontier"

• McKinsey case study — credit risk memo (20–60 % úspora času)

• Andrew Ng — termín „agentic workflows"

###Další soubory v této složce

• 01-raw-transcript.md — surový anglický přepis (manuální titulky, s timestampy ~60s)

• 03-summary-cs.md — stručné shrnutí (cca 1 strana)