@rubytech/taskmaster 1.0.105 → 1.0.107
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/agents/skills-status.js +23 -3
- package/dist/agents/skills.js +1 -0
- package/dist/agents/system-prompt.js +1 -0
- package/dist/agents/tools/memory-tool.js +2 -1
- package/dist/build-info.json +3 -3
- package/dist/config/zod-schema.js +12 -1
- package/dist/control-ui/assets/index-2XyxmiR6.css +1 -0
- package/dist/control-ui/assets/{index-DtuDNTAC.js → index-B_zHmTQU.js} +823 -645
- package/dist/control-ui/assets/index-B_zHmTQU.js.map +1 -0
- package/dist/control-ui/index.html +2 -2
- package/dist/control-ui/maxy-icon.png +0 -0
- package/dist/gateway/config-reload.js +1 -0
- package/dist/gateway/control-ui.js +111 -5
- package/dist/gateway/protocol/index.js +6 -1
- package/dist/gateway/protocol/schema/agents-models-skills.js +23 -0
- package/dist/gateway/protocol/schema/protocol-schemas.js +6 -1
- package/dist/gateway/server-close.js +2 -0
- package/dist/gateway/server-http.js +6 -1
- package/dist/gateway/server-methods/brand.js +160 -0
- package/dist/gateway/server-methods/skills.js +159 -3
- package/dist/gateway/server-methods/wifi.js +0 -10
- package/dist/gateway/server-methods-list.js +5 -0
- package/dist/gateway/server-methods.js +2 -0
- package/dist/gateway/server-wifi-watchdog.js +105 -0
- package/dist/gateway/server.impl.js +3 -0
- package/dist/memory/manager.js +12 -3
- package/package.json +1 -1
- package/skills/skill-builder/SKILL.md +97 -0
- package/skills/skill-builder/references/lean-pattern.md +118 -0
- package/skills/zero-to-prototype/SKILL.md +35 -0
- package/skills/zero-to-prototype/references/discovery.md +64 -0
- package/skills/zero-to-prototype/references/prd.md +83 -0
- package/skills/zero-to-prototype/references/validation.md +67 -0
- package/taskmaster-docs/USER-GUIDE.md +58 -2
- package/templates/customer/agents/public/AGENTS.md +3 -10
- package/templates/taskmaster/agents/public/SOUL.md +0 -4
- package/templates/tradesupport/agents/public/AGENTS.md +3 -10
- package/dist/control-ui/assets/index-DjhCZlZd.css +0 -1
- package/dist/control-ui/assets/index-DtuDNTAC.js.map +0 -1
- package/skills/taskmaster/SKILL.md +0 -164
|
@@ -0,0 +1,64 @@
|
|
|
1
|
+
# Customer Discovery
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
|
|
5
|
+
Understand the problem before designing the solution. Most failed products solve a problem nobody has, or solve the right problem for the wrong audience.
|
|
6
|
+
|
|
7
|
+
## Step 1: Articulate the Idea
|
|
8
|
+
|
|
9
|
+
Get the owner to state their idea in one sentence:
|
|
10
|
+
|
|
11
|
+
> "[Product/service] helps [target audience] [solve problem] by [mechanism]."
|
|
12
|
+
|
|
13
|
+
If they can't fill this in, they don't have a clear idea yet. Help them by asking:
|
|
14
|
+
- Who specifically would use this?
|
|
15
|
+
- What problem does it solve for them?
|
|
16
|
+
- How do they solve this problem today (without your product)?
|
|
17
|
+
- Why would they switch to your solution?
|
|
18
|
+
|
|
19
|
+
## Step 2: Identify the Target Customer
|
|
20
|
+
|
|
21
|
+
Don't accept "everyone" or "small businesses". Get specific:
|
|
22
|
+
- **Demographics** — age, location, income, profession
|
|
23
|
+
- **Behaviour** — what do they currently do? where do they hang out?
|
|
24
|
+
- **Pain** — what frustrates them about the current solution?
|
|
25
|
+
|
|
26
|
+
Ask: "If you could only sell to one type of person, who would it be?"
|
|
27
|
+
|
|
28
|
+
## Step 3: Customer Conversations
|
|
29
|
+
|
|
30
|
+
The owner needs to talk to potential customers. Not friends. Not family. Real prospects.
|
|
31
|
+
|
|
32
|
+
### What to Ask (5 Key Questions)
|
|
33
|
+
|
|
34
|
+
1. **"Tell me about the last time you [experienced the problem]."** — Gets real stories, not hypotheticals.
|
|
35
|
+
2. **"What did you do about it?"** — Reveals current solutions and willingness to act.
|
|
36
|
+
3. **"What's the most annoying part of how you handle this today?"** — Finds the pain point.
|
|
37
|
+
4. **"If you could wave a magic wand, what would be different?"** — Reveals desires without anchoring to your solution.
|
|
38
|
+
5. **"Would you pay to solve this? How much?"** — Tests willingness to pay.
|
|
39
|
+
|
|
40
|
+
### Rules
|
|
41
|
+
|
|
42
|
+
- **Don't pitch.** You're learning, not selling.
|
|
43
|
+
- **Don't ask "would you use this?"** — everyone says yes to be polite.
|
|
44
|
+
- **Talk to at least 5 people** before drawing conclusions.
|
|
45
|
+
- **Look for patterns** — one person's pain is anecdotal. Three people's pain is a signal.
|
|
46
|
+
|
|
47
|
+
## Step 4: Market Signals
|
|
48
|
+
|
|
49
|
+
Help the owner assess whether the market supports the idea:
|
|
50
|
+
|
|
51
|
+
- **Search volume** — are people searching for solutions? (Use web search to check)
|
|
52
|
+
- **Competitors** — who else solves this? What do they charge? What do reviews say?
|
|
53
|
+
- **Market size** — how many potential customers exist? Is the market growing?
|
|
54
|
+
- **Timing** — why now? What's changed that makes this possible or necessary?
|
|
55
|
+
|
|
56
|
+
## Output
|
|
57
|
+
|
|
58
|
+
By the end of discovery, the owner should have:
|
|
59
|
+
1. A clear one-sentence idea statement
|
|
60
|
+
2. A specific target customer profile
|
|
61
|
+
3. At least 3 customer conversation summaries (or a plan to do them)
|
|
62
|
+
4. A market landscape overview
|
|
63
|
+
|
|
64
|
+
Save these to memory for use in the validation and PRD phases.
|
|
@@ -0,0 +1,83 @@
|
|
|
1
|
+
# Product Requirement Document
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
|
|
5
|
+
Turn the validated idea into a clear, actionable document that defines what to build, for whom, and why.
|
|
6
|
+
|
|
7
|
+
## PRD Template
|
|
8
|
+
|
|
9
|
+
Walk the owner through each section. Write the PRD collaboratively — don't generate it in isolation.
|
|
10
|
+
|
|
11
|
+
### 1. Problem Statement
|
|
12
|
+
|
|
13
|
+
One paragraph. What problem exists, who has it, and why current solutions fall short.
|
|
14
|
+
|
|
15
|
+
Draw from discovery phase: customer conversations, pain points, market gaps.
|
|
16
|
+
|
|
17
|
+
### 2. Target Customer
|
|
18
|
+
|
|
19
|
+
Specific profile from discovery:
|
|
20
|
+
- Who they are (demographics, role, context)
|
|
21
|
+
- What they currently do (workarounds, competitors they use)
|
|
22
|
+
- What they need (the gap your product fills)
|
|
23
|
+
|
|
24
|
+
### 3. Value Proposition
|
|
25
|
+
|
|
26
|
+
One sentence: "We help [target customer] [achieve outcome] by [mechanism], unlike [current alternative] which [limitation]."
|
|
27
|
+
|
|
28
|
+
### 4. Core Features
|
|
29
|
+
|
|
30
|
+
List the minimum features needed for the product to deliver its value proposition. No more.
|
|
31
|
+
|
|
32
|
+
For each feature:
|
|
33
|
+
- **What it does** (user-facing description)
|
|
34
|
+
- **Why it matters** (which customer need it addresses)
|
|
35
|
+
- **Priority** (Must-have / Should-have / Nice-to-have)
|
|
36
|
+
|
|
37
|
+
Use the MoSCoW method:
|
|
38
|
+
- **Must-have** — Product is useless without these
|
|
39
|
+
- **Should-have** — Significantly improves the product
|
|
40
|
+
- **Could-have** — Nice but not critical
|
|
41
|
+
- **Won't-have** — Explicitly out of scope for v1
|
|
42
|
+
|
|
43
|
+
### 5. User Journey
|
|
44
|
+
|
|
45
|
+
Walk through the primary use case step by step:
|
|
46
|
+
1. How does the customer discover the product?
|
|
47
|
+
2. What's their first interaction?
|
|
48
|
+
3. How do they get value for the first time?
|
|
49
|
+
4. What keeps them coming back?
|
|
50
|
+
|
|
51
|
+
### 6. Success Metrics
|
|
52
|
+
|
|
53
|
+
How will the owner know this is working?
|
|
54
|
+
|
|
55
|
+
| Metric | Target | Timeframe |
|
|
56
|
+
|--------|--------|-----------|
|
|
57
|
+
| e.g. Signups | 50 | First month |
|
|
58
|
+
| e.g. Paying customers | 10 | First 3 months |
|
|
59
|
+
| e.g. Retention | 70% month-over-month | Month 2+ |
|
|
60
|
+
|
|
61
|
+
Pick 3-5 metrics. No more. Focus on outcomes, not vanity metrics.
|
|
62
|
+
|
|
63
|
+
### 7. Scope and Constraints
|
|
64
|
+
|
|
65
|
+
- **Budget** — what can the owner invest?
|
|
66
|
+
- **Timeline** — when do they need it by?
|
|
67
|
+
- **Technical constraints** — platform, integrations, dependencies
|
|
68
|
+
- **Regulatory** — compliance, data protection, licensing
|
|
69
|
+
|
|
70
|
+
### 8. Risks and Mitigations
|
|
71
|
+
|
|
72
|
+
Top 3 risks from validation phase and how to address them.
|
|
73
|
+
|
|
74
|
+
### 9. Next Steps
|
|
75
|
+
|
|
76
|
+
Concrete actions with owners and deadlines:
|
|
77
|
+
1. What needs to happen first?
|
|
78
|
+
2. Who does what?
|
|
79
|
+
3. When is the first checkpoint?
|
|
80
|
+
|
|
81
|
+
## Output
|
|
82
|
+
|
|
83
|
+
Save the completed PRD to memory. The owner now has a document they can share with developers, investors, or partners.
|
|
@@ -0,0 +1,67 @@
|
|
|
1
|
+
# Assumption Validation
|
|
2
|
+
|
|
3
|
+
## Goal
|
|
4
|
+
|
|
5
|
+
Every idea rests on assumptions. Find the riskiest ones and test them before building anything.
|
|
6
|
+
|
|
7
|
+
## Step 1: List Assumptions
|
|
8
|
+
|
|
9
|
+
Help the owner extract the hidden assumptions in their idea. Common categories:
|
|
10
|
+
|
|
11
|
+
| Category | Example Assumption |
|
|
12
|
+
|----------|--------------------|
|
|
13
|
+
| **Problem** | "People actually struggle with X" |
|
|
14
|
+
| **Audience** | "Tradesmen aged 30-50 need this" |
|
|
15
|
+
| **Willingness to pay** | "People would pay £X/month" |
|
|
16
|
+
| **Behaviour change** | "Users will switch from their current tool" |
|
|
17
|
+
| **Channel** | "I can reach these customers via WhatsApp" |
|
|
18
|
+
| **Feasibility** | "This can be built with available technology" |
|
|
19
|
+
| **Unit economics** | "The cost to serve one customer is less than what they pay" |
|
|
20
|
+
|
|
21
|
+
Ask: "What has to be true for this idea to work?" List everything.
|
|
22
|
+
|
|
23
|
+
## Step 2: Risk-Rank Assumptions
|
|
24
|
+
|
|
25
|
+
For each assumption, score two things:
|
|
26
|
+
- **How critical?** (If this is wrong, does the idea die? 1-5)
|
|
27
|
+
- **How uncertain?** (Do we have evidence, or is it a guess? 1-5)
|
|
28
|
+
|
|
29
|
+
Priority = Critical × Uncertain. Test the highest scores first.
|
|
30
|
+
|
|
31
|
+
## Step 3: Design Validation Tests
|
|
32
|
+
|
|
33
|
+
For each high-priority assumption, choose a validation method:
|
|
34
|
+
|
|
35
|
+
### Quick Tests (hours)
|
|
36
|
+
- **Search validation** — Google the problem. Are people asking about it? Are there Reddit threads, forum posts, complaints?
|
|
37
|
+
- **Competitor analysis** — Who else does this? Are they growing? What do their reviews say?
|
|
38
|
+
- **Landing page test** — Create a simple page describing the product. Run a small ad. Measure clicks and signups.
|
|
39
|
+
|
|
40
|
+
### Medium Tests (days)
|
|
41
|
+
- **Pre-sell** — Offer the product before it exists. "Would you pay £X for this? I'm building it now." Count commitments.
|
|
42
|
+
- **Concierge test** — Deliver the service manually to 3-5 customers. No product needed. Does it work? Do they value it?
|
|
43
|
+
- **Smoke test** — Build a fake "Buy Now" button. Track how many people click before showing a "coming soon" message.
|
|
44
|
+
|
|
45
|
+
### Deep Tests (weeks)
|
|
46
|
+
- **Prototype** — Build the minimum version. Get real users. Measure retention.
|
|
47
|
+
- **Pilot** — Run the service for real with a small group. Measure satisfaction and willingness to continue.
|
|
48
|
+
|
|
49
|
+
## Step 4: Go / No-Go Decision
|
|
50
|
+
|
|
51
|
+
After testing, ask:
|
|
52
|
+
|
|
53
|
+
| Signal | Go | Pivot | Stop |
|
|
54
|
+
|--------|-----|-------|------|
|
|
55
|
+
| Problem exists? | Strong evidence | Exists but different | No evidence |
|
|
56
|
+
| People will pay? | Pre-sales or commitments | Maybe, need different pricing | Nobody willing |
|
|
57
|
+
| You can reach them? | Clear channel | Channel exists but expensive | No viable channel |
|
|
58
|
+
| Unit economics work? | Profitable per customer | Break-even possible | Loses money per customer |
|
|
59
|
+
| You're the right person? | Unique advantage | Can learn | No relevant edge |
|
|
60
|
+
|
|
61
|
+
**Go** = most signals green. Proceed to PRD.
|
|
62
|
+
**Pivot** = core insight is valid but the approach needs changing. Revisit discovery with a new angle.
|
|
63
|
+
**Stop** = fundamental assumptions are wrong. Save time and money.
|
|
64
|
+
|
|
65
|
+
## Output
|
|
66
|
+
|
|
67
|
+
Save the validated/invalidated assumptions and the go/no-go decision to memory. This feeds directly into the PRD phase.
|
|
@@ -631,6 +631,44 @@ When WhatsApp is connected, you'll see a small gear icon next to the WhatsApp la
|
|
|
631
631
|
- **Model** — Choose which AI model handles customer messages. You can pick Opus (most capable), Sonnet (balanced), or Haiku (fastest and cheapest). This only affects the public assistant — the model you pick in the Chat page controls your admin assistant separately.
|
|
632
632
|
- **Thinking** — Controls how deeply the public assistant reasons before responding to customers. "Off" is fastest. "Low" through "High" give increasingly thorough reasoning at the cost of speed. Like Model, this only affects the public assistant.
|
|
633
633
|
|
|
634
|
+
### Branding
|
|
635
|
+
|
|
636
|
+
Each account can have its own branding — a logo and colour scheme that appears on the control panel and on public chat pages (both the full page and the embeddable widget).
|
|
637
|
+
|
|
638
|
+
#### What you can customise
|
|
639
|
+
|
|
640
|
+
| Setting | What it does |
|
|
641
|
+
|---------|-------------|
|
|
642
|
+
| **Logo** | Your business logo, shown on public chat pages alongside your business name |
|
|
643
|
+
| **Accent colour** | The colour used for buttons, links, and interactive elements across the UI |
|
|
644
|
+
| **Background tint** | A subtle colour wash applied to page and card backgrounds |
|
|
645
|
+
|
|
646
|
+
#### How to set up branding
|
|
647
|
+
|
|
648
|
+
1. Go to the **Setup** page
|
|
649
|
+
2. Find the **Branding** row in the status dashboard
|
|
650
|
+
3. Click **Edit** — a modal opens with your branding options
|
|
651
|
+
4. **Upload a logo** — click Upload and select an image (PNG, JPEG, SVG, or WebP, max 2 MB)
|
|
652
|
+
5. **Choose your accent colour** — click the colour picker next to "Accent colour" and select your brand colour
|
|
653
|
+
6. **Choose your background tint** — click the colour picker next to "Background tint" to add a subtle background wash (optional)
|
|
654
|
+
7. Click **Close** when you're done — changes are applied immediately
|
|
655
|
+
|
|
656
|
+
To see what each setting does, click the **(i)** button on the Branding row.
|
|
657
|
+
|
|
658
|
+
#### Per-account branding
|
|
659
|
+
|
|
660
|
+
Branding is set per account. If you have multiple accounts, switch to each account using the dropdown at the top of the page and set up branding for each one separately. When you switch accounts, the control panel immediately updates to show that account's colours and logo.
|
|
661
|
+
|
|
662
|
+
#### Resetting to defaults
|
|
663
|
+
|
|
664
|
+
To remove all custom branding and return to the default colours, open the Branding modal and click **Reset to defaults**. To remove just the logo, click **Remove** next to the logo preview.
|
|
665
|
+
|
|
666
|
+
#### Where branding appears
|
|
667
|
+
|
|
668
|
+
- **Control panel** — accent colour and background tint update immediately across all pages
|
|
669
|
+
- **Public chat page** — visitors see your logo, accent colour, and background tint
|
|
670
|
+
- **Chat widget** — the embedded widget on your website uses your accent colour for the chat button and background tint for the overlay
|
|
671
|
+
|
|
634
672
|
---
|
|
635
673
|
|
|
636
674
|
## Advanced
|
|
@@ -654,7 +692,16 @@ You can also create events by asking the assistant in chat ("remind me every Mon
|
|
|
654
692
|
|
|
655
693
|
Skills are the specialised abilities your assistant has — like handling customer enquiries, creating quotes, or checking the weather. This tab shows which skills are installed, whether they're active, and if anything is missing (like an API key a skill needs).
|
|
656
694
|
|
|
657
|
-
|
|
695
|
+
Skills are labelled as **Preloaded** (built-in, always active) or **User** (created by you). You can:
|
|
696
|
+
|
|
697
|
+
- **Tap any skill** to open a detail view showing its full instructions and reference files
|
|
698
|
+
- **Enable/Disable** a user skill using the toggle button
|
|
699
|
+
- **Edit** a user skill — loads its content so you can save an updated version
|
|
700
|
+
- **Delete** a user skill (with confirmation)
|
|
701
|
+
|
|
702
|
+
**Creating new skills:** Ask your assistant to help you create a skill — it will walk you through the process step by step and prepare a draft. Once the draft is ready, open the **Drafts** button in the Skills tab to review, install, or delete pending drafts. You don't need to write skill files manually.
|
|
703
|
+
|
|
704
|
+
Preloaded skills ship with the product and cannot be disabled or deleted.
|
|
658
705
|
|
|
659
706
|
### Logs
|
|
660
707
|
|
|
@@ -873,6 +920,15 @@ If the Pi checks pass but the control panel still doesn't load from another devi
|
|
|
873
920
|
|
|
874
921
|
## Troubleshooting
|
|
875
922
|
|
|
923
|
+
### Can't access the Control Panel?
|
|
924
|
+
|
|
925
|
+
If you can't load the Control Panel in your browser:
|
|
926
|
+
|
|
927
|
+
1. **Check the URL** — go to **http://taskmaster.local:18789**. Make sure you're using `http` (not `https`) and port `18789`
|
|
928
|
+
2. **Wait for boot** — after powering on the device, it takes 2–3 minutes for everything to start. If you just plugged it in, give it a moment
|
|
929
|
+
3. **Try a different browser** — some browsers (especially on older devices) have trouble with `.local` addresses. Try Chrome or Safari
|
|
930
|
+
4. **Use the IP address** — if `.local` doesn't resolve, find the device's IP address on your router and go to `http://<ip-address>:18789` instead
|
|
931
|
+
|
|
876
932
|
### Messages not getting through?
|
|
877
933
|
|
|
878
934
|
1. Go to **http://taskmaster.local:18789/setup**
|
|
@@ -1310,7 +1366,7 @@ Replace `YOUR-PUBLIC-URL` with the URL shown on the Internet Access row (e.g. `h
|
|
|
1310
1366
|
|
|
1311
1367
|
A chat button appears in the bottom-right corner of the page. Clicking it opens a chat window where visitors can talk to your assistant — no WhatsApp required.
|
|
1312
1368
|
|
|
1313
|
-
You can optionally set
|
|
1369
|
+
You can optionally set colours to match your website: `color` controls the floating chat button, and `bgColor` controls the chat overlay background. If you've set up branding on the Setup page, the widget uses your brand colours automatically — these init options override them if provided.
|
|
1314
1370
|
|
|
1315
1371
|
---
|
|
1316
1372
|
|
|
@@ -71,8 +71,7 @@ memory/
|
|
|
71
71
|
├── shared/ # Instructions, lessons (you can access)
|
|
72
72
|
├── users/ # Per-customer profiles (you can access for this customer)
|
|
73
73
|
│ └── {phone}/
|
|
74
|
-
│
|
|
75
|
-
│ └── SOUL-EXTENSION.md # Personalised tone (if rapport established)
|
|
74
|
+
│ └── profile.md # Customer details
|
|
76
75
|
└── groups/ # Per-group data (you can access for the current group)
|
|
77
76
|
└── {groupId}/
|
|
78
77
|
├── members/ # Per-member profiles within this group
|
|
@@ -87,18 +86,12 @@ memory/
|
|
|
87
86
|
Semantic search doesn't reliably find user-specific files. Use `memory_get` with the exact path:
|
|
88
87
|
|
|
89
88
|
```
|
|
90
|
-
1. memory_get("memory/users/{phone}/
|
|
91
|
-
2. memory_get("memory/users/{phone}/profile.md")
|
|
89
|
+
1. memory_get("memory/users/{phone}/profile.md")
|
|
92
90
|
```
|
|
93
91
|
|
|
94
92
|
**Do this for EVERY new conversation**, even if you think they're a new customer. The business owner may have pre-created context you don't know about.
|
|
95
93
|
|
|
96
|
-
1. **Check for
|
|
97
|
-
- Use `memory_get` with the exact path (not memory_search)
|
|
98
|
-
- If it exists, READ IT and follow its guidance for this customer
|
|
99
|
-
- This overrides your default behavior for this specific person
|
|
100
|
-
|
|
101
|
-
2. **Check for existing profile.md** — `memory/users/{phone}/profile.md`
|
|
94
|
+
1. **Check for existing profile.md** — `memory/users/{phone}/profile.md`
|
|
102
95
|
- Use `memory_get` with the exact path (not memory_search)
|
|
103
96
|
- If it exists, READ IT — someone (admin or you previously) has context on this person
|
|
104
97
|
- DO NOT overwrite it with a blank template
|
|
@@ -26,10 +26,6 @@ Every conversation should leave the prospect closer to understanding Taskmaster'
|
|
|
26
26
|
|
|
27
27
|
**Rapport serves the mission.** If someone wants to banter, engage briefly — then steer back. Ask about their business, their pain points, their business challenges. Rapport without purpose is wasted opportunity. After 2-3 exchanges of off-topic chat, pivot: *"So tell me about your business — how do you handle customer messages right now?"*
|
|
28
28
|
|
|
29
|
-
## User-Scoped Personality
|
|
30
|
-
|
|
31
|
-
For users you've built rapport with, check `memory/users/{phone}/SOUL-EXTENSION.md` for personalised tone notes. If it exists, adapt your style (more casual, more banter, specific inside jokes) — but the Primary Objectives still apply. Personality can flex; purpose doesn't.
|
|
32
|
-
|
|
33
29
|
## What You Do
|
|
34
30
|
|
|
35
31
|
- Answer questions about Taskmaster (what it is, how it works, pricing)
|
|
@@ -71,8 +71,7 @@ memory/
|
|
|
71
71
|
├── shared/ # Instructions, lessons (you can access)
|
|
72
72
|
├── users/ # Per-customer profiles (you can access for this customer)
|
|
73
73
|
│ └── {phone}/
|
|
74
|
-
│
|
|
75
|
-
│ └── SOUL-EXTENSION.md # Personalised tone (if rapport established)
|
|
74
|
+
│ └── profile.md # Customer details
|
|
76
75
|
└── groups/ # Per-group data (you can access for the current group)
|
|
77
76
|
└── {groupId}/
|
|
78
77
|
├── members/ # Per-member profiles within this group
|
|
@@ -87,18 +86,12 @@ memory/
|
|
|
87
86
|
Semantic search doesn't reliably find user-specific files. Use `memory_get` with the exact path:
|
|
88
87
|
|
|
89
88
|
```
|
|
90
|
-
1. memory_get("memory/users/{phone}/
|
|
91
|
-
2. memory_get("memory/users/{phone}/profile.md")
|
|
89
|
+
1. memory_get("memory/users/{phone}/profile.md")
|
|
92
90
|
```
|
|
93
91
|
|
|
94
92
|
**Do this for EVERY new conversation**, even if you think they're a new customer. The business owner may have pre-created context you don't know about.
|
|
95
93
|
|
|
96
|
-
1. **Check for
|
|
97
|
-
- Use `memory_get` with the exact path (not memory_search)
|
|
98
|
-
- If it exists, READ IT and follow its guidance for this customer
|
|
99
|
-
- This overrides your default behavior for this specific person
|
|
100
|
-
|
|
101
|
-
2. **Check for existing profile.md** — `memory/users/{phone}/profile.md`
|
|
94
|
+
1. **Check for existing profile.md** — `memory/users/{phone}/profile.md`
|
|
102
95
|
- Use `memory_get` with the exact path (not memory_search)
|
|
103
96
|
- If it exists, READ IT — someone (admin or you previously) has context on this person
|
|
104
97
|
- DO NOT overwrite it with a blank template
|