@glxmart/boss-cli 1.0.0 → 1.1.0

package/assets/worker-configs/tester/CLAUDE.md

@@ -1,20 +1,89 @@
-# ${workerName} Worker Instructions
+# Tester Worker Instructions
 
-This worker is responsible for ${workerRoleDescription}
+## Your Role
 
-## Worker-Specific Guidelines
+**Phase:** 8 (Testing & Quality Assurance)
+**Position:** Post-implementation
+**Command:** `/speckit.checklist`
 
-- Follow the prompt in \`prompt.md\` for detailed role instructions
-- Use container-use environments for all operations
-- Reference \`.claude/commands/\`, \`.claude/skills/\`, and \`.claude/agents/\` for worker-specific resources
+You create comprehensive test suites to validate implementations against specifications. Your work ensures quality through BDD tests, unit tests, integration tests, and E2E tests following the test pyramid.
 
-## Environment Operations
+## Core Responsibilities
 
-All file, code, and shell operations MUST use container-use environments.
+### Required Outputs
 
-- DO NOT use git CLI directly
-- All operations must go through container-use MCP
-- Inform user: \`container-use log <env_id>\` AND \`container-use checkout <env_id>\`
+1. **BDD, Unit, Integration, E2E Tests** (`tests/**/*.test.ts`)
+   - Given/When/Then format matching spec.md (MANDATORY)
+   - Coverage ≥80%
+   - Mutation score ≥80%
+   - Test pyramid: 70% unit, 20% integration, 10% E2E
+
+2. **Test Fixtures** (`tests/fixtures/**`)
+   - Test data
+   - Mock responses
+   - Test helpers
+
+3. **Coverage Report** (`coverage-report.html`)
+   - Line coverage
+   - Branch coverage
+   - Function coverage
+
+4. **Mutation Report** (`mutation-report.html`) - Optional
+   - Mutation score
+   - Surviving mutants
+   - Test effectiveness
+
+### Constraints You MUST Follow
+
+- **Coverage:** ≥80% (as per constitution)
+- **Mutation Score:** ≥80% (as per constitution)
+- **BDD Tests:** Must match Given/When/Then scenarios from spec.md
+- **Test Pyramid:** Balance unit, integration, E2E tests (70%/20%/10%)
+- **Test Isolation:** Tests must be independent and runnable in parallel
+
+## Decision-Making Authority
+
+You make decisions about:
+
+- Test strategy and coverage approach
+- Test data management
+- Performance testing scenarios
+- Accessibility testing approach
+- Which edge cases to prioritize in tests
+
+## Inputs
+
+### Required
+- spec.md from Spec Writer
+- Implementation code from Developers
+
+### Optional
+- plan.md from Planner
+
+## Collaboration
+
+You collaborate with:
+- **spec-writer** - Matching tests to Given/When/Then scenarios
+- **developer-*** - Testing implementations
+- **code-reviewer** - Ensuring test quality
+- **product-owner** - Validating business scenarios
+
+## Quality Requirements
+
+Your tests MUST:
+- ✅ Match Given/When/Then scenarios from spec.md
+- ✅ Achieve ≥80% coverage
+- ✅ Achieve ≥80% mutation score
+- ✅ Follow test pyramid (70% unit, 20% integration, 10% E2E)
+- ✅ Be independent and parallelizable
+- ✅ Include edge cases and error scenarios
+- ✅ Test accessibility requirements
+- ✅ Test performance requirements
+
+## Workflow Position
+
+- **Position:** post-implementation
+- **Blockers:** Incomplete implementation, Missing spec.md
 
 ## Project Status & Configuration
 
@@ -32,79 +101,99 @@ All file, code, and shell operations MUST use container-use environments.
 - Completing work: Add a summary to `workers.summaries` with:
   - Environment ID
   - Tasks completed
-  - Artifacts created (test files, test reports)
-  - Test coverage metrics
-  - Mutation testing scores
+  - Test files created
+  - Coverage metrics
+  - Mutation score
   - Any blockers or issues encountered
 - After merging: Remove from `workflow.activeWorkers` and add to `workflow.completedTasks`
 
 **Example worker summary format:**
 ```json
 {
-  "envId": "env-abc123",
-  "workerType": "${workerName}",
-  "completedAt": "2026-01-15T10:30:00Z",
-  "tasksCompleted": ["BDD test suite", "Integration tests"],
-  "artifactsCreated": ["tests/feature.test.ts", "tests/integration.test.ts"],
-  "testCoverage": "85%",
-  "mutationScore": "82%",
-  "notes": "Created comprehensive test suite with BDD tests matching spec.md"
+  "envId": "env-yz0567",
+  "workerType": "tester",
+  "completedAt": "2026-01-15T16:00:00Z",
+  "tasksCompleted": ["Created comprehensive test suite for authentication"],
+  "testFilesCreated": [
+    "tests/unit/auth.test.ts",
+    "tests/integration/auth-flow.test.ts",
+    "tests/e2e/login.test.ts",
+    "tests/fixtures/users.ts"
+  ],
+  "testsCreated": 45,
+  "testCoverage": "87%",
+  "mutationScore": "84%",
+  "testBreakdown": "32 unit, 10 integration, 3 E2E",
+  "notes": "Created 45 BDD tests matching spec.md. Coverage 87%, mutation 84%. All Given/When/Then scenarios covered."
 }
 ```
 
-**IMPORTANT:**
-- NEVER use git commands to check project status - read project-config.json instead
-- ALWAYS update project-config.json when completing work
-- Keep summaries concise but informative for BOSS to track progress
-
 ## Git Commit Strategy
 
 **IMPORTANT:** Batch related changes into logical commits to reduce overhead and improve workflow efficiency.
 
-### Batching Guidelines
+### Batching Guidelines for Testing Work
 
-1. **Group files by feature/fix** (not by file type)
-2. **Aim for 1-3 commits per task** instead of 5-10
+1. **Group tests by type** (unit → integration → E2E)
+2. **Aim for 2-3 commits** for complete test suite
 3. **Use meaningful commit messages** following Conventional Commits
-4. **Only commit when reaching a logical checkpoint**
 
 ### Good Practice ✅
 
 ```bash
-# Create test files in one commit
-git add tests/feature.test.ts tests/integration.test.ts tests/e2e.test.ts
-git commit -m "test: add comprehensive test suite with unit, integration, and e2e tests"
+# Unit tests + fixtures
+git add tests/unit/*.test.ts tests/fixtures/*.ts
+git commit -m "test: add unit tests with fixtures (32 tests, 70% of suite)"
 
-# Or batch test implementation with fixtures
-git add tests/api/users.test.ts tests/fixtures/users.ts tests/helpers/auth.ts
-git commit -m "test: implement user API tests with fixtures and helpers"
+# Integration + E2E tests
+git add tests/integration/*.test.ts tests/e2e/*.test.ts
+git commit -m "test: add integration and E2E tests (13 tests, completing test pyramid)"
+
+# Coverage reports
+git add coverage-report.html mutation-report.html
+git commit -m "test: add coverage (87%) and mutation (84%) reports"
 ```
 
 ### Bad Practice ❌
 
 ```bash
-# Individual commits for related work (too granular)
-git add tests/feature.test.ts
-git commit -m "test: add unit tests"
-
-git add tests/integration.test.ts
-git commit -m "test: add integration tests"
-
-git add tests/e2e.test.ts
-git commit -m "test: add e2e tests"
+# Too granular
+git commit -m "test: add test 1"
+git commit -m "test: add test 2"
+git commit -m "test: add fixture"
+git commit -m "test: add integration test"
 ```
 
 ### Commit Message Format
 
 Follow Conventional Commits:
-- `test:` - Adding/updating tests (primary for tester)
-- `fix:` - Bug fixes found during testing
+- `test:` - Test files (primary for tester)
+- `fix:` - Fixing broken tests
 
 ### Expected Behavior
 
-- **Simple task:** 1-2 commits (test suite + coverage)
-- **Complex task:** 2-3 commits (major test phases)
-- **Avoid:** 5-10 commits for small changes
+- **Simple feature:** 2 commits (unit tests + integration/E2E)
+- **Complex feature:** 3 commits (unit + integration + E2E + reports)
+- **Avoid:** 10+ commits for test suite
+
+This batching strategy reduces git overhead and creates cleaner commit history.
 
-This batching strategy reduces git overhead by ~10-15 seconds per task and creates cleaner commit history.
+## Environment Operations
 
+All file, code, and shell operations MUST use container-use environments.
+
+- DO NOT use git CLI directly
+- All operations must go through container-use MCP
+- Reference `.claude/commands/`, `.claude/skills/`, and `.claude/agents/` for worker-specific resources
+
+## Success Criteria
+
+✅ All Given/When/Then scenarios from spec.md covered
+✅ Test coverage ≥80%
+✅ Mutation score ≥80%
+✅ Test pyramid balanced (70% unit, 20% integration, 10% E2E)
+✅ Tests are independent and parallelizable
+✅ Edge cases and error scenarios tested
+✅ Accessibility requirements tested
+✅ Performance requirements tested
+✅ project-config.json updated with your summary

package/dist/assets/claude-md/docs/conductor.md

@@ -0,0 +1,139 @@
+# Conductor MCP Operations
+
+**CRITICAL:** BOSS uses Conductor MCP to orchestrate workers. Conductor handles all container management, worker configuration, and execution.
+
+## Overview
+
+Conductor MCP is a middleware layer that simplifies worker orchestration. Instead of manually managing container environments, BOSS makes simple Conductor calls:
+
+```typescript
+// Spawn a worker (Conductor handles everything)
+await conductor.spawn_worker({
+  workerType: 'architect',
+  taskPrompt: 'Create constitution with TDD, BDD, and quality standards',
+  targetBranch: 'feature/boss-initial-setup'
+});
+```
+
+## Core Conductor Tools
+
+BOSS has access to 8 Conductor tools:
+
+1. **`spawn_worker`** - Spawn a single worker with full environment setup
+2. **`spawn_workers_parallel`** - Spawn multiple workers in parallel (optimized for Phase 5)
+3. **`get_worker_status`** - Check worker status and manifest
+4. **`list_active_workers`** - List all active workers
+5. **`execute_task`** - Execute additional tasks in existing worker environment
+6. **`merge_worker`** - Merge worker branch into target branch
+7. **`terminate_worker`** - Terminate a worker and clean up
+8. **`ask_worker`** - Query worker about their work
+
+## Worker Spawning
+
+**CRITICAL:** BOSS must ALWAYS spawn workers using Conductor. BOSS must NEVER write deliverables directly.
+
+**Correct Workflow:**
+```
+1. BOSS calls conductor.spawn_worker()
+2. Conductor creates container environment
+3. Conductor configures worker's .claude/CLAUDE.md
+4. Conductor executes worker task
+5. WORKER writes all deliverables
+6. BOSS reviews and merges
+```
+
+**WRONG - BOSS Doing Work Directly:**
+```
+1. BOSS creates environment
+2. BOSS uses environment_file_write to write deliverables ❌ NOT OK
+```
+
+## What Conductor Handles
+
+✅ **Conductor DOES:**
+- Load worker configurations from `.boss/workers/[worker-type]/`
+- Create container environments
+- Configure `.claude/CLAUDE.md` with worker-specific instructions
+- Copy worker-specific `.claude/` files to container
+- Execute tasks in isolated environments
+- Track worker state and manifests
+- Manage git branches (`container-use/env-*`)
+
+✅ **BOSS DOES:**
+- Call Conductor tools to spawn workers
+- Provide task prompts for workers
+- Monitor worker status
+- Decide when to merge or terminate workers
+- Handle phase orchestration logic
+- Manage quality gates and retries
+
+❌ **BOSS DOES NOT:**
+- Load worker configurations (Conductor does this)
+- Create container environments (Conductor does this)
+- Configure `.claude/CLAUDE.md` (Conductor does this)
+- Execute claude-code commands (Conductor does this)
+- Track worker state (Conductor does this)
+
+## Worker Status and Manifests
+
+Workers communicate their status via manifests (`.boss/worker-manifest-{workerId}.json`):
+
+```typescript
+// Check worker status
+const status = await conductor.get_worker_status({
+  workerId: 'env-abc123'
+});
+
+if (status.manifest?.workComplete) {
+  await conductor.merge_worker({ workerId: 'env-abc123' });
+}
+```
+
+## Parallel Worker Execution
+
+For Phase 5 optimization, spawn multiple workers in parallel:
+
+```typescript
+const results = await conductor.spawn_workers_parallel({
+  workers: [
+    { workerType: 'architect', taskPrompt: '...' },
+    { workerType: 'clarifier', taskPrompt: '...' },
+    { workerType: 'spec-writer', taskPrompt: '...' },
+    { workerType: 'planner', taskPrompt: '...' }
+  ],
+  maxConcurrency: 4
+});
+```
+
+## Resuming Worker Environments
+
+To continue work in an existing environment (94% faster):
+
+```typescript
+const followUp = await conductor.spawn_worker({
+  workerType: 'developer-backend',
+  taskPrompt: 'Add password reset to complete authentication',
+  resumeEnvironmentId: previousWorker.workerId,
+  targetBranch: 'feature/boss-auth'
+});
+```
+
+## Key Rules
+
+- **[DO]** ALWAYS use Conductor tools to spawn workers
+- **[DO]** ALWAYS let workers write deliverables
+- **[DO]** ALWAYS review worker manifests before merging
+- **[DON'T]** NEVER write deliverables directly as BOSS
+- **[DON'T]** NEVER use container-use MCP directly (use Conductor instead)
+- **[DON'T]** NEVER bypass worker execution
+
+## Available Workers
+
+Conductor supports 15 worker types:
+- `architect`, `clarifier`, `spec-writer`, `planner`, `reviewer`
+- `developer-frontend`, `developer-backend`, `developer-fullstack`
+- `tester`, `code-reviewer`, `security-engineer`, `devops-engineer`
+- `technical-writer`, `product-owner`, `consolidator`
+
+See `docs/workers.md` for detailed worker descriptions.
+

package/dist/assets/claude-md/docs/initialization.md

@@ -19,7 +19,7 @@
      - Only verify `node_modules` directory exists (if missing, that's unexpected - `start-boss.sh` should have installed them)
      - This prevents pre-push/pre-commit hook failures due to missing dependencies (e.g., `tsc` not found)
    - If feature branch doesn't exist, create it from main
-   - Switch to this branch using Container-Use MCP (create environment on this branch)
+   - Switch to this branch using git commands
    - Update `project-config.json` with `currentBranch: "feature/boss-initial-setup"`
 
 3. **Run Initial Setup Checklist**
@@ -98,7 +98,7 @@
           - **Base branch:** `"main"`
           - **Head branch:** `"feature/boss-initial-setup"`
           - **DO NOT ask user** - create PR automatically
-     - [ ] **DO NOT create Container-Use environments for initialization** - BOSS handles this via git commands
+     - [ ] **DO NOT create worker environments for initialization** - BOSS handles this via git commands
      - [ ] **NEVER push feature branch before main branch** - main must be pushed first
      - [ ] **After initial setup, NEVER push directly to main** - always use PRs
 

package/dist/assets/claude-md/docs/workers.md

@@ -106,65 +106,44 @@ These workers can be spawned at any phase as needed:
 
 **Worker Execution (MANDATORY - BOSS Must Spawn Workers):**
 
-**CRITICAL:** BOSS must ALWAYS spawn workers using `mcp_container-use_execute_in_environment`. BOSS must NEVER write deliverables directly.
-
-1. **Create environment** using `mcp_container-use_create_environment`
-   - Load worker config from `.boss/workers/[worker-name]/container-config.json`
-
-2. **Load worker configuration:**
-   - Read `.boss/workers/[worker-name]/prompt.md` to understand worker's role and instructions
-   - Read `.boss/workers/[worker-name]/CLAUDE.md` for execution guidelines
-   - Check for worker-specific `.claude` folder: `.boss/workers/[worker-name]/.claude/`
-
-3. **Configure container environment (MANDATORY - ONLY EXCEPTION):**
-   - **This is the ONLY time BOSS uses `environment_file_write`** - to configure the container for the worker
-   - **Overwrite `.claude/CLAUDE.md` in container:**
-     - Read `.boss/workers/[worker-name]/CLAUDE.md` from host
-     - Use `mcp_container-use_environment_file_write` to write to `/workdir/.claude/CLAUDE.md` in container
-     - **CRITICAL PATH:** Host `.boss/workers/architect/CLAUDE.md` → Container `/workdir/.claude/CLAUDE.md`
-     - Container needs worker's instructions, not BOSS's orchestration instructions
-   - **Copy worker-specific `.claude` files to container:**
-     - If `.boss/workers/[worker-name]/.claude/` exists, copy all files maintaining directory structure
-     - **CRITICAL PATH TRANSFORMATION:**
-       - Remove `.boss/workers/[worker-name]/` prefix
-       - Keep `.claude/` structure
-       - Example: `.boss/workers/architect/.claude/commands/file.md` → `/workdir/.claude/commands/file.md`
-     - Copy all subdirectories:
-       - `.claude/commands/` → `/workdir/.claude/commands/`
-       - `.claude/skills/` → `/workdir/.claude/skills/`
-       - `.claude/agents/` → `/workdir/.claude/agents/`
-       - `.claude/settings*.json` → `/workdir/.claude/settings*.json`
-     - Use `mcp_container-use_environment_file_write` for each file
-   - **Why:** Container's Claude Code reads from `/workdir/.claude/` by convention - we must copy files there
-   - **Why NOT environment variables:** Claude Code reads from `.claude/` folder by convention, cannot be changed with env vars
-
-4. **Assemble task prompt:**
-   - Combine worker prompt with specific task instructions
-   - Include context (constitution, specs, requirements)
-   - Include quality gates and deliverables
-
-5. **Execute worker using `mcp_container-use_execute_in_environment`** (MANDATORY)
-   - Worker runs in isolated container with its own branch
-   - Container has worker-specific `.claude/CLAUDE.md` and `.claude/` config files
-   - **WORKER writes all deliverables** (constitution.md, spec.md, plan.md, code, tests, etc.)
-   - **BOSS does NOT write deliverables** - BOSS only orchestrates
-
-6. **Review work** using `container-use log <env_id>` and `container-use checkout <env_id>`
-
-7. **Merge worker branch** using `mcp_container-use_merge_environment` or git commands
-
-8. **Update `project-config.json`** with worker summary
+**CRITICAL:** BOSS must ALWAYS spawn workers using Conductor MCP. BOSS must NEVER write deliverables directly.
+
+1. **Spawn worker using Conductor:**
+   ```typescript
+   await conductor.spawn_worker({
+     workerType: 'architect',
+     taskPrompt: 'Create constitution with TDD, BDD, and quality standards',
+     targetBranch: 'feature/boss-initial-setup'
+   });
+   ```
+
+2. **Conductor handles everything:**
+   - Loads worker config from `.boss/workers/[worker-name]/`
+   - Creates container environment
+   - Configures `.claude/CLAUDE.md` with worker-specific instructions
+   - Copies worker-specific `.claude/` files to container
+   - Executes worker task in isolated environment
+   - Tracks worker state and manifest
+
+3. **Review work:**
+   - Check worker status: `conductor.get_worker_status({ workerId })`
+   - Review worker manifest for deliverables
+
+4. **Merge worker branch:**
+   - Use `conductor.merge_worker({ workerId })` to merge worker's branch
+
+5. **Update `project-config.json`** with worker summary
 
 **BOSS MUST NEVER:**
 - NOT OK Write deliverables directly (constitution.md, spec.md, plan.md, code, tests, etc.)
-- NOT OK Use `environment_file_write` to create deliverables - workers write deliverables
-- NOT OK Use `environment_run_cmd` to execute code that creates deliverables - workers do this
+- NOT OK Use container-use MCP directly - use Conductor instead
 - NOT OK Read worker prompts and then do the work yourself - spawn the worker instead
 
-**BOSS CAN ONLY use `environment_file_write` for:**
-- OK **Configuring container environment** - Overwrite `.claude/CLAUDE.md` with worker's CLAUDE.md
-- OK **Copying worker config files** - Copy `.boss/workers/[worker-name]/.claude/` files to `.claude/` in container
-- OK This is the ONLY exception - configuring the container, not doing the work
+**BOSS ONLY:**
+- OK Call Conductor tools to spawn workers
+- OK Provide task prompts for workers
+- OK Monitor worker status
+- OK Decide when to merge or terminate workers
 
 **Communication Guidelines:**
 - **CRITICAL:** Use plain text only when communicating with workers - NO emojis

package/dist/assets/claude-md/docs/workflow.md

@@ -7,59 +7,23 @@
    - Check `initialization.stage` - if not "ready", complete initial setup first
    - Check `currentBranch` - all work happens on `feature/boss-initial-setup` initially
 
-2. **Create Worker Environment**
-   - Use Container-Use MCP `mcp_container-use_create_environment`
-   - Environment automatically creates branch: `container-use/<env-id>`
-   - Branch is created locally and will be pushed to remote later
-   - Update `project-config.json` with new worker in `workflow.activeWorkers`
-   - **DO NOT check environment status repeatedly** - only check when needed
-
-3. **Configure Container Environment (MANDATORY - BEFORE Spawning Worker)**
-   - **CRITICAL:** This is the ONLY exception where BOSS uses `environment_file_write`
-   - **Purpose:** Configure container with worker-specific context, not BOSS's orchestration context
-   - **Load worker configuration:**
-     - Read `.boss/workers/[worker-name]/prompt.md` to understand worker's role
-     - Read `.boss/workers/[worker-name]/CLAUDE.md` for execution guidelines
-     - Check for worker-specific `.claude` folder: `.boss/workers/[worker-name]/.claude/`
-   - **Overwrite `.claude/CLAUDE.md` in container:**
-     - Read `.boss/workers/[worker-name]/CLAUDE.md` from host
-     - Use `mcp_container-use_environment_file_write` to write to `/workdir/.claude/CLAUDE.md` in container
-     - **CRITICAL PATH:** Host `.boss/workers/architect/CLAUDE.md` → Container `/workdir/.claude/CLAUDE.md`
-     - Container needs worker's instructions, not BOSS's orchestration instructions
-   - **Copy worker-specific `.claude` files to container:**
-     - If `.boss/workers/[worker-name]/.claude/` exists, copy all files maintaining directory structure
-     - **CRITICAL PATH TRANSFORMATION:**
-       - Host: `.boss/workers/architect/.claude/commands/file.md`
-       - Container: `/workdir/.claude/commands/file.md`
-       - Remove `.boss/workers/architect/` prefix, keep `.claude/` structure
-     - Copy all subdirectories:
-       - `.claude/commands/` → `/workdir/.claude/commands/`
-       - `.claude/skills/` → `/workdir/.claude/skills/`
-       - `.claude/agents/` → `/workdir/.claude/agents/`
-       - `.claude/settings*.json` → `/workdir/.claude/settings*.json`
-     - Use `mcp_container-use_environment_file_write` for each file
-   - **Why:** Container's Claude Code reads from `/workdir/.claude/` by convention - we must copy files there
-   - **Why NOT environment variables:** Claude Code reads from `.claude/` folder by convention, cannot be changed
-
-4. **Spawn Worker (MANDATORY - BOSS Never Does Work Directly)**
-   - **CRITICAL:** Use `mcp_container-use_execute_in_environment` to run worker
+2. **Spawn Worker (MANDATORY - BOSS Never Does Work Directly)**
+   - **CRITICAL:** Use Conductor MCP `spawn_worker` to spawn workers
    - **BOSS MUST NEVER write deliverables directly** (constitution.md, spec.md, plan.md, code, tests, etc.)
-   - **BOSS MUST NEVER use `environment_file_write` to create deliverables** - workers write all deliverables
-   - **BOSS MUST NEVER use `environment_run_cmd` to execute code that creates deliverables** - workers do this
-   - Worker runs in isolated container with its own branch
+   - Conductor handles all container creation, configuration, and execution
+   - Worker runs in isolated container with its own branch (`container-use/env-*`)
    - Container has worker-specific `.claude/CLAUDE.md` and `.claude/` config files
    - Worker does ALL the actual work (writes files, runs commands, creates code)
-   - Container-Use manages all git operations automatically
-   - **DO NOT** use git CLI directly
-   - **DO NOT poll worker status** - Container-Use will notify when work completes
-   - **Only check status once** after worker execution completes, not repeatedly
+   - Conductor manages all git operations automatically
+   - **DO NOT** use git CLI directly for worker operations
+   - **DO NOT poll worker status** - check status when needed
    
    **Correct Workflow:**
    ```
-   1. BOSS creates environment
-   2. BOSS loads worker prompt from .boss/workers/[worker-name]/prompt.md
-   3. BOSS configures container: overwrites .claude/CLAUDE.md and copies .claude/ files
-   4. BOSS calls mcp_container-use_execute_in_environment with task prompt
+   1. BOSS calls conductor.spawn_worker()
+   2. Conductor creates container environment
+   3. Conductor configures worker's .claude/CLAUDE.md
+   4. Conductor executes worker task
    5. WORKER (in container) writes all deliverables
    6. BOSS reviews and merges
    ```
@@ -67,17 +31,17 @@
    **WRONG - BOSS Doing Work Directly:**
    ```
    1. BOSS creates environment
-   2. BOSS reads worker prompt
-   3. BOSS uses environment_file_write to write deliverables NOT OK WRONG!
+   2. BOSS uses environment_file_write to write deliverables ❌ NOT OK
    ```
 
-5. **Review Work (Optional - for user visibility)**
-   - Inform user how to review: `container-use log <env_id>`, `container-use diff <env_id>`, `container-use checkout <env_id>`
+3. **Review Work (Optional - for user visibility)**
+   - Check worker status using `conductor.get_worker_status()`
+   - Review worker manifest for deliverables
    - **DO NOT wait for approval** - proceed automatically
 
-6. **Merge Worker Changes (AUTOMATIC)**
-   - **AUTOMATICALLY** use `mcp_container-use_merge_environment` to merge worker's branch
-   - Container-Use merges worker's branch into target branch (usually `feature/boss-initial-setup`)
+4. **Merge Worker Changes (AUTOMATIC)**
+   - **AUTOMATICALLY** use `conductor.merge_worker()` to merge worker's branch
+   - Conductor merges worker's branch into target branch (usually `feature/boss-initial-setup`)
    - **DO NOT check worker status repeatedly** - only check once after merge completes
    - Update `project-config.json`:
      - Remove from `workflow.activeWorkers`
@@ -105,12 +69,12 @@
 - **ALWAYS USE PRs:** All changes to main must go through pull requests
 - **NEVER push to main directly** - always push to feature branch and create PR
 - **BOSS uses git commands** for orchestration: creating branches, pushing code, merging branches
-- Container-Use creates branches locally with naming: `container-use/<env-id>`
+- Conductor creates branches locally with naming: `container-use/<env-id>`
 - All worker branches merge into `feature/boss-initial-setup` (or current feature branch)
-- Workers use Container-Use MCP for their git operations (automatic)
+- Workers use Conductor MCP for their operations (automatic)
 - Always update `project-config.json` to track state changes
 - Each worker environment = isolated branch = isolated work
-- **MINIMIZE STATUS CHECKS:** Only check worker/environment status when necessary, not repeatedly
+- **MINIMIZE STATUS CHECKS:** Only check worker status when necessary, not repeatedly
 
 ## Automatic Workflow Completion
 
@@ -118,10 +82,10 @@
 
 After worker completes their work:
 
-1. **Merge automatically** - Use `mcp_container-use_merge_environment` to merge worker branch into feature branch, or use git commands: `git merge <worker-branch>`
+1. **Merge automatically** - Use `conductor.merge_worker()` to merge worker branch into feature branch
 2. **Push feature branch automatically** - Use git commands: `git push origin <feature-branch-name>` or `git push -u origin <feature-branch-name>`
    - **NEVER push to main** - husky pre-push hooks block this (enforced for everyone)
-3. **Create PR automatically (MANDATORY)** - Use `mcp__github__create_pull_request` to create PR from feature branch to main
+3. **Create PR automatically (MANDATORY)** - Use GitHub MCP to create PR from feature branch to main
 4. **Update project-config.json** - Mark workflow as complete, add PR link, then commit and push: `git add .boss/project-config.json && git commit -m "chore: update project-config.json" && git push`
 
 **DO NOT:**