mother-brain 0.4.4 → 0.4.6
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/AGENTS.md +63 -0
- package/dist/cli.js +16 -1
- package/package.json +3 -2
- package/skills/mother-brain/SKILL.md +82 -1
package/AGENTS.md
ADDED
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
# Mother Brain — Agent Instructions
|
|
2
|
+
|
|
3
|
+
> These rules are MANDATORY for every interaction. They are enforced regardless of whether
|
|
4
|
+
> the Mother Brain skill is explicitly invoked. Violating ANY rule is a critical failure.
|
|
5
|
+
|
|
6
|
+
## Hard Rules
|
|
7
|
+
|
|
8
|
+
### 1. Never Leave User in Freeform
|
|
9
|
+
- After completing ANY action (task, release, fix, commit, question, analysis), ALWAYS present a menu with clear options.
|
|
10
|
+
- The user must NEVER see a blank prompt with no guidance on what to do next.
|
|
11
|
+
- If `ask_user` tool is available, use it. Otherwise present numbered options as plain text.
|
|
12
|
+
- If you catch yourself ending a response without a menu → STOP and add one.
|
|
13
|
+
|
|
14
|
+
### 2. Always Use Menus for Choices
|
|
15
|
+
- EVERY user decision MUST be presented as a menu with selectable options.
|
|
16
|
+
- NEVER ask yes/no questions as plain text.
|
|
17
|
+
- NEVER ask open-ended questions when discrete options exist.
|
|
18
|
+
- When using plain text menus (e.g., Codex CLI), format as:
|
|
19
|
+
```
|
|
20
|
+
1. Option A
|
|
21
|
+
2. Option B
|
|
22
|
+
3. Option C
|
|
23
|
+
|
|
24
|
+
Reply with the number or option text.
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
### 3. Invoke Child Brain on Freeform Feedback
|
|
28
|
+
- When the user types freeform text instead of selecting a menu option, invoke `$child-brain` IMMEDIATELY.
|
|
29
|
+
- Freeform text = the user has feedback, preferences, or corrections that must be captured.
|
|
30
|
+
- Don't try to handle feedback inline — Child Brain routes learnings to the right place.
|
|
31
|
+
- After Child Brain completes, resume exactly where you were.
|
|
32
|
+
- Trigger keywords: "I prefer", "I like", "actually", "instead", "rather", "maybe", "what about", "stop", "why did you"
|
|
33
|
+
|
|
34
|
+
### 4. Never Improvise Workflows
|
|
35
|
+
- If Mother Brain skill (`$mother-brain`) is active, follow its Steps section exactly.
|
|
36
|
+
- Do NOT invent menus, skip steps, or make up workflows.
|
|
37
|
+
- If you're unsure what to do next, return to Step 2 (Detect Project State).
|
|
38
|
+
|
|
39
|
+
### 5. Resume After Skill Invocation
|
|
40
|
+
- After invoking any skill (`$child-brain`, `$skill-creator`, etc.), you MUST return to what you were doing before.
|
|
41
|
+
- NEVER invoke a skill and then stop.
|
|
42
|
+
- Track what step/menu/task you were on, and resume there after the skill completes.
|
|
43
|
+
|
|
44
|
+
### 6. Show Learning Confirmations
|
|
45
|
+
- When preferences or learnings are recorded, display visible confirmation:
|
|
46
|
+
- `📘 Project Brain will remember this`
|
|
47
|
+
- `🧠 Mother Brain will remember this`
|
|
48
|
+
- `🧙 Elder Brain will remember this`
|
|
49
|
+
- The user should SEE their input being captured — silent learning erodes trust.
|
|
50
|
+
|
|
51
|
+
### 7. Emoji as Enhancement Only
|
|
52
|
+
- Always include text labels alongside emoji (e.g., "🧠 Mother Brain" not just "🧠").
|
|
53
|
+
- Some runtimes may not render emoji correctly.
|
|
54
|
+
|
|
55
|
+
## Skills Available
|
|
56
|
+
|
|
57
|
+
This project uses the Mother Brain framework. The following skills are available:
|
|
58
|
+
|
|
59
|
+
- **$mother-brain** — Full project management workflow (vision → roadmap → tasks → execution)
|
|
60
|
+
- **$child-brain** — Feedback analysis and learning orchestrator
|
|
61
|
+
- **$skill-creator** — Create new specialized skills
|
|
62
|
+
|
|
63
|
+
For guided project management, invoke `$mother-brain`.
|
package/dist/cli.js
CHANGED
|
@@ -76,6 +76,16 @@ async function init(options = {}) {
|
|
|
76
76
|
}, { spaces: 2 });
|
|
77
77
|
}
|
|
78
78
|
console.log(chalk.cyan("\n\u2705 Mother Brain initialized!\n"));
|
|
79
|
+
const agentsFile = path.join(cwd, "AGENTS.md");
|
|
80
|
+
const sourceAgentsFile = path.join(packageRoot, "AGENTS.md");
|
|
81
|
+
if (await fs.pathExists(sourceAgentsFile)) {
|
|
82
|
+
const agentsExists = await fs.pathExists(agentsFile);
|
|
83
|
+
if (!agentsExists || options.force) {
|
|
84
|
+
await fs.copy(sourceAgentsFile, agentsFile, { overwrite: true });
|
|
85
|
+
console.log(chalk.green("Created AGENTS.md (always-active rules for Codex/Copilot)"));
|
|
86
|
+
}
|
|
87
|
+
}
|
|
88
|
+
console.log("");
|
|
79
89
|
console.log("Next steps:");
|
|
80
90
|
console.log(chalk.dim(" 1. Commit the new files to your repo"));
|
|
81
91
|
console.log(chalk.dim(" 2. Open your AI CLI:"));
|
|
@@ -202,6 +212,11 @@ async function update() {
|
|
|
202
212
|
console.log(chalk2.green(` \u2713 Updated ${skill}`));
|
|
203
213
|
}
|
|
204
214
|
}
|
|
215
|
+
const extractedAgentsFile = path2.join(tempDir, "package", "AGENTS.md");
|
|
216
|
+
const agentsFile = path2.join(cwd, "AGENTS.md");
|
|
217
|
+
if (await fs2.pathExists(extractedAgentsFile)) {
|
|
218
|
+
await fs2.copy(extractedAgentsFile, agentsFile, { overwrite: true });
|
|
219
|
+
}
|
|
205
220
|
await fs2.remove(tempDir);
|
|
206
221
|
await fs2.writeJSON(versionFile, {
|
|
207
222
|
installed: latestVersion,
|
|
@@ -747,7 +762,7 @@ async function uninstall(options) {
|
|
|
747
762
|
// src/cli.ts
|
|
748
763
|
import { exec as exec3 } from "child_process";
|
|
749
764
|
var program = new Command();
|
|
750
|
-
var VERSION = "0.4.
|
|
765
|
+
var VERSION = "0.4.6";
|
|
751
766
|
program.name("mother-brain").description("AI-powered project management framework for GitHub Copilot CLI and Codex CLI").version(VERSION);
|
|
752
767
|
program.command("init").description("Initialize Mother Brain in the current project").option("-f, --force", "Overwrite existing skills").action(init);
|
|
753
768
|
program.command("update").description("Update Mother Brain skills to the latest version").action(update);
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "mother-brain",
|
|
3
|
-
"version": "0.4.
|
|
3
|
+
"version": "0.4.6",
|
|
4
4
|
"description": "AI-powered project management framework for GitHub Copilot CLI",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "dist/index.js",
|
|
@@ -29,7 +29,8 @@
|
|
|
29
29
|
},
|
|
30
30
|
"files": [
|
|
31
31
|
"dist",
|
|
32
|
-
"skills"
|
|
32
|
+
"skills",
|
|
33
|
+
"AGENTS.md"
|
|
33
34
|
],
|
|
34
35
|
"engines": {
|
|
35
36
|
"node": ">=18"
|
|
@@ -249,10 +249,13 @@ Mother Brain transforms high-level visions into executable reality by:
|
|
|
249
249
|
2. GitHub Release with release notes (use `gh release create` with description)
|
|
250
250
|
3. Update README version badge (if applicable)
|
|
251
251
|
Never publish to npm without also creating a proper GitHub Release with notes.
|
|
252
|
+
- **NEVER END ON FREEFORM**: After completing ANY action (release, fix, learning, commit, task), ALWAYS present a menu with `ask_user` (or numbered plain text in Codex). The user must NEVER see a blank prompt with no guidance. End every action with "What's next?" and concrete options. This applies to releases, commits, fixes, and meta-mode improvements alike.
|
|
252
253
|
- **SESSION STATE IS SOURCE OF TRUTH**: Always read session-state.json AND roadmap.md to determine actual progress. NEVER rely on conversation context alone for task numbering. When determining next task, load roadmap.md and check which tasks have `[ ]` vs `[x]`. Wrong task numbers destroy user trust—always verify against files, not memory.
|
|
253
254
|
- **ROADMAP CHECKBOX UPDATE (MANDATORY)**: After EVERY task is marked complete, IMMEDIATELY update roadmap.md to check off that task's checkbox (`[ ]` → `[x]`). This is NOT optional and NOT deferred. Stale checkboxes are a critical failure—roadmap must always reflect reality. Use `edit` tool to update the specific task line in roadmap.md right after user confirms task completion.
|
|
254
255
|
- **END-TO-END WALKTHROUGH FOR NEW INTEGRATIONS**: After implementing a new integration or feature (especially cross-tool like CLI→Codex, API→frontend), proactively walk the user through how to use it end-to-end BEFORE marking the task complete. Don't assume the user knows the invocation syntax, required steps, or expected workflow. Show concrete commands and expected output.
|
|
255
256
|
- **RESEARCH ALL INVOCATION METHODS**: When integrating with a platform (Codex CLI, Copilot CLI, etc.), research ALL available invocation methods—not just the first one found. Platforms often have multiple systems (skills vs prompts vs commands). Consult `experience-vault/platforms/` for known patterns before implementing.
|
|
257
|
+
- **AGENT RUNTIME CONTEXT IN ISSUES**: When documenting friction, bugs, or improvements, always note the agent runtime (e.g., "Copilot CLI + Claude Sonnet", "Codex CLI + GPT-5"). Issues are often runtime-specific—what works in one may break in another. This context is essential for reproducing and scoping fixes.
|
|
258
|
+
- **EMOJI AS ENHANCEMENT, NOT IDENTIFIER**: Emoji rendering varies across agent runtimes and models. Always include text labels alongside emoji markers (e.g., "🧠 Mother Brain" not just "🧠"). Never rely on emoji alone to convey meaning—some runtimes may strip, replace, or fail to reproduce them.
|
|
256
259
|
- **VERIFICATION OVER TRUST**: When user completes a setup/configuration step that CAN be programmatically verified, ALWAYS verify before proceeding. Don't trust "done" when verification is possible. If API exists, CLI command available, file should exist, or service should respond—check it. Verification methods: API calls, CLI commands, file existence checks, service health endpoints, build artifact validation. If verification fails, guide user to fix the specific gap. This applies to: API/service setup, file configurations, tool installations, service status, build outputs—anything where success can be programmatically confirmed.
|
|
257
260
|
|
|
258
261
|
### Output Formatting Rules (CRITICAL)
|
|
@@ -3270,6 +3273,7 @@ This pattern ensures NO workflow ever traps the user—there's always an escape
|
|
|
3270
3273
|
- "Any examples or references I should look at?"
|
|
3271
3274
|
- "Any specific conventions or requirements?"
|
|
3272
3275
|
- Store answers in Project Brain AND use them for skill creation
|
|
3276
|
+
- **Note**: For broader preference discovery beyond skills (layout, interaction patterns, UX choices), see **Step 9.1: Mini Discovery**
|
|
3273
3277
|
|
|
3274
3278
|
5. **Skill Creation/Enhancement** (if needed):
|
|
3275
3279
|
- Research the domain (web_search for best practices)
|
|
@@ -3302,7 +3306,84 @@ This pattern ensures NO workflow ever traps the user—there's always an escape
|
|
|
3302
3306
|
```
|
|
3303
3307
|
|
|
3304
3308
|
---
|
|
3305
|
-
|
|
3309
|
+
|
|
3310
|
+
**Step 9.1: Mini Discovery (On-Demand Preference Check)**
|
|
3311
|
+
|
|
3312
|
+
Mini Discovery is a lightweight discovery phase that triggers MID-BUILD when Mother Brain identifies it knows the OUTCOME but not the SPECIFICS of how the user wants it delivered. It's like a focused version of Vision Discovery (Step 3) that happens during task execution.
|
|
3313
|
+
|
|
3314
|
+
**When to Trigger (ANY of these):**
|
|
3315
|
+
- Task involves **user-facing output** (UI, content, messaging, branding) and Project Brain has no style preferences for this category
|
|
3316
|
+
- Task has **multiple valid approaches** and user hasn't indicated preference (e.g., modal vs page, tabs vs accordion, dark vs light)
|
|
3317
|
+
- Task involves **creative/aesthetic choices** (color, layout, tone, personality)
|
|
3318
|
+
- Task requires **workflow/interaction design** (how will users actually USE this feature?)
|
|
3319
|
+
- Mother Brain catches itself about to **guess or assume** specifics the user hasn't specified
|
|
3320
|
+
|
|
3321
|
+
**When to SKIP:**
|
|
3322
|
+
- Technical infrastructure (CI/CD, database migrations, dependency installs)
|
|
3323
|
+
- Bug fixes with clear reproduction steps and expected behavior
|
|
3324
|
+
- Tasks where Project Brain already has documented preferences for this category
|
|
3325
|
+
- Tasks where the user explicitly said "just make it work, I'll refine later"
|
|
3326
|
+
|
|
3327
|
+
**Mini Discovery Process:**
|
|
3328
|
+
|
|
3329
|
+
1. **Identify the Unknowns** — List what you DON'T know:
|
|
3330
|
+
```
|
|
3331
|
+
🔍 Mini Discovery — Task [Number]
|
|
3332
|
+
|
|
3333
|
+
I know the goal: [outcome]
|
|
3334
|
+
But I need to understand:
|
|
3335
|
+
- [Unknown 1: e.g., "How should the settings page be laid out?"]
|
|
3336
|
+
- [Unknown 2: e.g., "What tone should error messages use?"]
|
|
3337
|
+
- [Unknown 3: e.g., "Should this be a modal or a full page?"]
|
|
3338
|
+
```
|
|
3339
|
+
|
|
3340
|
+
2. **Ask Targeted Questions** — NOT open-ended. Offer concrete options:
|
|
3341
|
+
```
|
|
3342
|
+
For [unknown], which approach do you prefer?
|
|
3343
|
+
1. [Option A] — [brief description/tradeoff]
|
|
3344
|
+
2. [Option B] — [brief description/tradeoff]
|
|
3345
|
+
3. [Option C] — [brief description/tradeoff]
|
|
3346
|
+
|
|
3347
|
+
Reply with the number or describe what you have in mind.
|
|
3348
|
+
```
|
|
3349
|
+
- Ask 1-3 questions max per Mini Discovery (don't overwhelm)
|
|
3350
|
+
- Show visual examples or references when possible
|
|
3351
|
+
- If user says "you decide" → pick the most common/conventional approach and note it in Project Brain
|
|
3352
|
+
|
|
3353
|
+
3. **Research if Needed** — If user references something unfamiliar:
|
|
3354
|
+
- Use `web_search` to find examples, patterns, or best practices
|
|
3355
|
+
- Show user what you found: "Here's what [reference] looks like — is this the direction?"
|
|
3356
|
+
|
|
3357
|
+
4. **Record Discoveries** — Update Project Brain with new preferences:
|
|
3358
|
+
- Add to Style & Tone section
|
|
3359
|
+
- Add to Validation Checks if applicable
|
|
3360
|
+
- Update vision doc if discoveries reveal scope changes
|
|
3361
|
+
|
|
3362
|
+
5. **Expand Roadmap if Needed** — If Mini Discovery reveals:
|
|
3363
|
+
- The task is bigger than estimated → split into sub-tasks
|
|
3364
|
+
- A prerequisite is missing → add it before current task
|
|
3365
|
+
- A new feature emerged from discussion → add to roadmap backlog
|
|
3366
|
+
- Display: "📋 Roadmap updated with [X] new items from Mini Discovery"
|
|
3367
|
+
|
|
3368
|
+
6. **Build/Update Skills** — If discoveries reveal domain knowledge:
|
|
3369
|
+
- Create or update skills with user preferences
|
|
3370
|
+
- These skills now carry the user's specific choices for future tasks
|
|
3371
|
+
|
|
3372
|
+
**Display at Mini Discovery start:**
|
|
3373
|
+
```
|
|
3374
|
+
🔍 Mini Discovery — before I build this, let me understand what you're looking for...
|
|
3375
|
+
```
|
|
3376
|
+
|
|
3377
|
+
**Display at Mini Discovery end:**
|
|
3378
|
+
```
|
|
3379
|
+
✅ Mini Discovery complete — proceeding with implementation
|
|
3380
|
+
📘 Project Brain updated with [X] new preferences
|
|
3381
|
+
```
|
|
3382
|
+
|
|
3383
|
+
**KEY PRINCIPLE**: The goal is to understand HOW the user will experience the outcome, not just WHAT the outcome is. A login page can be minimal or elaborate, friendly or corporate, social-login-first or email-first — Mini Discovery captures these specifics so Mother Brain builds what the user actually envisioned.
|
|
3384
|
+
|
|
3385
|
+
---
|
|
3386
|
+
|
|
3306
3387
|
- **Pre-Task Analysis** (after gate passes):
|
|
3307
3388
|
- Load current task document
|
|
3308
3389
|
- Look ahead at next 3-5 tasks in current phase
|