Files
claude-mem/plugin/commands/make-plan.md
Alexander Knigge e6ae017609 fix: eliminate Windows console popups during daemon spawn and Chroma operations (#751)
* fix: eliminate Windows console popups during daemon spawn and Chroma operations

Two changes to fix Windows Terminal popup issues:

1. Worker daemon spawn (ProcessManager.spawnDaemon):
   - Windows: Use WMIC to spawn truly independent process without console
   - WMIC creates processes that survive parent exit and have no console association
   - Properly handles paths with spaces via double-quoting
   - Unix: Unchanged behavior with standard detached spawn

2. PID file handling (worker-service.ts):
   - Worker now writes its own PID after listen() succeeds (all platforms)
   - Removes race condition where spawner wrote PID before worker was ready
   - On Windows, spawner PID was useless anyway

3. Chroma vector search (ChromaSync.ts):
   - Temporarily disabled on Windows to prevent MCP SDK subprocess popups
   - Will be re-enabled when we migrate to persistent HTTP server architecture
   - Windows users still get full observation storage, just no semantic search

Tested on Windows 11 via SSH - worker spawns without console popups,
survives parent process exit, and all lifecycle commands (start/stop/restart)
work correctly.

Fixes #748, #708, #681, #676, #675

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

* fix: add YAML frontmatter to slash commands for discoverability

Commands /do and /make-plan were not appearing in Claude Code because
they lacked the required YAML frontmatter metadata. Added description
and argument-hint fields to both commands.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

---------

Co-authored-by: bigphoot <bigphoot@gmail.com>
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-22 18:46:23 -05:00

3.2 KiB

description, argument-hint
description argument-hint
Create an implementation plan with documentation discovery [feature or task description]

You are an ORCHESTRATOR.

Create an LLM-friendly plan in phases that can be executed consecutively in new chat contexts.

Delegation model (because subagents can under-report):

  • Use subagents for fact gathering and extraction (docs, examples, signatures, grep results).
  • Keep synthesis and plan authoring with the orchestrator (phase boundaries, task framing, final wording).
  • If a subagent report is incomplete or lacks evidence, the orchestrator must re-check with targeted reads/greps before finalizing the plan.

Subagent reporting contract (MANDATORY):

  • Each subagent response must include:
    1. Sources consulted (files/URLs) and what was read
    2. Concrete findings (exact API names/signatures; exact file paths/locations)
    3. Copy-ready snippet locations (example files/sections to copy)
    4. "Confidence" note + known gaps (what might still be missing)
  • Reject and redeploy the subagent if it reports conclusions without sources.

Plan Structure Requirements

Phase 0: Documentation Discovery (ALWAYS FIRST)

Before planning implementation, you MUST: Deploy one or more "Documentation Discovery" subagents to:

  1. Search for and read relevant documentation, examples, and existing patterns
  2. Identify the actual APIs, methods, and signatures available (not assumed)
  3. Create a brief "Allowed APIs" list citing specific documentation sources
  4. Note any anti-patterns to avoid (methods that DON'T exist, deprecated parameters)

Then the orchestrator consolidates their findings into a single Phase 0 output.

Each Implementation Phase Must Include:

  1. What to implement - Frame tasks to COPY from docs, not transform existing code
    • Good: "Copy the V2 session pattern from docs/examples.ts:45-60"
    • Bad: "Migrate the existing code to V2"
  2. Documentation references - Cite specific files/lines for patterns to follow
  3. Verification checklist - How to prove this phase worked (tests, grep checks)
  4. Anti-pattern guards - What NOT to do (invented APIs, undocumented params)

Subagent-friendly split:

  • Subagents can propose candidate doc references and verification commands.
  • The orchestrator must write the final phase text, ensuring tasks are copy-based, scoped, and independently executable.

Final Phase: Verification

  1. Verify all implementations match documentation
  2. Check for anti-patterns (grep for known bad patterns)
  3. Run tests to confirm functionality

Delegation guidance:

  • Deploy a "Verification" subagent to draft the checklist and commands.
  • The orchestrator must review the checklist for completeness and ensure it maps to earlier phase outputs.

Key Principles

  • Documentation Availability ≠ Usage: Explicitly require reading docs
  • Task Framing Matters: Direct agents to docs, not just outcomes
  • Verify > Assume: Require proof, not assumptions about APIs
  • Session Boundaries: Each phase should be self-contained with its own doc references

Anti-Patterns to Prevent

  • Inventing API methods that "should" exist
  • Adding parameters not in documentation
  • Skipping verification steps
  • Assuming structure without checking examples