@harness-lab/cli 0.2.1 → 0.2.3

package/assets/workshop-bundle/content/challenge-cards/print-spec.md

@@ -0,0 +1,28 @@
+# Challenge Cards Print Spec
+
+## Formát
+
+- velikost: A6 nebo čtvrtina A4
+- oboustranný tisk není potřeba
+- velký nadpis, 1 krátký popis, 1 ikonický štítek kategorie
+
+## Barevné rozlišení
+
+- Context Engineering: písková / žlutá
+- Workflow: modrozelená
+- Advanced: cihlová
+- Meta: šedá
+
+## Layout
+
+1. nahoře název karty
+2. pod ním kategorie
+3. 2-3 věty zadání
+4. dole malý štítek:
+   - `Před obědem`
+   - `Po rotaci`
+   - `Kdykoliv`
+
+## Tisková poznámka
+
+Pokud se tisk nestihne, primární kanál je dashboard a `/workshop challenges`. Tisk je bonus, ne závislost workshopu.

package/assets/workshop-bundle/content/czech-editorial-review-checklist.md

@@ -0,0 +1,88 @@
+# Czech Editorial Review Checklist
+
+Použijte tento checklist při revizi českého obsahu pro účastníky, hlavně pro:
+
+- workshop agenda a presenter scenes
+- pokyny pro participant room
+- project briefs
+- challenge cards
+- setup, reference, recap, follow-up a learner-kit materiály
+
+Tento checklist doplňuje [`content/style-guide.md`](./style-guide.md) a [`content/style-examples.md`](./style-examples.md). Není to náhrada. Je to poslední quality gate před tím, než se text bere jako workshop-ready.
+
+## 1. Přirozenost češtiny
+
+- Zní text jako přirozená čeština, ne jako překlad?
+- Přečetl by to český developer bez škobrtnutí?
+- Nejsou ve větách doslovné anglické kalky?
+- Nejsou věty zbytečně dlouhé nebo toporné?
+
+## 2. Kvalita míchání češtiny a angličtiny
+
+- Zůstává česká věta česká?
+- Jsou anglické termíny použité jen tam, kde jsou v developerské praxi opravdu přirozené?
+- Není v textu náhodně promíchaná angličtina jen proto, že původní zdroj byl anglický?
+- Když se méně známý anglický termín objevuje poprvé, je stručně ukotvený česky?
+
+## 3. Jasnost instrukce
+
+- Je z textu jasné, co má člověk udělat právě teď?
+- Mají věty konkrétní slovesa jako `spusťte`, `zkontrolujte`, `doplňte`, `ověřte`?
+- Neschovává se akce za abstraktní formulace typu „je vhodné realizovat“?
+- Nejsou odstavce přeplněné více cíli najednou?
+
+## 4. Workshop voice
+
+- Zní text jako zkušený peer, ne jako marketér nebo korporát?
+- Drží se text klidného, věcného a praktického tónu?
+- Nezní text jako slide, slogan nebo generický AI obsah?
+- Je z textu cítit disciplína workshopu: kontext zapsaný v repu, ověření, handoff?
+
+## 5. Terminologická disciplína
+
+- Jsou opakované workshop terms použité konzistentně?
+- Neobjevují se slabé nebo matoucí fráze jen proto, že znějí „AI-ish“?
+- Jsou výrazy jako `safe move`, `handoff`, `checkpoint`, `workflow`, `review`, `skill`, `runbook` použité záměrně, ne náhodně?
+- Není stejná věc jednou česky a podruhé napůl anglicky bez důvodu?
+
+## 6. Vyhněte se těmto signálům
+
+Pokud se v textu objeví něco z toho, vraťte ho do editace:
+
+- doslovný překlad anglické vazby
+- česká věta s náhodně vloženými anglickými slovy mimo technické termíny
+- korporátní nebo školometský tón
+- fráze, které nic nekotví k akci
+- generické AI obraty bez konkrétního významu
+
+## 7. Spoken check
+
+Přečtěte text nahlas nebo aspoň polohlasem.
+
+Text vrátit do editace, pokud:
+
+- se nedá říct plynule
+- obsahuje nepřirozený slovosled
+- zní tvrdě přeloženě
+- potřebuje v hlavě „opravovat“, co tím autor asi myslel
+
+## 8. Cross-locale check
+
+Pokud text vznikal z anglického source:
+
+- není to doslovný překlad?
+- drží česká verze stejný význam, ale přirozenější formulací?
+- není česká verze výrazně slabší, plošší nebo méně konkrétní než anglická?
+- není anglický source sám o sobě slabý a nehodí se nejdřív přepsat?
+
+## 9. Before publish
+
+Před schválením českého textu pro účastníky musí být možné říct `ano` na všechno:
+
+1. Je to přirozená čeština?
+2. Rozumí tomu český developer napoprvé?
+3. Je jasné, co má člověk udělat nebo pochopit?
+4. Drží text workshop voice bez hype a bez korporátu?
+5. Je míchání češtiny a angličtiny disciplinované?
+6. Neobsahuje text slabé fráze nebo „AI slop“?
+7. Obstojí text při čtení nahlas?

package/assets/workshop-bundle/content/facilitation/codex-setup-verification.md

@@ -0,0 +1,54 @@
+# Codex Setup Verification
+
+## Cíl
+
+Do 10:30 musí mít každý účastník jednu funkční cestu:
+
+- `pi`
+- `Codex CLI`
+- `Codex App`
+- nebo web fallback
+
+Cíl není perfektní instalace. Cíl je dostat každého co nejdřív do práce s agentem.
+
+## Rychlý start
+
+### macOS / Linux
+
+1. Otevřete terminál.
+2. Přihlaste se do Codex prostředí podle firemního flow.
+3. Otevřete repozitář.
+4. Pošlete první prompt.
+
+### pi
+
+1. Nainstalujte `pi`:
+   `npm install -g @mariozechner/pi-coding-agent`
+2. Přihlaste provider nebo účet, který chcete používat.
+3. Otevřete repozitář.
+4. Spusťte `pi`.
+5. Načtěte workshop skill přes `/skill:workshop` a řekněte si o další krok.
+
+### Windows / macOS
+
+1. Otevřete `Codex App`.
+2. Přihlaste se.
+3. Otevřete workshop repo nebo týmový projekt.
+4. Pošlete první prompt.
+
+### Web fallback
+
+Použijte ho ve chvíli, kdy vás blokuje instalace, firemní politika nebo autentizace. Nečekejte na ideální setup, když už můžete pracovat.
+
+## Troubleshooting checklist
+
+- Nejde login → přejděte na `App` nebo web fallback a pokračujte.
+- Nejde CLI instalace → nenechte se blokovat déle než 7 minut.
+- Nejde otevřít repo → spárujte se s někým od stolu a vraťte se k tomu později.
+- Nevíte, co je další krok → v Codexu použijte `$workshop setup`. V pi načtěte `/skill:workshop` a řekněte si o setup pomoc.
+
+## Facilitátorské rozhodnutí
+
+- 7 minut blokace → fallback nebo pairing.
+- 10 minut chaosu → facilitátor dává jeden konkrétní další krok.
+- Jakmile má člověk jednu funkční cestu, setup je pro tuto chvíli dost dobrý.

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 opravdu unese převzetí dalším týmem.
+- 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 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
+
+### 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
+- vracejte týmům hlavně artefakty, ze kterých se dá opravdu pracovat, 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ý výsledek
+- 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ší 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
+
+- 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.
+- 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 vodítko 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/locales/en/code-review-helper.md

@@ -0,0 +1,31 @@
+# Code Review Helper
+
+## Problem
+
+Code review is often uneven. Some changes arrive with a strong checklist and clear risk framing, while others come through without a shared standard. The reviewer improvises, the author does not know what to verify in advance, and the team loses consistency.
+
+Your task is to design a tool that turns a diff or change set into a usable review checklist.
+
+## User stories
+
+- As a reviewer, I want a fast checklist of risks, questions, and focus areas from a diff.
+- As the author of a change, I want to know what I should verify before the review starts.
+- As the team after rotation, I want to continue from the heuristics the original team already discovered instead of reinventing them.
+
+## Architecture notes
+
+- This can be a CLI, web app, or simple script. The important part is a clear `diff -> analysis -> checklist` flow.
+- It must be obvious which inputs the tool expects and what it cannot evaluate reliably.
+- Add a seed diff or `examples/` so the workflow can be checked locally.
+- Separate heuristic from certainty clearly. The tool should help the reviewer, not pretend to be infallible.
+
+## Done when
+
+- The tool produces a review checklist from a seed diff.
+- The output distinguishes certain findings from recommendations or hypotheses.
+- It is clear how to add another rule or heuristic without a long onboarding pass.
+- Another team can continue development within minutes without chaos.
+
+## First step for the agent
+
+Do not start with code. First write the review rules, the input flow, and a definition of what a good checklist means. Only then propose the first implementation slice.

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

@@ -0,0 +1,31 @@
+# DevToolbox CLI
+
+## Problem
+
+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.
+
+## User stories
+
+- As a developer, I want to turn a log or JSON blob into a readable format with one command.
+- As a developer, I want to quickly find suspicious commits, branches, or changes without manually assembling git commands.
+- As a team, I want both the commands and the way of working documented so another team can continue after rotation without confusion.
+
+## Architecture notes
+
+- Choose any language or framework, but the CLI must stay easy to run and easy to discover.
+- 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.
+
+## Done when
+
+- There are at least 3 useful commands or subcommands.
+- `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.
+
+## 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.

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

@@ -0,0 +1,31 @@
+# Doc Generator
+
+## 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.
+
+Your task is to design a tool that generates baseline technical documentation or a structured project overview from an existing codebase.
+
+## User stories
+
+- As a developer, I want basic technical documentation from a project without writing everything from scratch.
+- As a reviewer, I want to understand the module structure and main entry points within minutes.
+- As the team after rotation, I want to discover the architecture without long detective work.
+
+## Architecture notes
+
+- The input can be a local repo, seed directory, or simplified dataset.
+- 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.
+
+## Done when
+
+- The tool produces at least one readable documentation page or report.
+- 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.
+
+## 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.

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

@@ -0,0 +1,31 @@
+# Metrics Dashboard
+
+## Problem
+
+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.
+
+## User stories
+
+- As a team, I want several metrics on one screen so the current state is legible quickly.
+- As a facilitator, I want to change seed data without touching UI logic.
+- As the team after rotation, I want to understand the data structure, components, and screens within minutes.
+
+## Architecture notes
+
+- Separate seed data from UI from the first commit.
+- 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.
+
+## Done when
+
+- The dashboard shows at least 3 metrics and one trend or comparison.
+- 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.
+
+## 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.

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

@@ -0,0 +1,31 @@
+# Standup Bot
+
+## Problem
+
+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.
+
+## User stories
+
+- As a team lead, I want standup responses collected into one readable summary.
+- As a developer, I want to quickly see blockers, dependencies, and topics that need coordination.
+- As the team after rotation, I want to understand the data flow and integration points without verbal handoff.
+
+## Architecture notes
+
+- Prefer a clear data model over complicated integration.
+- 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.
+
+## Done when
+
+- The tool can ingest seed data and produce a readable summary.
+- 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.
+
+## 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.

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.