@harness-lab/cli 0.2.8 → 0.3.0

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.

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

@@ -2,30 +2,32 @@
 
 ## 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.
+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.
+Vaším úkolem je navrhnout nástroj, který ze standup vstupů vytvoří přehled, se kterým se dá dál pracovat i bez původního autora nebo bez otevřeného původního vlákna.
 
 ## 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.
+- 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.
+- 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.
+- Neřešte „hezký summary text“ dřív než to, jestli jsou vidět blokery, dependency a další safe move.
 
 ## Hotovo když
 
-- Nástroj umí ingestovat seed data a vytvořit čitelný souhrn.
+- 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í.
+- Je jasné, co je jisté shrnutí a co je jen heuristika nebo návrh.
 
 ## 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.
+Rozděl práci na ingest, sumarizaci a kontext pro další tým. Nejdřív napiš datový model, jistoty vs. heuristiky a dokumentaci, kterou nový tým otevře jako první. Až potom navrhni implementační kroky.

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

@@ -2,15 +2,15 @@
 
 ## Cíl
 
-Jedna příběhová ukázka, ne seznam funkcí. Publikum má během 15 minut pochopit, jak vypadá dobrý workflow s agentem.
+Jedna příběhová ukázka, ne seznam funkcí. Publikum má během 15 minut pochopit, jak vypadá dobrý workflow s agentem a proč tenhle repozitář drží pohromadě díky harnessu, ne díky improvizaci.
 
 ## 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.“
+„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, review i převzetí jiným člověkem.“
 
 ## Flow
 
-1. Otevři jednoduchý repozitář nebo sandbox projekt.
+1. Otevři jednoduchý repozitář nebo přímo Harness Lab slice, na kterém je vidět `README`, `AGENTS.md`, rozpad práce do kroků a způsob kontroly změny.
 2. Ukaž, že bez kontextu agent rychle tápe.
 3. Vytvoř `AGENTS.md` se 4 prvky:
    - Goal
@@ -18,12 +18,13 @@ Jedna příběhová ukázka, ne seznam funkcí. Publikum má během 15 minut poc
    - 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:
+5. Krátce ukaž, jak se v repu propisuje záměr: kde je mapa, kde je další bezpečný krok a kde je vidět, že tenhle repozitář vznikal jako continuation-ready systém.
+6. Nech agenta implementovat malý kus.
+7. Spusť `/review` a ukaž, že kontrola je součást workflow, ne nouzová brzda na konci.
+8. Krátce ukaž workshop skill:
+   - jak se instaluje přes `harness skill install`
+   - jak z něj plyne první použitelný krok v Codexu nebo v pi
+9. Zavři to větou:
    - „Nástroj sám nestačí. Rozhoduje pracovní systém kolem něj.“
 
 ## Fallbacky
@@ -37,7 +38,8 @@ Jedna příběhová ukázka, ne seznam funkcí. Publikum má během 15 minut poc
 - pět různých režimů práce
 - složitou přehlídku funkcí
 - dlouhé čekání na generování
+- demo odtržené od repa, ve kterém právě workshop běží
 
 ## Pointa pro místnost
 
-Nejde o to ukázat „kouzelný výsledek“. Jde o to ukázat, jak rychle roste kvalita, když přidáme kontext, plán a review.
+Nejde o to ukázat „kouzelný výsledek“. Jde o to ukázat, jak rychle roste kvalita, když přidáme kontext, plán, review a repozitář postavený tak, aby se v něm dalo pokračovat.

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

@@ -2,25 +2,25 @@
 
 ## Otevírací modul
 
-Tenhle 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.
+Tenhle 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.
 
-Rámec pro room launch:
+Rámec pro otevření dne:
 
-- dnes nezačínáme tool demo ani soutěž v promptování
-- budeme se učit, stavět, předávat i přebírat
-- odpoledne se ukáže, co z práce přežije bez nás
+- dnes nezačínáme tool demo ani soutěž v promptování
+- budeme se učit, stavět, předávat i přebírat
+- odpoledne se ukáže, co z práce přežije bez nás
 
 ## 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. Staví systém, ve kterém tým funguje. A přesně tohle dnes budeme dělat pro agenty.
+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. Staví systém, ve kterém tým funguje. A přesně tohle dnes budeme dělat pro agenty.
 
 Moje hlavní 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.
+> 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.
 
 ## Analogický beat
 
-Když dáte lidem stejné kostky, nevznikne jedna správná kachna. Stejně tak ze stejného modelu nevzniká jedna správná práce. Rozdíl nedělá jen model. Rozdíl dělá kontext, mantinely, ověřování a představivost týmu.
+Když dáte lidem stejné kostky, nevznikne jedna správná kachna. Stejně tak ze stejného modelu nevzniká jedna správná práce. Rozdíl nedělá jen model. Rozdíl dělá kontext, mantinely, ověřování a představivost týmu.
 
 Pointa analogie:
 
@@ -30,7 +30,9 @@ Pointa analogie:
 
 ## Mikro-cvičení
 
-Všichni dostanou stejný malý task. Jedna varianta bude prompt blob. Druhá varianta bude krátké zadání se 4 prvky a s odkazem na kontext zapsaný v repu. Pak porovnáme výsledky. Nehledáme „nejhezčí prompt“. Hledáme způsob práce, který přenese záměr, omezení a done criteria i do dalšího kroku.
+Tohle je krátká facilitátorova ukázka, ne práce pro celou místnost.
+
+Vezmeme stejný malý task ve dvou podmínkách. Jedna varianta bude prompt blob. Druhá varianta bude krátké zadání se 4 prvky a s odkazem na kontext zapsaný v repu. Pak porovnáme výsledky. Nehledáme „nejhezčí prompt“. Hledáme způsob práce, který přenese záměr, omezení a done criteria i do dalšího kroku.
 
 4 prvky pro druhou variantu:
 
@@ -42,33 +44,34 @@ Všichni dostanou stejný malý task. Jedna varianta bude prompt blob. Druhá va
 ## Hlavní teze
 
 - Kontext je páka, ne kosmetika.
-- `AGENTS.md`, skills a runbooky jsou týmová infrastruktura.
+- `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 návaznosti rozpadají.
+- Co není v repu, neexistuje. Slack, ústní dovysvětlení a "to si pamatujeme" se při návaznosti 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í výchozí doporučení. 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í návaznost prověří, jestli váš kontext funguje i bez vás.
+- 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í výchozí doporučení. Bezpečnější je izolované lokální prostředí a jasné mantinely.
+- Ověření napsané dřív, než pustíte agenta do většího kusu práce, není test-first dogma. Je to zápis done criteria do formy, kterou agent i další tým umí zkontrolovat. Iteraci to zrychluje, protože agent dostane přesné mantinely, ne další prompt.
+- Úklid není bonus po workshopu. Když narazíte na opakující se chaos, je čas ho proměnit v lepší template, ověření nebo runbook.
+- Odpolední návaznost prověří, jestli váš kontext funguje i bez vás.
 
 ## Co chci, aby si adoptovali
 
-- Než začnu generovat další funkci, udělám z repa místo, kde se dá orientovat.
+- Než začnu generovat další funkci, 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á podmínka celé práce.
 
 ## Most do Build fáze 1
 
-Po tomhle talku se tým nemá vracet k repu s pocitem, že potřebuje jen chytřejší prompt. Má se vracet s jedním jasným očekáváním:
+Po tomhle talku se tým nemá vracet k repu s pocitem, že potřebuje jen chytřejší prompt. Má se vracet s jedním jasným očekáváním:
 
-- nejdřív krátká mapa v repu
-- potom plan
-- potom první explicitní check
+- pokud ještě nemá workshop skill, teď je chvíle na `harness skill install`, pak `Codex: $workshop setup` nebo `pi: /skill:workshop`
+- nejdřív krátká mapa v repu
+- potom krátký plán kroků
+- potom první explicitní ověření
 - teprve potom další feature motion
 
 ## 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.
+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.

package/assets/workshop-bundle/docs/harness-cli-foundation.md

@@ -8,7 +8,7 @@ Current implementation in this repo:
 
 - lives in the repository `harness-cli/` package and ships publicly as `@harness-lab/cli`
 - distributes a portable participant workshop skill bundle through `harness skill install`
-- covers `auth login/logout/status` plus `workshop status/list-instances/show-instance/create-instance/update-instance/reset-instance/prepare/remove-instance/archive/phase set`
+- covers `auth login/logout/status` plus `workshop current-instance/select-instance/status/list-instances/show-instance/create-instance/update-instance/reset-instance/prepare/remove-instance/archive/phase set`
 - targets the existing shared dashboard facilitator APIs
 - is tested for browser/device auth, local-dev Basic Auth fallback, and cookie-backed Neon bootstrap fallback
 - stores sessions in a local file under `HARNESS_CLI_HOME` or `~/.harness` by default
@@ -38,9 +38,12 @@ Required commands:
 - `harness auth login`
 - `harness auth logout`
 - `harness auth status`
+- `harness workshop current-instance`
+- `harness workshop select-instance <instance-id>`
 - `harness workshop status`
 - `harness workshop list-instances`
 - `harness workshop show-instance <instance-id>`
+- `harness workshop participant-access [<instance-id>]`
 - `harness workshop create-instance`
 - `harness workshop update-instance`
 - `harness workshop reset-instance <instance-id>`
@@ -85,33 +88,42 @@ Current auth layering:
 Current target-selection order:
 
 1. an explicit command or route instance id
-2. the selected control-room instance in the dashboard
+2. the CLI-local persisted selection set by `harness workshop select-instance`
 3. the deployment default `HARNESS_WORKSHOP_INSTANCE_ID`
 4. a repository fallback only on surfaces that intentionally present a workspace-level default
 
 Current command posture:
 
 - explicit workspace-discovery commands:
+  - `harness workshop current-instance`
+  - `harness workshop select-instance <instance-id>`
   - `harness workshop list-instances`
-- explicit target required:
-  - `harness workshop show-instance <instance-id>`
-- explicit target required:
-  - `harness workshop update-instance <instance-id>`
-  - `harness workshop reset-instance <instance-id>`
-  - `harness workshop prepare <instance-id>`
-  - `harness workshop remove-instance <instance-id>`
+- explicit target preferred but selected-instance fallback allowed:
+  - `harness workshop show-instance [<instance-id>]`
+  - `harness workshop participant-access [<instance-id>]`
+  - `harness workshop update-instance [<instance-id>]`
+  - `harness workshop reset-instance [<instance-id>]`
+  - `harness workshop prepare [<instance-id>]`
+  - `harness workshop remove-instance [<instance-id>]`
 - explicit target is the created resource:
   - `harness workshop create-instance [<instance-id>]`
-- deployment-default target:
+- selected-instance target first, otherwise deployment-default target:
   - `harness workshop status`
-  - `harness workshop archive`
   - `harness workshop phase set <phase-id>`
+- deployment-default target:
+  - `harness workshop archive`
 
 Current discoverability path:
 
 - facilitators can inspect available workshop instances through the dashboard workspace view
 - the same platform-scoped list lives behind the authenticated instances API surface at `/api/workshop/instances`
 - the CLI should expose that list directly so facilitator skills do not need session-file inspection or raw authenticated scripts for routine discovery
+- the CLI should also expose a local current-target selector so repeated facilitator work does not depend on ambient dashboard selection or deployment-default routing
+
+Machine-readable posture:
+
+- facilitator commands should support `--json` for strict machine parsing without headings or prose wrappers
+- skills and agents should prefer `harness --json ...` over scraping human-oriented terminal formatting
 
 For the current facilitator lifecycle slice: