@fernado03/zoo-flow 0.5.1 → 0.5.2

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@fernado03/zoo-flow",
   "description": "Workflow control plane for Zoo Code.",
-  "version": "0.5.1",
+  "version": "0.5.2",
   "type": "module",
   "bin": {
     "zoo-flow": "bin/zoo-flow.js"

package/templates/full/.roo/skills/engineering/grill-with-docs/CONTEXT-FORMAT.md

@@ -20,11 +20,9 @@ _Avoid_: Purchase, transaction
 
 ## Rules
 
-- MUST pick canonical term; aliases under `_Avoid_`.
-- MUST flag ambiguity + resolution.
+- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others under `_Avoid`.
 - Define term in 1–2 sentences: what it is, not behavior.
 - Include domain terms only; exclude generic programming terms.
-- Group under headings when useful.
 
 ## Slots
 

package/templates/full/.roo/skills/engineering/to-prd/SKILL.md

@@ -12,8 +12,8 @@ RULE: Do not interview user. Synthesize current context.
 ## Process
 
 1. Explore repo if needed; use glossary; respect ADRs.
-2. Sketch test seams. Prefer existing seams; use highest seam possible. Propose new seams at highest point.
-3. Check with user: seams match expectations?
+2. Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can.
+3. Check with the user that these seams match their expectations.
 4. Write PRD.
 5. Publish to issue tracker.
 6. Apply `ready-for-agent`.

package/templates/full/.roo/skills/in-progress/teach/SKILL.md

@@ -12,8 +12,10 @@ Stateful. Treat current directory as the teaching workspace.
 ## Files
 
 - `MISSION.md` — why user wants this; grounds every decision. Format: `mission-format.md`.
-- `GLOSSARY.md` — canonical terms; all output conforms. Format: `glossary-format.md`.
 - `RESOURCES.md` — trusted knowledge + community sources. Format: `resources-format.md`.
+- `./reference/*.html` — A directory of reference materials. These are the compressed learnings from the lessons — cheat sheets, reference algorithms, syntax, yoga poses, glossaries. They are the raw units of learning. They should be beautiful documents which print out well, and are designed for quick reference.
+- `./lessons/*.html` — A directory of lessons. A lesson is a single, self-contained HTML output that teaches one tightly-scoped thing tied to the mission. This is the primary unit of teaching in the workspace.
+- `NOTES.md` — A scratchpad for you to jot down user preferences, or working notes.
 - `learning-records/NNNN-slug.md` — non-obvious lessons + prior knowledge. Format: `learning-record-format.md`.
 
 ## Triad
@@ -24,6 +26,16 @@ Stateful. Treat current directory as the teaching workspace.
 
 Topic mix varies: theoretical → knowledge-heavy; practical → skills-heavy.
 
+## Lessons
+
+A lesson is the main thing you produce — the unit in which knowledge and skills reach the user. Each lesson is one self-contained HTML file, saved to `./lessons/` and titled `0001-<dash-case-name>.html`, where the number increments each time.
+
+A lesson should be beautiful — clean, readable typography and layout — since the user will return to these later to review.
+
+The lesson should teach ONE THING only. It should be completable very quickly, but give the user a tangible win that they can build on. It should be directly tied to the mission, and should be in the user's zone of proximal development.
+
+Make opening a lesson as easy as possible — ideally a single CLI command the user can run to open the HTML file in their browser.
+
 ## Mission first
 
 If `MISSION.md` missing or vague, interview before teaching. No mission = no grounding, abstract exercises, no signal for what's next.
@@ -39,21 +51,28 @@ User says "I already know X" → record in `learning-records/`.
 
 ## Knowledge loop
 
+Knowledge should first be gathered from trusted resources. Use `RESOURCES.md` to keep track of them. Lessons should be littered with citations - links to external resources to back up any claim made. This increases the trustworthiness of the lesson, and gives the user a path to acquire more knowledge if they want to go deeper.
+
 1. Pull from `RESOURCES.md`.
 2. Write HTML explainer to local file. Beautiful, glossary-correct. Litter with citations linking external resources backing every claim. Interactive: "try this" callouts to apply the knowledge.
 3. Give one-line CLI command to open it.
 4. Take questions; amend explainer or write a new one.
-5. Once user clearly owns the term, add to `GLOSSARY.md`.
 
-## Skills loop
 
-Tools:
-- Interactive HTML explainers with quizzes / in-browser drills.
-- Step-through HTML guides for real-world tasks.
-- In-agent scenario quizzes.
+## Skills
+
+Skills should be taught through interactive lessons. There are several tools at your disposal:
+
+- Interactive lessons, using quizzes and light in-browser tasks
+- Lessons which guide the user through a list of real-world steps to take (for instance, yoga poses)
+- In-agent quizzes, where you ask the user scenario-based questions about what they've learned
 
 Every exercise closes a tight feedback loop.
 
 ## Wisdom
 
 Default: attempt an answer, then route to a high-reputation community from `RESOURCES.md`. If user opted out of communities, record it in `RESOURCES.md` and stop suggesting.
+
+## `NOTES.md`
+
+The user will sometimes express preferences of how they want to be taught, or things you should keep in mind. This is the place to record those preferences, so you can refer back to them when designing lessons or working with the user.