@harness-lab/cli 0.2.2 → 0.2.4

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/style-examples.md

@@ -88,7 +88,7 @@ Don't:
 
 ## Approved English Terms
 
-Tyto výrazy se v participant-facing textech běžně nechávají v angličtině:
+Tyto výrazy se v textech pro účastníky běžně nechávají v angličtině:
 
 - `prompt`
 - `review`

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

@@ -85,7 +85,7 @@ Dobře:
 
 - Commands, file names, slash commands a literal terms piš v backticks.
 - Nadpisy a běžný výklad piš normální češtinou.
-- V participant-facing textu nezahlcuj čtenáře dlouhými bloky textu.
+- V textech pro účastníky nezahlcuj čtenáře dlouhými bloky textu.
 
 ## Audience Calibration
 
@@ -97,10 +97,12 @@ Workshop je pro developery. Nepiš, jako by publikum bylo netechnické.
 
 ## Final Check Before Publishing
 
-Před uložením participant-facing textu si ověř:
+Před uložením textu pro účastníky si ověř:
 
 1. Zní to jako přirozená čeština?
 2. Pochopí to český developer napoprvé?
 3. Nepřekládám něco, co má zůstat v angličtině?
 4. Nezní to jako marketing nebo korporát?
 5. Je z textu jasné, co má člověk udělat?
+
+Pro finální workshop-ready revizi použijte i [`content/czech-editorial-review-checklist.md`](./czech-editorial-review-checklist.md).

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

@@ -2,7 +2,7 @@
 
 ## Cíl
 
-Jedna příběhová ukázka, ne seznam feature. 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.
 
 ## Příběh
 
@@ -35,9 +35,9 @@ Jedna příběhová ukázka, ne seznam feature. Publikum má během 15 minut poc
 ## Co explicitně neukazovat
 
 - pět různých režimů práce
-- složitou feature tour
+- složitou přehlídku funkcí
 - dlouhé čekání na generování
 
 ## Pointa pro místnost
 
-Nejde o to ukázat „kouzelný output“. Jde o to ukázat, jak rychle roste kvalita, když přidáme kontext, plán a review.
+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.

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

@@ -6,36 +6,36 @@ Tento workshop skill i dashboard vznikly stejným způsobem, jakým dnes budeme
 
 ## Klíčová linka
 
-Harness engineering je práce s instrukcemi, kontextem a workflow tak, aby agent dělal správné věci opakovaně a předvídatelně. Team lead přece neříká každých třicet sekund jednomu vývojáři, co má dělat. Vytváří systém, ve kterém tým funguje. A přesně tohle dnes budeme dělat pro agenty.
+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í reframing věta pro dnešek:
+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.
 
 ## Mikro-cvičení
 
-Všichni dostanou stejný malý úkol. Jedna varianta bude prompt blob. Druhá varianta bude krátké zadání se 4 prvky a s odkazem na repo-native kontext. Pak porovnáme výsledky. Nehledáme „nejhezčí prompt“. Hledáme způsob práce, který přenese záměr, omezení a kritéria hotovo i do dalšího kroku.
+Všichni dostanou stejný malý úkol. Jedna varianta bude prompt blob. Druhá varianta bude krátké zadání se 4 prvky a s odkazem na 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 kritéria hotovo i do dalšího kroku.
 
 ## Hlavní teze
 
 - Kontext je páka, ne kosmetika.
 - `AGENTS.md`, skills a runbooky jsou týmová infrastruktura.
 - `AGENTS.md` nemá být encyklopedie. Má to být mapa, která ukáže, kam sáhnout dál.
-- Co není v repu, neexistuje. Slack, ústní dovysvětlení a "to si pamatujeme" se při continuation rozpadají.
+- 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í default. Bezpečnější je izolované lokální prostředí a jasné mantinely.
+- „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í continuation prověří, jestli váš kontext funguje i bez vás.
+- Odpolední návaznost prověří, jestli váš kontext funguje i bez vás.
 
 ## Co chci, aby si adoptovali
 
-- Než začnu generovat feature, udělám z repa místo, kde se dá orientovat.
+- 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ý design constraint.
+- Handoff není závěr dne. Je to průběžná podmínka celé práce.
 
 ## Závěr
 

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

@@ -63,7 +63,7 @@ Preferred interactive path:
 1. facilitator starts `harness auth login`
 2. CLI opens browser or emits a device-code style flow
 3. dashboard auth/backend completes facilitator identity verification
-4. CLI stores the resulting session material in local session storage
+4. CLI stores the resulting platform session material in local session storage
 
 The facilitator skill should call the CLI for privileged operations instead of storing raw auth/session material itself.
 
@@ -73,6 +73,37 @@ Control model:
 - CLI invokes shared protected dashboard APIs
 - APIs enforce authz, validation, idempotency, and audit logging
 
+Current auth layering:
+
+- `harness auth login` authenticates the facilitator to the platform
+- workshop commands then target a concrete workshop instance explicitly or through a default-selection rule
+- instance grants are checked when a workshop is targeted, not during login bootstrap
+
+Current target-selection order:
+
+1. an explicit command or route instance id
+2. the selected control-room instance in the dashboard
+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 target required:
+  - `harness workshop update-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:
+  - `harness workshop status`
+  - `harness workshop archive`
+  - `harness workshop phase set <phase-id>`
+
+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`
+
 For the current facilitator lifecycle slice:
 
 - `workshop status`, `create-instance`, `update-instance`, and `prepare` are brokered-session commands

package/assets/workshop-bundle/docs/learner-reference-gallery.md

@@ -12,19 +12,19 @@ Jakmile tato stránka začne připomínat „awesome list“, je moc dlouhá.
 ## Oficiální dokumentace
 
 - [OpenAI Codex documentation](https://developers.openai.com/codex)
-  Použijte jako hlavní zdroj pro aktuální Codex workflows, skills, `AGENTS.md`, subagents a security guidance.
+  Použijte jako hlavní zdroj pro aktuální Codex workflow, skills, `AGENTS.md`, subagenty a bezpečnostní doporučení.
 
 - [OpenAI Codex best practices](https://developers.openai.com/codex/learn/best-practices)
   Nejlepší rychlý vstup pro to, jak Codex používat jako dlouhodobého spolupracovníka: kontext, `AGENTS.md`, review, verification, MCP a automatizace.
 
 - [OpenAI Codex skills documentation](https://developers.openai.com/codex/skills)
-  Hodí se ve chvíli, kdy chcete z opakovaných promptů udělat znovupoužitelné repo-native skills.
+  Hodí se ve chvíli, kdy chcete z opakovaných promptů udělat znovupoužitelné skills zapsané přímo v repu.
 
 - [OpenAI Codex plugins](https://developers.openai.com/codex/plugins)
-  Dobré pro pochopení, kdy v Codexu použít pluginy a marketplace místo samotných repo-native skills. Pro workshop je berte jako volitelný Codex akcelerátor, ne jako základní bootstrap.
+  Dobré pro pochopení, kdy v Codexu použít pluginy a marketplace místo samotných skills zapsaných v repu. Pro workshop je berte jako volitelný Codex akcelerátor, ne jako základní bootstrap.
 
 - [OpenAI Codex build plugins](https://developers.openai.com/codex/plugins/build)
-  Hodí se maintainerům, když chtějí pochopit marketplace model, repo-local marketplace nebo bundling skills, app integrations a MCP serverů do jednoho Codex package.
+  Hodí se maintainerům, když chtějí pochopit marketplace model, repo-local marketplace nebo balení skills, app integrací a MCP serverů do jednoho Codex balíčku.
 
 - [OpenAI Codex workflows](https://developers.openai.com/codex/workflows)
   Dobré pro převedení workshopových návyků do reálných projektových workflow.
@@ -66,12 +66,12 @@ Jakmile tato stránka začne připomínat „awesome list“, je moc dlouhá.
   Když se stejný task vrací napříč více sessions nebo repy, je to kandidát na skill.
 
 - Pluginy a marketplace berte jako Codex-specific distribuční vrstvu, ne jako definici workshop metody.
-  Když něco učíme jako Harness Lab default, mělo by to dávat smysl i mimo Codex. Plugin má smysl tam, kde skutečně přidává Codex integrations nebo pohodlnější distribuci.
+  Když něco učíme jako výchozí přístup v Harness Labu, mělo by to dávat smysl i mimo Codex. Plugin má smysl tam, kde skutečně přidává Codex integrace nebo pohodlnější distribuci.
 
 - Testy, tracer bullets a checklisty berte jako hranici důvěry.
   Čím víc autonomie agent dostane, tím méně stačí „rychle jsem projel diff“.
 
-- Participant-facing příklady držte menší než backstage systémy.
+- Příklady pro účastníky držte menší než backstage systémy.
   Dobrý learner artefakt je kopírovatelný a čitelný, ne vyčerpávající.
 
 ## Pravidlo čerstvosti

package/assets/workshop-bundle/docs/learner-resource-kit.md

@@ -1,39 +1,39 @@
 # Learner Resource Kit
 
-Tato stránka definuje participant-facing resource kit pro Harness Lab.
+Tato stránka definuje účastnický kit zdrojů pro Harness Lab.
 
 Je to malá, kopírovatelná část repa, kterou si mají účastníci odnést, projít a znovu použít ve vlastních projektech.
 
 ## Základní pravidlo
 
-Learner kit není celý backstage harness.
+Learner kit není celý backstage workshopu.
 
 Má odpovídat na otázky:
 - co si mám z workshopu zkopírovat do vlastního repa?
 - co má agent udělat jako první?
 - jak zařídit, aby práce přežila handoff?
-- co musím ověřit, než výstupu uvěřím?
+- co musím ověřit, než výsledku uvěřím?
 
-Výchozí participant pattern, který má learner kit posilovat, je:
+Výchozí pracovní rytmus, který má learner kit posilovat, je:
 - `workshop` pro orientaci
 - `brainstorm` nebo `plan` před větším řezem
 - `work` proti jednomu ověřitelnému cíli
 - `review` před důvěrou
-- `compound` a cleanup pro věci, které mají přežít session
+- `compound` a průběžný úklid pro věci, které mají přežít session
 
 ## Jádro learner kitu
 
 ### 1. Workshop skill
 
-Hlavní participant interface:
+Hlavní rozhraní pro účastníky:
 - [`SKILL.md`](../SKILL.md)
 - [`workshop-skill/setup.md`](../workshop-skill/setup.md)
 - [`workshop-skill/reference.md`](../workshop-skill/reference.md)
 - [`workshop-skill/recap.md`](../workshop-skill/recap.md)
 
 Proč sem patří:
-- ukazuje, jak může participant-facing skill vést setup, workflow i ověřování v češtině
-- je to reálné repo-native rozhraní, ne workshopový slide artefakt
+- ukazuje, jak může skill pro účastníky vést setup, workflow i ověřování v češtině
+- je to reálné rozhraní opřené o repo, ne workshopový slide artefakt
 
 ### 2. `AGENTS.md` příklad
 
@@ -44,7 +44,7 @@ Proč sem patří:
 - je to nejmenší znovupoužitelný příklad trvalého kontextu v repu
 - účastníci ho mohou upravit přímo pro vlastní projekt
 
-### 3. Příklad pro verification / review
+### 3. Příklad pro ověření a review
 
 Výchozí checklist:
 - [`workshop-skill/analyze-checklist.md`](../workshop-skill/analyze-checklist.md)
@@ -80,17 +80,17 @@ Použijte:
 - [`workshop-skill/setup.md`](../workshop-skill/setup.md)
 - [`workshop-skill/reference.md`](../workshop-skill/reference.md)
 
-### Během Build Phase 1
+### Během build fáze 1
 
 Použijte:
 - [`workshop-skill/template-agents.md`](../workshop-skill/template-agents.md)
-- the `Context Engineering` cards in [`content/challenge-cards/deck.md`](../content/challenge-cards/deck.md)
+- karty `Context Engineering` v [`content/challenge-cards/deck.md`](../content/challenge-cards/deck.md)
 
-### Během continuation shift
+### Během odpoledního převzetí
 
 Použijte:
 - [`workshop-skill/analyze-checklist.md`](../workshop-skill/analyze-checklist.md)
-- the `Workflow` cards in [`content/challenge-cards/deck.md`](../content/challenge-cards/deck.md)
+- karty `Workflow` v [`content/challenge-cards/deck.md`](../content/challenge-cards/deck.md)
 
 ### Po workshopu
 
@@ -109,18 +109,18 @@ Použijte:
    - context
    - constraints
    - done when
-2. Do `context` napište, co má agent číst jako první a které docs jsou source of truth.
-3. Do `done when` napište konkrétní ověření a další safe move, když práce zůstane rozdělaná.
+2. Do `context` napište, co má agent číst jako první a které docs jsou zdroj pravdy.
+3. Do `done when` napište konkrétní ověření a další bezpečný krok, když práce zůstane rozdělaná.
 4. Přidejte build/test příkazy, které zvládne spustit další tým nebo agent bez ústního dovysvětlení.
 5. Přidejte jeden review nebo handoff checklist.
 6. Přesuňte jedno trvalé pravidlo z chatu do repa.
 7. Před větší implementací použijte plan a po větší změně review nebo check.
-8. Když už používáte externí workflow skill pack, napojte ho až nad tento základ místo toho, abyste jím nahrazovali repo-native kontext a verification.
+8. Když už používáte externí workflow skill pack, napojte ho až nad tento základ místo toho, abyste jím nahrazovali kontext zapsaný v repu a ověřování.
 
 ## Co sem nepatří
 
-Learner kit nemá obsahovat plný backstage operating detail, například:
-- workshop-instance runbooky
+Learner kit nemá obsahovat plný backstage provozní detail, například:
+- runbooky pro konkrétní workshop instance
 - privátní runtime architekturu a operace
-- facilitator-only monitoring nebo control postupy
-- maintainer-level deployment a security postupy, pokud se zrovna neučí explicitně jako participant skill
+- monitoring nebo řídicí postupy jen pro facilitátory
+- maintainer-level deployment a security postupy, pokud se zrovna neučí explicitně jako skill pro účastníky

package/assets/workshop-bundle/docs/locales/en/learner-reference-gallery.md

@@ -0,0 +1,82 @@
+# Learner Reference Gallery
+
+This is a short list of resources for participants after the workshop.
+
+The rule is simple:
+- official documentation first
+- then a few strong public repos
+- and finally a small number of patterns directly relevant to Harness Lab
+
+Once this page starts to look like an “awesome list,” it has become too long.
+
+## Official documentation
+
+- [OpenAI Codex documentation](https://developers.openai.com/codex)
+  Use this as the main source for current Codex workflows, skills, `AGENTS.md`, subagents, and security guidance.
+
+- [OpenAI Codex best practices](https://developers.openai.com/codex/learn/best-practices)
+  The best fast entry point for using Codex as a long-term collaborator: context, `AGENTS.md`, review, verification, MCP, and automation.
+
+- [OpenAI Codex skills documentation](https://developers.openai.com/codex/skills)
+  Useful once you want to turn repeated prompts into reusable repo-native skills.
+
+- [OpenAI Codex plugins](https://developers.openai.com/codex/plugins)
+  Good for understanding when to use plugins and marketplace distribution in Codex instead of repo-native skills alone. In this workshop, treat plugins as an optional Codex accelerator, not as the core bootstrap.
+
+- [OpenAI Codex build plugins](https://developers.openai.com/codex/plugins/build)
+  Useful for maintainers who want to understand the marketplace model, repo-local marketplace patterns, or bundling skills, app integrations, and MCP servers into one Codex package.
+
+- [OpenAI Codex workflows](https://developers.openai.com/codex/workflows)
+  Good for turning workshop habits into real project workflows.
+
+- [OpenAI: Harness engineering: leveraging Codex in an agent-first world](https://openai.com/index/harness-engineering/)
+  Useful for understanding why repo knowledge should be the system of record and why plans, review, and garbage collection belong to engineering discipline rather than bonus process.
+
+- [Next.js AI Coding Agents](https://nextjs.org/docs/app/guides/ai-agents)
+  Important mainly for Next.js projects: it shows why agents should read version-matched framework docs instead of relying on stale model memory.
+
+## Public repositories
+
+- [openai/codex](https://github.com/openai/codex)
+  The official CLI repo and the best anchor for how the tool itself evolves.
+
+- [openai/skills](https://github.com/openai/skills)
+  The official skills catalog and the best reference for what a Codex-native skill looks like.
+
+- [openai/codex-action](https://github.com/openai/codex-action)
+  A strong example of narrow, safe automation around Codex in CI.
+
+- [vercel-labs/skills](https://github.com/vercel-labs/skills)
+  Useful when you want skill packaging that stays portable across more than one coding agent.
+
+- [vercel-labs/agent-skills](https://github.com/vercel-labs/agent-skills)
+  Good examples of practical, high-quality skills, especially for frontend and React work.
+
+## Optional workflow packs
+
+- [EveryInc/compound-engineering-plugin](https://github.com/EveryInc/compound-engineering-plugin)
+  A strong optional choice for people who want an explicit `brainstorm -> plan -> work -> review -> compound` loop. This repo supports installation for both Codex and pi, but treat it as an accelerator on top of the workshop default, not as required setup.
+
+## Practical patterns
+
+- Start with repo context before you start repeating the prompt.
+  In practice: first add `AGENTS.md`, build/test commands, and a concrete definition of done.
+
+- Use skills for repeated workflows, not as one-off chat macros.
+  If the same task returns across multiple sessions or repos, it is a good skill candidate.
+
+- Treat plugins and marketplace distribution as a Codex-specific delivery layer, not as the definition of the workshop method.
+  If something is taught as a Harness Lab default, it should still make sense outside Codex. A plugin makes sense where it genuinely adds Codex integrations or easier distribution.
+
+- Treat tests, tracer bullets, and checklists as the trust boundary.
+  The more autonomy the agent gets, the less “I skimmed the diff quickly” is enough.
+
+- Keep participant-facing examples smaller than backstage systems.
+  A good learner artifact is copyable and readable, not exhaustive.
+
+## Freshness rule
+
+Review this list:
+- before every workshop run
+- after a major change in Codex capabilities
+- when a recommended repo becomes stale, noisy, or stops being the best example

package/assets/workshop-bundle/docs/locales/en/learner-resource-kit.md

@@ -0,0 +1,126 @@
+# Learner Resource Kit
+
+This page defines the participant-facing resource kit for Harness Lab.
+
+It is the small, copyable slice of the repo that participants should take away, revisit, and reuse in their own projects.
+
+## Core rule
+
+The learner kit is not the full backstage harness.
+
+It should answer:
+- what should I copy from the workshop into my own repo?
+- what should the agent do first?
+- how do I make the work survive handoff?
+- what must I verify before I trust the output?
+
+The default participant pattern this kit should reinforce is:
+- `workshop` for orientation
+- `brainstorm` or `plan` before a larger cut
+- `work` against one verifiable goal
+- `review` before trust
+- `compound` and cleanup for things that should survive the session
+
+## Core learner kit
+
+### 1. Workshop skill
+
+Primary participant interface:
+- [`SKILL.md`](../../../SKILL.md)
+- [`workshop-skill/locales/en/setup.md`](../../../workshop-skill/locales/en/setup.md)
+- [`workshop-skill/locales/en/reference.md`](../../../workshop-skill/locales/en/reference.md)
+- [`workshop-skill/locales/en/recap.md`](../../../workshop-skill/locales/en/recap.md)
+
+Why it belongs here:
+- it shows how a participant-facing skill can guide setup, workflow, and verification in reviewed workshop language
+- it is a real repo-native interface, not a workshop slide artifact
+
+### 2. `AGENTS.md` example
+
+Default starter:
+- [`workshop-skill/template-agents.md`](../../../workshop-skill/template-agents.md)
+
+Why it belongs here:
+- it is the smallest reusable example of durable context in the repo
+- participants can adapt it directly for their own project
+
+### 3. Verification / review example
+
+Default checklist:
+- [`workshop-skill/analyze-checklist.md`](../../../workshop-skill/analyze-checklist.md)
+
+Why it belongs here:
+- it provides a concrete standard for “can another team continue from here?”
+- it turns repo quality into a checklist people can actually run
+
+### 4. Challenge cards
+
+Recommended subset:
+- [`content/challenge-cards/locales/en/deck.md`](../../../content/challenge-cards/locales/en/deck.md)
+
+Use:
+- as small interventions during the workshop
+- as prompts for what to improve later in a real repo
+
+### 5. Follow-up package
+
+Post-workshop reinforcement:
+- [`workshop-skill/locales/en/follow-up-package.md`](../../../workshop-skill/locales/en/follow-up-package.md)
+- [`materials/locales/en/participant-resource-kit.md`](../../../materials/locales/en/participant-resource-kit.md)
+
+Why it belongs here:
+- it turns the workshop from a one-day event into a repeatable prompt for behavior change
+- it provides a literal handout you can send or print without further explanation
+
+## When to use which artifact
+
+### During setup
+
+Use:
+- [`workshop-skill/locales/en/setup.md`](../../../workshop-skill/locales/en/setup.md)
+- [`workshop-skill/locales/en/reference.md`](../../../workshop-skill/locales/en/reference.md)
+
+### During Build Phase 1
+
+Use:
+- [`workshop-skill/template-agents.md`](../../../workshop-skill/template-agents.md)
+- the `Context Engineering` cards in [`content/challenge-cards/locales/en/deck.md`](../../../content/challenge-cards/locales/en/deck.md)
+
+### During the continuation shift
+
+Use:
+- [`workshop-skill/analyze-checklist.md`](../../../workshop-skill/analyze-checklist.md)
+- the `Workflow` cards in [`content/challenge-cards/locales/en/deck.md`](../../../content/challenge-cards/locales/en/deck.md)
+
+### After the workshop
+
+Use:
+- [`workshop-skill/locales/en/recap.md`](../../../workshop-skill/locales/en/recap.md)
+- [`workshop-skill/locales/en/follow-up-package.md`](../../../workshop-skill/locales/en/follow-up-package.md)
+- [`materials/locales/en/participant-resource-kit.md`](../../../materials/locales/en/participant-resource-kit.md)
+- [`learner-reference-gallery.md`](learner-reference-gallery.md)
+
+## What to carry into a real project
+
+Participants should leave with these concrete moves:
+
+1. Add `AGENTS.md` with:
+   - goal
+   - context
+   - constraints
+   - done when
+2. In `context`, write what the agent should read first and which docs are the source of truth.
+3. In `done when`, write explicit verification and the next safe move if work remains unfinished.
+4. Add build/test commands that another team or agent can run without verbal backfilling.
+5. Add one review or handoff checklist.
+6. Move one durable rule from chat into the repo.
+7. Use plan before a larger implementation and review or another check after a larger change.
+8. If you already use an external workflow skill pack, layer it on top of this foundation instead of replacing repo-native context and verification.
+
+## What does not belong here
+
+The learner kit should not include the full backstage operating detail, for example:
+- workshop-instance runbooks
+- private runtime architecture and operations
+- facilitator-only monitoring or control procedures
+- maintainer-level deployment and security procedures unless they are being taught explicitly as participant skill content