@fernado03/zoo-flow 0.5.1 → 0.5.3
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 +3 -11
- package/bin/zoo-flow.js +7 -6
- package/package.json +1 -1
- package/templates/full/.roo/commands/explore.md +13 -13
- package/templates/full/.roo/commands/scaffold-context.md +13 -13
- package/templates/full/.roo/commands/setup-matt-pocock-skills.md +8 -8
- package/templates/full/.roo/commands/update-docs.md +22 -22
- package/templates/full/.roo/rules/04-context-economy.md +29 -29
- package/templates/full/.roo/rules-custom-orchestrator/00-routing.md +69 -69
- package/templates/full/.roo/rules-custom-orchestrator/01-delegation-message.md +62 -62
- package/templates/full/.roo/skills/engineering/grill-with-docs/CONTEXT-FORMAT.md +61 -63
- package/templates/full/.roo/skills/engineering/prototype/SKILL.md +37 -37
- package/templates/full/.roo/skills/engineering/scaffold-context/SKILL.md +152 -152
- package/templates/full/.roo/skills/engineering/to-prd/SKILL.md +57 -57
- package/templates/full/.roo/skills/in-progress/teach/SKILL.md +26 -7
- package/templates/full/.roomodes +47 -47
- package/templates/full/.zoo-flow/CONTEXT.md +8 -8
- package/templates/full/.zoo-flow/START_HERE.md +61 -61
- package/templates/full/.zoo-flow/docs/adr/0001-record-architecture-decisions.md +22 -22
- package/templates/full/.zoo-flow/evals/no-regression-checklist.md +26 -26
- package/templates/full/.zoo-flow/evals/routing-cases.md +203 -203
|
@@ -12,8 +12,10 @@ Stateful. Treat current directory as the teaching workspace.
|
|
|
12
12
|
## Files
|
|
13
13
|
|
|
14
14
|
- `MISSION.md` — why user wants this; grounds every decision. Format: `mission-format.md`.
|
|
15
|
-
- `GLOSSARY.md` — canonical terms; all output conforms. Format: `glossary-format.md`.
|
|
16
15
|
- `RESOURCES.md` — trusted knowledge + community sources. Format: `resources-format.md`.
|
|
16
|
+
- `./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.
|
|
17
|
+
- `./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.
|
|
18
|
+
- `NOTES.md` — A scratchpad for you to jot down user preferences, or working notes.
|
|
17
19
|
- `learning-records/NNNN-slug.md` — non-obvious lessons + prior knowledge. Format: `learning-record-format.md`.
|
|
18
20
|
|
|
19
21
|
## Triad
|
|
@@ -24,6 +26,16 @@ Stateful. Treat current directory as the teaching workspace.
|
|
|
24
26
|
|
|
25
27
|
Topic mix varies: theoretical → knowledge-heavy; practical → skills-heavy.
|
|
26
28
|
|
|
29
|
+
## Lessons
|
|
30
|
+
|
|
31
|
+
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.
|
|
32
|
+
|
|
33
|
+
A lesson should be beautiful — clean, readable typography and layout — since the user will return to these later to review.
|
|
34
|
+
|
|
35
|
+
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.
|
|
36
|
+
|
|
37
|
+
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.
|
|
38
|
+
|
|
27
39
|
## Mission first
|
|
28
40
|
|
|
29
41
|
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/`.
|
|
|
39
51
|
|
|
40
52
|
## Knowledge loop
|
|
41
53
|
|
|
54
|
+
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.
|
|
55
|
+
|
|
42
56
|
1. Pull from `RESOURCES.md`.
|
|
43
57
|
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.
|
|
44
58
|
3. Give one-line CLI command to open it.
|
|
45
59
|
4. Take questions; amend explainer or write a new one.
|
|
46
|
-
5. Once user clearly owns the term, add to `GLOSSARY.md`.
|
|
47
60
|
|
|
48
|
-
## Skills loop
|
|
49
61
|
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
62
|
+
## Skills
|
|
63
|
+
|
|
64
|
+
Skills should be taught through interactive lessons. There are several tools at your disposal:
|
|
65
|
+
|
|
66
|
+
- Interactive lessons, using quizzes and light in-browser tasks
|
|
67
|
+
- Lessons which guide the user through a list of real-world steps to take (for instance, yoga poses)
|
|
68
|
+
- In-agent quizzes, where you ask the user scenario-based questions about what they've learned
|
|
54
69
|
|
|
55
70
|
Every exercise closes a tight feedback loop.
|
|
56
71
|
|
|
57
72
|
## Wisdom
|
|
58
73
|
|
|
59
74
|
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.
|
|
75
|
+
|
|
76
|
+
## `NOTES.md`
|
|
77
|
+
|
|
78
|
+
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.
|
package/templates/full/.roomodes
CHANGED
|
@@ -1,47 +1,47 @@
|
|
|
1
|
-
{
|
|
2
|
-
"customModes": [
|
|
3
|
-
{
|
|
4
|
-
"slug": "code-tweaker",
|
|
5
|
-
"name": "⚡ Code Tweaker",
|
|
6
|
-
"roleDefinition": "You are an Execution Specialist. You implement, test, update docs, prototype, and commit when explicitly approved.",
|
|
7
|
-
"whenToUse": "Use for small or well-understood implementation, CSS/UI changes, TDD loops, documentation updates, runnable prototypes, known fixes, and approved commits. Do not make broad architecture decisions.",
|
|
8
|
-
"description": "Fast execution for tweaks, TDD, docs, prototypes, and approved commits.",
|
|
9
|
-
"customInstructions": "Use `.roo/rules-code-tweaker/` for mode-specific behavior.\n\nPermitted commands: /tweak, /tdd, /update-docs, /commit-and-document, /prototype, /scaffold-context.\n\nFollow `.roo/rules/01-command-protocol.md` to load and execute commands. Follow `.roo/rules/00-paths.md` for path safety. Follow `.roo/rules/03-manual-reply-protocol.md` when asking the user to choose, approve, or continue.\n\nIf assigned any other command, stop and report the routing error.",
|
|
10
|
-
"groups": [
|
|
11
|
-
"read",
|
|
12
|
-
"edit",
|
|
13
|
-
"command",
|
|
14
|
-
"mcp"
|
|
15
|
-
]
|
|
16
|
-
},
|
|
17
|
-
{
|
|
18
|
-
"slug": "system-architect",
|
|
19
|
-
"name": "🏗️ System Architect",
|
|
20
|
-
"roleDefinition": "You are a System Architect. You plan, diagnose, explore, triage, and design. You do NOT write implementation code.",
|
|
21
|
-
"whenToUse": "Use for unknown bugs, feature planning, architecture/refactor design, codebase exploration, and issue triage. Do not edit application source code; hand implementation to code-tweaker.",
|
|
22
|
-
"description": "Planning, diagnosis, refactor design, exploration, and triage.",
|
|
23
|
-
"customInstructions": "Use `.roo/rules-system-architect/` for mode-specific behavior.\n\nPermitted commands: /feature, /fix, /refactor, /explore, /triage.\n\nFollow `.roo/rules/01-command-protocol.md` to load and execute commands. Follow `.roo/rules/00-paths.md` for path safety. Follow `.roo/rules/03-manual-reply-protocol.md` when asking the user to choose, approve, or continue.\n\nIf assigned any other command, stop and report the routing error.",
|
|
24
|
-
"groups": [
|
|
25
|
-
"command",
|
|
26
|
-
"mcp",
|
|
27
|
-
"read",
|
|
28
|
-
[
|
|
29
|
-
"edit",
|
|
30
|
-
{
|
|
31
|
-
"fileRegex": "(.*\\.md$|^\\.scratch/.*|^docs/.*)",
|
|
32
|
-
"description": "Markdown files, .scratch/, and docs/ directories only"
|
|
33
|
-
}
|
|
34
|
-
]
|
|
35
|
-
]
|
|
36
|
-
},
|
|
37
|
-
{
|
|
38
|
-
"slug": "custom-orchestrator",
|
|
39
|
-
"name": "🪃 Custom Orchestrator",
|
|
40
|
-
"roleDefinition": "You are a PM and router. You choose workflows and delegate subtasks. You NEVER inspect implementation files, write code, or use switch_mode.",
|
|
41
|
-
"whenToUse": "Use as the default entry mode for normal user requests. Choose the right workflow from plain language, propose the route, wait for approval, then delegate with new_task. Use slash commands only when the user explicitly invokes them.",
|
|
42
|
-
"description": "Router that consults, delegates, and waits for user direction.",
|
|
43
|
-
"customInstructions": "Use `.roo/rules-custom-orchestrator/` for mode-specific behavior.\n\nRoute only these commands. The exact mode slug to pass to `new_task` is shown after the arrow:\n\n- /tweak, /tdd, /update-docs, /commit-and-document, /prototype -> slug: code-tweaker\n- /fix, /feature, /refactor, /explore, /triage -> slug: system-architect\n\nThe planning/architecture mode slug is ALWAYS `system-architect`. Never use `architect`.\n\nPropose, then wait for approval before delegating. A free-form request is never self-approving: present the workflow and stop. Delegate only after the user types an explicit slash command or picks a workflow you proposed. See `.roo/rules-custom-orchestrator/00-routing.md` (Approval gate).\n\nUse `new_task` only. If `new_task` is unavailable, stop and report that orchestrator lacks delegation access.\n\nFollow `.roo/rules/03-manual-reply-protocol.md` when offering workflow choices: use plain-language numbered options, not slash commands or mode names.\n\nNever use built-in/default modes for new_task. Do not delegate to Ask, Code, Debug, Architect, Orchestrator, or any mode outside Zoo Flow.\n\nFor analysis/review/inspection tasks, use slug: system-architect.\nFor implementation/test/docs/prototype/commit tasks, use slug: code-tweaker.",
|
|
44
|
-
"groups": []
|
|
45
|
-
}
|
|
46
|
-
]
|
|
47
|
-
}
|
|
1
|
+
{
|
|
2
|
+
"customModes": [
|
|
3
|
+
{
|
|
4
|
+
"slug": "code-tweaker",
|
|
5
|
+
"name": "⚡ Code Tweaker",
|
|
6
|
+
"roleDefinition": "You are an Execution Specialist. You implement, test, update docs, prototype, and commit when explicitly approved.",
|
|
7
|
+
"whenToUse": "Use for small or well-understood implementation, CSS/UI changes, TDD loops, documentation updates, runnable prototypes, known fixes, and approved commits. Do not make broad architecture decisions.",
|
|
8
|
+
"description": "Fast execution for tweaks, TDD, docs, prototypes, and approved commits.",
|
|
9
|
+
"customInstructions": "Use `.roo/rules-code-tweaker/` for mode-specific behavior.\n\nPermitted commands: /tweak, /tdd, /update-docs, /commit-and-document, /prototype, /scaffold-context.\n\nFollow `.roo/rules/01-command-protocol.md` to load and execute commands. Follow `.roo/rules/00-paths.md` for path safety. Follow `.roo/rules/03-manual-reply-protocol.md` when asking the user to choose, approve, or continue.\n\nIf assigned any other command, stop and report the routing error.",
|
|
10
|
+
"groups": [
|
|
11
|
+
"read",
|
|
12
|
+
"edit",
|
|
13
|
+
"command",
|
|
14
|
+
"mcp"
|
|
15
|
+
]
|
|
16
|
+
},
|
|
17
|
+
{
|
|
18
|
+
"slug": "system-architect",
|
|
19
|
+
"name": "🏗️ System Architect",
|
|
20
|
+
"roleDefinition": "You are a System Architect. You plan, diagnose, explore, triage, and design. You do NOT write implementation code.",
|
|
21
|
+
"whenToUse": "Use for unknown bugs, feature planning, architecture/refactor design, codebase exploration, and issue triage. Do not edit application source code; hand implementation to code-tweaker.",
|
|
22
|
+
"description": "Planning, diagnosis, refactor design, exploration, and triage.",
|
|
23
|
+
"customInstructions": "Use `.roo/rules-system-architect/` for mode-specific behavior.\n\nPermitted commands: /feature, /fix, /refactor, /explore, /triage.\n\nFollow `.roo/rules/01-command-protocol.md` to load and execute commands. Follow `.roo/rules/00-paths.md` for path safety. Follow `.roo/rules/03-manual-reply-protocol.md` when asking the user to choose, approve, or continue.\n\nIf assigned any other command, stop and report the routing error.",
|
|
24
|
+
"groups": [
|
|
25
|
+
"command",
|
|
26
|
+
"mcp",
|
|
27
|
+
"read",
|
|
28
|
+
[
|
|
29
|
+
"edit",
|
|
30
|
+
{
|
|
31
|
+
"fileRegex": "(.*\\.md$|^\\.scratch/.*|^docs/.*)",
|
|
32
|
+
"description": "Markdown files, .scratch/, and docs/ directories only"
|
|
33
|
+
}
|
|
34
|
+
]
|
|
35
|
+
]
|
|
36
|
+
},
|
|
37
|
+
{
|
|
38
|
+
"slug": "custom-orchestrator",
|
|
39
|
+
"name": "🪃 Custom Orchestrator",
|
|
40
|
+
"roleDefinition": "You are a PM and router. You choose workflows and delegate subtasks. You NEVER inspect implementation files, write code, or use switch_mode.",
|
|
41
|
+
"whenToUse": "Use as the default entry mode for normal user requests. Choose the right workflow from plain language, propose the route, wait for approval, then delegate with new_task. Use slash commands only when the user explicitly invokes them.",
|
|
42
|
+
"description": "Router that consults, delegates, and waits for user direction.",
|
|
43
|
+
"customInstructions": "Use `.roo/rules-custom-orchestrator/` for mode-specific behavior.\n\nRoute only these commands. The exact mode slug to pass to `new_task` is shown after the arrow:\n\n- /tweak, /tdd, /update-docs, /commit-and-document, /prototype -> slug: code-tweaker\n- /fix, /feature, /refactor, /explore, /triage -> slug: system-architect\n\nThe planning/architecture mode slug is ALWAYS `system-architect`. Never use `architect`.\n\nPropose, then wait for approval before delegating. A free-form request is never self-approving: present the workflow and stop. Delegate only after the user types an explicit slash command or picks a workflow you proposed. See `.roo/rules-custom-orchestrator/00-routing.md` (Approval gate).\n\nUse `new_task` only. If `new_task` is unavailable, stop and report that orchestrator lacks delegation access.\n\nFollow `.roo/rules/03-manual-reply-protocol.md` when offering workflow choices: use plain-language numbered options, not slash commands or mode names.\n\nNever use built-in/default modes for new_task. Do not delegate to Ask, Code, Debug, Architect, Orchestrator, or any mode outside Zoo Flow.\n\nFor analysis/review/inspection tasks, use slug: system-architect.\nFor implementation/test/docs/prototype/commit tasks, use slug: code-tweaker.",
|
|
44
|
+
"groups": []
|
|
45
|
+
}
|
|
46
|
+
]
|
|
47
|
+
}
|
|
@@ -1,8 +1,8 @@
|
|
|
1
|
-
# Context
|
|
2
|
-
<!-- Domain language, terms, and ambiguities for this project. Run /grill-with-docs to fill. -->
|
|
3
|
-
|
|
4
|
-
## Language
|
|
5
|
-
<!-- Term: 1-2 sentence definition. _Avoid_: aliases. -->
|
|
6
|
-
|
|
7
|
-
## Flagged ambiguities
|
|
8
|
-
<!-- "X means Y, not Z." -->
|
|
1
|
+
# Context
|
|
2
|
+
<!-- Domain language, terms, and ambiguities for this project. Run /grill-with-docs to fill. -->
|
|
3
|
+
|
|
4
|
+
## Language
|
|
5
|
+
<!-- Term: 1-2 sentence definition. _Avoid_: aliases. -->
|
|
6
|
+
|
|
7
|
+
## Flagged ambiguities
|
|
8
|
+
<!-- "X means Y, not Z." -->
|
|
@@ -1,61 +1,61 @@
|
|
|
1
|
-
# Zoo Flow Quick Start
|
|
2
|
-
|
|
3
|
-
## After installation
|
|
4
|
-
|
|
5
|
-
1. Start in Custom Orchestrator mode.
|
|
6
|
-
|
|
7
|
-
2. For an existing project, bootstrap project context:
|
|
8
|
-
|
|
9
|
-
`/scaffold-context`
|
|
10
|
-
|
|
11
|
-
This scans the codebase and proposes initial `.zoo-flow/CONTEXT.md` terms plus optional starter ADRs. It asks before writing anything.
|
|
12
|
-
|
|
13
|
-
3. If you plan to use PRDs, issue slicing, or triage, configure agent skill metadata:
|
|
14
|
-
|
|
15
|
-
`/setup-matt-pocock-skills`
|
|
16
|
-
|
|
17
|
-
This sets up issue tracker, triage label, and domain-doc configuration used by PRD, issue, and triage workflows.
|
|
18
|
-
|
|
19
|
-
4. After that, describe tasks normally. You do not need slash commands unless you already know the workflow.
|
|
20
|
-
|
|
21
|
-
## First-run checklist
|
|
22
|
-
|
|
23
|
-
- [ ] Custom Orchestrator mode is selected.
|
|
24
|
-
- [ ] Run `/scaffold-context` for an existing codebase.
|
|
25
|
-
- [ ] Run `/setup-matt-pocock-skills` if using PRDs, issue slicing, or triage.
|
|
26
|
-
- [ ] Start normal work by describing the task in plain language.
|
|
27
|
-
|
|
28
|
-
## Common requests
|
|
29
|
-
|
|
30
|
-
| What you want | What Zoo Flow will likely do |
|
|
31
|
-
|---|---|
|
|
32
|
-
| Small obvious edit | Small implementation workflow |
|
|
33
|
-
| Known localized fix | Small implementation workflow |
|
|
34
|
-
| Bug with unknown cause | Diagnosis workflow |
|
|
35
|
-
| New feature needing planning | Feature planning workflow |
|
|
36
|
-
| Improve structure without behavior change | Refactor workflow |
|
|
37
|
-
| Understand unfamiliar area | Exploration workflow |
|
|
38
|
-
| Write tests first | TDD workflow |
|
|
39
|
-
| Update docs | Documentation workflow |
|
|
40
|
-
| Commit finished work | Commit + journal workflow |
|
|
41
|
-
|
|
42
|
-
## What the orchestrator will show you
|
|
43
|
-
|
|
44
|
-
For normal requests, the orchestrator should recommend plain-language workflows, not slash commands.
|
|
45
|
-
|
|
46
|
-
Example:
|
|
47
|
-
|
|
48
|
-
> "This looks like a small implementation change. Proceed?"
|
|
49
|
-
|
|
50
|
-
Slash commands below are optional shortcuts for users who already know the workflow.
|
|
51
|
-
|
|
52
|
-
## Power-user shortcuts
|
|
53
|
-
|
|
54
|
-
You may type slash commands directly when you already know the workflow, but this is optional.
|
|
55
|
-
|
|
56
|
-
Examples:
|
|
57
|
-
|
|
58
|
-
- `/tweak change button copy`
|
|
59
|
-
- `/fix checkout crashes after payment`
|
|
60
|
-
- `/feature add team invitations`
|
|
61
|
-
- `/refactor simplify auth service`
|
|
1
|
+
# Zoo Flow Quick Start
|
|
2
|
+
|
|
3
|
+
## After installation
|
|
4
|
+
|
|
5
|
+
1. Start in Custom Orchestrator mode.
|
|
6
|
+
|
|
7
|
+
2. For an existing project, bootstrap project context:
|
|
8
|
+
|
|
9
|
+
`/scaffold-context`
|
|
10
|
+
|
|
11
|
+
This scans the codebase and proposes initial `.zoo-flow/CONTEXT.md` terms plus optional starter ADRs. It asks before writing anything.
|
|
12
|
+
|
|
13
|
+
3. If you plan to use PRDs, issue slicing, or triage, configure agent skill metadata:
|
|
14
|
+
|
|
15
|
+
`/setup-matt-pocock-skills`
|
|
16
|
+
|
|
17
|
+
This sets up issue tracker, triage label, and domain-doc configuration used by PRD, issue, and triage workflows.
|
|
18
|
+
|
|
19
|
+
4. After that, describe tasks normally. You do not need slash commands unless you already know the workflow.
|
|
20
|
+
|
|
21
|
+
## First-run checklist
|
|
22
|
+
|
|
23
|
+
- [ ] Custom Orchestrator mode is selected.
|
|
24
|
+
- [ ] Run `/scaffold-context` for an existing codebase.
|
|
25
|
+
- [ ] Run `/setup-matt-pocock-skills` if using PRDs, issue slicing, or triage.
|
|
26
|
+
- [ ] Start normal work by describing the task in plain language.
|
|
27
|
+
|
|
28
|
+
## Common requests
|
|
29
|
+
|
|
30
|
+
| What you want | What Zoo Flow will likely do |
|
|
31
|
+
|---|---|
|
|
32
|
+
| Small obvious edit | Small implementation workflow |
|
|
33
|
+
| Known localized fix | Small implementation workflow |
|
|
34
|
+
| Bug with unknown cause | Diagnosis workflow |
|
|
35
|
+
| New feature needing planning | Feature planning workflow |
|
|
36
|
+
| Improve structure without behavior change | Refactor workflow |
|
|
37
|
+
| Understand unfamiliar area | Exploration workflow |
|
|
38
|
+
| Write tests first | TDD workflow |
|
|
39
|
+
| Update docs | Documentation workflow |
|
|
40
|
+
| Commit finished work | Commit + journal workflow |
|
|
41
|
+
|
|
42
|
+
## What the orchestrator will show you
|
|
43
|
+
|
|
44
|
+
For normal requests, the orchestrator should recommend plain-language workflows, not slash commands.
|
|
45
|
+
|
|
46
|
+
Example:
|
|
47
|
+
|
|
48
|
+
> "This looks like a small implementation change. Proceed?"
|
|
49
|
+
|
|
50
|
+
Slash commands below are optional shortcuts for users who already know the workflow.
|
|
51
|
+
|
|
52
|
+
## Power-user shortcuts
|
|
53
|
+
|
|
54
|
+
You may type slash commands directly when you already know the workflow, but this is optional.
|
|
55
|
+
|
|
56
|
+
Examples:
|
|
57
|
+
|
|
58
|
+
- `/tweak change button copy`
|
|
59
|
+
- `/fix checkout crashes after payment`
|
|
60
|
+
- `/feature add team invitations`
|
|
61
|
+
- `/refactor simplify auth service`
|
|
@@ -1,22 +1,22 @@
|
|
|
1
|
-
# 1. Record architecture decisions
|
|
2
|
-
|
|
3
|
-
Date: <YYYY-MM-DD>
|
|
4
|
-
|
|
5
|
-
## Status
|
|
6
|
-
|
|
7
|
-
Accepted.
|
|
8
|
-
|
|
9
|
-
## Context
|
|
10
|
-
|
|
11
|
-
We need to record significant architectural decisions so future contributors
|
|
12
|
-
(including AI agents) understand why the project is shaped the way it is.
|
|
13
|
-
Use this template: copy the file, rename to `NNNN-slug.md`, fill the three
|
|
14
|
-
sections below.
|
|
15
|
-
|
|
16
|
-
## Decision
|
|
17
|
-
|
|
18
|
-
What we chose to do.
|
|
19
|
-
|
|
20
|
-
## Consequences
|
|
21
|
-
|
|
22
|
-
What becomes easier. What becomes harder. What we trade away.
|
|
1
|
+
# 1. Record architecture decisions
|
|
2
|
+
|
|
3
|
+
Date: <YYYY-MM-DD>
|
|
4
|
+
|
|
5
|
+
## Status
|
|
6
|
+
|
|
7
|
+
Accepted.
|
|
8
|
+
|
|
9
|
+
## Context
|
|
10
|
+
|
|
11
|
+
We need to record significant architectural decisions so future contributors
|
|
12
|
+
(including AI agents) understand why the project is shaped the way it is.
|
|
13
|
+
Use this template: copy the file, rename to `NNNN-slug.md`, fill the three
|
|
14
|
+
sections below.
|
|
15
|
+
|
|
16
|
+
## Decision
|
|
17
|
+
|
|
18
|
+
What we chose to do.
|
|
19
|
+
|
|
20
|
+
## Consequences
|
|
21
|
+
|
|
22
|
+
What becomes easier. What becomes harder. What we trade away.
|
|
@@ -1,26 +1,26 @@
|
|
|
1
|
-
# Zoo Flow No-Regression Checklist
|
|
2
|
-
|
|
3
|
-
Before accepting workflow changes, verify:
|
|
4
|
-
|
|
5
|
-
- [ ] Users can start in Custom Orchestrator and describe tasks normally.
|
|
6
|
-
- [ ] Slash commands are optional power-user overrides.
|
|
7
|
-
- [ ] No `/choose` command exists.
|
|
8
|
-
- [ ] Free-form requests require route proposal and user approval before delegation.
|
|
9
|
-
- [ ] Explicit slash commands route immediately.
|
|
10
|
-
- [ ] Orchestrator delegates only with `new_task`.
|
|
11
|
-
- [ ] Orchestrator delegates only to `code-tweaker` or `system-architect`.
|
|
12
|
-
- [ ] Code Tweaker does not make architecture decisions.
|
|
13
|
-
- [ ] System Architect does not edit application source code.
|
|
14
|
-
- [ ] CONTEXT.md / ADRs are read only when useful or command-required.
|
|
15
|
-
- [ ] Small known changes prefer the lightest safe workflow.
|
|
16
|
-
- [ ] High-risk changes keep approval gates.
|
|
17
|
-
- [ ] Commit and push still require explicit approval.
|
|
18
|
-
- [ ] Free-form routing recommendations use plain-language workflow names, not slash command names.
|
|
19
|
-
- [ ] Slash command names appear only when the user explicitly invokes them, asks for syntax, or inside internal delegation context.
|
|
20
|
-
- [ ] README links to `.zoo-flow/START_HERE.md`.
|
|
21
|
-
- [ ] README does not duplicate the full Zoo Flow onboarding guide.
|
|
22
|
-
- [ ] `.zoo-flow/START_HERE.md` remains the source of truth for first-run initialization.
|
|
23
|
-
- [ ] First-run guidance explains `/scaffold-context` and `/setup-matt-pocock-skills`.
|
|
24
|
-
- [ ] Custom Orchestrator never delegates to built-in/default Ask mode.
|
|
25
|
-
- [ ] Analysis, review, inspection, and safety-check subtasks route to `system-architect`.
|
|
26
|
-
- [ ] Implementation, tests, docs, prototype, and commit subtasks route to `code-tweaker`.
|
|
1
|
+
# Zoo Flow No-Regression Checklist
|
|
2
|
+
|
|
3
|
+
Before accepting workflow changes, verify:
|
|
4
|
+
|
|
5
|
+
- [ ] Users can start in Custom Orchestrator and describe tasks normally.
|
|
6
|
+
- [ ] Slash commands are optional power-user overrides.
|
|
7
|
+
- [ ] No `/choose` command exists.
|
|
8
|
+
- [ ] Free-form requests require route proposal and user approval before delegation.
|
|
9
|
+
- [ ] Explicit slash commands route immediately.
|
|
10
|
+
- [ ] Orchestrator delegates only with `new_task`.
|
|
11
|
+
- [ ] Orchestrator delegates only to `code-tweaker` or `system-architect`.
|
|
12
|
+
- [ ] Code Tweaker does not make architecture decisions.
|
|
13
|
+
- [ ] System Architect does not edit application source code.
|
|
14
|
+
- [ ] CONTEXT.md / ADRs are read only when useful or command-required.
|
|
15
|
+
- [ ] Small known changes prefer the lightest safe workflow.
|
|
16
|
+
- [ ] High-risk changes keep approval gates.
|
|
17
|
+
- [ ] Commit and push still require explicit approval.
|
|
18
|
+
- [ ] Free-form routing recommendations use plain-language workflow names, not slash command names.
|
|
19
|
+
- [ ] Slash command names appear only when the user explicitly invokes them, asks for syntax, or inside internal delegation context.
|
|
20
|
+
- [ ] README links to `.zoo-flow/START_HERE.md`.
|
|
21
|
+
- [ ] README does not duplicate the full Zoo Flow onboarding guide.
|
|
22
|
+
- [ ] `.zoo-flow/START_HERE.md` remains the source of truth for first-run initialization.
|
|
23
|
+
- [ ] First-run guidance explains `/scaffold-context` and `/setup-matt-pocock-skills`.
|
|
24
|
+
- [ ] Custom Orchestrator never delegates to built-in/default Ask mode.
|
|
25
|
+
- [ ] Analysis, review, inspection, and safety-check subtasks route to `system-architect`.
|
|
26
|
+
- [ ] Implementation, tests, docs, prototype, and commit subtasks route to `code-tweaker`.
|