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/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "sensorium-mcp",
3
- "version": "2.17.8",
3
+ "version": "2.17.11",
4
4
  "description": "MCP server for remote control of AI assistants via Telegram",
5
5
  "main": "dist/index.js",
6
6
  "bin": {
@@ -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` (required): The type of worker agent (e.g., Copilot, Claude).
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.