@iaforged/context-code 1.0.58 → 1.0.61

package/dist/src/services/MagicDocs/prompts.js

@@ -5,55 +5,55 @@ import { getFsImplementation } from '../../utils/fsOperations.js';
  * Get the Magic Docs update prompt template
  */
 function getUpdatePromptTemplate() {
-    return `IMPORTANT: This message and these instructions are NOT part of the actual user conversation. Do NOT include any references to "documentation updates", "magic docs", or these update instructions in the document content.
-
-Based on the user conversation above (EXCLUDING this documentation update instruction message), update the Magic Doc file to incorporate any NEW learnings, insights, or information that would be valuable to preserve.
-
-The file {{docPath}} has already been read for you. Here are its current contents:
-<current_doc_content>
-{{docContents}}
-</current_doc_content>
-
-Document title: {{docTitle}}
-{{customInstructions}}
-
-Your ONLY task is to use the Edit tool to update the documentation file if there is substantial new information to add, then stop. You can make multiple edits (update multiple sections as needed) - make all Edit tool calls in parallel in a single message. If there's nothing substantial to add, simply respond with a brief explanation and do not call any tools.
-
-CRITICAL RULES FOR EDITING:
-- Preserve the Magic Doc header exactly as-is: # MAGIC DOC: {{docTitle}}
-- If there's an italicized line immediately after the header, preserve it exactly as-is
-- Keep the document CURRENT with the latest state of the codebase - this is NOT a changelog or history
-- Update information IN-PLACE to reflect the current state - do NOT append historical notes or track changes over time
-- Remove or replace outdated information rather than adding "Previously..." or "Updated to..." notes
-- Clean up or DELETE sections that are no longer relevant or don't align with the document's purpose
-- Fix obvious errors: typos, grammar mistakes, broken formatting, incorrect information, or confusing statements
-- Keep the document well organized: use clear headings, logical section order, consistent formatting, and proper nesting
-
-DOCUMENTATION PHILOSOPHY - READ CAREFULLY:
-- BE TERSE. High signal only. No filler words or unnecessary elaboration.
-- Documentation is for OVERVIEWS, ARCHITECTURE, and ENTRY POINTS - not detailed code walkthroughs
-- Do NOT duplicate information that's already obvious from reading the source code
-- Do NOT document every function, parameter, or line number reference
-- Focus on: WHY things exist, HOW components connect, WHERE to start reading, WHAT patterns are used
-- Skip: detailed implementation steps, exhaustive API docs, play-by-play narratives
-
-What TO document:
-- High-level architecture and system design
-- Non-obvious patterns, conventions, or gotchas
-- Key entry points and where to start reading code
-- Important design decisions and their rationale
-- Critical dependencies or integration points
-- References to related files, docs, or code (like a wiki) - help readers navigate to relevant context
-
-What NOT to document:
-- Anything obvious from reading the code itself
-- Exhaustive lists of files, functions, or parameters
-- Step-by-step implementation details
-- Low-level code mechanics
-- Information already in CLAUDE.md or other project docs
-
-Use the Edit tool with file_path: {{docPath}}
-
+    return `IMPORTANT: This message and these instructions are NOT part of the actual user conversation. Do NOT include any references to "documentation updates", "magic docs", or these update instructions in the document content.
+
+Based on the user conversation above (EXCLUDING this documentation update instruction message), update the Magic Doc file to incorporate any NEW learnings, insights, or information that would be valuable to preserve.
+
+The file {{docPath}} has already been read for you. Here are its current contents:
+<current_doc_content>
+{{docContents}}
+</current_doc_content>
+
+Document title: {{docTitle}}
+{{customInstructions}}
+
+Your ONLY task is to use the Edit tool to update the documentation file if there is substantial new information to add, then stop. You can make multiple edits (update multiple sections as needed) - make all Edit tool calls in parallel in a single message. If there's nothing substantial to add, simply respond with a brief explanation and do not call any tools.
+
+CRITICAL RULES FOR EDITING:
+- Preserve the Magic Doc header exactly as-is: # MAGIC DOC: {{docTitle}}
+- If there's an italicized line immediately after the header, preserve it exactly as-is
+- Keep the document CURRENT with the latest state of the codebase - this is NOT a changelog or history
+- Update information IN-PLACE to reflect the current state - do NOT append historical notes or track changes over time
+- Remove or replace outdated information rather than adding "Previously..." or "Updated to..." notes
+- Clean up or DELETE sections that are no longer relevant or don't align with the document's purpose
+- Fix obvious errors: typos, grammar mistakes, broken formatting, incorrect information, or confusing statements
+- Keep the document well organized: use clear headings, logical section order, consistent formatting, and proper nesting
+
+DOCUMENTATION PHILOSOPHY - READ CAREFULLY:
+- BE TERSE. High signal only. No filler words or unnecessary elaboration.
+- Documentation is for OVERVIEWS, ARCHITECTURE, and ENTRY POINTS - not detailed code walkthroughs
+- Do NOT duplicate information that's already obvious from reading the source code
+- Do NOT document every function, parameter, or line number reference
+- Focus on: WHY things exist, HOW components connect, WHERE to start reading, WHAT patterns are used
+- Skip: detailed implementation steps, exhaustive API docs, play-by-play narratives
+
+What TO document:
+- High-level architecture and system design
+- Non-obvious patterns, conventions, or gotchas
+- Key entry points and where to start reading code
+- Important design decisions and their rationale
+- Critical dependencies or integration points
+- References to related files, docs, or code (like a wiki) - help readers navigate to relevant context
+
+What NOT to document:
+- Anything obvious from reading the code itself
+- Exhaustive lists of files, functions, or parameters
+- Step-by-step implementation details
+- Low-level code mechanics
+- Information already in CLAUDE.md or other project docs
+
+Use the Edit tool with file_path: {{docPath}}
+
 REMEMBER: Only update if there is substantial new information. The Magic Doc header (# MAGIC DOC: {{docTitle}}) must remain unchanged.`;
 }
 /**
@@ -90,13 +90,13 @@ export async function buildMagicDocsUpdatePrompt(docContents, docPath, docTitle,
     const promptTemplate = await loadMagicDocsPrompt();
     // Build custom instructions section if provided
     const customInstructions = instructions
-        ? `
-
-DOCUMENT-SPECIFIC UPDATE INSTRUCTIONS:
-The document author has provided specific instructions for how this file should be updated. Pay extra attention to these instructions and follow them carefully:
-
-"${instructions}"
-
+        ? `
+
+DOCUMENT-SPECIFIC UPDATE INSTRUCTIONS:
+The document author has provided specific instructions for how this file should be updated. Pay extra attention to these instructions and follow them carefully:
+
+"${instructions}"
+
 These instructions take priority over the general rules below. Make sure your updates align with these specific guidelines.`
         : '';
     // Substitute variables in the prompt

package/dist/src/services/PromptSuggestion/promptSuggestion.js

@@ -184,35 +184,35 @@ export function getParentCacheSuppressReason(lastAssistantMessage) {
         ? 'cache_cold'
         : null;
 }
-const SUGGESTION_PROMPT = `[SUGGESTION MODE: Suggest what the user might naturally type next into Context Code.]
-
-FIRST: Look at the user's recent messages and original request.
-
-Your job is to predict what THEY would type - not what you think they should do.
-
-THE TEST: Would they think "I was just about to type that"?
-
-EXAMPLES:
-User asked "fix the bug and run tests", bug is fixed → "run the tests"
-After code written → "try it out"
-Claude offers options → suggest the one the user would likely pick, based on conversation
-Claude asks to continue → "yes" or "go ahead"
-Task complete, obvious follow-up → "commit this" or "push it"
-After error or misunderstanding → silence (let them assess/correct)
-
-Be specific: "run the tests" beats "continue".
-
-NEVER SUGGEST:
-- Evaluative ("looks good", "thanks")
-- Questions ("what about...?")
-- Claude-voice ("Let me...", "I'll...", "Here's...")
-- New ideas they didn't ask about
-- Multiple sentences
-
-Stay silent if the next step isn't obvious from what the user said.
-
-Format: 2-12 words, match the user's style. Or nothing.
-
+const SUGGESTION_PROMPT = `[SUGGESTION MODE: Suggest what the user might naturally type next into Context Code.]
+
+FIRST: Look at the user's recent messages and original request.
+
+Your job is to predict what THEY would type - not what you think they should do.
+
+THE TEST: Would they think "I was just about to type that"?
+
+EXAMPLES:
+User asked "fix the bug and run tests", bug is fixed → "run the tests"
+After code written → "try it out"
+Claude offers options → suggest the one the user would likely pick, based on conversation
+Claude asks to continue → "yes" or "go ahead"
+Task complete, obvious follow-up → "commit this" or "push it"
+After error or misunderstanding → silence (let them assess/correct)
+
+Be specific: "run the tests" beats "continue".
+
+NEVER SUGGEST:
+- Evaluative ("looks good", "thanks")
+- Questions ("what about...?")
+- Claude-voice ("Let me...", "I'll...", "Here's...")
+- New ideas they didn't ask about
+- Multiple sentences
+
+Stay silent if the next step isn't obvious from what the user said.
+
+Format: 2-12 words, match the user's style. Or nothing.
+
 Reply with ONLY the suggestion, no quotes or explanation.`;
 const SUGGESTION_PROMPTS = {
     user_intent: SUGGESTION_PROMPT,

package/dist/src/services/SessionMemory/prompts.js

@@ -6,74 +6,74 @@ import { getErrnoCode, toError } from '../../utils/errors.js';
 import { logError } from '../../utils/log.js';
 const MAX_SECTION_LENGTH = 2000;
 const MAX_TOTAL_SESSION_MEMORY_TOKENS = 12000;
-export const DEFAULT_SESSION_MEMORY_TEMPLATE = `
-# Session Title
-_A short and distinctive 5-10 word descriptive title for the session. Super info dense, no filler_
-
-# Current State
-_What is actively being worked on right now? Pending tasks not yet completed. Immediate next steps._
-
-# Task specification
-_What did the user ask to build? Any design decisions or other explanatory context_
-
-# Files and Functions
-_What are the important files? In short, what do they contain and why are they relevant?_
-
-# Workflow
-_What bash commands are usually run and in what order? How to interpret their output if not obvious?_
-
-# Errors & Corrections
-_Errors encountered and how they were fixed. What did the user correct? What approaches failed and should not be tried again?_
-
-# Codebase and System Documentation
-_What are the important system components? How do they work/fit together?_
-
-# Learnings
-_What has worked well? What has not? What to avoid? Do not duplicate items from other sections_
-
-# Key results
-_If the user asked a specific output such as an answer to a question, a table, or other document, repeat the exact result here_
-
-# Worklog
-_Step by step, what was attempted, done? Very terse summary for each step_
+export const DEFAULT_SESSION_MEMORY_TEMPLATE = `
+# Session Title
+_A short and distinctive 5-10 word descriptive title for the session. Super info dense, no filler_
+
+# Current State
+_What is actively being worked on right now? Pending tasks not yet completed. Immediate next steps._
+
+# Task specification
+_What did the user ask to build? Any design decisions or other explanatory context_
+
+# Files and Functions
+_What are the important files? In short, what do they contain and why are they relevant?_
+
+# Workflow
+_What bash commands are usually run and in what order? How to interpret their output if not obvious?_
+
+# Errors & Corrections
+_Errors encountered and how they were fixed. What did the user correct? What approaches failed and should not be tried again?_
+
+# Codebase and System Documentation
+_What are the important system components? How do they work/fit together?_
+
+# Learnings
+_What has worked well? What has not? What to avoid? Do not duplicate items from other sections_
+
+# Key results
+_If the user asked a specific output such as an answer to a question, a table, or other document, repeat the exact result here_
+
+# Worklog
+_Step by step, what was attempted, done? Very terse summary for each step_
 `;
 function getDefaultUpdatePrompt() {
-    return `IMPORTANT: This message and these instructions are NOT part of the actual user conversation. Do NOT include any references to "note-taking", "session notes extraction", or these update instructions in the notes content.
-
-Based on the user conversation above (EXCLUDING this note-taking instruction message as well as system prompt, claude.md entries, or any past session summaries), update the session notes file.
-
-The file {{notesPath}} has already been read for you. Here are its current contents:
-<current_notes_content>
-{{currentNotes}}
-</current_notes_content>
-
-Your ONLY task is to use the Edit tool to update the notes file, then stop. You can make multiple edits (update every section as needed) - make all Edit tool calls in parallel in a single message. Do not call any other tools.
-
-CRITICAL RULES FOR EDITING:
-- The file must maintain its exact structure with all sections, headers, and italic descriptions intact
--- NEVER modify, delete, or add section headers (the lines starting with '#' like # Task specification)
--- NEVER modify or delete the italic _section description_ lines (these are the lines in italics immediately following each header - they start and end with underscores)
--- The italic _section descriptions_ are TEMPLATE INSTRUCTIONS that must be preserved exactly as-is - they guide what content belongs in each section
--- ONLY update the actual content that appears BELOW the italic _section descriptions_ within each existing section
--- Do NOT add any new sections, summaries, or information outside the existing structure
-- Do NOT reference this note-taking process or instructions anywhere in the notes
-- It's OK to skip updating a section if there are no substantial new insights to add. Do not add filler content like "No info yet", just leave sections blank/unedited if appropriate.
-- Write DETAILED, INFO-DENSE content for each section - include specifics like file paths, function names, error messages, exact commands, technical details, etc.
-- For "Key results", include the complete, exact output the user requested (e.g., full table, full answer, etc.)
-- Do not include information that's already in the CLAUDE.md files included in the context
-- Keep each section under ~${MAX_SECTION_LENGTH} tokens/words - if a section is approaching this limit, condense it by cycling out less important details while preserving the most critical information
-- Focus on actionable, specific information that would help someone understand or recreate the work discussed in the conversation
-- IMPORTANT: Always update "Current State" to reflect the most recent work - this is critical for continuity after compaction
-
-Use the Edit tool with file_path: {{notesPath}}
-
-STRUCTURE PRESERVATION REMINDER:
-Each section has TWO parts that must be preserved exactly as they appear in the current file:
-1. The section header (line starting with #)
-2. The italic description line (the _italicized text_ immediately after the header - this is a template instruction)
-
-You ONLY update the actual content that comes AFTER these two preserved lines. The italic description lines starting and ending with underscores are part of the template structure, NOT content to be edited or removed.
-
+    return `IMPORTANT: This message and these instructions are NOT part of the actual user conversation. Do NOT include any references to "note-taking", "session notes extraction", or these update instructions in the notes content.
+
+Based on the user conversation above (EXCLUDING this note-taking instruction message as well as system prompt, claude.md entries, or any past session summaries), update the session notes file.
+
+The file {{notesPath}} has already been read for you. Here are its current contents:
+<current_notes_content>
+{{currentNotes}}
+</current_notes_content>
+
+Your ONLY task is to use the Edit tool to update the notes file, then stop. You can make multiple edits (update every section as needed) - make all Edit tool calls in parallel in a single message. Do not call any other tools.
+
+CRITICAL RULES FOR EDITING:
+- The file must maintain its exact structure with all sections, headers, and italic descriptions intact
+-- NEVER modify, delete, or add section headers (the lines starting with '#' like # Task specification)
+-- NEVER modify or delete the italic _section description_ lines (these are the lines in italics immediately following each header - they start and end with underscores)
+-- The italic _section descriptions_ are TEMPLATE INSTRUCTIONS that must be preserved exactly as-is - they guide what content belongs in each section
+-- ONLY update the actual content that appears BELOW the italic _section descriptions_ within each existing section
+-- Do NOT add any new sections, summaries, or information outside the existing structure
+- Do NOT reference this note-taking process or instructions anywhere in the notes
+- It's OK to skip updating a section if there are no substantial new insights to add. Do not add filler content like "No info yet", just leave sections blank/unedited if appropriate.
+- Write DETAILED, INFO-DENSE content for each section - include specifics like file paths, function names, error messages, exact commands, technical details, etc.
+- For "Key results", include the complete, exact output the user requested (e.g., full table, full answer, etc.)
+- Do not include information that's already in the CLAUDE.md files included in the context
+- Keep each section under ~${MAX_SECTION_LENGTH} tokens/words - if a section is approaching this limit, condense it by cycling out less important details while preserving the most critical information
+- Focus on actionable, specific information that would help someone understand or recreate the work discussed in the conversation
+- IMPORTANT: Always update "Current State" to reflect the most recent work - this is critical for continuity after compaction
+
+Use the Edit tool with file_path: {{notesPath}}
+
+STRUCTURE PRESERVATION REMINDER:
+Each section has TWO parts that must be preserved exactly as they appear in the current file:
+1. The section header (line starting with #)
+2. The italic description line (the _italicized text_ immediately after the header - this is a template instruction)
+
+You ONLY update the actual content that comes AFTER these two preserved lines. The italic description lines starting and ending with underscores are part of the template structure, NOT content to be edited or removed.
+
 REMEMBER: Use the Edit tool in parallel and stop. Do not continue after the edits. Only include insights from the actual user conversation, never from these note-taking instructions. Do not delete or change section headers or italic _section descriptions_.`;
 }
 /**

package/dist/src/services/toolUseSummary/toolUseSummaryGenerator.js

@@ -10,15 +10,15 @@ import { logError } from '../../utils/log.js';
 import { jsonStringify } from '../../utils/slowOperations.js';
 import { asSystemPrompt } from '../../utils/systemPromptType.js';
 import { queryHaiku } from '../api/claude.js';
-const TOOL_USE_SUMMARY_SYSTEM_PROMPT = `Write a short summary label describing what these tool calls accomplished. It appears as a single-line row in a mobile app and truncates around 30 characters, so think git-commit-subject, not sentence.
-
-Keep the verb in past tense and the most distinctive noun. Drop articles, connectors, and long location context first.
-
-Examples:
-- Searched in auth/
-- Fixed NPE in UserService
-- Created signup endpoint
-- Read config.json
+const TOOL_USE_SUMMARY_SYSTEM_PROMPT = `Write a short summary label describing what these tool calls accomplished. It appears as a single-line row in a mobile app and truncates around 30 characters, so think git-commit-subject, not sentence.
+
+Keep the verb in past tense and the most distinctive noun. Drop articles, connectors, and long location context first.
+
+Examples:
+- Searched in auth/
+- Fixed NPE in UserService
+- Created signup endpoint
+- Read config.json
 - Ran failing tests`;
 /**
  * Generates a human-readable summary of completed tools.

package/dist/src/skills/bundled/batch.js

@@ -7,89 +7,89 @@ import { getIsGit } from '../../utils/git.js';
 import { registerBundledSkill } from '../bundledSkills.js';
 const MIN_AGENTS = 5;
 const MAX_AGENTS = 30;
-const WORKER_INSTRUCTIONS = `After you finish implementing the change:
-1. **Simplify** — Invoke the \`${SKILL_TOOL_NAME}\` tool with \`skill: "simplify"\` to review and clean up your changes.
-2. **Run unit tests** — Run the project's test suite (check for package.json scripts, Makefile targets, or common commands like \`npm test\`, \`bun test\`, \`pytest\`, \`go test\`). If tests fail, fix them.
-3. **Test end-to-end** — Follow the e2e test recipe from the coordinator's prompt (below). If the recipe says to skip e2e for this unit, skip it.
-4. **Commit and push** — Commit all changes with a clear message, push the branch, and create a PR with \`gh pr create\`. Use a descriptive title. If \`gh\` is not available or the push fails, note it in your final message.
+const WORKER_INSTRUCTIONS = `After you finish implementing the change:
+1. **Simplify** — Invoke the \`${SKILL_TOOL_NAME}\` tool with \`skill: "simplify"\` to review and clean up your changes.
+2. **Run unit tests** — Run the project's test suite (check for package.json scripts, Makefile targets, or common commands like \`npm test\`, \`bun test\`, \`pytest\`, \`go test\`). If tests fail, fix them.
+3. **Test end-to-end** — Follow the e2e test recipe from the coordinator's prompt (below). If the recipe says to skip e2e for this unit, skip it.
+4. **Commit and push** — Commit all changes with a clear message, push the branch, and create a PR with \`gh pr create\`. Use a descriptive title. If \`gh\` is not available or the push fails, note it in your final message.
 5. **Report** — End with a single line: \`PR: <url>\` so the coordinator can track it. If no PR was created, end with \`PR: none — <reason>\`.`;
 function buildPrompt(instruction) {
-    return `# Batch: Parallel Work Orchestration
-
-You are orchestrating a large, parallelizable change across this codebase.
-
-## User Instruction
-
-${instruction}
-
-## Phase 1: Research and Plan (Plan Mode)
-
-Call the \`${ENTER_PLAN_MODE_TOOL_NAME}\` tool now to enter plan mode, then:
-
-1. **Understand the scope.** Launch one or more subagents (in the foreground — you need their results) to deeply research what this instruction touches. Find all the files, patterns, and call sites that need to change. Understand the existing conventions so the migration is consistent.
-
-2. **Decompose into independent units.** Break the work into ${MIN_AGENTS}–${MAX_AGENTS} self-contained units. Each unit must:
-   - Be independently implementable in an isolated git worktree (no shared state with sibling units)
-   - Be mergeable on its own without depending on another unit's PR landing first
-   - Be roughly uniform in size (split large units, merge trivial ones)
-
-   Scale the count to the actual work: few files → closer to ${MIN_AGENTS}; hundreds of files → closer to ${MAX_AGENTS}. Prefer per-directory or per-module slicing over arbitrary file lists.
-
-3. **Determine the e2e test recipe.** Figure out how a worker can verify its change actually works end-to-end — not just that unit tests pass. Look for:
-   - A \`claude-in-chrome\` skill or browser-automation tool (for UI changes: click through the affected flow, screenshot the result)
-   - A \`tmux\` or CLI-verifier skill (for CLI changes: launch the app interactively, exercise the changed behavior)
-   - A dev-server + curl pattern (for API changes: start the server, hit the affected endpoints)
-   - An existing e2e/integration test suite the worker can run
-
-   If you cannot find a concrete e2e path, use the \`${ASK_USER_QUESTION_TOOL_NAME}\` tool to ask the user how to verify this change end-to-end. Offer 2–3 specific options based on what you found (e.g., "Screenshot via chrome extension", "Run \`bun run dev\` and curl the endpoint", "No e2e — unit tests are sufficient"). Do not skip this — the workers cannot ask the user themselves.
-
-   Write the recipe as a short, concrete set of steps that a worker can execute autonomously. Include any setup (start a dev server, build first) and the exact command/interaction to verify.
-
-4. **Write the plan.** In your plan file, include:
-   - A summary of what you found during research
-   - A numbered list of work units — for each: a short title, the list of files/directories it covers, and a one-line description of the change
-   - The e2e test recipe (or "skip e2e because …" if the user chose that)
-   - The exact worker instructions you will give each agent (the shared template)
-
-5. Call \`${EXIT_PLAN_MODE_TOOL_NAME}\` to present the plan for approval.
-
-## Phase 2: Spawn Workers (After Plan Approval)
-
-Once the plan is approved, spawn one background agent per work unit using the \`${AGENT_TOOL_NAME}\` tool. **All agents must use \`isolation: "worktree"\` and \`run_in_background: true\`.** Launch them all in a single message block so they run in parallel.
-
-For each agent, the prompt must be fully self-contained. Include:
-- The overall goal (the user's instruction)
-- This unit's specific task (title, file list, change description — copied verbatim from your plan)
-- Any codebase conventions you discovered that the worker needs to follow
-- The e2e test recipe from your plan (or "skip e2e because …")
-- The worker instructions below, copied verbatim:
-
-\`\`\`
-${WORKER_INSTRUCTIONS}
-\`\`\`
-
-Use \`subagent_type: "general-purpose"\` unless a more specific agent type fits.
-
-## Phase 3: Track Progress
-
-After launching all workers, render an initial status table:
-
-| # | Unit | Status | PR |
-|---|------|--------|----|
-| 1 | <title> | running | — |
-| 2 | <title> | running | — |
-
-As background-agent completion notifications arrive, parse the \`PR: <url>\` line from each agent's result and re-render the table with updated status (\`done\` / \`failed\`) and PR links. Keep a brief failure note for any agent that did not produce a PR.
-
-When all agents have reported, render the final table and a one-line summary (e.g., "22/24 units landed as PRs").
+    return `# Batch: Parallel Work Orchestration
+
+You are orchestrating a large, parallelizable change across this codebase.
+
+## User Instruction
+
+${instruction}
+
+## Phase 1: Research and Plan (Plan Mode)
+
+Call the \`${ENTER_PLAN_MODE_TOOL_NAME}\` tool now to enter plan mode, then:
+
+1. **Understand the scope.** Launch one or more subagents (in the foreground — you need their results) to deeply research what this instruction touches. Find all the files, patterns, and call sites that need to change. Understand the existing conventions so the migration is consistent.
+
+2. **Decompose into independent units.** Break the work into ${MIN_AGENTS}–${MAX_AGENTS} self-contained units. Each unit must:
+   - Be independently implementable in an isolated git worktree (no shared state with sibling units)
+   - Be mergeable on its own without depending on another unit's PR landing first
+   - Be roughly uniform in size (split large units, merge trivial ones)
+
+   Scale the count to the actual work: few files → closer to ${MIN_AGENTS}; hundreds of files → closer to ${MAX_AGENTS}. Prefer per-directory or per-module slicing over arbitrary file lists.
+
+3. **Determine the e2e test recipe.** Figure out how a worker can verify its change actually works end-to-end — not just that unit tests pass. Look for:
+   - A \`claude-in-chrome\` skill or browser-automation tool (for UI changes: click through the affected flow, screenshot the result)
+   - A \`tmux\` or CLI-verifier skill (for CLI changes: launch the app interactively, exercise the changed behavior)
+   - A dev-server + curl pattern (for API changes: start the server, hit the affected endpoints)
+   - An existing e2e/integration test suite the worker can run
+
+   If you cannot find a concrete e2e path, use the \`${ASK_USER_QUESTION_TOOL_NAME}\` tool to ask the user how to verify this change end-to-end. Offer 2–3 specific options based on what you found (e.g., "Screenshot via chrome extension", "Run \`bun run dev\` and curl the endpoint", "No e2e — unit tests are sufficient"). Do not skip this — the workers cannot ask the user themselves.
+
+   Write the recipe as a short, concrete set of steps that a worker can execute autonomously. Include any setup (start a dev server, build first) and the exact command/interaction to verify.
+
+4. **Write the plan.** In your plan file, include:
+   - A summary of what you found during research
+   - A numbered list of work units — for each: a short title, the list of files/directories it covers, and a one-line description of the change
+   - The e2e test recipe (or "skip e2e because …" if the user chose that)
+   - The exact worker instructions you will give each agent (the shared template)
+
+5. Call \`${EXIT_PLAN_MODE_TOOL_NAME}\` to present the plan for approval.
+
+## Phase 2: Spawn Workers (After Plan Approval)
+
+Once the plan is approved, spawn one background agent per work unit using the \`${AGENT_TOOL_NAME}\` tool. **All agents must use \`isolation: "worktree"\` and \`run_in_background: true\`.** Launch them all in a single message block so they run in parallel.
+
+For each agent, the prompt must be fully self-contained. Include:
+- The overall goal (the user's instruction)
+- This unit's specific task (title, file list, change description — copied verbatim from your plan)
+- Any codebase conventions you discovered that the worker needs to follow
+- The e2e test recipe from your plan (or "skip e2e because …")
+- The worker instructions below, copied verbatim:
+
+\`\`\`
+${WORKER_INSTRUCTIONS}
+\`\`\`
+
+Use \`subagent_type: "general-purpose"\` unless a more specific agent type fits.
+
+## Phase 3: Track Progress
+
+After launching all workers, render an initial status table:
+
+| # | Unit | Status | PR |
+|---|------|--------|----|
+| 1 | <title> | running | — |
+| 2 | <title> | running | — |
+
+As background-agent completion notifications arrive, parse the \`PR: <url>\` line from each agent's result and re-render the table with updated status (\`done\` / \`failed\`) and PR links. Keep a brief failure note for any agent that did not produce a PR.
+
+When all agents have reported, render the final table and a one-line summary (e.g., "22/24 units landed as PRs").
 `;
 }
 const NOT_A_GIT_REPO_MESSAGE = `This is not a git repository. The \`/batch\` command requires a git repo because it spawns agents in isolated git worktrees and creates PRs from each. Initialize a repo first, or run this from inside an existing one.`;
-const MISSING_INSTRUCTION_MESSAGE = `Provide an instruction describing the batch change you want to make.
-
-Examples:
-  /batch migrate from react to vue
-  /batch replace all uses of lodash with native equivalents
+const MISSING_INSTRUCTION_MESSAGE = `Provide an instruction describing the batch change you want to make.
+
+Examples:
+  /batch migrate from react to vue
+  /batch replace all uses of lodash with native equivalents
   /batch add type annotations to all untyped function parameters`;
 export function registerBatchSkill() {
     registerBundledSkill({

package/dist/src/skills/bundled/claudeApi.js

@@ -60,40 +60,40 @@ function buildInlineReference(filePaths, content) {
     }
     return sections.join('\n\n');
 }
-const INLINE_READING_GUIDE = `## Reference Documentation
-
-The relevant documentation for your detected language is included below in \`<doc>\` tags. Each tag has a \`path\` attribute showing its original file path. Use this to find the right section:
-
-### Quick Task Reference
-
-**Single text classification/summarization/extraction/Q&A:**
-→ Refer to \`{lang}/claude-api/README.md\`
-
-**Chat UI or real-time response display:**
-→ Refer to \`{lang}/claude-api/README.md\` + \`{lang}/claude-api/streaming.md\`
-
-**Long-running conversations (may exceed context window):**
-→ Refer to \`{lang}/claude-api/README.md\` — see Compaction section
-
-**Prompt caching / optimize caching / "why is my cache hit rate low":**
-→ Refer to \`shared/prompt-caching.md\` + \`{lang}/claude-api/README.md\` (Prompt Caching section)
-
-**Function calling / tool use / agents:**
-→ Refer to \`{lang}/claude-api/README.md\` + \`shared/tool-use-concepts.md\` + \`{lang}/claude-api/tool-use.md\`
-
-**Batch processing (non-latency-sensitive):**
-→ Refer to \`{lang}/claude-api/README.md\` + \`{lang}/claude-api/batches.md\`
-
-**File uploads across multiple requests:**
-→ Refer to \`{lang}/claude-api/README.md\` + \`{lang}/claude-api/files-api.md\`
-
-**Agent with built-in tools (file/web/terminal) (Python & TypeScript only):**
-→ Refer to \`{lang}/agent-sdk/README.md\` + \`{lang}/agent-sdk/patterns.md\`
-
-**Error handling:**
-→ Refer to \`shared/error-codes.md\`
-
-**Latest docs via WebFetch:**
+const INLINE_READING_GUIDE = `## Reference Documentation
+
+The relevant documentation for your detected language is included below in \`<doc>\` tags. Each tag has a \`path\` attribute showing its original file path. Use this to find the right section:
+
+### Quick Task Reference
+
+**Single text classification/summarization/extraction/Q&A:**
+→ Refer to \`{lang}/claude-api/README.md\`
+
+**Chat UI or real-time response display:**
+→ Refer to \`{lang}/claude-api/README.md\` + \`{lang}/claude-api/streaming.md\`
+
+**Long-running conversations (may exceed context window):**
+→ Refer to \`{lang}/claude-api/README.md\` — see Compaction section
+
+**Prompt caching / optimize caching / "why is my cache hit rate low":**
+→ Refer to \`shared/prompt-caching.md\` + \`{lang}/claude-api/README.md\` (Prompt Caching section)
+
+**Function calling / tool use / agents:**
+→ Refer to \`{lang}/claude-api/README.md\` + \`shared/tool-use-concepts.md\` + \`{lang}/claude-api/tool-use.md\`
+
+**Batch processing (non-latency-sensitive):**
+→ Refer to \`{lang}/claude-api/README.md\` + \`{lang}/claude-api/batches.md\`
+
+**File uploads across multiple requests:**
+→ Refer to \`{lang}/claude-api/README.md\` + \`{lang}/claude-api/files-api.md\`
+
+**Agent with built-in tools (file/web/terminal) (Python & TypeScript only):**
+→ Refer to \`{lang}/agent-sdk/README.md\` + \`{lang}/agent-sdk/patterns.md\`
+
+**Error handling:**
+→ Refer to \`shared/error-codes.md\`
+
+**Latest docs via WebFetch:**
 → Refer to \`shared/live-sources.md\` for URLs`;
 function buildPrompt(lang, args, content) {
     // Take the SKILL.md content up to the "Reading Guide" section

package/dist/src/skills/bundled/claudeInChrome.js

@@ -3,10 +3,10 @@ import { BASE_CHROME_PROMPT } from '../../utils/claudeInChrome/prompt.js';
 import { shouldAutoEnableClaudeInChrome } from '../../utils/claudeInChrome/setup.js';
 import { registerBundledSkill } from '../bundledSkills.js';
 const CLAUDE_IN_CHROME_MCP_TOOLS = BROWSER_TOOLS.map(tool => `mcp__claude-in-chrome__${tool.name}`);
-const SKILL_ACTIVATION_MESSAGE = `
-Now that this skill is invoked, you have access to Chrome browser automation tools. You can now use the mcp__claude-in-chrome__* tools to interact with web pages.
-
-IMPORTANT: Start by calling mcp__claude-in-chrome__tabs_context_mcp to get information about the user's current browser tabs.
+const SKILL_ACTIVATION_MESSAGE = `
+Now that this skill is invoked, you have access to Chrome browser automation tools. You can now use the mcp__claude-in-chrome__* tools to interact with web pages.
+
+IMPORTANT: Start by calling mcp__claude-in-chrome__tabs_context_mcp to get information about the user's current browser tabs.
 `;
 export function registerClaudeInChromeSkill() {
     registerBundledSkill({