claude-multi-session 2.3.0 → 2.3.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-multi-session",
-  "version": "2.3.0",
+  "version": "2.3.1",
   "description": "Multi-session orchestrator for Claude Code CLI — spawn, control, pause, resume, and send multiple inputs to Claude Code sessions programmatically",
   "main": "src/index.js",
   "bin": {

package/src/prompts.js

@@ -66,6 +66,15 @@ Your inbox may contain:
 - Dependency artifacts you need before starting
 - Updated instructions from the orchestrator
 
+### Step 1.5: CHECK FOR SHARED CONVENTIONS
+Call \`mcp__multi-session__artifact_list\` and look for a conventions or API contract artifact.
+If one exists, call \`mcp__multi-session__artifact_get\` to read it and follow those conventions STRICTLY.
+Conventions may define: response format, status codes, naming rules, error format, file path rules.
+
+If NO convention artifact exists AND your work must match other workers' output:
+- Use \`team_ask\` to ask the relevant teammate about their format BEFORE writing code
+- NEVER guess or assume format — mismatches cause test failures
+
 ### Step 2: UPDATE YOUR STATUS
 Call \`mcp__multi-session__team_update_status\` to set yourself as "active" with your current task.
 
@@ -137,6 +146,8 @@ IMPORTANT: Follow these rules strictly. Violating them causes coordination failu
 
 8. **If you are blocked, say so.** Update your status to "busy" with a note about what you're waiting for, and send a \`team_ask\` to the teammate who can unblock you.
 
+9. **ALWAYS use relative file paths in code.** When creating database files, configs, or any path in generated code, use RELATIVE paths (e.g., \`path.join(__dirname, '..', 'data.db')\`). NEVER hardcode absolute paths like \`C:\\...\` or \`/home/...\` — they break portability.
+
 <examples>
 
 <example>
@@ -458,6 +469,8 @@ IMPORTANT: You are the ORCHESTRATOR. Your job is to PLAN, SPAWN, and MONITOR —
 - Do NOT fix bugs found by one session yourself — tell that session to fix them
 - Do NOT act as a message router between sessions — they can talk directly
 - Do NOT do implementation work that should be delegated
+- Do NOT fix code yourself when a worker's tests fail — send corrections to the worker that wrote the failing code
+- Do NOT assume workers will agree on response formats — define shared conventions before spawning
 
 === CORRECT PATTERN ===
 1. Plan the work and identify parallel tasks
@@ -474,6 +487,36 @@ Break the user's request into independent work units. Identify:
 - What tasks are SEQUENTIAL (B needs output from A)
 - What ROLES are needed (backend, frontend, testing, etc.)
 
+### Phase 1.5: Define Shared Conventions
+IMPORTANT: Before spawning workers, define shared conventions that ALL workers must follow. Either:
+(a) Publish a conventions artifact that workers will read, OR
+(b) Include the same convention rules in every worker's prompt
+
+Conventions MUST cover:
+- **Response format:** e.g., "All endpoints return { data: <result> } for success"
+- **Error format:** e.g., "All errors return { error: <message> }"
+- **Status codes:** e.g., "201 for create, 200 for update/delete/read, 404 for not found, 400 for validation"
+- **Naming:** e.g., "snake_case for DB fields (in_progress not in-progress)"
+- **File paths:** "Use relative paths only — never absolute"
+
+\`\`\`
+// Example: publish conventions before spawning workers
+mcp__multi-session__artifact_publish({
+  artifactId: "shared-conventions",
+  type: "api-contract",
+  name: "Shared API Conventions",
+  data: {
+    responseFormat: "{ data: <result> }",
+    errorFormat: "{ error: <message> }",
+    statusCodes: { create: 201, read: 200, update: 200, delete: 200, notFound: 404, badRequest: 400 },
+    naming: "snake_case for DB fields",
+    paths: "relative only, never absolute"
+  }
+})
+\`\`\`
+
+NEVER assume workers will independently agree on conventions. Define them explicitly.
+
 ### Phase 2: Spawn Workers (use team_spawn, NOT delegate_task)
 Spawn all independent workers at once. Example:
 
@@ -675,10 +718,14 @@ const ROLE_PROMPTS = {
 
   'testing': `
 ### Role-Specific: Test Engineer
-- ALWAYS check artifact_list for API contracts and schemas before writing tests
-- If dependencies are not yet published, use team_ask to check when they'll be ready
+- CRITICAL: NEVER assume response format, status codes, or field names. Before writing ANY test:
+  1. Check \`artifact_list\` for a shared-conventions or api-contract artifact
+  2. If found, use \`artifact_get\` to read it and match your assertions to those conventions
+  3. If NOT found, use \`team_ask\` to ask route/API workers: "What response format and status codes do your endpoints use?"
+  4. Only write tests AFTER you know the exact response shape
 - Publish test results as artifacts with type "test-results" including: passed, failed, skipped counts and failure details
-- If tests fail due to bugs in another session's code, use team_send_message to notify them with the exact error and file path
+- If tests fail due to bugs in another session's code, use \`team_send_message\` to notify them with the exact error and file path
+- Use the correct status values as defined in the database schema (e.g., "in_progress" not "in-progress")
 `,
 
   'database': `
@@ -762,6 +809,8 @@ IMPORTANT: You are the ORCHESTRATOR. Your job is to PLAN, SPAWN, and MONITOR —
 
 1. **Plan** — Break the user's request into independent work units. Identify what can run in PARALLEL vs what is SEQUENTIAL.
 
+1.5. **Define Conventions** — Before spawning, define shared conventions (response format, status codes, naming) either as a published artifact or in each worker's prompt. Workers CANNOT coordinate on conventions after they start — define them upfront.
+
 2. **Spawn** — Use \`team_spawn\` to launch all independent workers in a SINGLE message with multiple tool calls. This makes them run in parallel. NEVER spawn workers one at a time sequentially.
 
 3. **Tell workers** — Every worker prompt MUST include instructions to:
@@ -819,6 +868,7 @@ IMPORTANT: Always tell workers in their prompt to:
 3. Publish results as artifacts (\`artifact_publish\`)
 4. Broadcast completion (\`team_broadcast\`)
 5. Update their status when done (\`team_update_status\`)
+6. Follow shared conventions you defined (include the convention rules in the prompt OR tell them to read the conventions artifact)
 `;
 
 const ORCHESTRATOR_DELEGATE = `
@@ -859,7 +909,7 @@ WHY: Specific file, exact error, expected behavior, and how to verify.
 const ORCHESTRATOR_MONITORING = `
 ## How to Monitor Without Micromanaging
 
-Check progress periodically — do NOT read full outputs from workers:
+You MUST check progress using these tools after spawning workers — do NOT fall back to filesystem checks (Glob, Read) to verify worker output:
 
 \`\`\`
 mcp__multi-session__team_roster()      — See who's active/idle/blocked