sensorium-mcp 2.16.108 → 2.16.109
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/package.json
CHANGED
|
@@ -0,0 +1,67 @@
|
|
|
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
|