@harness-lab/cli 0.2.1 → 0.2.2

package/assets/workshop-bundle/content/facilitation/master-guide.md

@@ -0,0 +1,131 @@
+# Facilitační průvodce
+
+## Otevření a welcome
+
+### Cíl
+
+Nastavit energii dne a jasně pojmenovat, o čem workshop je.
+
+### Klíčová message
+
+> „Dnes nejde o to být nejrychlejší. Jde o to předat práci tak, aby ji cizí tým dokázal převzít a posunout dál.“
+
+### Co potřebuje zaznít
+
+- Nejde o soutěž v promptování.
+- Jde o práci s agentem tak, aby po vás zůstával použitelný kontext.
+- Odpolední část prověří, jestli repo umí mluvit samo za sebe.
+- Pokud nějaké důležité pravidlo žije jen v hovoru u stolu, ještě neexistuje.
+
+### Co má facilitátor průběžně vracet
+
+- „Kde by to našel další tým bez vás?“
+- „Co je tady skutečně ověřené?“
+- „Je `AGENTS.md` mapa, nebo už se z něj stává dump?“
+- „Jaký je další bezpečný krok pro cizího člověka nebo agenta?“
+
+## Build Phase 1
+
+### Viditelný milestone board
+
+1. do 10:50 existuje repo
+2. do 11:15 existuje `AGENTS.md`
+3. do 11:30 existuje plan
+4. do 11:45 existuje build/test command nebo tracer bullet
+5. do 12:00 existuje první reviewed output
+
+### Role facilitátora
+
+- nejdřív coach — ptejte se, co tým potřebuje a kde je zaseknutý
+- pak mentor — pomozte s workflow nebo s nástrojem
+- učitel až jako poslední možnost — krátce vysvětlete princip a vraťte tým do práce
+- participantům vracejte hlavně learner-facing artefakty, ne celý backstage Harness Lab
+
+### Na co se při obcházení dívat
+
+- Má tým jednu společnou představu o cíli?
+- Přibývá kontext v repu, nebo zůstává jen v chatu a v hlavách?
+- Ověřují si výstupy, nebo jen generují další text?
+- Mají test, tracer bullet nebo jiné explicitní ověření, které drží agenta v mezích?
+- Je z repa poznat, co je hotové, co je rozpracované a co je jen hypotéza?
+- Uměl by jiný tým během pěti minut najít první bezpečný krok?
+
+### Facilitační pointa k testům
+
+- S coding agentem nestačí říct „tohle si pak projdeme“.
+- Jakmile agent dostává větší autonomii, tým musí zvýšit kvalitu ověřování.
+- Test-first přístup není dogma pro čistotu. Je to praktický způsob, jak převést záměr do formy, kterou agent umí opakovaně trefovat.
+- Když tým žádné ověření nemá, facilitátor má tlačit na nejmenší možný test nebo tracer bullet, ne na další generování funkcí.
+- U UI práce připomínejte pattern: rychlá agent exploration v izolovaném prostředí, potom browser test, potom lidské review.
+- Pokud tým mluví o tom, že „agent to prostě nakliká v mém browseru“, vraťte debatu k sandboxu, nízkému riziku a explicitní kontrole.
+
+### Co normalizovat
+
+- `AGENTS.md` jako krátkou mapu, ne rostoucí skladiště všeho
+- plan jako pracovní artefakt, ne ceremonii navíc
+- malý průběžný úklid, když se začne šířit chaos nebo duplicity
+- převod opakovaných připomínek do repa místo dalšího ústního mentoringu
+
+## Intermezza
+
+Každé intermezzo má tři kroky:
+
+1. Týmy napíšou jednu větu: „Co jsme změnili a proč.“
+2. Ondřej shrne, co vidí u stolů a co ukazuje monitoring.
+3. Zazní jedna principová pointa navázaná na to, co se opravdu děje v místnosti.
+
+Preferované checkpoint otázky:
+
+- Co jste přesunuli z chatu nebo z hlavy do repa?
+- Co dnes ověřujete pomocí spustitelného checku?
+- Co by měl číst další tým jako první?
+
+### Smysl intermezz
+
+- zviditelnit učení napříč týmy
+- udělat z průběhu dne sérii krátkých checkpointů
+- připomenout, že workflow je stejně důležité jako samotný output
+- vracet týmy k tomu, že bez ověření jen akcelerují nejistotu
+
+## Rotace
+
+- Bez ústního handoffu.
+- Prvních 10 minut nový tým jen čte repo a mapuje situaci.
+- Frustrace není chyba workshopu. Je to signál kvality kontextu v repozitáři.
+
+### Instrukce pro nový tým
+
+- Začněte `README`, `AGENTS.md` a planem.
+- Needitujte hned první soubor, který otevřete.
+- Nejprve si udělejte mapu: co funguje, co chybí, co je rizikové.
+- Nejdřív napište vlastní diagnózu: co pomáhá, co chybí, co je rizikové a jaký je další safe move.
+- Když tým neví, po čem sáhnout, vraťte ho k learner kit artefaktům: `template-agents`, `reference`, `analyze-checklist`, challenge cards.
+
+### Facilitační pointa k rotaci
+
+- Frustrace je užitečný signál, pokud ukazuje na skrytý kontext nebo chybějící verifikaci.
+- Nepomáhejte týmům ústním handoffem nahrazovat slabý repo signal.
+- Pomáhejte jim pojmenovat, co musí být po rotaci dopsáno, zpřesněno nebo ověřeno.
+
+## Reveal a reflexe
+
+### `1-2-4-All`
+
+Otázky:
+
+- Co vám pomohlo pokračovat?
+- Co chybělo?
+- Jaký signál v repu vám nejvíc ušetřil čas?
+
+### `W³`
+
+- `Co?` — co se dnes stalo bez hodnocení
+- `A co?` — co to znamená pro práci s AI agenty
+- `A teď?` — co uděláte jinak příští týden
+
+### Rámec pro facilitaci
+
+- Nehodnotíme, který tým byl lepší.
+- Díváme se na systém: které signály pomáhají práci přežít handoff a které ji brzdí.
+- Sbíráme konkrétní příklady, ne obecné dojmy.
+- Každá opakující se bolest je kandidát na lepší template, challenge card nebo guidance v blueprintu.

package/assets/workshop-bundle/content/project-briefs/code-review-helper.md

@@ -0,0 +1,31 @@
+# Code Review Helper
+
+## Problém
+
+Code review bývá nevyrovnané. Některé změny projdou s dobrým checklistem a jasným popisem rizik, jiné bez společného rámce. Reviewer pak improvizuje, autor neví, co má ověřit předem, a tým ztrácí konzistenci.
+
+Vaším úkolem je navrhnout nástroj, který z diffu nebo změny vytvoří použitelný review checklist.
+
+## User stories
+
+- Jako reviewer chci z diffu rychle získat checklist rizik, otázek a míst, na která se zaměřit.
+- Jako autor změny chci vědět, co mám zkontrolovat ještě před samotným review.
+- Jako tým po rotaci chci navázat na heuristiky, které původní tým objevil, místo abych je znovu vymýšlel.
+
+## Architektonické poznámky
+
+- Může jít o CLI, web nebo jednoduchý skript. Důležitý je jasný tok `diff → analýza → checklist`.
+- Musí být zřejmé, jaké vstupy nástroj očekává a co naopak neumí spolehlivě vyhodnotit.
+- Přidejte seed diff nebo `examples/`, aby šlo workflow lokálně ověřit.
+- Jasně oddělte heuristiku od jistoty. Nástroj má pomáhat reviewerovi, ne předstírat neomylnost.
+
+## Hotovo když
+
+- Nástroj vytvoří review checklist ze seed diffu.
+- Výstup odlišuje jistá zjištění od doporučení nebo hypotéz.
+- Je jasné, jak přidat nové pravidlo nebo heuristiku bez dlouhého onboardingu.
+- Další tým může během několika minut pokračovat v rozvoji bez chaosu.
+
+## První krok pro agenta
+
+Nezačínej kódem. Nejdřív napiš pravidla review, tok vstupů a definici toho, co znamená dobrý checklist. Teprve potom navrhni první implementační slice.

package/assets/workshop-bundle/content/project-briefs/devtoolbox-cli.md

@@ -0,0 +1,31 @@
+# DevToolbox CLI
+
+## Problém
+
+Ve skoro každém týmu vznikají malé jednorázové skripty: na čištění logů, převody JSONu, dohledání podezřelých commitů nebo rychlé kontroly nad repem. Fungují chvíli, často jen u jednoho člověka, a po pár dnech už nikdo neví, jak je spustit nebo rozšířit.
+
+Vaším úkolem je navrhnout CLI nástroj, který řeší několik běžných developerských úloh tak, aby přežil handoff na jiný tým.
+
+## User stories
+
+- Jako vývojář chci jedním příkazem převést log nebo JSON do čitelné podoby.
+- Jako vývojář chci rychle dohledat podezřelé commity, větve nebo změny bez ručního skládání git příkazů.
+- Jako tým chci mít příkazy i způsob práce popsané tak, aby po rotaci mohl bez zmatku pokračovat někdo jiný.
+
+## Architektonické poznámky
+
+- Jazyk i framework si zvolte sami, ale CLI musí být snadno spustitelné a snadno objevitelné.
+- Od začátku oddělte samotné příkazy od pomocných utilit a konfigurace.
+- `AGENTS.md` má popsat build/test flow, konvence pro výstupy a pravidla pro další rozšiřování.
+- Stejně důležitý jako funkční příkaz je i runbook pro tým, který projekt převezme po obědě.
+
+## Hotovo když
+
+- Existují alespoň 3 užitečné příkazy nebo subcommands.
+- `README` i `AGENTS.md` popisují lokální spuštění a způsob ověření.
+- Je jasné, kde přidat další příkaz bez rozbití struktury projektu.
+- Nový tým zvládne během 10 minut přidat nebo opravit další command.
+
+## První krok pro agenta
+
+Nejdřív navrhni minimální architekturu, která přežije handoff. Začni `AGENTS.md`, potom připrav plan a teprve pak implementuj první command.

package/assets/workshop-bundle/content/project-briefs/doc-generator.md

@@ -0,0 +1,31 @@
+# Doc Generator
+
+## Problém
+
+Dokumentace stárne skoro okamžitě. Jakmile je její údržba čistě ruční, tým ji začne odkládat a po pár iteracích už nikdo neví, jestli popisuje realitu.
+
+Vaším úkolem je navrhnout nástroj, který z projektu vygeneruje základní technickou dokumentaci nebo strukturovaný přehled.
+
+## User stories
+
+- Jako vývojář chci z projektu rychle získat základní technickou dokumentaci bez ručního sepisování všeho od nuly.
+- Jako reviewer chci během pár minut pochopit strukturu modulů a hlavní vstupní body.
+- Jako tým po rotaci chci objevit architekturu projektu bez dlouhého pátrání po souvislostech.
+
+## Architektonické poznámky
+
+- Vstup může být lokální repo, seed adresář nebo zjednodušený dataset.
+- Výstup může být Markdown, HTML nebo jednoduchý textový report.
+- Důležité je vysvětlit, co nástroj umí spolehlivě odvodit a co je jen heuristika.
+- Od začátku navrhněte strukturu tak, aby šlo časem přidat další typ výstupu.
+
+## Hotovo když
+
+- Nástroj vytvoří aspoň jednu čitelnou dokumentační stránku nebo report.
+- Je jasné, jak se nástroj spouští lokálně a nad jakým vstupem.
+- Výstup odděluje fakta od odhadů nebo heuristik.
+- Další tým umí přidat nový typ výstupu bez chaosu v repu.
+
+## První krok pro agenta
+
+Nejdřív popiš, jaké signály budeš z projektu číst, co z nich umíš odvodit a kde jsou hranice jistoty. Až potom navrhni první implementaci.

package/assets/workshop-bundle/content/project-briefs/metrics-dashboard.md

@@ -0,0 +1,31 @@
+# Metrics Dashboard
+
+## Problém
+
+Týmy často data mají, ale chybí jim obrazovka, která z nich udělá rychle čitelný přehled. Bez toho se hůř rozhoduje, hůř diskutuje a každý si z čísel odnese něco jiného.
+
+Vaším úkolem je navrhnout jednoduchý dashboard, který z několika metrik vytvoří srozumitelný společný pohled.
+
+## User stories
+
+- Jako tým chci zobrazit několik metrik na jedné obrazovce tak, aby z nich šlo rychle vyčíst stav.
+- Jako facilitátor chci snadno měnit seed data bez zásahu do UI logiky.
+- Jako tým po rotaci chci během několika minut pochopit strukturu dat, komponent i obrazovek.
+
+## Architektonické poznámky
+
+- Seed data a UI oddělte hned od prvního commitu.
+- Mobile-first je výhoda, ale dashboard musí být dobře čitelný i na projekci.
+- README a monitoring mají vysvětlit, co už funguje, co je mock a co zatím chybí.
+- Myslete na to, aby přidání další metriky nevedlo k přepisování celé obrazovky.
+
+## Hotovo když
+
+- Dashboard ukáže alespoň 3 metriky a jeden trend nebo srovnání.
+- Repo popisuje datové zdroje i mock fallback.
+- Je jasné, kde se přidává nová metrika a jak se ověřuje layout.
+- Nový tým zvládne rozšířit dashboard bez rozbití struktury.
+
+## První krok pro agenta
+
+Navrhni dashboard, který zvládne handoff. Nejdřív popiš datový model, komponenty a kritéria `Hotovo když`, teprve potom stav UI.

package/assets/workshop-bundle/content/project-briefs/standup-bot.md

@@ -0,0 +1,31 @@
+# Standup Bot
+
+## Problém
+
+Denní standupy v chatu často končí jako dlouhé vlákno bez struktury. Blokery zapadnou, návaznosti mezi lidmi nejsou vidět a po pár hodinách už se těžko dohledává, co se vlastně domluvilo.
+
+Vaším úkolem je navrhnout nástroj, který ze standup vstupů vytvoří přehled, se kterým se dá dál pracovat.
+
+## User stories
+
+- Jako team lead chci sesbírat standup odpovědi do jednoho přehledného souhrnu.
+- Jako vývojář chci rychle vidět blokery, dependency a témata, která potřebují domluvu.
+- Jako tým po rotaci chci pochopit datový tok i integrační body bez ústního handoffu.
+
+## Architektonické poznámky
+
+- Upřednostněte jasný datový model před složitou integrací.
+- Mock data jsou v pořádku, pokud workflow působí realisticky a je dobře popsané.
+- Oddělte ingest, zpracování a prezentaci výstupu.
+- Prompty, runbooky a rozhodnutí musí být uložené v repu, ne jen v hlavách původního týmu.
+
+## Hotovo když
+
+- Nástroj umí ingestovat seed data a vytvořit čitelný souhrn.
+- Výstup zvýrazní blokery nebo položky, které potřebují pozornost.
+- Repo obsahuje instrukce, jak řešení napojit na reálný chat nebo jiný vstupní kanál.
+- Po rotaci lze navázat bez dalšího vysvětlování.
+
+## První krok pro agenta
+
+Rozděl práci na ingest, sumarizaci a kontext pro další tým. Nejdřív napiš dokumentaci, kterou nový tým otevře jako první, a až potom navrhni implementační kroky.

package/assets/workshop-bundle/content/style-examples.md

@@ -0,0 +1,127 @@
+# Czech Style Examples
+
+## Do / Don't
+
+### 1. Instrukce
+
+Do:
+
+- „Otevřete repozitář a nejdřív doplňte `AGENTS.md`.“
+
+Don't:
+
+- „V prvním kroku je vhodné provést vytvoření souboru `AGENTS.md`.“
+
+### 2. Setup
+
+Do:
+
+- „Když se setup sekne, přejděte na Codex App nebo web fallback.“
+
+Don't:
+
+- „V případě komplikací v procesu instalace je možné využít alternativní variantu přístupu.“
+
+### 3. Facilitation
+
+Do:
+
+- „Prvních 10 minut po rotaci jen čtěte a mapujte repo.“
+
+Don't:
+
+- „Po realizaci rotace doporučujeme zahájit aktivitu detailní analýzou repozitáře.“
+
+### 4. Workshop framing
+
+Do:
+
+- „Dnes nejde o to být nejrychlejší. Jde o to předat práci tak, aby ji cizí tým dokázal převzít.“
+
+Don't:
+
+- „Hlavním cílem dnešního dne je maximalizace schopnosti efektivního předávání výstupů mezi týmy.“
+
+### 5. Czech + English
+
+Do:
+
+- „Nejdřív spusťte `/plan`, potom implementujte malý krok a nakonec udělejte `/review`.“
+
+Don't:
+
+- „Nejdříve vytvořte plán, pak proveďte implementaci a následně zrevidujte změnu.“
+
+Poznámka:
+
+Tady je angličtina přirozenější, protože jde o konkrétní commands a workflow terms.
+
+### 6. Technical explanation
+
+Do:
+
+- „Monitoring teď běží jako manuální MVP. Ondřej spustí scan repozitářů a z výsledku připraví intermezzo brief.“
+
+Don't:
+
+- „Monitoring je aktuálně realizován prostřednictvím minimální životaschopné verze manuálního typu.“
+
+### 7. Briefs
+
+Do:
+
+- „Mock data jsou v pořádku, pokud workflow působí realisticky.“
+
+Don't:
+
+- „Použití simulovaných dat je akceptovatelné za předpokladu, že výsledný proces bude působit realisticky.“
+
+### 8. Error / fallback messaging
+
+Do:
+
+- „Pokud vám nefunguje CLI, pokračujte přes App a neztrácejte dalších 20 minut.“
+
+Don't:
+
+- „V případě nefunkčnosti rozhraní příkazové řádky doporučujeme zvážit alternativní postup.“
+
+## Approved English Terms
+
+Tyto výrazy se v participant-facing textech běžně nechávají v angličtině:
+
+- `prompt`
+- `review`
+- `workflow`
+- `skill`
+- `runbook`
+- `build`
+- `deploy`
+- `checkpoint`
+- `fallback`
+- `handoff`
+- `CLI`
+- `App`
+- `repo`
+- `README`
+- `AGENTS.md`
+- `Done When`
+
+## Usually Better In Czech
+
+Tyto části bývají lepší česky:
+
+- cíle a instrukce
+- facilitační věty
+- reflexe a uzavírání
+- vysvětlení, proč něco děláme
+- očekávání a pravidla workshopu
+
+## Rewrite Heuristic
+
+Když text zní moc tvrdě přeloženě, uprav ho takto:
+
+1. zkrať větu
+2. vrať české sloveso do aktivního rodu
+3. nech technický termín v angličtině
+4. zkontroluj, že věta vede k akci

package/assets/workshop-bundle/content/style-guide.md

@@ -0,0 +1,106 @@
+# Czech Voice & Style Guide
+
+## Purpose
+
+Tento workshop mluví česky, ale přemýšlí jako moderní developerský tým. Cílem není přeložit celý obor do češtiny. Cílem je psát tak, aby český developer text pochopil napoprvé a zároveň měl pocit, že čte přirozený, profesionální a jazykově kultivovaný obsah.
+
+## Core Principle
+
+Preferujeme porozumění před doslovným překladem.
+
+- čeština pro význam, instrukce, facilitaci a vysvětlení
+- angličtina pro běžné technické termíny, commands, file names a tool names
+
+## Tone of Voice
+
+- Piš jako zkušený peer, ne jako marketér a ne jako školní učebnice.
+- Buď věcný, klidný a praktický.
+- Piš s energií, ale bez hype.
+- Vysvětluj jasně, ale ne patronizujícím tónem.
+- Preferuj přesnost a použitelnost před efektní formulací.
+
+## Language Rules
+
+- Základní jazyk je spisovná, přirozená čeština.
+- Technické výrazy nech v angličtině, pokud jsou v developerské praxi běžnější než český ekvivalent.
+- Nepřekládej násilně výrazy jako `prompt`, `review`, `workflow`, `skill`, `runbook`, `deploy`, `build`, `checkpoint`, `handoff`, `fallback`, `CLI`, `App`.
+- Slash commands, file names, paths a config keys vždy nech v originále.
+- Když je anglický termín méně samozřejmý, při prvním výskytu ho krátce ukotvi česky.
+
+## Sentence Style
+
+- Používej kratší věty.
+- Preferuj aktivní rod.
+- Piš konkrétní slovesa místo abstraktních obratů.
+- Každý odstavec má mít jeden jasný účel.
+- Když lze něco říct jednodušeji, zjednoduš to.
+
+## What Good Looks Like
+
+- „Nejdřív spusťte `/plan` a teprve potom začněte implementaci.“
+- „Pokud se zaseknete déle než 7 minut, přejděte na fallback nebo pairing.“
+- „Do 10:30 potřebujete mít jednu funkční cestu do Codexu.“
+
+## What To Avoid
+
+- korporátní omáčka
+- doslovné kalky z angličtiny
+- přehnaně akademický tón
+- agresivní marketingový tón
+- zbytečné vykřičníky
+
+## Preferred Vocabulary
+
+- `udělejte`
+- `zkontrolujte`
+- `spusťte`
+- `doplňte`
+- `ověřte`
+- `pokračujte`
+- `když se zaseknete`
+
+## Avoid These Patterns
+
+- „je žádoucí realizovat“
+- „dochází k implementaci“
+- „v rámci workshopu bude umožněno“
+- „s cílem maximalizace efektivity“
+- „využitím tohoto přístupu dosáhnete…“
+
+## Czech + English Mixing Rule
+
+Česká věta má zůstat česká, i když obsahuje anglické technické termíny.
+
+Dobře:
+
+- „Po rotaci si nejdřív přečtěte `README`, `AGENTS.md` a aktuální plan.“
+- „Použijte `/review`, když chcete zkontrolovat větší změnu.“
+
+Špatně:
+
+- „Use `/plan` before coding, because it gives better context.“
+- „V rámci challenge budete implementing a new workflow.“
+
+## Formatting Rule
+
+- Commands, file names, slash commands a literal terms piš v backticks.
+- Nadpisy a běžný výklad piš normální češtinou.
+- V participant-facing textu nezahlcuj čtenáře dlouhými bloky textu.
+
+## Audience Calibration
+
+Workshop je pro developery. Nepiš, jako by publikum bylo netechnické.
+
+- není nutné vysvětlovat běžné výrazy typu `repo`, `review`, `deploy`
+- je vhodné vysvětlit nový koncept, pokud je specifický pro workshop
+- když volíš mezi „přeložit“ a „zachovat známý termín“, preferuj známý termín
+
+## Final Check Before Publishing
+
+Před uložením participant-facing textu si ověř:
+
+1. Zní to jako přirozená čeština?
+2. Pochopí to český developer napoprvé?
+3. Nepřekládám něco, co má zůstat v angličtině?
+4. Nezní to jako marketing nebo korporát?
+5. Je z textu jasné, co má člověk udělat?

package/assets/workshop-bundle/content/talks/codex-demo-script.md

@@ -0,0 +1,43 @@
+# Codex Demo Script
+
+## Cíl
+
+Jedna příběhová ukázka, ne seznam feature. Publikum má během 15 minut pochopit, jak vypadá dobrý workflow s agentem.
+
+## Příběh
+
+„Jsem vývojář, dostal jsem malý úkol a nechci být s agentem jen někdo, kdo zkouší další prompt. Chci postavit pracovní systém, který unese další iterace.“
+
+## Flow
+
+1. Otevři jednoduchý repozitář nebo sandbox projekt.
+2. Ukaž, že bez kontextu agent rychle tápe.
+3. Vytvoř `AGENTS.md` se 4 prvky:
+   - Goal
+   - Context
+   - Constraints
+   - Done When
+4. Spusť `/plan`, aby agent rozpadl práci na kroky.
+5. Nech agenta implementovat malý kus.
+6. Spusť `/review` a ukaž, že kontrola je součást workflow, ne nouzová brzda na konci.
+7. Krátce ukaž skill:
+   - instalovaný skill
+   - nebo jednoduchý command z workshop skillu
+8. Zavři to větou:
+   - „Nástroj sám nestačí. Rozhoduje pracovní systém kolem něj.“
+
+## Fallbacky
+
+- Když nefunguje CLI: přejdi na Codex App
+- Když nefunguje App: použij web fallback
+- Když je demo pomalé: měj připravený repo snapshot po každém kroku
+
+## Co explicitně neukazovat
+
+- pět různých režimů práce
+- složitou feature tour
+- dlouhé čekání na generování
+
+## Pointa pro místnost
+
+Nejde o to ukázat „kouzelný output“. Jde o to ukázat, jak rychle roste kvalita, když přidáme kontext, plán a review.

package/assets/workshop-bundle/content/talks/context-is-king.md

@@ -0,0 +1,42 @@
+# Context is King
+
+## Otevírací moment
+
+Tento workshop skill i dashboard vznikly stejným způsobem, jakým dnes budeme pracovat my: s AI agentem, ale s důrazem na kontext. Nejde mi o prodej nástroje. Jde mi o to ukázat disciplínu, která z nástroje dělá použitelného spolupracovníka.
+
+## Klíčová linka
+
+Harness engineering je práce s instrukcemi, kontextem a workflow tak, aby agent dělal správné věci opakovaně a předvídatelně. Team lead přece neříká každých třicet sekund jednomu vývojáři, co má dělat. Vytváří systém, ve kterém tým funguje. A přesně tohle dnes budeme dělat pro agenty.
+
+Moje hlavní reframing věta pro dnešek:
+
+> Neučíme se "lépe promptovat". Učíme se postavit repo a workflow, ve kterém agent i cizí tým dokážou bezpečně pokračovat.
+
+## Mikro-cvičení
+
+Všichni dostanou stejný malý úkol. Jedna varianta bude prompt blob. Druhá varianta bude krátké zadání se 4 prvky a s odkazem na repo-native kontext. Pak porovnáme výsledky. Nehledáme „nejhezčí prompt“. Hledáme způsob práce, který přenese záměr, omezení a kritéria hotovo i do dalšího kroku.
+
+## Hlavní teze
+
+- Kontext je páka, ne kosmetika.
+- `AGENTS.md`, skills a runbooky jsou týmová infrastruktura.
+- `AGENTS.md` nemá být encyklopedie. Má to být mapa, která ukáže, kam sáhnout dál.
+- Co není v repu, neexistuje. Slack, ústní dovysvětlení a "to si pamatujeme" se při continuation rozpadají.
+- Testy jsou hranice důvěry. Když agent pracuje samostatněji, musíte mnohem líp ověřovat, že udělal právě to, co jste chtěli.
+- Jednoduché mantinely zrychlují práci. Agentovi pomáhá jasný build/test flow, viditelné hranice a předvídatelná struktura.
+- U UI práce je výchozí pattern: agent exploration, potom repeatable browser test, potom lidské review.
+- „Nech model jezdit v mém běžném přihlášeném browseru“ není default. Bezpečnější je izolované lokální prostředí a jasné mantinely.
+- RED → GREEN není s agenty pomalejší. Naopak často zlevňuje korekce, protože agent dostane přesnější mantinely.
+- Úklid není bonus po workshopu. Když narazíte na opakující se chaos, je čas ho proměnit v lepší template, check nebo runbook.
+- Odpolední continuation prověří, jestli váš kontext funguje i bez vás.
+
+## Co chci, aby si adoptovali
+
+- Než začnu generovat feature, udělám z repa místo, kde se dá orientovat.
+- Když řekneme nějaké pravidlo dvakrát nahlas, patří do repa.
+- Když agent dělá víc, já musím lépe ověřovat.
+- Handoff není závěr dne. Je to průběžný design constraint.
+
+## Závěr
+
+Odpoledne nezažijete jen to, že „AI někdy funguje a někdy ne“. Zažijete, jak moc výsledek závisí na kvalitě pracovního systému, který kolem agenta postavíte.