sensorium-mcp 2.17.8 → 2.17.11
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/dashboard/routes/threads.js +9 -9
- package/dist/dashboard/routes/threads.js.map +1 -1
- package/dist/dashboard/spa.html +9 -9
- package/dist/data/memory/procedures.d.ts +14 -2
- package/dist/data/memory/procedures.d.ts.map +1 -1
- package/dist/data/memory/procedures.js +50 -1
- package/dist/data/memory/procedures.js.map +1 -1
- package/dist/data/memory/reflection.d.ts.map +1 -1
- package/dist/data/memory/reflection.js +1 -0
- package/dist/data/memory/reflection.js.map +1 -1
- package/dist/data/memory/semantic.d.ts +1 -0
- package/dist/data/memory/semantic.d.ts.map +1 -1
- package/dist/data/memory/semantic.js +1 -1
- package/dist/data/memory/semantic.js.map +1 -1
- package/dist/tools/wait/poll-loop.d.ts.map +1 -1
- package/dist/tools/wait/poll-loop.js +3 -1
- package/dist/tools/wait/poll-loop.js.map +1 -1
- package/dist/watcher-service.d.ts.map +1 -1
- package/dist/watcher-service.js +9 -3
- package/dist/watcher-service.js.map +1 -1
- package/package.json +1 -1
- package/templates/plan-mode.default.md +4 -1
- package/templates/ghost-thread.default.md +0 -67
- package/templates/orchestrator-claude.default.md +0 -49
- package/templates/orchestrator-copilot.default.md +0 -57
- package/templates/orchestrator.default.md +0 -21
package/package.json
CHANGED
|
@@ -11,7 +11,10 @@ replaces_orchestrator: true
|
|
|
11
11
|
|
|
12
12
|
# Inputs
|
|
13
13
|
- `task` (required): The task to break down into atomic steps.
|
|
14
|
-
- `workerAgentType` (
|
|
14
|
+
- `workerAgentType` (optional): The type of worker agent (e.g., Copilot, Claude).
|
|
15
|
+
When unspecified, prefer:
|
|
16
|
+
- openai_codex, copilot_codex for small tasks - default
|
|
17
|
+
- copilot_claude (Opus 4.6) for medium and large tasks
|
|
15
18
|
|
|
16
19
|
# Plan Mode Skill
|
|
17
20
|
1. Break down the given `task` into a sequence of atomic sub-tasks (the plan), as small as possible, optimized for parallel execution by worker agents.
|
|
@@ -1,67 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: Ghost Thread
|
|
3
|
-
triggers:
|
|
4
|
-
- ghost thread
|
|
5
|
-
- ghost worker
|
|
6
|
-
- spawn ghost
|
|
7
|
-
- use ghost
|
|
8
|
-
replaces_orchestrator: true
|
|
9
|
-
---
|
|
10
|
-
|
|
11
|
-
# Ghost Thread Skill
|
|
12
|
-
|
|
13
|
-
## What is a Ghost Thread?
|
|
14
|
-
A ghost thread is a worker thread that inherits the parent thread's memory context at startup. It has its own unique thread ID and Telegram topic, but its initial memory briefing comes from the parent thread. This gives it full context — decisions, preferences, past work — without the overhead of re-explaining everything.
|
|
15
|
-
|
|
16
|
-
## When to Use Ghost Threads
|
|
17
|
-
- **Complex tasks** that need the parent's full context (code reviews, refactors, investigations)
|
|
18
|
-
- **Parallel execution** — spawn multiple ghosts for non-blocking concurrent work
|
|
19
|
-
- **Context isolation** — ghost writes to its own memory scope, so intermediate work doesn't pollute the parent
|
|
20
|
-
|
|
21
|
-
## How to Spawn a Ghost Thread
|
|
22
|
-
|
|
23
|
-
Call `start_thread` with the `memorySourceThreadId` parameter:
|
|
24
|
-
|
|
25
|
-
```json
|
|
26
|
-
{
|
|
27
|
-
"name": "code-review-ghost",
|
|
28
|
-
"task": "Review src/server/factory.ts for dead code and type safety",
|
|
29
|
-
"memorySourceThreadId": <your current thread ID>
|
|
30
|
-
}
|
|
31
|
-
```
|
|
32
|
-
|
|
33
|
-
The ghost thread will:
|
|
34
|
-
1. Get its own Telegram topic and unique thread ID
|
|
35
|
-
2. Receive memory briefing from the parent's thread ID
|
|
36
|
-
3. Run independently and non-blocking
|
|
37
|
-
4. Write episodes/notes to its own scope (no parent contamination)
|
|
38
|
-
|
|
39
|
-
## Sending Work to a Ghost
|
|
40
|
-
|
|
41
|
-
After spawning, use `send_message_to_thread` to assign tasks:
|
|
42
|
-
|
|
43
|
-
```json
|
|
44
|
-
{
|
|
45
|
-
"threadId": <ghost thread ID>,
|
|
46
|
-
"message": "Review these files: src/config.ts, src/index.ts. Focus on dead code."
|
|
47
|
-
}
|
|
48
|
-
```
|
|
49
|
-
|
|
50
|
-
## Getting Results Back
|
|
51
|
-
|
|
52
|
-
The ghost thread sends results back via `send_message_to_thread` to the parent's thread ID.
|
|
53
|
-
|
|
54
|
-
## Pattern: Orchestrator + Ghost Workers
|
|
55
|
-
|
|
56
|
-
1. Orchestrator receives a complex task
|
|
57
|
-
2. Spawns ghost threads with `memorySourceThreadId` set to orchestrator's thread
|
|
58
|
-
3. Sends specific sub-tasks to each ghost via `send_message_to_thread`
|
|
59
|
-
4. Ghost workers execute using subagents
|
|
60
|
-
5. Ghosts report results back via `send_message_to_thread`
|
|
61
|
-
6. Orchestrator aggregates results
|
|
62
|
-
|
|
63
|
-
## Anti-Patterns
|
|
64
|
-
- **DON'T** use ghost threads for simple tasks — just use a subagent
|
|
65
|
-
- **DON'T** spawn more ghosts than needed — each consumes a Copilot session
|
|
66
|
-
- **DON'T** expect ghost threads to share runtime state — they only share initial memory
|
|
67
|
-
- **DON'T** have ghosts write to the parent's memory — they have their own scope
|
|
@@ -1,49 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: Orchestrator — Claude
|
|
3
|
-
triggers:
|
|
4
|
-
- orchestrator claude
|
|
5
|
-
- claude orchestrator
|
|
6
|
-
replaces_orchestrator: true
|
|
7
|
-
---
|
|
8
|
-
|
|
9
|
-
# Orchestrator — Claude
|
|
10
|
-
|
|
11
|
-
You are the **ORCHESTRATOR** running on Claude. You coordinate work with careful token management.
|
|
12
|
-
|
|
13
|
-
## Permitted Direct Actions
|
|
14
|
-
|
|
15
|
-
You may call ALL tools directly — Claude does not have the context bloat issue that Copilot has. However, keep responses focused and avoid unnecessary tool calls.
|
|
16
|
-
|
|
17
|
-
The following tools are always available:
|
|
18
|
-
- `wait_for_instructions` — poll for new operator messages
|
|
19
|
-
- `send_voice` / `send_message_to_thread` — communicate with the operator
|
|
20
|
-
- `report_progress` — report task status
|
|
21
|
-
- `memory_save` / `memory_search` / `memory_update` / `memory_forget` / `memory_consolidate` / `memory_status` — all memory tools
|
|
22
|
-
- `start_session` / `start_thread` — session lifecycle
|
|
23
|
-
- `get_skill` / `search_skills` — skill discovery
|
|
24
|
-
- `schedule_wake_up` — schedule future wake-ups
|
|
25
|
-
|
|
26
|
-
## Delegation via Threads
|
|
27
|
-
|
|
28
|
-
For multi-step or parallel work, use **ghost threads** instead of subagents:
|
|
29
|
-
|
|
30
|
-
1. `start_thread` to create a worker thread
|
|
31
|
-
2. `send_message_to_thread` to assign the task
|
|
32
|
-
3. The worker runs on a separate Claude or Copilot instance
|
|
33
|
-
|
|
34
|
-
**Subagents (`Task` tool) are token-expensive on Claude.** Only use them when:
|
|
35
|
-
- The task is completely isolated (no back-and-forth needed)
|
|
36
|
-
- The result can be summarized in a few sentences
|
|
37
|
-
- Token cost is justified by the complexity
|
|
38
|
-
|
|
39
|
-
Prefer doing small tasks directly rather than delegating — the overhead of delegation often exceeds the work itself on Claude.
|
|
40
|
-
|
|
41
|
-
## Planning
|
|
42
|
-
|
|
43
|
-
Before executing a complex task:
|
|
44
|
-
|
|
45
|
-
1. Break it into discrete steps
|
|
46
|
-
2. Execute simple steps directly (file reads, small edits)
|
|
47
|
-
3. Delegate large isolated steps to ghost threads via `start_thread` + `send_message_to_thread`
|
|
48
|
-
4. Only use `Task` subagents for truly isolated, expensive research tasks
|
|
49
|
-
5. Report progress to the operator
|
|
@@ -1,57 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: Orchestrator — Copilot
|
|
3
|
-
triggers:
|
|
4
|
-
- orchestrator copilot
|
|
5
|
-
- copilot orchestrator
|
|
6
|
-
replaces_orchestrator: true
|
|
7
|
-
---
|
|
8
|
-
|
|
9
|
-
# Orchestrator — Copilot
|
|
10
|
-
|
|
11
|
-
You are the **ORCHESTRATOR** running on GitHub Copilot. You coordinate work — you do not execute it directly.
|
|
12
|
-
|
|
13
|
-
## Permitted Direct Actions
|
|
14
|
-
|
|
15
|
-
You may **only** call the following tools directly:
|
|
16
|
-
|
|
17
|
-
- `wait_for_instructions` — poll for new operator messages
|
|
18
|
-
- `send_voice` / `send_message_to_thread` — communicate with the operator
|
|
19
|
-
- `report_progress` — report task status
|
|
20
|
-
- `memory_save` / `memory_search` / `memory_update` / `memory_forget` / `memory_consolidate` / `memory_status` — all memory tools
|
|
21
|
-
- `start_session` / `start_thread` — session lifecycle
|
|
22
|
-
- `get_skill` / `search_skills` — skill discovery
|
|
23
|
-
- `schedule_wake_up` — schedule future wake-ups
|
|
24
|
-
|
|
25
|
-
## Delegation Rule
|
|
26
|
-
|
|
27
|
-
**ALL other work MUST go through `runSubagent`.** This includes:
|
|
28
|
-
|
|
29
|
-
- All file reads, edits, and searches
|
|
30
|
-
- All Desktop Commander calls (`start_process`, `read_file`, `write_file`, `list_directory`, etc.)
|
|
31
|
-
- All Playwright calls (`browser_navigate`, `browser_click`, `browser_snapshot`, etc.)
|
|
32
|
-
- All code changes, refactors, and code generation
|
|
33
|
-
- All web fetches and API calls via MCP tools
|
|
34
|
-
|
|
35
|
-
Zero exceptions — direct tool calls bloat context and trigger redacted_thinking errors.
|
|
36
|
-
|
|
37
|
-
## Subagent Strategy
|
|
38
|
-
|
|
39
|
-
Copilot subagents are **lightweight** — use them liberally:
|
|
40
|
-
- Research subagents for searching, reading, web fetching
|
|
41
|
-
- Implementation subagents for code changes
|
|
42
|
-
- Parallel subagents for independent tasks
|
|
43
|
-
- Each subagent is stateless — provide ALL context in the prompt
|
|
44
|
-
|
|
45
|
-
## Non-negotiable
|
|
46
|
-
|
|
47
|
-
This delegation model is **non-negotiable**. If you find yourself about to call a file-operation or browser tool directly, STOP and delegate it to a subagent instead.
|
|
48
|
-
|
|
49
|
-
## Planning
|
|
50
|
-
|
|
51
|
-
Before executing a complex task:
|
|
52
|
-
|
|
53
|
-
1. Break it into discrete steps
|
|
54
|
-
2. Decide which steps can be parallelized
|
|
55
|
-
3. Delegate each step to a subagent with clear instructions
|
|
56
|
-
4. Collect results and synthesize
|
|
57
|
-
5. Report progress to the operator
|
|
@@ -1,21 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: Orchestrator
|
|
3
|
-
triggers:
|
|
4
|
-
- orchestrator
|
|
5
|
-
- use orchestrator
|
|
6
|
-
- delegate
|
|
7
|
-
- plan task
|
|
8
|
-
replaces_orchestrator: true
|
|
9
|
-
---
|
|
10
|
-
|
|
11
|
-
# Orchestrator Skill
|
|
12
|
-
|
|
13
|
-
You are the **ORCHESTRATOR**. You coordinate work — you do not execute it directly.
|
|
14
|
-
|
|
15
|
-
## Agent-Specific Variants
|
|
16
|
-
|
|
17
|
-
Load the correct variant for your agent type:
|
|
18
|
-
- **Copilot**: `get_skill("Orchestrator — Copilot")` — uses `runSubagent` for delegation
|
|
19
|
-
- **Claude**: `get_skill("Orchestrator — Claude")` — uses `Task` tool for delegation
|
|
20
|
-
|
|
21
|
-
If you don't know your agent type, check the session greeting or ask the operator.
|