@harness-lab/cli 0.2.2 → 0.2.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +6 -0
- package/assets/workshop-bundle/SKILL.md +22 -11
- package/assets/workshop-bundle/bundle-manifest.json +82 -22
- package/assets/workshop-bundle/content/challenge-cards/deck.md +3 -3
- package/assets/workshop-bundle/content/challenge-cards/locales/en/deck.md +38 -0
- package/assets/workshop-bundle/content/czech-editorial-review-checklist.md +88 -0
- package/assets/workshop-bundle/content/facilitation/master-guide.md +9 -9
- package/assets/workshop-bundle/content/project-briefs/locales/en/code-review-helper.md +31 -0
- package/assets/workshop-bundle/content/project-briefs/locales/en/devtoolbox-cli.md +31 -0
- package/assets/workshop-bundle/content/project-briefs/locales/en/doc-generator.md +31 -0
- package/assets/workshop-bundle/content/project-briefs/locales/en/metrics-dashboard.md +31 -0
- package/assets/workshop-bundle/content/project-briefs/locales/en/standup-bot.md +31 -0
- package/assets/workshop-bundle/content/style-examples.md +1 -1
- package/assets/workshop-bundle/content/style-guide.md +4 -2
- package/assets/workshop-bundle/content/talks/codex-demo-script.md +3 -3
- package/assets/workshop-bundle/content/talks/context-is-king.md +8 -8
- package/assets/workshop-bundle/docs/harness-cli-foundation.md +32 -1
- package/assets/workshop-bundle/docs/learner-reference-gallery.md +6 -6
- package/assets/workshop-bundle/docs/learner-resource-kit.md +20 -20
- package/assets/workshop-bundle/docs/locales/en/learner-reference-gallery.md +82 -0
- package/assets/workshop-bundle/docs/locales/en/learner-resource-kit.md +126 -0
- package/assets/workshop-bundle/materials/locales/en/participant-resource-kit.md +72 -0
- package/assets/workshop-bundle/materials/participant-resource-kit.md +5 -5
- package/assets/workshop-bundle/workshop-blueprint/README.md +8 -1
- package/assets/workshop-bundle/workshop-skill/analyze-checklist.md +1 -1
- package/assets/workshop-bundle/workshop-skill/commands.md +7 -7
- package/assets/workshop-bundle/workshop-skill/facilitator.md +16 -6
- package/assets/workshop-bundle/workshop-skill/follow-up-package.md +1 -1
- package/assets/workshop-bundle/workshop-skill/install.md +6 -6
- package/assets/workshop-bundle/workshop-skill/locales/en/commands.md +44 -0
- package/assets/workshop-bundle/workshop-skill/locales/en/follow-up-package.md +35 -0
- package/assets/workshop-bundle/workshop-skill/locales/en/recap.md +22 -0
- package/assets/workshop-bundle/workshop-skill/locales/en/reference.md +80 -0
- package/assets/workshop-bundle/workshop-skill/locales/en/setup.md +84 -0
- package/assets/workshop-bundle/workshop-skill/reference.md +12 -12
- package/assets/workshop-bundle/workshop-skill/setup.md +5 -5
- package/assets/workshop-bundle/workshop-skill/template-agents.md +4 -4
- package/package.json +2 -2
- package/src/workshop-bundle.js +26 -1
package/README.md
CHANGED
|
@@ -36,6 +36,11 @@ Participant-facing default install:
|
|
|
36
36
|
npm install -g @harness-lab/cli
|
|
37
37
|
```
|
|
38
38
|
|
|
39
|
+
Supported runtime:
|
|
40
|
+
|
|
41
|
+
- Node `22` or newer
|
|
42
|
+
- npm `10` or newer recommended
|
|
43
|
+
|
|
39
44
|
Verify the binary:
|
|
40
45
|
|
|
41
46
|
```bash
|
|
@@ -78,6 +83,7 @@ harness skill install --target /path/to/team-repo
|
|
|
78
83
|
This creates `.agents/skills/harness-lab-workshop` in the target repo. The install does not require a local clone of the Harness Lab source repo.
|
|
79
84
|
Rerunning `harness skill install` refreshes the installed bundle when the packaged workshop content changed and reports clearly when the target is already current. Use `--force` only when you want a full reinstall.
|
|
80
85
|
After install, the CLI prints the first recommended agent commands, starting with `Codex: $workshop commands` and `pi: /skill:workshop`.
|
|
86
|
+
Treat the installed `workshop` skill as the first participant entrypoint. It should route setup, reference, and workshop guidance through live `contentLang` when available or the best reviewed bundled locale otherwise, instead of assuming the base authored Czech docs are always the right first stop.
|
|
81
87
|
|
|
82
88
|
Treat `.agents/skills/harness-lab-workshop` as generated workshop bundle content. The canonical authored source remains in this repository under `workshop-skill/`, `workshop-blueprint/`, selected `docs/`, and selected `materials/`.
|
|
83
89
|
|
|
@@ -18,7 +18,7 @@ allowed-tools:
|
|
|
18
18
|
|
|
19
19
|
# Workshop
|
|
20
20
|
|
|
21
|
-
Participant-facing skill for the Harness Lab workshop.
|
|
21
|
+
Participant-facing skill for the Harness Lab workshop. Command semantics stay in English, but participant-facing delivery should follow the active workshop `contentLang` when live runtime data is available and fall back to the best reviewed bundled locale otherwise.
|
|
22
22
|
|
|
23
23
|
## Purpose
|
|
24
24
|
|
|
@@ -31,6 +31,8 @@ Core mental model:
|
|
|
31
31
|
- dashboard facilitator surface = řízení workshop instance
|
|
32
32
|
- workshop skill = AI interface ke stejnému workshop systému
|
|
33
33
|
- workshop blueprint = veřejná kanonická definice workshop method
|
|
34
|
+
- `uiLang` = jazyk product chrome
|
|
35
|
+
- `contentLang` = jazyk workshopového obsahu pro participant-facing delivery
|
|
34
36
|
|
|
35
37
|
## Sources Of Truth
|
|
36
38
|
|
|
@@ -44,6 +46,7 @@ Use runtime dashboard data for anything that changes during the workshop day:
|
|
|
44
46
|
Use repo-native content for stable public guidance:
|
|
45
47
|
- `content/` workshop materials
|
|
46
48
|
- `workshop-skill/` reference docs
|
|
49
|
+
- `workshop-skill/locales/<locale>/` when a reviewed localized fallback doc exists for the requested delivery language
|
|
47
50
|
- `workshop-blueprint/` for the reusable workshop method
|
|
48
51
|
- challenge cards, project briefs, and public-safe framing
|
|
49
52
|
|
|
@@ -52,6 +55,10 @@ Rule:
|
|
|
52
55
|
- repo docs first for durable workshop guidance
|
|
53
56
|
- if runtime is unavailable, fall back to repo material and say explicitly that the answer is fallback rather than live state
|
|
54
57
|
- runtime edits do not imply blueprint edits; reusable changes belong back in the repo deliberately
|
|
58
|
+
- prefer workshop `contentLang` for participant-facing responses in live mode
|
|
59
|
+
- if there is no live workshop context, prefer the best reviewed bundled locale and say when the answer is fallback content rather than live workshop state
|
|
60
|
+
- for bundled fallback docs, resolve `workshop-skill/locales/<locale>/...` first; if a reviewed localized doc does not exist yet, fall back to the best reviewed bundled locale and say so explicitly
|
|
61
|
+
- do not translate workshop copy ad hoc when a reviewed locale exists in the repo or bundle
|
|
55
62
|
|
|
56
63
|
## Commands
|
|
57
64
|
|
|
@@ -83,12 +90,12 @@ Clear the current participant session and return to fallback/public-only mode.
|
|
|
83
90
|
|
|
84
91
|
### `workshop setup`
|
|
85
92
|
|
|
86
|
-
Guide the participant through Codex or pi setup in
|
|
93
|
+
Guide the participant through Codex or pi setup in the active workshop content language. Prefer the fastest viable path:
|
|
87
94
|
- pi in terminal when the participant wants a hackable multi-model interface
|
|
88
95
|
- Codex CLI on macOS/Linux
|
|
89
96
|
- Codex App on Windows or macOS
|
|
90
97
|
- web fallback if local install is blocked
|
|
91
|
-
Use
|
|
98
|
+
Use `workshop-skill/locales/<locale>/setup.md` when present, otherwise fall back to `workshop-skill/setup.md`.
|
|
92
99
|
|
|
93
100
|
### `workshop brief`
|
|
94
101
|
|
|
@@ -97,6 +104,7 @@ Show the assigned project brief. Include:
|
|
|
97
104
|
- user stories
|
|
98
105
|
- architecture considerations
|
|
99
106
|
- first recommended prompt for the AI agent
|
|
107
|
+
If live runtime brief data is unavailable, prefer `content/project-briefs/locales/<locale>/<brief>.md` when present and otherwise fall back to `content/project-briefs/<brief>.md`.
|
|
100
108
|
|
|
101
109
|
### `workshop challenges`
|
|
102
110
|
|
|
@@ -104,6 +112,7 @@ Show available challenge cards, clearly marking:
|
|
|
104
112
|
- semi-mandatory before lunch
|
|
105
113
|
- semi-mandatory after the continuation shift
|
|
106
114
|
- optional stretch cards
|
|
115
|
+
If live runtime challenge data is unavailable, prefer `content/challenge-cards/locales/<locale>/deck.md` when present and otherwise fall back to `content/challenge-cards/deck.md`.
|
|
107
116
|
|
|
108
117
|
### `workshop team`
|
|
109
118
|
|
|
@@ -135,8 +144,8 @@ Keep it short and map-like. Prefer links to deeper docs over long prose dumps.
|
|
|
135
144
|
|
|
136
145
|
### `workshop recap`
|
|
137
146
|
|
|
138
|
-
Return a short post-workshop reinforcement prompt in
|
|
139
|
-
Use
|
|
147
|
+
Return a short post-workshop reinforcement prompt in the active workshop content language.
|
|
148
|
+
Use `workshop-skill/locales/<locale>/recap.md` when present, otherwise fall back to `workshop-skill/recap.md`.
|
|
140
149
|
|
|
141
150
|
### `workshop commands`
|
|
142
151
|
|
|
@@ -144,7 +153,7 @@ Return a short participant-facing menu of the skill surface:
|
|
|
144
153
|
- what the main commands are
|
|
145
154
|
- when to use them
|
|
146
155
|
- the shortest recommended path for a new participant
|
|
147
|
-
Use `workshop-skill/commands.md`.
|
|
156
|
+
Use `workshop-skill/locales/<locale>/commands.md` when present, otherwise fall back to `workshop-skill/commands.md`.
|
|
148
157
|
|
|
149
158
|
### `workshop closing`
|
|
150
159
|
|
|
@@ -157,14 +166,14 @@ Treat this as facilitator-facing. Do not proactively surface it to participants
|
|
|
157
166
|
|
|
158
167
|
### `workshop reference`
|
|
159
168
|
|
|
160
|
-
Return the workshop reference card from `workshop-skill/reference.md`.
|
|
169
|
+
Return the workshop reference card from `workshop-skill/locales/<locale>/reference.md` when present, otherwise fall back to `workshop-skill/reference.md`.
|
|
161
170
|
|
|
162
171
|
### `workshop resources`
|
|
163
172
|
|
|
164
173
|
Return the participant-facing resource bundle after or during the workshop.
|
|
165
174
|
Use these sources together:
|
|
166
|
-
- `materials/participant-resource-kit.md`
|
|
167
|
-
- `docs/learner-resource-kit.md`
|
|
175
|
+
- `materials/locales/<locale>/participant-resource-kit.md` when present, otherwise `materials/participant-resource-kit.md`
|
|
176
|
+
- `docs/locales/<locale>/learner-resource-kit.md` when present, otherwise `docs/learner-resource-kit.md`
|
|
168
177
|
|
|
169
178
|
The response should:
|
|
170
179
|
- summarize what is in the kit
|
|
@@ -173,12 +182,12 @@ The response should:
|
|
|
173
182
|
|
|
174
183
|
### `workshop gallery`
|
|
175
184
|
|
|
176
|
-
Return the curated external reference gallery from `docs/learner-reference-gallery.md`.
|
|
185
|
+
Return the curated external reference gallery from `docs/locales/<locale>/learner-reference-gallery.md` when present, otherwise `docs/learner-reference-gallery.md`.
|
|
177
186
|
Use this when the participant asks for further reading, public examples, optional skill packs, or recommended external resources after the workshop.
|
|
178
187
|
|
|
179
188
|
### `workshop follow-up`
|
|
180
189
|
|
|
181
|
-
Return the follow-up package from `workshop-skill/follow-up-package.md`.
|
|
190
|
+
Return the follow-up package from `workshop-skill/locales/<locale>/follow-up-package.md` when present, otherwise `workshop-skill/follow-up-package.md`.
|
|
182
191
|
Use this when the participant asks what to do after the workshop, what to revisit tomorrow, or what materials to keep using next week.
|
|
183
192
|
|
|
184
193
|
### `workshop facilitator login`
|
|
@@ -209,6 +218,7 @@ Prefer invoking `harness workshop create-instance` over raw API scripts.
|
|
|
209
218
|
The skill should support rich event metadata, not just id and city:
|
|
210
219
|
- `id`
|
|
211
220
|
- `templateId`
|
|
221
|
+
- `contentLang`
|
|
212
222
|
- `eventTitle`
|
|
213
223
|
- `city`
|
|
214
224
|
- `dateRange`
|
|
@@ -223,6 +233,7 @@ The skill should support rich event metadata, not just id and city:
|
|
|
223
233
|
Update event metadata for an existing workshop instance. Requires facilitator session.
|
|
224
234
|
Prefer invoking `harness workshop update-instance` over raw API scripts.
|
|
225
235
|
Use this when the facilitator wants to correct or refine date, venue, room, address, or event title without resetting the instance.
|
|
236
|
+
Support `contentLang` changes explicitly so facilitators can choose workshop delivery language per instance without changing admin UI language.
|
|
226
237
|
|
|
227
238
|
### `workshop facilitator remove-instance`
|
|
228
239
|
|
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
{
|
|
2
2
|
"manifestVersion": 1,
|
|
3
3
|
"bundleName": "harness-lab-workshop",
|
|
4
|
-
"bundleVersion": "0.2.
|
|
5
|
-
"contentHash": "
|
|
4
|
+
"bundleVersion": "0.2.4",
|
|
5
|
+
"contentHash": "9e57d44e4a3f9296f4913cd51eefbf9dff7d6d9da8d4afb1ae5a2ce2a7dc4323",
|
|
6
6
|
"files": [
|
|
7
7
|
{
|
|
8
8
|
"path": "content/challenge-cards/.gitkeep",
|
|
@@ -10,12 +10,20 @@
|
|
|
10
10
|
},
|
|
11
11
|
{
|
|
12
12
|
"path": "content/challenge-cards/deck.md",
|
|
13
|
-
"sha256": "
|
|
13
|
+
"sha256": "c2828eb5258031351d6d5abd3388b26b0894a9122e88e3203efaccbfd95a3e82"
|
|
14
|
+
},
|
|
15
|
+
{
|
|
16
|
+
"path": "content/challenge-cards/locales/en/deck.md",
|
|
17
|
+
"sha256": "6b6a3882ef31b3bca9f1f1ed43ef4fb2d8340af9879fee4261922fb55f6cd921"
|
|
14
18
|
},
|
|
15
19
|
{
|
|
16
20
|
"path": "content/challenge-cards/print-spec.md",
|
|
17
21
|
"sha256": "be7ecfdae9ada4145272f12e2d6018ccde7cfaeb9f48feb58aca7da7236815c0"
|
|
18
22
|
},
|
|
23
|
+
{
|
|
24
|
+
"path": "content/czech-editorial-review-checklist.md",
|
|
25
|
+
"sha256": "23539ba8b2c6ed193cfadc7ad0f0f75e99b2926ebff5beade5df9789e6071fcf"
|
|
26
|
+
},
|
|
19
27
|
{
|
|
20
28
|
"path": "content/facilitation/.gitkeep",
|
|
21
29
|
"sha256": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
|
|
@@ -26,7 +34,7 @@
|
|
|
26
34
|
},
|
|
27
35
|
{
|
|
28
36
|
"path": "content/facilitation/master-guide.md",
|
|
29
|
-
"sha256": "
|
|
37
|
+
"sha256": "e22f4a811459be1fe23412e7d85c02fe20170e6e6c8534fc97c1616f65b2cfd8"
|
|
30
38
|
},
|
|
31
39
|
{
|
|
32
40
|
"path": "content/project-briefs/.gitkeep",
|
|
@@ -44,6 +52,26 @@
|
|
|
44
52
|
"path": "content/project-briefs/doc-generator.md",
|
|
45
53
|
"sha256": "3f3bea866c68a927916d90fa3e387ceccdd174290944bc83db7b89d43f3ba7a0"
|
|
46
54
|
},
|
|
55
|
+
{
|
|
56
|
+
"path": "content/project-briefs/locales/en/code-review-helper.md",
|
|
57
|
+
"sha256": "57339193c04eb3cfd444e5477d86923b0c9d189163437f0c56a7db5a0045aa87"
|
|
58
|
+
},
|
|
59
|
+
{
|
|
60
|
+
"path": "content/project-briefs/locales/en/devtoolbox-cli.md",
|
|
61
|
+
"sha256": "cb7a92f20fa0565611feb9f24eb65aafc4a7b151a32de42c93d33b93049f161e"
|
|
62
|
+
},
|
|
63
|
+
{
|
|
64
|
+
"path": "content/project-briefs/locales/en/doc-generator.md",
|
|
65
|
+
"sha256": "5ff49a57e51c030b34385709ab7519a5d8e19cd98a1e3a5b26603a7eb59c02e3"
|
|
66
|
+
},
|
|
67
|
+
{
|
|
68
|
+
"path": "content/project-briefs/locales/en/metrics-dashboard.md",
|
|
69
|
+
"sha256": "ff6b429001ea4ab2d9c23fbdfe02c5daaaf413d52609f9dabc365902f2ad063a"
|
|
70
|
+
},
|
|
71
|
+
{
|
|
72
|
+
"path": "content/project-briefs/locales/en/standup-bot.md",
|
|
73
|
+
"sha256": "bc3972786dac4298607c63e15262cf5330c7e7fcf754e5df64e8fae081f5b44b"
|
|
74
|
+
},
|
|
47
75
|
{
|
|
48
76
|
"path": "content/project-briefs/metrics-dashboard.md",
|
|
49
77
|
"sha256": "a678058b6515fec4acba5d288bb71a725dfe9e75320efa11a475d63492db14f6"
|
|
@@ -54,11 +82,11 @@
|
|
|
54
82
|
},
|
|
55
83
|
{
|
|
56
84
|
"path": "content/style-examples.md",
|
|
57
|
-
"sha256": "
|
|
85
|
+
"sha256": "c8e62493e119995fca1c738584b864506bc838203b1adad008c37b6f6ec57c50"
|
|
58
86
|
},
|
|
59
87
|
{
|
|
60
88
|
"path": "content/style-guide.md",
|
|
61
|
-
"sha256": "
|
|
89
|
+
"sha256": "ec9a49e040efbc6c365eb264bd3452fdf1906f141f358ff28d2e0e3360648d28"
|
|
62
90
|
},
|
|
63
91
|
{
|
|
64
92
|
"path": "content/talks/.gitkeep",
|
|
@@ -66,35 +94,47 @@
|
|
|
66
94
|
},
|
|
67
95
|
{
|
|
68
96
|
"path": "content/talks/codex-demo-script.md",
|
|
69
|
-
"sha256": "
|
|
97
|
+
"sha256": "4f40188a8d3ccaddf44b89b39178c7e9cfb53298a8803815f91dce204181a9c2"
|
|
70
98
|
},
|
|
71
99
|
{
|
|
72
100
|
"path": "content/talks/context-is-king.md",
|
|
73
|
-
"sha256": "
|
|
101
|
+
"sha256": "c380947051f4a66cdf47e846d5cc5d60ace0487f75dbc718b03fb7164cb94ef1"
|
|
74
102
|
},
|
|
75
103
|
{
|
|
76
104
|
"path": "docs/harness-cli-foundation.md",
|
|
77
|
-
"sha256": "
|
|
105
|
+
"sha256": "65b0b2cee7be792ad03f9be794230298d3efe8283e8e73acb033ef401d204e51"
|
|
78
106
|
},
|
|
79
107
|
{
|
|
80
108
|
"path": "docs/learner-reference-gallery.md",
|
|
81
|
-
"sha256": "
|
|
109
|
+
"sha256": "42a9e595e28a580b4d5104cf9967211d611c03e7ee020cb14daed25c26ef575d"
|
|
82
110
|
},
|
|
83
111
|
{
|
|
84
112
|
"path": "docs/learner-resource-kit.md",
|
|
85
|
-
"sha256": "
|
|
113
|
+
"sha256": "c1c35a7896a835a49599688993f9782ad09e4f1c012b7c2b8d60b90b826eab1b"
|
|
114
|
+
},
|
|
115
|
+
{
|
|
116
|
+
"path": "docs/locales/en/learner-reference-gallery.md",
|
|
117
|
+
"sha256": "1ab9df5b5ce9e95dd594974d867377a6d32463a4e3f7590f3611400e8fae59ed"
|
|
118
|
+
},
|
|
119
|
+
{
|
|
120
|
+
"path": "docs/locales/en/learner-resource-kit.md",
|
|
121
|
+
"sha256": "70a8acd554f8785360d0fb40b5b9648d9fbc90bf70b8b6776e98d33c931f4348"
|
|
86
122
|
},
|
|
87
123
|
{
|
|
88
124
|
"path": "docs/workshop-event-context-contract.md",
|
|
89
125
|
"sha256": "a7706a398ea5250537fb34323c4371ea2a7db15e477aec3a7893e6089fcd281f"
|
|
90
126
|
},
|
|
127
|
+
{
|
|
128
|
+
"path": "materials/locales/en/participant-resource-kit.md",
|
|
129
|
+
"sha256": "1d8b2fbf019db86c56db9cd001965f97985461c79cd615cd861562f336b175fb"
|
|
130
|
+
},
|
|
91
131
|
{
|
|
92
132
|
"path": "materials/participant-resource-kit.md",
|
|
93
|
-
"sha256": "
|
|
133
|
+
"sha256": "19564e2e1156f60654e07a1c965f87668a8cb78cab5f9d06b1e1127ce812f13c"
|
|
94
134
|
},
|
|
95
135
|
{
|
|
96
136
|
"path": "SKILL.md",
|
|
97
|
-
"sha256": "
|
|
137
|
+
"sha256": "b25a7730eb123edd941bcb176bd861ad209868189601c49845d1b6892f689647"
|
|
98
138
|
},
|
|
99
139
|
{
|
|
100
140
|
"path": "workshop-blueprint/agenda.json",
|
|
@@ -118,7 +158,7 @@
|
|
|
118
158
|
},
|
|
119
159
|
{
|
|
120
160
|
"path": "workshop-blueprint/README.md",
|
|
121
|
-
"sha256": "
|
|
161
|
+
"sha256": "ae809a473bbc88411891044de7609fa053e66e370a8d4063e5d7b9e68179a98c"
|
|
122
162
|
},
|
|
123
163
|
{
|
|
124
164
|
"path": "workshop-blueprint/teaching-spine.md",
|
|
@@ -130,7 +170,7 @@
|
|
|
130
170
|
},
|
|
131
171
|
{
|
|
132
172
|
"path": "workshop-skill/analyze-checklist.md",
|
|
133
|
-
"sha256": "
|
|
173
|
+
"sha256": "b8ec5bb13a5ec25f0d3b8cbd60295c0b290aaae195d833956cd906092efc945d"
|
|
134
174
|
},
|
|
135
175
|
{
|
|
136
176
|
"path": "workshop-skill/closing-skill.md",
|
|
@@ -138,19 +178,39 @@
|
|
|
138
178
|
},
|
|
139
179
|
{
|
|
140
180
|
"path": "workshop-skill/commands.md",
|
|
141
|
-
"sha256": "
|
|
181
|
+
"sha256": "932305291e1fc943308f218a5d2714f43a2fea471f4702fe5c94192ed3cbc1e8"
|
|
142
182
|
},
|
|
143
183
|
{
|
|
144
184
|
"path": "workshop-skill/facilitator.md",
|
|
145
|
-
"sha256": "
|
|
185
|
+
"sha256": "39dcb46914f19b66fd270627f42702b1f394ceb05dd0f3cf1f0c514becb6dca1"
|
|
146
186
|
},
|
|
147
187
|
{
|
|
148
188
|
"path": "workshop-skill/follow-up-package.md",
|
|
149
|
-
"sha256": "
|
|
189
|
+
"sha256": "a8c9e847ac1c7dd03bc044ab4d82f8ce18f83c48b665aee3723e64487f845963"
|
|
150
190
|
},
|
|
151
191
|
{
|
|
152
192
|
"path": "workshop-skill/install.md",
|
|
153
|
-
"sha256": "
|
|
193
|
+
"sha256": "2bb08f93523348de834d1e7004ef4603905c8d036247037e2111153cd0fea76b"
|
|
194
|
+
},
|
|
195
|
+
{
|
|
196
|
+
"path": "workshop-skill/locales/en/commands.md",
|
|
197
|
+
"sha256": "17856fa19a44c3336709186cba171505db4b503d11bc16ad2fbc49f67d6c78a0"
|
|
198
|
+
},
|
|
199
|
+
{
|
|
200
|
+
"path": "workshop-skill/locales/en/follow-up-package.md",
|
|
201
|
+
"sha256": "c3d4b0057ddc7a2a50713b6a01e7a3564b4e8668118464e19f932d2baa7a81a0"
|
|
202
|
+
},
|
|
203
|
+
{
|
|
204
|
+
"path": "workshop-skill/locales/en/recap.md",
|
|
205
|
+
"sha256": "68141bac34417fbc8669ebd2e998658dcb66a2a8d1df6cf8ac8d2f449baacdae"
|
|
206
|
+
},
|
|
207
|
+
{
|
|
208
|
+
"path": "workshop-skill/locales/en/reference.md",
|
|
209
|
+
"sha256": "5269750632ab577f9373cd84ae57741b11364cfbd9a05d6ac7dd8de555236b53"
|
|
210
|
+
},
|
|
211
|
+
{
|
|
212
|
+
"path": "workshop-skill/locales/en/setup.md",
|
|
213
|
+
"sha256": "b5efeee9bb2ee1ada3ab2c86ae47c63afd51534fe58a849f0584384737150375"
|
|
154
214
|
},
|
|
155
215
|
{
|
|
156
216
|
"path": "workshop-skill/recap.md",
|
|
@@ -158,15 +218,15 @@
|
|
|
158
218
|
},
|
|
159
219
|
{
|
|
160
220
|
"path": "workshop-skill/reference.md",
|
|
161
|
-
"sha256": "
|
|
221
|
+
"sha256": "2023dabca1aba04a539152131e8cec2eb832c0e1107e2bb808bd8b296159bbdb"
|
|
162
222
|
},
|
|
163
223
|
{
|
|
164
224
|
"path": "workshop-skill/setup.md",
|
|
165
|
-
"sha256": "
|
|
225
|
+
"sha256": "ef67c05751f2c48182b834314e411fc912d0ec99f7cb28fab540534e2a07096c"
|
|
166
226
|
},
|
|
167
227
|
{
|
|
168
228
|
"path": "workshop-skill/template-agents.md",
|
|
169
|
-
"sha256": "
|
|
229
|
+
"sha256": "07dd6ee5a017a0af01bf3bdcc465f06a9d8701851a413e805d29cbb22a7d991a"
|
|
170
230
|
}
|
|
171
231
|
]
|
|
172
232
|
}
|
|
@@ -11,7 +11,7 @@ Karty nejsou body navíc. Jsou to malé zásahy, které zlepšují způsob prác
|
|
|
11
11
|
|
|
12
12
|
## Workflow
|
|
13
13
|
|
|
14
|
-
- `Použijte /plan před kódováním` — ukažte, z jakého
|
|
14
|
+
- `Použijte /plan před kódováním` — ukažte, z jakého plánu tým vycházel, co z něj opravdu plní a jaký je další bezpečný krok.
|
|
15
15
|
- `Rozdělte práci do více vláken` — zkuste dvě nezávislé linie práce a jednoho člověka na integraci.
|
|
16
16
|
- `Delegujte úkol a vraťte se ke kontrole za 10 minut` — neskákejte agentovi do každého kroku, kontrolujte až výsledek.
|
|
17
17
|
- `Přidejte nejmenší užitečné ověření` — vytvořte RED test, tracer bullet nebo jednoduchý browser check dřív, než agent dostane víc autonomie.
|
|
@@ -32,7 +32,7 @@ Karty nejsou body navíc. Jsou to malé zásahy, které zlepšují způsob prác
|
|
|
32
32
|
|
|
33
33
|
## Jak s kartami pracovat
|
|
34
34
|
|
|
35
|
-
- Před obědem má každý tým splnit aspoň jednu kartu z `Context Engineering`.
|
|
36
|
-
- Před rotací má být v repu dohledatelné, co bylo opravdu ověřeno a jaký je další
|
|
35
|
+
- Před obědem má každý tým splnit aspoň jednu kartu z části `Context Engineering`.
|
|
36
|
+
- Před rotací má být v repu dohledatelné, co bylo opravdu ověřeno a jaký je další bezpečný krok.
|
|
37
37
|
- Po rotaci má každý tým splnit aspoň jednu kartu z `Workflow`.
|
|
38
38
|
- Ostatní karty jsou dobrovolné. Berte je jako stretch cíle nebo inspiraci, když nevíte, co zlepšit dál.
|
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
# Challenge Cards
|
|
2
|
+
|
|
3
|
+
These cards are not bonus points. They are small interventions that improve both the way of working with the agent and the quality of the handoff.
|
|
4
|
+
|
|
5
|
+
## Context Engineering
|
|
6
|
+
|
|
7
|
+
- `Create AGENTS.md as a map` - write down the goal, build and test commands, durable rules, and where the next team should look first.
|
|
8
|
+
- `Add build/test commands` - the agent must be able to verify the result without manual backfilling.
|
|
9
|
+
- `Write a code review skill` - formalize one review routine that another team could use too.
|
|
10
|
+
- `Move one rule from conversation into the repo` - anything the team has said out loud twice should be turned into `AGENTS.md`, README, a runbook, or a test.
|
|
11
|
+
|
|
12
|
+
## Workflow
|
|
13
|
+
|
|
14
|
+
- `Use /plan before coding` - show which plan the team is working from, what is actually being executed, and what the next safe move is.
|
|
15
|
+
- `Split the work into multiple threads` - try two independent work streams and one person on integration.
|
|
16
|
+
- `Delegate a task and come back to check it in 10 minutes` - do not jump into every agent step; inspect the outcome instead.
|
|
17
|
+
- `Add the smallest useful verification` - create a RED test, tracer bullet, or simple browser check before the agent gets more autonomy.
|
|
18
|
+
|
|
19
|
+
## Advanced
|
|
20
|
+
|
|
21
|
+
- `Run 2 parallel Codex sessions` - split the problem into two independent parts and compare the outputs.
|
|
22
|
+
- `Create a deployment runbook` - even if the deploy stays simulated.
|
|
23
|
+
- `Write AGENTS.md for a subfolder` - show that context can be global and local at the same time.
|
|
24
|
+
- `Introduce garbage collection` - find one repeating form of chaos and turn it into a check, template, or rule.
|
|
25
|
+
|
|
26
|
+
## Meta
|
|
27
|
+
|
|
28
|
+
- `Move a durable rule from a prompt into AGENTS.md`.
|
|
29
|
+
- `Add a Done When section to every task`.
|
|
30
|
+
- `Write README for the team after rotation, not for yourself`.
|
|
31
|
+
- `Record what is actually verified` - distinguish done, in progress, and assumed.
|
|
32
|
+
|
|
33
|
+
## How to use the cards
|
|
34
|
+
|
|
35
|
+
- Before lunch, every team should complete at least one `Context Engineering` card.
|
|
36
|
+
- Before rotation, the repo should clearly show what was actually verified and what the next safe move is.
|
|
37
|
+
- After rotation, every team should complete at least one `Workflow` card.
|
|
38
|
+
- The other cards are optional. Treat them as stretch goals or prompts for what to improve next.
|
|
@@ -0,0 +1,88 @@
|
|
|
1
|
+
# Czech Editorial Review Checklist
|
|
2
|
+
|
|
3
|
+
Použijte tento checklist při revizi českého obsahu pro účastníky, hlavně pro:
|
|
4
|
+
|
|
5
|
+
- workshop agenda a presenter scenes
|
|
6
|
+
- pokyny pro participant room
|
|
7
|
+
- project briefs
|
|
8
|
+
- challenge cards
|
|
9
|
+
- setup, reference, recap, follow-up a learner-kit materiály
|
|
10
|
+
|
|
11
|
+
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.
|
|
12
|
+
|
|
13
|
+
## 1. Přirozenost češtiny
|
|
14
|
+
|
|
15
|
+
- Zní text jako přirozená čeština, ne jako překlad?
|
|
16
|
+
- Přečetl by to český developer bez škobrtnutí?
|
|
17
|
+
- Nejsou ve větách doslovné anglické kalky?
|
|
18
|
+
- Nejsou věty zbytečně dlouhé nebo toporné?
|
|
19
|
+
|
|
20
|
+
## 2. Kvalita míchání češtiny a angličtiny
|
|
21
|
+
|
|
22
|
+
- Zůstává česká věta česká?
|
|
23
|
+
- Jsou anglické termíny použité jen tam, kde jsou v developerské praxi opravdu přirozené?
|
|
24
|
+
- Není v textu náhodně promíchaná angličtina jen proto, že původní zdroj byl anglický?
|
|
25
|
+
- Když se méně známý anglický termín objevuje poprvé, je stručně ukotvený česky?
|
|
26
|
+
|
|
27
|
+
## 3. Jasnost instrukce
|
|
28
|
+
|
|
29
|
+
- Je z textu jasné, co má člověk udělat právě teď?
|
|
30
|
+
- Mají věty konkrétní slovesa jako `spusťte`, `zkontrolujte`, `doplňte`, `ověřte`?
|
|
31
|
+
- Neschovává se akce za abstraktní formulace typu „je vhodné realizovat“?
|
|
32
|
+
- Nejsou odstavce přeplněné více cíli najednou?
|
|
33
|
+
|
|
34
|
+
## 4. Workshop voice
|
|
35
|
+
|
|
36
|
+
- Zní text jako zkušený peer, ne jako marketér nebo korporát?
|
|
37
|
+
- Drží se text klidného, věcného a praktického tónu?
|
|
38
|
+
- Nezní text jako slide, slogan nebo generický AI obsah?
|
|
39
|
+
- Je z textu cítit disciplína workshopu: kontext zapsaný v repu, ověření, handoff?
|
|
40
|
+
|
|
41
|
+
## 5. Terminologická disciplína
|
|
42
|
+
|
|
43
|
+
- Jsou opakované workshop terms použité konzistentně?
|
|
44
|
+
- Neobjevují se slabé nebo matoucí fráze jen proto, že znějí „AI-ish“?
|
|
45
|
+
- Jsou výrazy jako `safe move`, `handoff`, `checkpoint`, `workflow`, `review`, `skill`, `runbook` použité záměrně, ne náhodně?
|
|
46
|
+
- Není stejná věc jednou česky a podruhé napůl anglicky bez důvodu?
|
|
47
|
+
|
|
48
|
+
## 6. Vyhněte se těmto signálům
|
|
49
|
+
|
|
50
|
+
Pokud se v textu objeví něco z toho, vraťte ho do editace:
|
|
51
|
+
|
|
52
|
+
- doslovný překlad anglické vazby
|
|
53
|
+
- česká věta s náhodně vloženými anglickými slovy mimo technické termíny
|
|
54
|
+
- korporátní nebo školometský tón
|
|
55
|
+
- fráze, které nic nekotví k akci
|
|
56
|
+
- generické AI obraty bez konkrétního významu
|
|
57
|
+
|
|
58
|
+
## 7. Spoken check
|
|
59
|
+
|
|
60
|
+
Přečtěte text nahlas nebo aspoň polohlasem.
|
|
61
|
+
|
|
62
|
+
Text vrátit do editace, pokud:
|
|
63
|
+
|
|
64
|
+
- se nedá říct plynule
|
|
65
|
+
- obsahuje nepřirozený slovosled
|
|
66
|
+
- zní tvrdě přeloženě
|
|
67
|
+
- potřebuje v hlavě „opravovat“, co tím autor asi myslel
|
|
68
|
+
|
|
69
|
+
## 8. Cross-locale check
|
|
70
|
+
|
|
71
|
+
Pokud text vznikal z anglického source:
|
|
72
|
+
|
|
73
|
+
- není to doslovný překlad?
|
|
74
|
+
- drží česká verze stejný význam, ale přirozenější formulací?
|
|
75
|
+
- není česká verze výrazně slabší, plošší nebo méně konkrétní než anglická?
|
|
76
|
+
- není anglický source sám o sobě slabý a nehodí se nejdřív přepsat?
|
|
77
|
+
|
|
78
|
+
## 9. Before publish
|
|
79
|
+
|
|
80
|
+
Před schválením českého textu pro účastníky musí být možné říct `ano` na všechno:
|
|
81
|
+
|
|
82
|
+
1. Je to přirozená čeština?
|
|
83
|
+
2. Rozumí tomu český developer napoprvé?
|
|
84
|
+
3. Je jasné, co má člověk udělat nebo pochopit?
|
|
85
|
+
4. Drží text workshop voice bez hype a bez korporátu?
|
|
86
|
+
5. Je míchání češtiny a angličtiny disciplinované?
|
|
87
|
+
6. Neobsahuje text slabé fráze nebo „AI slop“?
|
|
88
|
+
7. Obstojí text při čtení nahlas?
|
|
@@ -14,7 +14,7 @@ Nastavit energii dne a jasně pojmenovat, o čem workshop je.
|
|
|
14
14
|
|
|
15
15
|
- Nejde o soutěž v promptování.
|
|
16
16
|
- Jde o práci s agentem tak, aby po vás zůstával použitelný kontext.
|
|
17
|
-
- Odpolední část prověří, jestli repo
|
|
17
|
+
- Odpolední část prověří, jestli repo opravdu unese převzetí dalším týmem.
|
|
18
18
|
- Pokud nějaké důležité pravidlo žije jen v hovoru u stolu, ještě neexistuje.
|
|
19
19
|
|
|
20
20
|
### Co má facilitátor průběžně vracet
|
|
@@ -24,7 +24,7 @@ Nastavit energii dne a jasně pojmenovat, o čem workshop je.
|
|
|
24
24
|
- „Je `AGENTS.md` mapa, nebo už se z něj stává dump?“
|
|
25
25
|
- „Jaký je další bezpečný krok pro cizího člověka nebo agenta?“
|
|
26
26
|
|
|
27
|
-
## Build
|
|
27
|
+
## Build fáze 1
|
|
28
28
|
|
|
29
29
|
### Viditelný milestone board
|
|
30
30
|
|
|
@@ -32,14 +32,14 @@ Nastavit energii dne a jasně pojmenovat, o čem workshop je.
|
|
|
32
32
|
2. do 11:15 existuje `AGENTS.md`
|
|
33
33
|
3. do 11:30 existuje plan
|
|
34
34
|
4. do 11:45 existuje build/test command nebo tracer bullet
|
|
35
|
-
5. do 12:00 existuje první
|
|
35
|
+
5. do 12:00 existuje první ověřený výstup
|
|
36
36
|
|
|
37
37
|
### Role facilitátora
|
|
38
38
|
|
|
39
39
|
- nejdřív coach — ptejte se, co tým potřebuje a kde je zaseknutý
|
|
40
40
|
- pak mentor — pomozte s workflow nebo s nástrojem
|
|
41
41
|
- učitel až jako poslední možnost — krátce vysvětlete princip a vraťte tým do práce
|
|
42
|
-
-
|
|
42
|
+
- vracejte týmům hlavně artefakty, ze kterých se dá opravdu pracovat, ne celý backstage Harness Lab
|
|
43
43
|
|
|
44
44
|
### Na co se při obcházení dívat
|
|
45
45
|
|
|
@@ -84,7 +84,7 @@ Preferované checkpoint otázky:
|
|
|
84
84
|
|
|
85
85
|
- zviditelnit učení napříč týmy
|
|
86
86
|
- udělat z průběhu dne sérii krátkých checkpointů
|
|
87
|
-
- připomenout, že workflow je stejně důležité jako samotný
|
|
87
|
+
- připomenout, že workflow je stejně důležité jako samotný výsledek
|
|
88
88
|
- vracet týmy k tomu, že bez ověření jen akcelerují nejistotu
|
|
89
89
|
|
|
90
90
|
## Rotace
|
|
@@ -98,13 +98,13 @@ Preferované checkpoint otázky:
|
|
|
98
98
|
- Začněte `README`, `AGENTS.md` a planem.
|
|
99
99
|
- Needitujte hned první soubor, který otevřete.
|
|
100
100
|
- Nejprve si udělejte mapu: co funguje, co chybí, co je rizikové.
|
|
101
|
-
- Nejdřív napište vlastní diagnózu: co pomáhá, co chybí, co je rizikové a jaký je další
|
|
102
|
-
- Když tým neví, po čem sáhnout, vraťte ho k learner
|
|
101
|
+
- Nejdřív napište vlastní diagnózu: co pomáhá, co chybí, co je rizikové a jaký je další bezpečný krok.
|
|
102
|
+
- Když tým neví, po čem sáhnout, vraťte ho k learner kitu: `template-agents`, `reference`, `analyze-checklist` a challenge cards.
|
|
103
103
|
|
|
104
104
|
### Facilitační pointa k rotaci
|
|
105
105
|
|
|
106
106
|
- Frustrace je užitečný signál, pokud ukazuje na skrytý kontext nebo chybějící verifikaci.
|
|
107
|
-
- Nepomáhejte týmům ústním handoffem nahrazovat slabý
|
|
107
|
+
- Nepomáhejte týmům ústním handoffem nahrazovat slabý signál v repu.
|
|
108
108
|
- Pomáhejte jim pojmenovat, co musí být po rotaci dopsáno, zpřesněno nebo ověřeno.
|
|
109
109
|
|
|
110
110
|
## Reveal a reflexe
|
|
@@ -128,4 +128,4 @@ Otázky:
|
|
|
128
128
|
- Nehodnotíme, který tým byl lepší.
|
|
129
129
|
- Díváme se na systém: které signály pomáhají práci přežít handoff a které ji brzdí.
|
|
130
130
|
- Sbíráme konkrétní příklady, ne obecné dojmy.
|
|
131
|
-
- Každá opakující se bolest je kandidát na lepší template, challenge card nebo
|
|
131
|
+
- Každá opakující se bolest je kandidát na lepší template, challenge card nebo vodítko v blueprintu.
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
# Code Review Helper
|
|
2
|
+
|
|
3
|
+
## Problem
|
|
4
|
+
|
|
5
|
+
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.
|
|
6
|
+
|
|
7
|
+
Your task is to design a tool that turns a diff or change set into a usable review checklist.
|
|
8
|
+
|
|
9
|
+
## User stories
|
|
10
|
+
|
|
11
|
+
- As a reviewer, I want a fast checklist of risks, questions, and focus areas from a diff.
|
|
12
|
+
- As the author of a change, I want to know what I should verify before the review starts.
|
|
13
|
+
- As the team after rotation, I want to continue from the heuristics the original team already discovered instead of reinventing them.
|
|
14
|
+
|
|
15
|
+
## Architecture notes
|
|
16
|
+
|
|
17
|
+
- This can be a CLI, web app, or simple script. The important part is a clear `diff -> analysis -> checklist` flow.
|
|
18
|
+
- It must be obvious which inputs the tool expects and what it cannot evaluate reliably.
|
|
19
|
+
- Add a seed diff or `examples/` so the workflow can be checked locally.
|
|
20
|
+
- Separate heuristic from certainty clearly. The tool should help the reviewer, not pretend to be infallible.
|
|
21
|
+
|
|
22
|
+
## Done when
|
|
23
|
+
|
|
24
|
+
- The tool produces a review checklist from a seed diff.
|
|
25
|
+
- The output distinguishes certain findings from recommendations or hypotheses.
|
|
26
|
+
- It is clear how to add another rule or heuristic without a long onboarding pass.
|
|
27
|
+
- Another team can continue development within minutes without chaos.
|
|
28
|
+
|
|
29
|
+
## First step for the agent
|
|
30
|
+
|
|
31
|
+
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.
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
# DevToolbox CLI
|
|
2
|
+
|
|
3
|
+
## Problem
|
|
4
|
+
|
|
5
|
+
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.
|
|
6
|
+
|
|
7
|
+
Your task is to design a CLI tool that handles several common developer tasks in a way that survives handoff to another team.
|
|
8
|
+
|
|
9
|
+
## User stories
|
|
10
|
+
|
|
11
|
+
- As a developer, I want to turn a log or JSON blob into a readable format with one command.
|
|
12
|
+
- As a developer, I want to quickly find suspicious commits, branches, or changes without manually assembling git commands.
|
|
13
|
+
- As a team, I want both the commands and the way of working documented so another team can continue after rotation without confusion.
|
|
14
|
+
|
|
15
|
+
## Architecture notes
|
|
16
|
+
|
|
17
|
+
- Choose any language or framework, but the CLI must stay easy to run and easy to discover.
|
|
18
|
+
- Separate commands from helper utilities and configuration from the start.
|
|
19
|
+
- `AGENTS.md` should describe the build and test flow, output conventions, and the rules for future extension.
|
|
20
|
+
- A runbook for the team that inherits the project after lunch matters as much as a working command.
|
|
21
|
+
|
|
22
|
+
## Done when
|
|
23
|
+
|
|
24
|
+
- There are at least 3 useful commands or subcommands.
|
|
25
|
+
- `README` and `AGENTS.md` describe local execution and verification.
|
|
26
|
+
- It is clear where to add another command without breaking the project structure.
|
|
27
|
+
- A new team can add or fix another command within 10 minutes.
|
|
28
|
+
|
|
29
|
+
## First step for the agent
|
|
30
|
+
|
|
31
|
+
First design the minimal architecture that survives handoff. Start with `AGENTS.md`, then prepare a plan, and only then implement the first command.
|