@harness-lab/cli 0.2.9 → 0.3.0

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

@@ -1,84 +1,84 @@
 # Facilitační průvodce
 
-## Otevření a welcome
+## Otevření a welcome
 
 ### Cíl
 
-Spustit den jako room-facing launch pro celý workshop, ne jako provozní brief k dopoledni.
+Spustit den jako společný start pro celý workshop, ne jako provozní brief k dopoledni.
 
 ### Klíčová message
 
-> „Dnes nejde o to být nejrychlejší. Jde o to postavit práci tak, aby ji cizí tým dokázal převzít a posunout dál.“
+> „Dnes nejde o to být nejrychlejší. Jde o to postavit práci tak, aby ji cizí tým dokázal převzít a posunout dál.“
 
 ### Co potřebuje zaznít
 
-- Nezačínáme tool demo ani soutěž v promptování.
-- Budeme se učit, stavět, předávat i přebírat. Ten oblouk dne je záměr workshopu.
-- Jde o práci s agentem tak, aby po vás zůstával použitelný kontext.
+- Nezačínáme tool demo ani soutěž v promptování.
+- Budeme se učit, stavět, předávat i přebírat. Ten oblouk dne je záměr workshopu.
+- Jde o práci s agentem tak, aby po vás zůstával použitelný kontext.
 - Odpolední část prověří, jestli repo opravdu unese převzetí dalším týmem.
-- Pokud nějaké důležité pravidlo žije jen v hovoru u stolu, ještě neexistuje.
+- Pokud nějaké důležité pravidlo žije jen v hovoru u stolu, ještě neexistuje.
 
 ### Doporučený sled beatů
 
 1. day-opening promise
 2. proč na tom záleží právě teď
 3. analogie typu Lego duck: stejné ingredience, různé použitelné výsledky
-4. krátká pohybová aktivace podle zkušenosti s AI agenty
+4. krátká pohybová aktivace podle zkušenosti s AI agenty
 5. první pracovní kontrakt pro Build fázi 1
 
 ### Lego-duck analogie
 
-Použijte ji krátce a věcně.
+Použijte ji krátce a věcně.
 
 Pointa:
 
 - stejný agent neznamená stejný výsledek
 - kvalitu neurčuje samotný model
-- kontext, mantinely a ověřování jsou součást výsledku
+- kontext, mantinely a ověřování jsou součást výsledku
 
-Nevést jako zábavnou odbočku. Vést jako vysvětlení, proč je harness engineering tvůrčí a inženýrská disciplína zároveň.
+Nevést jako zábavnou odbočku. Vést jako vysvětlení, proč je harness engineering tvůrčí a inženýrská disciplína zároveň.
 
 ### Pohybová aktivace
 
-Použijte krátké rozdělení místnosti podle aktuální zkušenosti s AI agenty:
+Použijte krátké rozdělení místnosti podle aktuální zkušenosti s AI agenty:
 
 - používám skoro denně
 - používám, ale opatrně
 - jsem spíš na startu
-- jsem skeptický, ale chci důkaz
+- jsem skeptický, ale chci vidět, že to funguje
 
 Pravidla:
 
-- ne dělat z toho networking kolo
+- ne dělat z toho networking kolo
 - stačí přesun a 2 krátké hlasy
-- pointa není seniorita, ale kalibrace místnosti a signál, že den je participativní
+- pointa není seniorita, ale kalibrace místnosti a signál, že den je participativní
 
 ### 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?“
+- „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?“
 
 ### První pracovní kontrakt
 
-Po launchi potřebuje místnost ještě jednu konkrétní věc:
+Po otevření dne potřebuje místnost ještě jednu konkrétní věc:
 
-- co má být po prvním build bloku opravdu vidět v repu
-- co nestačí jen slíbit nebo dovysvětlit u stolu
+- co má být po prvním build bloku opravdu vidět v repu
+- co nestačí jen slíbit nebo dovysvětlit u stolu
 
 Do oběda má být vidět:
 
 - `README`, které dává smysl cizímu člověku
 - `AGENTS.md` jako krátká mapa, ne sklad všeho
-- plan nebo jasně vedená implementační stopa, ze které je poznat další safe move
-- první explicitní check před dalším generováním
+- plán kroků nebo jasně vedená implementační stopa, ze které je poznat další bezpečný krok
+- první explicitní ověření před dalším generováním
 
 ## Context is King talk
 
 ### Cíl
 
-Proměnit energii z openingu v přesnou tezi a čistý most do Build fáze 1.
+Proměnit energii z openingu v přesnou tezi a čistý most do Build fáze 1.
 
 ### Klíčová message
 
@@ -86,10 +86,10 @@ Proměnit energii z openingu v přesnou tezi a čistý most do Build fáze 1.
 
 ### Co potřebuje zaznít
 
-- 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.
-- `AGENTS.md`, skills, runbooky a checks jsou týmová infrastruktura, ne polish navíc.
-- Team lead nestojí modelu za zády a nediktuje další větu každých třicet sekund.
-- Po talku se tým vrací k repu s mapou, planem a prvním checkem, ne s lovem na chytřejší prompt.
+- 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.
+- `AGENTS.md`, skills, runbooky a ověřovací kroky jsou týmová infrastruktura, ne polish navíc.
+- Team lead nestojí modelu za zády a nediktuje další větu každých třicet sekund.
+- Po talku se tým vrací k repu s mapou, plánem kroků a prvním ověřením, ne s lovem na chytřejší prompt.
 
 ### Mikro-cvičení
 
@@ -100,7 +100,7 @@ Použijte stejný malý task ve dvou podmínkách:
 1. prompt blob
 2. krátké zadání s `Goal`, `Context`, `Constraints`, `Done When`
 
-Nenechte to sklouznout do debaty o tom, který model je chytřejší.
+Nenechte to sklouznout do debaty o tom, který model je chytřejší.
 
 Pointa:
 
@@ -113,95 +113,142 @@ Pointa:
 Na konci talku má být jasné:
 
 - teorie tím končí
-- tým se vrací k repu
+- tým se vrací k repu
 - pokud tým ještě nemá workshop skill, teď je chvíle na `harness skill install`, pak `Codex: $workshop setup` nebo `pi: /skill:workshop`
-- nejdřív vzniká mapa a první explicitní check
+- nejdřív vzniká mapa a první explicitní ověření
 - teprve potom dává smysl další feature motion
 
 ## Build fáze 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í ověřený výstup
+Do oběda má být v repu vidět pět základních věcí:
+
+1. `README`, které dává smysl cizímu člověku
+2. `AGENTS.md` jako krátká mapa
+3. plán, ze kterého je poznat další bezpečný krok
+4. build/test command nebo tracer bullet
+5. první opravdu ověřený posun
 
 ### 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
+- 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
 - vracejte týmům hlavně artefakty, ze kterých se dá opravdu pracovat, ne celý backstage Harness Lab
+- když se tým zasekne, vraťte ho k ověření, ne k delšímu promptu
 
 ### 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?
+- 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?
+- 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
+### Facilitační pointa k testům
 
-- S coding agentem nestačí říct „tohle si pak projdeme“.
+- 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.
+- 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
+- plán 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
 
+## Codex demo
+
+### Cíl
+
+Ukázat Codex jako součást pracovního systému, ne jako samostatné kouzlo. Demo má vysvětlit i to, proč tenhle repo drží pohromadě: protože v repu žije záměr, mantinely, rozpad práce do kroků i způsob kontroly, ne jen v hlavě facilitátora.
+
+### Co má být vidět
+
+- jedna příběhová linka, ne přehlídka funkcí
+- repozitář, ve kterém je vidět `README`, `AGENTS.md`, rozpad práce do kroků a způsob, jak změnu zkontrolujete
+- kontrast mezi slabým startem bez kontextu a prací, která má mapu a další bezpečný krok
+- krátké ukotvení workshop skillu: `harness skill install`, první command a proč to šetří ústní rescue
+
+### Co explicitně říct
+
+- „Tohle není demo pro demo. Tohle je způsob, jak vznikal i tenhle workshopový repo systém.“
+- „Když z repa není poznat, proč se změna dělá, jaký je další krok a podle čeho ji zkontrolujete, další člověk ani další agent nenaváže bezpečně.“
+- „Codex je v tomhle důležitý, ale není to pointa sám o sobě. Pointa je harness kolem něj.“
+
+### Co neukazovat
+
+- pět různých módů Codexu za sebou
+- dlouhé čekání na generování bez komentáře
+- repo, které není continuation-ready a slouží jen jako jednorázový sandbox
+
 ## 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.
+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 jste přesunuli z chatu nebo z hlavy do repa?
+- Co dnes ověřujete pomocí spustitelného ověření?
 - 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ů
+- udělat z průběhu dne sérii krátkých checkpointů
 - připomenout, že workflow je stejně důležité jako samotný výsledek
-- vracet týmy k tomu, že bez ověření jen akcelerují nejistotu
+- vracet týmy k tomu, že bez ověření jen akcelerují nejistotu
+
+Nevést intermezzo jako status meeting.
+Vést ho jako krátký checkpoint, ze kterého si týmy odnesou jednu věc, kterou ještě ten den dopíšou, zpřesní nebo ověří.
+
+## Oběd a příprava na handoff
+
+- Oběd není pauza od handoffu.
+- Než týmy vstanou od stolu, musí být z repa poznat:
+  - co se změnilo
+  - co je hotové
+  - co je stále hypotéza
+  - jaký je další bezpečný krok
+- Když něco z toho zůstane jen v hovoru, odpoledne se to vrátí jako tření.
 
 ## 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.
+- 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.
+- 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ší bezpečný krok.
-- Když tým neví, po čem sáhnout, vraťte ho k learner kitu: `template-agents`, `reference`, `analyze-checklist` a challenge cards.
+- Nejdřív napište vlastní diagnózu: co pomáhá, co chybí, co je rizikové a jaký je další bezpečný krok.
+- Když tým neví, po čem sáhnout, vraťte ho k learner kitu: `template-agents`, `reference`, `analyze-checklist` a challenge cards.
 
-### Facilitační pointa k rotaci
+### 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ý signál v repu.
+- Nepomáhejte týmům ústním handoffem nahrazovat slabý signál v repu.
 - Pomáhejte jim pojmenovat, co musí být po rotaci dopsáno, zpřesněno nebo ověřeno.
 
-## Reveal a reflexe
+## Build fáze 2
+
+- Po rotaci neopravujeme jen feature. Opravujeme i signál, který převzetí zbrzdil.
+- Každá opakující se bolest je kandidát na lepší mapu, pravidlo, runbook nebo ověření.
+- Další větší změna má přijít až po nové explicitní verifikaci.
+
+## Reveal a reflexe
 
 ### `1-2-4-All`
 
@@ -209,17 +256,37 @@ Otázky:
 
 - Co vám pomohlo pokračovat?
 - Co chybělo?
-- Jaký signál v repu vám nejvíc ušetřil čas?
+- 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 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í.
+- 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 vodítko v blueprintu.
+- Každá opakující se bolest je kandidát na lepší template, challenge card nebo vodítko v blueprintu.
+
+Na konci dne chceme, aby si lidé odnesli tři věci:
+
+1. jeden signál, který chtějí zavést natrvalo
+2. jednu slabinu, kterou už příště nenechají jen v hovoru
+3. jeden konkrétní tah pro příští týden
+
+### `Monday commitments` — sdílený artefakt
+
+Reflexe bez zápisu se do pondělí většinou neudrží. Proto na samém konci dne:
+
+- každý účastník napíše jednu větu ve tvaru: **„Příští týden udělám [X], protože [důvod z dnešního dne]."**
+- věty se napíší na papírek, sticky note nebo přímo do sdíleného dokumentu
+- facilitátor je sesbírá a udělá z nich jeden krátký sdílený seznam, který si tým odnese
+- seznam není hodnocení ani soutěž. Je to jediný artefakt z dnešního dne, který prokáže, že reflexe skutečně něco změnila
+
+Facilitátorův tah:
+- věty vybízejte k tomu, aby byly konkrétní (ne „budu lépe pracovat s agenty“, ale „do AGENTS.md svého hlavního repa napíšu 4 elementy: goal, context, constraints, done when“)
+- když někdo napíše něco velmi obecného, zeptejte se: „Jaký je první konkrétní tah, který to spustí?"
+- commitmenty nepublikujte jmenovitě mimo room; artefakt patří týmu, ne marketingu

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

@@ -2,30 +2,30 @@
 
 ## 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 právě tam, kde by měl být nejpřesnější.
+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 právě tam, kde by měl být nejpřesnější.
 
-Vaším úkolem je navrhnout nástroj, který z diffu nebo změny vytvoří použitelný review checklist a zároveň jasně oddělí jistotu, heuristiku a místa, kde je pořád potřeba lidský úsudek.
+Vaším úkolem je navrhnout nástroj, který z diffu nebo změny vytvoří použitelný review checklist a zároveň jasně oddělí jistotu, heuristiku a místa, kde je pořád potřeba lidský úsudek.
 
 ## User stories
 
-- Jako reviewer chci z diffu rychle získat checklist změněných hranic, rizik, otázek a míst, na která se zaměřit.
+- Jako reviewer chci z diffu rychle získat checklist změněných hranic, rizik, otázek a míst, na která se zaměřit.
 - Jako autor změny chci vědět, co mám ověřit 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 → rubric → checklist`.
-- Musí být zřejmé, jaké vstupy nástroj očekává, co umí označit jistě a co naopak zůstává heuristické.
-- Přidejte seed diff nebo `examples/`, aby šlo workflow lokálně ověřit a další tým rychle přidal nové pravidlo.
+- Může jít o CLI, web nebo jednoduchý skript. Důležitý je jasný tok `diff → rubric → checklist`.
+- Musí být zřejmé, jaké vstupy nástroj očekává, co umí označit jistě a co naopak zůstává heuristické.
+- Přidejte seed diff nebo `examples/`, aby šlo workflow lokálně ověřit a další tým rychle přidal nové pravidlo.
 - 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í, hypotéz a bodů pro lidský úsudek.
+- Výstup odlišuje jistá zjištění od doporučení, hypotéz a bodů pro lidský úsudek.
 - 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.
+- 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š review rubric, tok vstupů a definici toho, co znamená dobrý checklist. Ukaž, kde je jistota, kde heuristika a co musí posoudit člověk. Teprve potom navrhni první implementační slice.
+Nezačínej kódem. Nejdřív napiš review rubric, tok vstupů a definici toho, co znamená dobrý checklist. Ukaž, kde je jistota, kde heuristika a co musí posoudit člověk. Teprve potom navrhni první implementační slice.

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

@@ -2,30 +2,32 @@
 
 ## 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.
+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.
+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 a nerozsypal se po přidání dalšího commandu.
 
 ## 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ý.
+- 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ě.
+- 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ě.
+- Nejde o pytel skriptů. Jde o malý systém, ve kterém je jasné, kde přibude další command, test a dokumentace.
 
 ## 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í.
+- `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.
+- Každý command má aspoň jednu čitelnou ukázku vstupu a výstupu.
 
 ## 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.
+Nejdřív navrhni minimální architekturu, která přežije handoff. Začni `AGENTS.md`, flow pro přidání dalšího commandu a prvním ověřením. Teprve pak implementuj první command.

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

@@ -2,30 +2,32 @@
 
 ## 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.
+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. Po handoffu pak nový tým neví, čemu má věřit a co je jen odhad.
 
-Vaším úkolem je navrhnout nástroj, který z projektu vygeneruje základní technickou dokumentaci nebo strukturovaný přehled.
+Vaším úkolem je navrhnout nástroj, který z projektu vygeneruje základní technickou dokumentaci nebo strukturovaný přehled tak, aby bylo zřejmé, co nástroj opravdu ví a co si jen domýšlí.
 
 ## 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 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.
+- 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.
+- Neřešte AI show. Řešte důvěryhodnost, dohledatelnost a další safe move pro tým po handoffu.
 
 ## 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.
+- 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.
+- Další tým umí přidat nový typ výstupu bez chaosu v repu.
+- Reviewer během pár minut pozná, odkud které tvrzení pochází.
 
 ## 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.
+Nejdřív napiš, jaké signály budeš z projektu číst, které výstupy budou jistota a které jen heuristika. Teprve potom navrhni první implementační slice.

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

@@ -4,7 +4,7 @@
 
 Almost every team ends up with small one-off scripts for log cleanup, JSON conversion, suspicious commit lookup, or fast repo checks. They work for a while, often for one person only, and after a few days nobody remembers how to run or extend them.
 
-Your task is to design a CLI tool that handles several common developer tasks in a way that survives handoff to another team.
+Your task is to design a CLI tool that handles several common developer tasks in a way that survives handoff to another team and does not collapse the moment another command is added.
 
 ## User stories
 
@@ -18,6 +18,7 @@ Your task is to design a CLI tool that handles several common developer tasks in
 - Separate commands from helper utilities and configuration from the start.
 - `AGENTS.md` should describe the build and test flow, output conventions, and the rules for future extension.
 - A runbook for the team that inherits the project after lunch matters as much as a working command.
+- Do not build a bag of scripts. Build a small system where it is obvious where the next command, test, and doc belong.
 
 ## Done when
 
@@ -25,7 +26,8 @@ Your task is to design a CLI tool that handles several common developer tasks in
 - `README` and `AGENTS.md` describe local execution and verification.
 - It is clear where to add another command without breaking the project structure.
 - A new team can add or fix another command within 10 minutes.
+- Each command has at least one readable input/output example.
 
 ## First step for the agent
 
-First design the minimal architecture that survives handoff. Start with `AGENTS.md`, then prepare a plan, and only then implement the first command.
+First design the minimal architecture that survives handoff. Start with `AGENTS.md`, the extension flow for another command, and the first verification step. Only then implement the first command.

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

@@ -2,9 +2,9 @@
 
 ## Problem
 
-Documentation becomes stale almost immediately. Once maintenance is fully manual, the team starts postponing it, and after a few iterations nobody knows whether the docs still describe reality.
+Documentation becomes stale almost immediately. Once maintenance is fully manual, the team starts postponing it, and after a few iterations nobody knows whether the docs still describe reality. After handoff, the next team no longer knows what to trust and what is only inference.
 
-Your task is to design a tool that generates baseline technical documentation or a structured project overview from an existing codebase.
+Your task is to design a tool that generates baseline technical documentation or a structured project overview from an existing codebase in a way that makes certainty and inference visibly different.
 
 ## User stories
 
@@ -18,6 +18,7 @@ Your task is to design a tool that generates baseline technical documentation or
 - The output can be Markdown, HTML, or a simple text report.
 - The important part is to explain what the tool can infer reliably and what remains heuristic.
 - Design the structure from the start so another output type can be added later.
+- Do not optimize for AI theatre. Optimize for trust, traceability, and a clear next safe move for a team after handoff.
 
 ## Done when
 
@@ -25,7 +26,8 @@ Your task is to design a tool that generates baseline technical documentation or
 - It is clear how the tool runs locally and which input it expects.
 - The output separates facts from estimates or heuristics.
 - Another team can add a new output type without chaos in the repo.
+- A reviewer can tell where each claim came from within minutes.
 
 ## First step for the agent
 
-First describe which signals you will read from the project, what you can infer from them, and where certainty stops. Only then propose the first implementation.
+First define which project signals you will read and which outputs are certainty versus heuristic. Then propose the first implementation slice.

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

@@ -4,7 +4,7 @@
 
 Teams often have the data, but not the screen that turns it into a readable shared view. Without that, decisions get harder, discussion gets noisier, and everyone walks away with a different interpretation of the numbers.
 
-Your task is to design a simple dashboard that turns a handful of metrics into a clear shared view.
+Your task is to design a simple dashboard that turns a handful of metrics into a clear shared view and stays understandable after handoff to another team.
 
 ## User stories
 
@@ -18,6 +18,7 @@ Your task is to design a simple dashboard that turns a handful of metrics into a
 - Mobile-first is an advantage, but the dashboard must remain readable on a projected screen too.
 - README and monitoring should explain what already works, what is still mock, and what is still missing.
 - Design the structure so adding another metric does not require rewriting the whole screen.
+- Do not optimize only for the look. Make the data model, layout rules, and verification path easy for another team to understand.
 
 ## Done when
 
@@ -25,7 +26,8 @@ Your task is to design a simple dashboard that turns a handful of metrics into a
 - The repo documents the data sources and a mock fallback.
 - It is clear where a new metric is added and how layout changes are verified.
 - A new team can extend the dashboard without breaking the structure.
+- The layout stays legible on mobile and on a larger screen, and the verification path says how to check that.
 
 ## First step for the agent
 
-Design a dashboard that survives handoff. First describe the data model, components, and `Done When` criteria, and only then start building the UI.
+Design a dashboard that survives handoff. First describe the data model, components, layout rules, and `Done When` criteria. Only then start building the UI.

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

@@ -4,7 +4,7 @@
 
 Daily standups in chat often turn into a long thread with no structure. Blockers disappear in the noise, dependencies between people are hard to see, and after a few hours it is difficult to reconstruct what was actually agreed.
 
-Your task is to design a tool that turns standup inputs into an overview people can continue working with.
+Your task is to design a tool that turns standup inputs into an overview people can continue working with even without the original author or the original chat thread open.
 
 ## User stories
 
@@ -18,6 +18,7 @@ Your task is to design a tool that turns standup inputs into an overview people
 - Mock data is fine if the workflow feels realistic and is documented clearly.
 - Separate ingest, processing, and presentation of the output.
 - Prompts, runbooks, and decisions must live in the repo, not only in the heads of the original team.
+- Do not optimize for pretty summary prose before blockers, dependencies, and the next safe move are visible.
 
 ## Done when
 
@@ -25,7 +26,8 @@ Your task is to design a tool that turns standup inputs into an overview people
 - The output highlights blockers or items that need attention.
 - The repo explains how to connect the solution to a real chat or another input channel.
 - After rotation, another team can continue without further explanation.
+- It is clear what is certain summary versus heuristic suggestion.
 
 ## First step for the agent
 
-Split the work into ingest, summarization, and context for the next team. First write the documentation the new team should open first, and only then propose implementation steps.
+Split the work into ingest, summarization, and context for the next team. First write the data model, certainty-versus-heuristic rules, and the documentation the new team should open first. Then propose implementation steps.

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

@@ -2,30 +2,32 @@
 
 ## 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.
+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.
+Vaším úkolem je navrhnout jednoduchý dashboard, který z několika metrik vytvoří srozumitelný společný pohled a zůstane čitelný i po handoffu na jiný tým.
 
 ## User stories
 
-- Jako tým chci zobrazit několik metrik na jedné obrazovce tak, aby z nich šlo rychle vyčíst stav.
+- 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.
+- 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.
+- 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.
+- Neoptimalizujte jen vzhled. Hlídejte, aby nový tým rychle pochopil datový model, layout pravidla a způsob ověření.
 
 ## 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.
+- 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.
+- Layout je čitelný na mobilu i na větší obrazovce a je jasné, jak to ověřit.
 
 ## 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.
+Navrhni dashboard, který zvládne handoff. Nejdřív popiš datový model, komponenty, layout pravidla a kritéria `Hotovo když`, teprve potom stav UI.