@rubytech/taskmaster 1.0.106 → 1.0.108
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 +3 -0
- package/dist/agents/taskmaster-tools.js +5 -0
- package/dist/agents/tool-policy.js +2 -1
- package/dist/agents/tools/authorize-admin-tool.js +1 -1
- package/dist/agents/tools/memory-tool.js +2 -1
- package/dist/agents/tools/software-update-tool.js +114 -0
- package/dist/auto-reply/reply/commands-status.js +5 -9
- package/dist/auto-reply/reply/get-reply-run.js +1 -1
- package/dist/auto-reply/reply/get-reply.js +1 -1
- package/dist/auto-reply/reply/model-selection.js +1 -1
- package/dist/browser/routes/screencast.js +1 -1
- package/dist/browser/screencast.js +1 -1
- package/dist/build-info.json +3 -3
- package/dist/commands/agent.js +2 -2
- package/dist/config/zod-schema.js +12 -1
- package/dist/control-ui/assets/index-B2FEGOCu.css +1 -0
- package/dist/control-ui/assets/index-nLVF-pVT.js +3762 -0
- package/dist/control-ui/assets/index-nLVF-pVT.js.map +1 -0
- package/dist/control-ui/index.html +2 -2
- package/dist/control-ui/maxy-icon.png +0 -0
- package/dist/cron/isolated-agent/recipients.js +70 -0
- package/dist/cron/isolated-agent/run.js +43 -13
- 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-http.js +6 -1
- package/dist/gateway/server-methods/access.js +3 -3
- package/dist/gateway/server-methods/brand.js +160 -0
- package/dist/gateway/server-methods/browser-screencast.js +3 -3
- package/dist/gateway/server-methods/skills.js +159 -3
- package/dist/gateway/server-methods/workspaces.js +7 -7
- package/dist/gateway/server-methods-list.js +5 -0
- package/dist/gateway/server-methods.js +2 -0
- package/dist/gateway/server.impl.js +1 -1
- package/dist/infra/heartbeat-runner.js +17 -0
- package/dist/infra/heartbeat-update-notify.js +120 -0
- package/dist/infra/tunnel.js +1 -1
- package/dist/memory/embeddings.js +0 -4
- package/dist/memory/manager.js +15 -6
- package/dist/web/inbound/media.js +1 -1
- package/dist/web/login-qr.js +0 -23
- package/dist/web/providers/cloud/receive.js +1 -1
- package/dist/web/providers/cloud/webhook.js +1 -1
- 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 +65 -31
- 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 +0 -3539
- package/dist/control-ui/assets/index-DtuDNTAC.js.map +0 -1
- package/skills/taskmaster/SKILL.md +0 -164
|
@@ -0,0 +1,97 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: skill-builder
|
|
3
|
+
description: "Guide the user through creating a new lean skill — collect name, description, behaviour rules, and references, then save as a draft for the user to install via the Control Panel."
|
|
4
|
+
user-invocable: true
|
|
5
|
+
disable-model-invocation: true
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Skill Builder
|
|
9
|
+
|
|
10
|
+
A deterministic walkthrough for creating new lean skills. Follow each step in order. Be conversational — one question at a time.
|
|
11
|
+
|
|
12
|
+
## When to Activate
|
|
13
|
+
|
|
14
|
+
The admin requests a new skill, asks to "create a skill", "add a skill", or invokes `/skill-builder`.
|
|
15
|
+
|
|
16
|
+
## Before Starting
|
|
17
|
+
|
|
18
|
+
Load `references/lean-pattern.md` for the template and examples. Use it throughout as your reference for correct structure.
|
|
19
|
+
|
|
20
|
+
## Step 1: Understand the Purpose
|
|
21
|
+
|
|
22
|
+
Ask: **"What should this skill do?"**
|
|
23
|
+
|
|
24
|
+
Listen for:
|
|
25
|
+
- What capability it adds (scheduling, quoting, inventory, etc.)
|
|
26
|
+
- When it should activate (what triggers it)
|
|
27
|
+
- What tools or data it needs (memory, web search, file access, etc.)
|
|
28
|
+
|
|
29
|
+
Clarify until you can describe the skill in one sentence. This becomes the `description` in frontmatter.
|
|
30
|
+
|
|
31
|
+
## Step 2: Choose a Name
|
|
32
|
+
|
|
33
|
+
Propose a name based on the purpose. Names must be:
|
|
34
|
+
- Lowercase
|
|
35
|
+
- Hyphen-separated (e.g. `inventory-management`)
|
|
36
|
+
- Short and descriptive
|
|
37
|
+
|
|
38
|
+
Confirm with the user.
|
|
39
|
+
|
|
40
|
+
## Step 3: Define Behaviour
|
|
41
|
+
|
|
42
|
+
Ask what rules the agent should follow when using this skill:
|
|
43
|
+
- **Tone and style** — formal, casual, WhatsApp-short?
|
|
44
|
+
- **Activation conditions** — when exactly should the agent use this skill?
|
|
45
|
+
- **Hard boundaries** — what should the agent never do?
|
|
46
|
+
- **Data sources** — where does the skill's knowledge live? (memory, external API, files)
|
|
47
|
+
- **Escalation** — when should it hand off to admin?
|
|
48
|
+
|
|
49
|
+
Not every skill needs all of these. Only include what's relevant.
|
|
50
|
+
|
|
51
|
+
## Step 4: Decide on References
|
|
52
|
+
|
|
53
|
+
If the skill has detailed procedures, templates, or data formats, those belong in `references/` files — not inline in SKILL.md.
|
|
54
|
+
|
|
55
|
+
Ask: **"Are there any detailed procedures, templates, or formats this skill needs?"**
|
|
56
|
+
|
|
57
|
+
For each reference file:
|
|
58
|
+
- Give it a descriptive filename (e.g. `event-format.md`, `quoting-rules.md`)
|
|
59
|
+
- Collect the content from the user — they can dictate, paste, or describe it and you draft it
|
|
60
|
+
|
|
61
|
+
If the skill is simple enough to fit in SKILL.md alone (under ~30 lines of instructions), skip references.
|
|
62
|
+
|
|
63
|
+
## Step 5: Compose the Skill
|
|
64
|
+
|
|
65
|
+
Using the lean pattern from `references/lean-pattern.md`, compose:
|
|
66
|
+
|
|
67
|
+
1. **SKILL.md** — frontmatter (`name`, `description`) + activation conditions + behaviour rules + references index
|
|
68
|
+
2. **Reference files** — one per detailed topic
|
|
69
|
+
|
|
70
|
+
Show the user the complete SKILL.md content and each reference file. Ask them to review.
|
|
71
|
+
|
|
72
|
+
## Step 6: Save the Draft
|
|
73
|
+
|
|
74
|
+
Use your `write` tool to save the skill as a draft:
|
|
75
|
+
|
|
76
|
+
1. Create `../../.skill-drafts/{name}/SKILL.md` with the composed content
|
|
77
|
+
2. For each reference file: create `../../.skill-drafts/{name}/references/{filename}`
|
|
78
|
+
|
|
79
|
+
The `../../` resolves from your agent directory to the workspace root. The `.skill-drafts/` folder at the workspace root is where the Control Panel looks for drafts.
|
|
80
|
+
|
|
81
|
+
**Important:** Write to `.skill-drafts/`, NOT directly to `skills/`. The user installs the skill through the Control Panel.
|
|
82
|
+
|
|
83
|
+
## Step 7: Direct to Control Panel
|
|
84
|
+
|
|
85
|
+
Tell the user:
|
|
86
|
+
|
|
87
|
+
> "Your skill draft is ready. To install it:
|
|
88
|
+
> 1. Open the **Control Panel** → **Advanced** → **Skills**
|
|
89
|
+
> 2. Click **Add Skill**
|
|
90
|
+
> 3. Your draft will appear under 'Import from draft' — click it to load
|
|
91
|
+
> 4. Review the content and click **Save Skill**
|
|
92
|
+
>
|
|
93
|
+
> Once saved, the skill will be available to agents on the next message."
|
|
94
|
+
|
|
95
|
+
---
|
|
96
|
+
|
|
97
|
+
**Remember:** Be conversational. Don't dump all questions at once. Guide through each step one at a time.
|
|
@@ -0,0 +1,118 @@
|
|
|
1
|
+
# Lean SKILL.md Pattern
|
|
2
|
+
|
|
3
|
+
Skills teach agents specialised capabilities. Each skill is a directory containing a `SKILL.md` file and optional `references/` subdirectory.
|
|
4
|
+
|
|
5
|
+
## Directory Structure
|
|
6
|
+
|
|
7
|
+
```
|
|
8
|
+
skills/
|
|
9
|
+
my-skill/
|
|
10
|
+
SKILL.md ← Main file (lean index)
|
|
11
|
+
references/
|
|
12
|
+
detailed-guide.md ← Loaded on demand via skill_read
|
|
13
|
+
templates.md
|
|
14
|
+
```
|
|
15
|
+
|
|
16
|
+
## SKILL.md Template
|
|
17
|
+
|
|
18
|
+
```markdown
|
|
19
|
+
---
|
|
20
|
+
name: my-skill
|
|
21
|
+
description: "One-line summary of what this skill does — used for agent routing."
|
|
22
|
+
---
|
|
23
|
+
|
|
24
|
+
# My Skill
|
|
25
|
+
|
|
26
|
+
Applies when [activation conditions].
|
|
27
|
+
|
|
28
|
+
## When to Activate
|
|
29
|
+
|
|
30
|
+
- [Trigger condition 1]
|
|
31
|
+
- [Trigger condition 2]
|
|
32
|
+
|
|
33
|
+
## Behaviour
|
|
34
|
+
|
|
35
|
+
[Concise rules — keep this section short. Move detailed procedures to references.]
|
|
36
|
+
|
|
37
|
+
## References
|
|
38
|
+
|
|
39
|
+
Load `references/detailed-guide.md` for [what it covers].
|
|
40
|
+
Load `references/templates.md` for [what it covers].
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
## Principles
|
|
44
|
+
|
|
45
|
+
1. **SKILL.md is an index, not a manual.** Keep it under 30 lines of instructions. The agent reads it on every activation — bloated skills waste context.
|
|
46
|
+
|
|
47
|
+
2. **References hold the detail.** Procedures, templates, data formats, and examples go in `references/`. The agent loads them on demand with `skill_read`.
|
|
48
|
+
|
|
49
|
+
3. **Frontmatter is required.** Every SKILL.md must start with YAML frontmatter containing `name` and `description`. Missing `description` causes the skill to be silently skipped.
|
|
50
|
+
|
|
51
|
+
4. **Description drives routing.** The description is injected into the agent's prompt as part of the available skills list. Make it specific enough that the agent activates the skill for the right messages.
|
|
52
|
+
|
|
53
|
+
5. **Behaviour, not data.** Skills define how the agent should act. Business-specific data (pricing, customer info, hours) belongs in memory, not in the skill file. Skills are generic; memory is specific.
|
|
54
|
+
|
|
55
|
+
## Optional Frontmatter Fields
|
|
56
|
+
|
|
57
|
+
```yaml
|
|
58
|
+
metadata: {"taskmaster":{"always":true,"emoji":"📦","primaryEnv":"MY_API_KEY"}}
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
| Field | Purpose |
|
|
62
|
+
|-------|---------|
|
|
63
|
+
| `always` | Always include in prompt (skip eligibility checks) |
|
|
64
|
+
| `emoji` | Display emoji in the Control Panel |
|
|
65
|
+
| `primaryEnv` | Env var for API key — enables the key input field in the UI |
|
|
66
|
+
| `requires.bins` | Required binaries (e.g. `["curl"]`) |
|
|
67
|
+
| `requires.env` | Required environment variables |
|
|
68
|
+
|
|
69
|
+
Most user-created skills need only `name` and `description`.
|
|
70
|
+
|
|
71
|
+
## Examples
|
|
72
|
+
|
|
73
|
+
### Simple skill (no references)
|
|
74
|
+
|
|
75
|
+
```markdown
|
|
76
|
+
---
|
|
77
|
+
name: weather
|
|
78
|
+
description: "Provide weather context for scheduling and outdoor work decisions."
|
|
79
|
+
---
|
|
80
|
+
|
|
81
|
+
# Weather
|
|
82
|
+
|
|
83
|
+
When scheduling or planning outdoor work, check weather conditions.
|
|
84
|
+
|
|
85
|
+
## When to Activate
|
|
86
|
+
|
|
87
|
+
- Customer asks about weather
|
|
88
|
+
- Scheduling outdoor appointments
|
|
89
|
+
- Weather might affect planned work
|
|
90
|
+
|
|
91
|
+
## Behaviour
|
|
92
|
+
|
|
93
|
+
Use the `web_search` tool to check current weather for the business location.
|
|
94
|
+
Keep weather info brief — one or two sentences unless asked for detail.
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
### Lean skill with references
|
|
98
|
+
|
|
99
|
+
```markdown
|
|
100
|
+
---
|
|
101
|
+
name: event-management
|
|
102
|
+
description: "Manage anything time-bound: appointments, meetings, reminders, follow-ups."
|
|
103
|
+
---
|
|
104
|
+
|
|
105
|
+
# Event Management
|
|
106
|
+
|
|
107
|
+
Applies when handling anything time-bound.
|
|
108
|
+
|
|
109
|
+
## When to Activate
|
|
110
|
+
|
|
111
|
+
- Customer requests or confirms an appointment
|
|
112
|
+
- Business owner asks to schedule, reschedule, or cancel something
|
|
113
|
+
- A reminder or follow-up needs to be recorded
|
|
114
|
+
|
|
115
|
+
## References
|
|
116
|
+
|
|
117
|
+
Load `references/events.md` for the standard event template, file naming, and calendar query instructions.
|
|
118
|
+
```
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: zero-to-prototype
|
|
3
|
+
description: "Guide business owners from a raw idea to a validated concept — customer discovery, assumption testing, value proposition, and a simple PRD. For entrepreneurs exploring new products, services, or pivots."
|
|
4
|
+
metadata: {"taskmaster":{"emoji":"🚀"}}
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Zero to Prototype
|
|
8
|
+
|
|
9
|
+
Helps business owners validate ideas before investing time and money. Covers the full journey from initial concept to a clear product requirement document.
|
|
10
|
+
|
|
11
|
+
## When to Activate
|
|
12
|
+
|
|
13
|
+
- Owner says they have an idea for a new product, service, or offering
|
|
14
|
+
- Owner wants to validate whether something is worth pursuing
|
|
15
|
+
- Owner asks about customer discovery, market validation, or testing assumptions
|
|
16
|
+
- Owner wants to write a PRD or product brief
|
|
17
|
+
- Phrases like "pressure test this idea", "is this worth building", "help me think through this"
|
|
18
|
+
|
|
19
|
+
## Workflow
|
|
20
|
+
|
|
21
|
+
Walk through each phase conversationally. Don't dump all phases at once — progress naturally based on where the owner is.
|
|
22
|
+
|
|
23
|
+
**Phase 1 — Capture the idea.** Understand what they want to build and why. Load `references/discovery.md`.
|
|
24
|
+
|
|
25
|
+
**Phase 2 — Validate assumptions.** Identify and test the riskiest assumptions. Load `references/validation.md`.
|
|
26
|
+
|
|
27
|
+
**Phase 3 — Define the product.** Turn validated concepts into a clear PRD. Load `references/prd.md`.
|
|
28
|
+
|
|
29
|
+
## References
|
|
30
|
+
|
|
31
|
+
Load reference files on demand as each phase is reached — not all at once.
|
|
32
|
+
|
|
33
|
+
- `references/discovery.md` — customer discovery framework, interview questions, market signals
|
|
34
|
+
- `references/validation.md` — assumption mapping, validation techniques, go/no-go criteria
|
|
35
|
+
- `references/prd.md` — PRD template, prioritisation, scope definition
|
|
@@ -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.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# Taskmaster User Guide
|
|
2
2
|
|
|
3
|
-
Taskmaster is an AI-powered assistant that runs on your own device (Apple Mac or Pi). You can interact with via its chat interface, WhatsApp
|
|
3
|
+
Taskmaster is an AI-powered assistant that runs on your own device (Apple Mac or Pi). You can interact with it via its chat interface, WhatsApp, iMessage (Mac), or its intuitive control panel. It handles customer messages via WhatsApp, manages your schedule, remembers your customers, browses the web, organises your files, and learns your business over time — all through natural conversation. You should read this User Guide completely before doing anything else.
|
|
4
4
|
|
|
5
5
|
---
|
|
6
6
|
|
|
@@ -633,6 +633,46 @@ When WhatsApp is connected, you'll see a small gear icon next to the WhatsApp la
|
|
|
633
633
|
|
|
634
634
|
---
|
|
635
635
|
|
|
636
|
+
## Branding
|
|
637
|
+
|
|
638
|
+
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).
|
|
639
|
+
|
|
640
|
+
### What you can customise
|
|
641
|
+
|
|
642
|
+
| Setting | What it does |
|
|
643
|
+
|---------|-------------|
|
|
644
|
+
| **Logo** | Your business logo, shown on public chat pages alongside your business name |
|
|
645
|
+
| **Accent colour** | The colour used for buttons, links, and interactive elements across the UI |
|
|
646
|
+
| **Background tint** | A subtle colour wash applied to page and card backgrounds |
|
|
647
|
+
|
|
648
|
+
### How to set up branding
|
|
649
|
+
|
|
650
|
+
1. Go to the **Setup** page
|
|
651
|
+
2. Find the **Branding** row in the status dashboard
|
|
652
|
+
3. Click **Edit** — a modal opens with your branding options
|
|
653
|
+
4. **Upload a logo** — click Upload and select an image (PNG, JPEG, SVG, or WebP, max 2 MB)
|
|
654
|
+
5. **Choose your accent colour** — click the colour picker next to "Accent colour" and select your brand colour
|
|
655
|
+
6. **Choose your background tint** — click the colour picker next to "Background tint" to add a subtle background wash (optional)
|
|
656
|
+
7. Click **Close** when you're done — changes are applied immediately
|
|
657
|
+
|
|
658
|
+
To see what each setting does, click the **(i)** button on the Branding row.
|
|
659
|
+
|
|
660
|
+
### Per-account branding
|
|
661
|
+
|
|
662
|
+
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.
|
|
663
|
+
|
|
664
|
+
### Resetting to defaults
|
|
665
|
+
|
|
666
|
+
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.
|
|
667
|
+
|
|
668
|
+
### Where branding appears
|
|
669
|
+
|
|
670
|
+
- **Control panel** — accent colour and background tint update immediately across all pages
|
|
671
|
+
- **Public chat page** — visitors see your logo, accent colour, and background tint
|
|
672
|
+
- **Chat widget** — the embedded widget on your website uses your accent colour for the chat button and background tint for the overlay
|
|
673
|
+
|
|
674
|
+
---
|
|
675
|
+
|
|
636
676
|
## Advanced
|
|
637
677
|
|
|
638
678
|
The **Advanced** page has four tabs for monitoring and managing your assistant behind the scenes. You don't need these day-to-day, but they're useful when you want to see what's happening under the hood.
|
|
@@ -654,7 +694,16 @@ You can also create events by asking the assistant in chat ("remind me every Mon
|
|
|
654
694
|
|
|
655
695
|
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
696
|
|
|
657
|
-
|
|
697
|
+
Skills are labelled as **Preloaded** (built-in, always active) or **User** (created by you). You can:
|
|
698
|
+
|
|
699
|
+
- **Tap any skill** to open a detail view showing its full instructions and reference files
|
|
700
|
+
- **Enable/Disable** a user skill using the toggle button
|
|
701
|
+
- **Edit** a user skill — loads its content so you can save an updated version
|
|
702
|
+
- **Delete** a user skill (with confirmation)
|
|
703
|
+
|
|
704
|
+
**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.
|
|
705
|
+
|
|
706
|
+
Preloaded skills ship with the product and cannot be disabled or deleted.
|
|
658
707
|
|
|
659
708
|
### Logs
|
|
660
709
|
|
|
@@ -873,6 +922,16 @@ If the Pi checks pass but the control panel still doesn't load from another devi
|
|
|
873
922
|
|
|
874
923
|
## Troubleshooting
|
|
875
924
|
|
|
925
|
+
### Can't access the Control Panel?
|
|
926
|
+
|
|
927
|
+
If you can't load the Control Panel in your browser:
|
|
928
|
+
|
|
929
|
+
1. **Same network?** — Make sure your device is on the same WiFi or LAN as Taskmaster
|
|
930
|
+
2. **Check the URL** — go to **http://taskmaster.local:18789**. Make sure you're using `http` (not `https`) and port `18789`
|
|
931
|
+
3. **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
|
|
932
|
+
4. **Try a different browser** — some browsers (especially on older devices) have trouble with `.local` addresses. Try Chrome or Safari
|
|
933
|
+
5. **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
|
|
934
|
+
|
|
876
935
|
### Messages not getting through?
|
|
877
936
|
|
|
878
937
|
1. Go to **http://taskmaster.local:18789/setup**
|
|
@@ -887,10 +946,6 @@ WhatsApp is linked but the connection dropped. This often resolves itself. If no
|
|
|
887
946
|
2. Tap **"Refresh Status"** (top of dashboard) — it may reconnect automatically
|
|
888
947
|
3. If still yellow after a minute, **then** tap the circular arrow next to WhatsApp to generate a new QR code and re-pair
|
|
889
948
|
|
|
890
|
-
> **Important:** The top Refresh Status button refreshes the existing connection without creating a new QR code. Only use the WhatsApp circular arrow button if you need to completely re-pair from scratch.
|
|
891
|
-
|
|
892
|
-
|
|
893
|
-
|
|
894
949
|
### WhatsApp messages failing with "No sessions" or "Bad MAC" errors?
|
|
895
950
|
|
|
896
951
|
The WhatsApp connection for one of your accounts has lost sync. This can happen after a power cut, an unclean shutdown, or when WhatsApp rotates its security keys. Other accounts on the same device are not affected — only the account with the problem stops sending or receiving.
|
|
@@ -903,17 +958,11 @@ The WhatsApp connection for one of your accounts has lost sync. This can happen
|
|
|
903
958
|
|
|
904
959
|
On a Raspberry Pi, you can also just unplug the device, wait 10 seconds, and plug it back in.
|
|
905
960
|
|
|
906
|
-
**If restarting doesn't fix it**,
|
|
961
|
+
**If restarting doesn't fix it**, re-pair WhatsApp from scratch (see below).
|
|
907
962
|
|
|
908
|
-
|
|
909
|
-
2. Tap **"Reset WhatsApp"** (red button) for that account
|
|
910
|
-
3. **On your phone:** WhatsApp → Settings → Linked Devices
|
|
911
|
-
4. **Remove** "macOS" (Taskmaster's connection) from the list for that number (if present)
|
|
912
|
-
5. **Scan** the new QR code
|
|
963
|
+
### WhatsApp needs re-pairing (linking fails, status red, or out of sync)?
|
|
913
964
|
|
|
914
|
-
|
|
915
|
-
|
|
916
|
-
The old connection data may be corrupted. To start fresh:
|
|
965
|
+
If WhatsApp linking keeps failing, the status stays red despite showing "linked" on your phone, or the connection data is corrupted — you need to start fresh:
|
|
917
966
|
|
|
918
967
|
1. Go to **http://taskmaster.local:18789/setup**
|
|
919
968
|
2. Tap **"Reset WhatsApp"** (red button)
|
|
@@ -921,15 +970,6 @@ The old connection data may be corrupted. To start fresh:
|
|
|
921
970
|
4. **Remove** "macOS" (Taskmaster's connection) from the list if present
|
|
922
971
|
5. **Scan** the new QR code
|
|
923
972
|
|
|
924
|
-
### WhatsApp shows "linked" on phone but status is red?
|
|
925
|
-
|
|
926
|
-
The phone and Taskmaster are out of sync. To fix:
|
|
927
|
-
|
|
928
|
-
1. **On your phone:** WhatsApp → Settings → Linked Devices
|
|
929
|
-
2. **Remove** "macOS" (Taskmaster's connection) from the list
|
|
930
|
-
3. On the setup page, tap the circular arrow next to WhatsApp
|
|
931
|
-
4. **Scan** the new QR code
|
|
932
|
-
|
|
933
973
|
### Claude connection expired?
|
|
934
974
|
|
|
935
975
|
1. Go to **http://taskmaster.local:18789/setup**
|
|
@@ -945,12 +985,6 @@ The gateway is the software that runs your assistant. If it's showing red:
|
|
|
945
985
|
3. Wait 30 seconds for it to come back online
|
|
946
986
|
4. If still not working, try unplugging your Taskmaster device, waiting 10 seconds, and plugging it back in
|
|
947
987
|
|
|
948
|
-
### Can't reach the setup page?
|
|
949
|
-
|
|
950
|
-
- Make sure you're on the same WiFi as Taskmaster
|
|
951
|
-
- Try using the IP address: **http://192.168.x.x:18789** (contact Support for assistance)
|
|
952
|
-
- Wait 2 minutes after power-on for the device to start
|
|
953
|
-
|
|
954
988
|
### "sudo: unable to resolve host taskmaster" warning?
|
|
955
989
|
|
|
956
990
|
This harmless warning appears when the Pi's hostname isn't listed in `/etc/hosts`. Every `sudo` command still works — it's just a cosmetic message. To fix it, open a terminal on the Pi and run:
|
|
@@ -1310,7 +1344,7 @@ Replace `YOUR-PUBLIC-URL` with the URL shown on the Internet Access row (e.g. `h
|
|
|
1310
1344
|
|
|
1311
1345
|
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
1346
|
|
|
1313
|
-
You can optionally set
|
|
1347
|
+
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
1348
|
|
|
1315
1349
|
---
|
|
1316
1350
|
|
|
@@ -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)
|