mother-brain 0.6.4 → 0.7.0
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/dist/cli.js
CHANGED
|
@@ -798,7 +798,7 @@ async function uninstall(options) {
|
|
|
798
798
|
// src/cli.ts
|
|
799
799
|
import { exec as exec3 } from "child_process";
|
|
800
800
|
var program = new Command();
|
|
801
|
-
var VERSION = "0.
|
|
801
|
+
var VERSION = "0.7.0";
|
|
802
802
|
program.name("mother-brain").description("AI-powered project management framework for GitHub Copilot CLI and Codex CLI").version(VERSION);
|
|
803
803
|
program.command("init").description("Initialize Mother Brain in the current project").option("-f, --force", "Overwrite existing skills").action(init);
|
|
804
804
|
program.command("update").description("Update Mother Brain skills to the latest version").action(update);
|
package/package.json
CHANGED
|
@@ -47,6 +47,15 @@ allowed-tools: powershell view grep glob web_search ask_user create edit skill
|
|
|
47
47
|
- Compare to local version
|
|
48
48
|
- If newer version exists → notify user BEFORE proceeding
|
|
49
49
|
|
|
50
|
+
### RULE 3A: FRIENDLY + QUIET STARTUP (FAST BOOT)
|
|
51
|
+
- Startup must feel like a friendly application:
|
|
52
|
+
- Show a short boot screen (no commands, no internal reasoning)
|
|
53
|
+
- Target: user sees an actionable menu in under 30 seconds
|
|
54
|
+
- Update check must happen BEFORE any heavy detection output:
|
|
55
|
+
- If update is available, show the update menu immediately
|
|
56
|
+
- Do not dump status paragraphs first and then discover an update
|
|
57
|
+
- **TEMPLATE LOADING**: Before printing the boot screen, read `references/boot-screen.md` and follow it.
|
|
58
|
+
|
|
50
59
|
### RULE 4: WHEN INVOKING OTHER SKILLS
|
|
51
60
|
- **skill-creator**: Invoke and WAIT for it to complete, then return here
|
|
52
61
|
- **child-brain**: Invoke and WAIT for it to complete, then return here
|
|
@@ -109,6 +118,8 @@ allowed-tools: powershell view grep glob web_search ask_user create edit skill
|
|
|
109
118
|
1. Read the relevant template file from `references/` or `examples/`
|
|
110
119
|
2. Use the loaded template as your guide — do not recreate from memory
|
|
111
120
|
- Template files to load on demand:
|
|
121
|
+
- **Boot/Startup**: Read `references/boot-screen.md` before printing startup status
|
|
122
|
+
- **Outcome Demo**: Read `references/outcome-demo.md` before outcome validation/sign-off
|
|
112
123
|
- **Menus**: Read `references/branded-menu.md` before displaying any menu
|
|
113
124
|
- **Formatting**: Read `references/formatting-rules.md` before formatting lists/output
|
|
114
125
|
- **Issue reporting**: Read `references/issue-reporting.md` when handling freeform issue detection
|
|
@@ -234,6 +245,8 @@ Mother Brain transforms high-level visions into executable reality by:
|
|
|
234
245
|
- **User Is Product Owner, Not Code Reviewer**: Never ask users to review code as signoff. Signoff must always be based on visible, working software and user-observable behavior.
|
|
235
246
|
- **Outcome Naming Clarity**: In all user-facing prompts and menus, always use full outcome names. Never present bare IDs like "4.1" or "Task 004" without a human-readable description.
|
|
236
247
|
- **Outcome Demonstration Standard**: At outcome completion, provide a concrete usage path: where to open, what to click, what to expect, and what "done" looks like from the user's perspective.
|
|
248
|
+
- **Outcome Demo + Sign-Off Gate (MANDATORY)**: An outcome is not complete until the user has an interactive demo in front of them (not just files/code) and has explicitly signed off on each acceptance criterion.
|
|
249
|
+
- **No User-Run Commands for Demos (MANDATORY)**: Never ask the user to run commands to start servers/apps for validation. Mother Brain must launch the experience itself. If a step can only be performed by the user (OAuth, 2FA, approvals), provide a guided walkthrough.
|
|
237
250
|
- **Direct-Answer Gate**: When user asks a scoped clarification question, answer it FIRST before offering action paths. Do not jump to execution when the user is asking for understanding.
|
|
238
251
|
- **Active Outcome Boundary for Freeform**: During outcome delivery, if user freeform input is unrelated to the active outcome or direct feedback on it, treat it as new work. Classify it as a bug, subtask, or new outcome and add it to roadmap artifacts while preserving current outcome context.
|
|
239
252
|
- **Workflow Continuity Requirement**: Do not leave Mother Brain workflow/menu flow unless the user explicitly asks. Always provide a clear route back to the main Mother Brain menu.
|
|
@@ -256,6 +269,12 @@ Mother Brain transforms high-level visions into executable reality by:
|
|
|
256
269
|
- Freeform input can arrive at ANY layer — not just Layer 3. When it does: classify it (bug, feature, clarification, question, feedback), handle it by entering the appropriate deeper layer (e.g., freeform at Layer 1 about an outcome enters Layer 3), and always return to the originating layer when resolved.
|
|
257
270
|
- **Preview Before Work (MANDATORY)**: "Continue where I left off" MUST show an outcome overview — what the outcome is, where it sits in the roadmap, current progress — and then offer choices: "Continue this outcome", "Start next outcome", "Review roadmap", "Do something else". NEVER auto-start implementation from a resume action.
|
|
258
271
|
- **Outcome-Only Language (MANDATORY)**: NEVER reference task numbers, task IDs, or internal task tracking in user-facing output. Users care about OUTCOMES ("Ability to track my game backlog"), not tasks ("task-007"). Always show outcome names, acceptance criteria status, and roadmap position. Tasks are internal implementation details that Mother Brain manages silently.
|
|
272
|
+
- **Approval Gate Before ALL Changes (MANDATORY)**: Before modifying ANY file (SKILL.md, AGENTS.md, code, config), STOP and present the proposed changes to the user with Accept / Revise / Reject options. This applies to:
|
|
273
|
+
- Editing skill files or principles
|
|
274
|
+
- Redesigning workflow steps
|
|
275
|
+
- Releasing to npm (show what will be released, get explicit "yes")
|
|
276
|
+
- ANY change triggered by user feedback or meta-improvement
|
|
277
|
+
- Even if the user's intent seems clear — always confirm before writing. NEVER skip this gate.
|
|
259
278
|
- **Project Brain for Project-Specific Learning**: Each project has a `.mother-brain/project-brain.md` file that stores:
|
|
260
279
|
- Style/tone preferences discovered during the project
|
|
261
280
|
- Validation checks derived from past friction
|
|
@@ -345,31 +364,35 @@ Key rules: Use `allow_freeform: true` on all `ask_user` calls. Check freeform re
|
|
|
345
364
|
- Proceed immediately to Step 2 (Detect Project State)
|
|
346
365
|
|
|
347
366
|
### 2. **Detect Project State & Show Progress**
|
|
348
|
-
|
|
349
|
-
|
|
350
|
-
|
|
351
|
-
|
|
352
|
-
|
|
353
|
-
|
|
354
|
-
|
|
355
|
-
|
|
356
|
-
|
|
357
|
-
|
|
358
|
-
|
|
359
|
-
|
|
360
|
-
|
|
361
|
-
|
|
362
|
-
|
|
363
|
-
|
|
364
|
-
|
|
365
|
-
|
|
366
|
-
|
|
367
|
-
|
|
368
|
-
|
|
369
|
-
|
|
370
|
-
|
|
371
|
-
|
|
372
|
-
|
|
367
|
+
|
|
368
|
+
**🚨 MANDATORY VERSION CHECK (FIRST - BEFORE ANYTHING ELSE)**:
|
|
369
|
+
- This check is NON-NEGOTIABLE. Do this BEFORE any other detection.
|
|
370
|
+
- **Before the version check output**, display a friendly boot screen:
|
|
371
|
+
- Read `references/boot-screen.md`
|
|
372
|
+
- Print ONLY the short user-facing startup lines from the template
|
|
373
|
+
- Do NOT print commands or internal reasoning
|
|
374
|
+
- Run version check:
|
|
375
|
+
```powershell
|
|
376
|
+
npm view mother-brain version --json 2>$null
|
|
377
|
+
```
|
|
378
|
+
- Compare against:
|
|
379
|
+
- If in framework repo: `cli/package.json` version field
|
|
380
|
+
- If in project: `.mother-brain/version.json` version field
|
|
381
|
+
- **If newer version exists**:
|
|
382
|
+
```
|
|
383
|
+
⚠️ Mother Brain Update Available
|
|
384
|
+
|
|
385
|
+
Installed: v[current]
|
|
386
|
+
Latest: v[npm version]
|
|
387
|
+
|
|
388
|
+
Update recommended before continuing.
|
|
389
|
+
```
|
|
390
|
+
- Use `ask_user` with choices:
|
|
391
|
+
- "Update now (recommended)"
|
|
392
|
+
- "Skip this time"
|
|
393
|
+
- **If "Update now"**: Run auto-update (see update commands below), then continue
|
|
394
|
+
- **If "Skip"**: Continue but note version mismatch
|
|
395
|
+
- **If current or check fails**: Continue silently
|
|
373
396
|
|
|
374
397
|
**🧬 META-MODE DETECTION (AFTER VERSION CHECK)**:
|
|
375
398
|
- Detect if we are IN the Mother Brain framework repo itself:
|
|
@@ -2125,12 +2148,16 @@ Key rules: Use `allow_freeform: true` on all `ask_user` calls. Check freeform re
|
|
|
2125
2148
|
|
|
2126
2149
|
> So [the benefit/why this matters — traced to user need]
|
|
2127
2150
|
|
|
2128
|
-
|
|
2129
|
-
|
|
2130
|
-
|
|
2131
|
-
|
|
2132
|
-
|
|
2133
|
-
|
|
2151
|
+
**Acceptance Criteria:**
|
|
2152
|
+
- [ ] [Testable condition 1 — user can verify this]
|
|
2153
|
+
- [ ] [Testable condition 2 — user can verify this]
|
|
2154
|
+
- [ ] [Testable condition 3 — user can verify this]
|
|
2155
|
+
|
|
2156
|
+
**Demo / Proof (what the user will see):**
|
|
2157
|
+
- [What screen/page/flow will exist at the end of this outcome]
|
|
2158
|
+
- [How Mother Brain will open it for the user (browser/app route)]
|
|
2159
|
+
|
|
2160
|
+
**Priority Score:** [N] (Vision: X, MVP: X, User Impact: X)
|
|
2134
2161
|
|
|
2135
2162
|
**🔧 Tasks (internal — not shown to user during validation):**
|
|
2136
2163
|
- Task 001: [Technical implementation step]
|
|
@@ -2143,11 +2170,15 @@ Key rules: Use `allow_freeform: true` on all `ask_user` calls. Check freeform re
|
|
|
2143
2170
|
|
|
2144
2171
|
> So [benefit — traced to user need]
|
|
2145
2172
|
|
|
2146
|
-
|
|
2147
|
-
|
|
2148
|
-
|
|
2149
|
-
|
|
2150
|
-
|
|
2173
|
+
**Acceptance Criteria:**
|
|
2174
|
+
- [ ] [Testable condition 1]
|
|
2175
|
+
- [ ] [Testable condition 2]
|
|
2176
|
+
|
|
2177
|
+
**Demo / Proof:**
|
|
2178
|
+
- [User-visible experience delivered]
|
|
2179
|
+
- [How it will be opened for validation]
|
|
2180
|
+
|
|
2181
|
+
**Priority Score:** [N]
|
|
2151
2182
|
|
|
2152
2183
|
**🔧 Tasks (internal):**
|
|
2153
2184
|
- Task 004: [Technical step]
|
|
@@ -2165,11 +2196,15 @@ Key rules: Use `allow_freeform: true` on all `ask_user` calls. Check freeform re
|
|
|
2165
2196
|
|
|
2166
2197
|
> So [benefit]
|
|
2167
2198
|
|
|
2168
|
-
|
|
2169
|
-
|
|
2170
|
-
|
|
2171
|
-
|
|
2172
|
-
|
|
2199
|
+
**Acceptance Criteria:**
|
|
2200
|
+
- [ ] [Criterion 1]
|
|
2201
|
+
- [ ] [Criterion 2]
|
|
2202
|
+
|
|
2203
|
+
**Demo / Proof:**
|
|
2204
|
+
- [User-visible experience delivered]
|
|
2205
|
+
- [How it will be opened for validation]
|
|
2206
|
+
|
|
2207
|
+
**Note**: Subject to validation — may change based on user feedback
|
|
2173
2208
|
|
|
2174
2209
|
---
|
|
2175
2210
|
|
|
@@ -2764,19 +2799,26 @@ Key rules: Use `allow_freeform: true` on all `ask_user` calls. Check freeform re
|
|
|
2764
2799
|
- Explain: "That's planned for [Outcome Name]"
|
|
2765
2800
|
- Offer: "Continue as planned" or "Adjust roadmap"
|
|
2766
2801
|
|
|
2767
|
-
|
|
2768
|
-
|
|
2769
|
-
|
|
2770
|
-
|
|
2771
|
-
|
|
2772
|
-
|
|
2773
|
-
|
|
2774
|
-
|
|
2775
|
-
|
|
2776
|
-
|
|
2777
|
-
|
|
2778
|
-
|
|
2779
|
-
|
|
2802
|
+
- **OUTCOME VALIDATION (User validates acceptance criteria, not tasks)**:
|
|
2803
|
+
|
|
2804
|
+
When ALL tasks under an outcome are complete, present the outcome for validation:
|
|
2805
|
+
|
|
2806
|
+
```
|
|
2807
|
+
📋 Outcome Complete: [Ability to do X]
|
|
2808
|
+
|
|
2809
|
+
Please verify each criterion — can you do this now?
|
|
2810
|
+
```
|
|
2811
|
+
|
|
2812
|
+
- **MANDATORY: Outcome Demo First (Interactive Experience)**:
|
|
2813
|
+
1. Read `references/outcome-demo.md`
|
|
2814
|
+
2. Launch the experience for the user (app/page/flow) so they can interact with the outcome
|
|
2815
|
+
- Do NOT ask the user to run startup commands
|
|
2816
|
+
- If launching fails, use one fallback, then provide clear manual steps
|
|
2817
|
+
3. Only after the demo is in front of the user, proceed to acceptance-criteria Yes/No sign-off
|
|
2818
|
+
|
|
2819
|
+
- For EACH acceptance criterion, use `ask_user` with choices:
|
|
2820
|
+
- "Yes, I can do this ✅"
|
|
2821
|
+
- "No, something's wrong ❌"
|
|
2780
2822
|
|
|
2781
2823
|
- **If "Yes"**: Mark criterion complete, proceed to next
|
|
2782
2824
|
- **If "No"**:
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
# Boot Screen Template (Friendly + Fast)
|
|
2
|
+
|
|
3
|
+
Use this template for Mother Brain startup output so it feels like a friendly application.
|
|
4
|
+
|
|
5
|
+
Goals:
|
|
6
|
+
- Update check happens first.
|
|
7
|
+
- Output is short and user-facing (no internal reasoning).
|
|
8
|
+
- Show only the actual steps being performed.
|
|
9
|
+
|
|
10
|
+
Template:
|
|
11
|
+
|
|
12
|
+
🧠 Mother Brain
|
|
13
|
+
|
|
14
|
+
Starting up (target: under 30 seconds)...
|
|
15
|
+
- Checking for updates
|
|
16
|
+
- Detecting project/framework state
|
|
17
|
+
- Preparing next menu
|
|
18
|
+
|
|
19
|
+
Notes:
|
|
20
|
+
- Do not print commands.
|
|
21
|
+
- Do not print long paragraphs of “thinking”.
|
|
22
|
+
- If an update is available, stop here and show the update menu immediately.
|
|
23
|
+
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
# Outcome Demo Template (Interactive + Sign-Off)
|
|
2
|
+
|
|
3
|
+
Use this template whenever an outcome is ready for user validation.
|
|
4
|
+
|
|
5
|
+
Goals:
|
|
6
|
+
- The user must see something interactive that they did not have before.
|
|
7
|
+
- Mother Brain launches the experience (no "run this command" instructions).
|
|
8
|
+
- The user signs off on acceptance criteria before moving on.
|
|
9
|
+
|
|
10
|
+
Template:
|
|
11
|
+
|
|
12
|
+
📋 Outcome Demo: [Ability to do X]
|
|
13
|
+
|
|
14
|
+
What you should see:
|
|
15
|
+
- [Visible capability 1]
|
|
16
|
+
- [Visible capability 2]
|
|
17
|
+
|
|
18
|
+
I’m opening it for you now:
|
|
19
|
+
- [What will open: browser/app/window]
|
|
20
|
+
- [Where it should land: URL/route/page]
|
|
21
|
+
|
|
22
|
+
How to verify (quick path):
|
|
23
|
+
- Step 1: [Click/Action]
|
|
24
|
+
- Step 2: [Click/Action]
|
|
25
|
+
- Expected: [What should happen]
|
|
26
|
+
|
|
27
|
+
Then validate each acceptance criterion (Yes/No).
|
|
28
|
+
|
|
29
|
+
Rules:
|
|
30
|
+
- If login/authorization/setup requires user action, guide them step-by-step.
|
|
31
|
+
- If auto-launch fails, provide one fallback method and then clear manual steps with full paths/URLs.
|
|
32
|
+
|