feat: convert make-plan and do commands to skills (#1216)

CLAUDE.md

@@ -14,6 +14,10 @@ Claude-mem is a Claude Code plugin providing persistent memory across sessions.
 
 **Search Skill** (`plugin/skills/mem-search/SKILL.md`) - HTTP API for searching past work, auto-invoked when users ask about history
 
+**Planning Skill** (`plugin/skills/make-plan/SKILL.md`) - Orchestrator instructions for creating phased implementation plans with documentation discovery
+
+**Execution Skill** (`plugin/skills/do/SKILL.md`) - Orchestrator instructions for executing phased plans using subagents
+
 **Chroma** (`src/services/sync/ChromaSync.ts`) - Vector embeddings for semantic search
 
 **Viewer UI** (`src/ui/viewer/`) - React interface at http://localhost:37777, built to `plugin/ui/viewer.html`

openclaw/openclaw.plugin.json

@@ -6,7 +6,7 @@
   "version": "1.0.0",
   "author": "thedotmack",
   "homepage": "https://claude-mem.com",
-  "skills": ["skills/make-plan", "skills/do-plan"],
+  "skills": ["skills/make-plan", "skills/do"],
   "configSchema": {
     "type": "object",
     "additionalProperties": false,

openclaw/skills/do/SKILL.md

@@ -0,0 +1 @@
+../../../plugin/skills/do/SKILL.md

openclaw/skills/make-plan/SKILL.md

@@ -1,63 +0,0 @@
----
-name: make-plan
-description: Create a detailed, phased implementation plan with documentation discovery. Use when asked to plan a feature, task, or multi-step implementation — especially before executing with do-plan.
----
-
-# Make Plan
-
-You are an ORCHESTRATOR. Create an LLM-friendly plan in phases that can be executed consecutively in new chat contexts.
-
-## Delegation Model
-
-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, re-check with targeted reads/greps before finalizing.
-
-### 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
-
-### Phase 0: Documentation Discovery (ALWAYS FIRST)
-
-Before planning implementation, deploy "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)
-
-The orchestrator consolidates 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)
-
-### 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
-
-## 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

openclaw/skills/make-plan/SKILL.md

@@ -0,0 +1 @@
+../../../plugin/skills/make-plan/SKILL.md

plugin/commands/do.md

@@ -1,43 +0,0 @@
----
-description: "Execute a plan using subagents for implementation"
-argument-hint: "[task or plan reference]"
----
-
-You are an ORCHESTRATOR.
-
-Primary instruction: deploy subagents to execute *all* work for #$ARGUMENTS.
-Do not do the work yourself except to coordinate, route context, and verify that each subagent completed its assigned checklist.
-
-Deploy subagents to execute each phase of #$ARGUMENTS independently and consecutively. For every checklist item below, explicitly deploy (or reuse) a subagent responsible for that item and record its outcome before proceeding.
-
-## Execution Protocol (Orchestrator-Driven)
-
-Orchestrator rules:
-- Each phase uses fresh subagents where noted (or when context is large/unclear).
-- The orchestrator assigns one clear objective per subagent and requires evidence (commands run, outputs, files changed).
-- Do not advance to the next step until the assigned subagent reports completion and the orchestrator confirms it matches the plan.
-
-### During Each Phase:
-Deploy an "Implementation" subagent to:
-1. Execute the implementation as specified
-2. COPY patterns from documentation, don't invent
-3. Cite documentation sources in code comments when using unfamiliar APIs
-4. If an API seems missing, STOP and verify - don't assume it exists
-
-### After Each Phase:
-Deploy subagents for each post-phase responsibility:
-1. **Run verification checklist** - Deploy a "Verification" subagent to prove the phase worked
-2. **Anti-pattern check** - Deploy an "Anti-pattern" subagent to grep for known bad patterns from the plan
-3. **Code quality review** - Deploy a "Code Quality" subagent to review changes
-4. **Commit only if verified** - Deploy a "Commit" subagent *only after* verification passes; otherwise, do not commit
-
-### Between Phases:
-Deploy a "Branch/Sync" subagent to:
-- Push to working branch after each verified phase
-- Prepare the next phase handoff so the next phase's subagents start fresh but have plan context
-
-## Failure Modes to Prevent
-- Don't invent APIs that "should" exist - verify against docs
-- Don't add undocumented parameters - copy exact signatures
-- Don't skip verification - deploy a verification subagent and run the checklist
-- Don't commit before verification passes (or without explicit orchestrator approval)

plugin/commands/make-plan.md

@@ -1,66 +0,0 @@
----
-description: "Create an implementation plan with documentation discovery"
-argument-hint: "[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

plugin/skills/do/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: do-plan
+name: do
 description: Execute a phased implementation plan using subagents. Use when asked to execute, run, or carry out a plan — especially one created by make-plan.
 ---
 

plugin/skills/make-plan/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: make-plan
+description: Create a detailed, phased implementation plan with documentation discovery. Use when asked to plan a feature, task, or multi-step implementation — especially before executing with do.
+---
+
+# Make Plan
+
+You are an ORCHESTRATOR. Create an LLM-friendly plan in phases that can be executed consecutively in new chat contexts.
+
+## Delegation Model
+
+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, re-check with targeted reads/greps before finalizing.
+
+### 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
+
+### Phase 0: Documentation Discovery (ALWAYS FIRST)
+
+Before planning implementation, deploy "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)
+
+The orchestrator consolidates 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)
+
+### 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
+
+## 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