@xmem-ai/memcode 4.0.2

package/dist/skills/bundled/remember.js

@@ -0,0 +1,89 @@
+import { registerBundledSkill } from "../bundledSkills.js";
+function registerRememberSkill() {
+  const SKILL_PROMPT = `# Memory Review
+
+## Goal
+Review the user's XMem memory landscape and produce a clear report of proposed changes. Do not apply changes or save new memories; present proposals for user approval.
+
+## Available memory tools
+- Use XMemSearch for broad searches across stored memory entries.
+- Use XMemRetrieve when you need a consolidated answer for a specific topic.
+- Do not use XMemIngest during this review.
+
+## Steps
+
+### 1. Gather memory context
+Search XMem with several broad queries before making recommendations:
+- project conventions and repository instructions
+- user preferences and interaction style
+- workflow, PR, testing, deployment, and command preferences
+- temporary notes, stale context, or uncertain memories
+
+Read XCODE.md and XCODE.local.md from the project root if they exist. Use Grep to find those files if the project root is unclear.
+
+Success criteria: You have representative XMem results plus any project and local instruction files available in this workspace.
+
+### 2. Classify each memory entry
+For each substantive XMem entry, determine the best destination:
+
+| Destination | What belongs there | Examples |
+|---|---|---|
+| XCODE.md | Project conventions and instructions for memCode that all contributors should follow | use bun not npm, API routes use kebab-case, test command is bun test |
+| XCODE.local.md | Personal instructions for memCode specific to this user, not applicable to other contributors | prefer concise responses, do not auto-commit, run tests before committing |
+| Stay in XMem | Cross-project personal memory, working context that is still useful, or entries that do not belong in repo files | broad user preferences, active investigations, uncertain patterns |
+| Remove or replace | Duplicate, stale, contradicted, or low-value memory | old commands, obsolete paths, duplicate preferences |
+
+Important distinctions:
+- XCODE.md and XCODE.local.md contain instructions for memCode, not preferences for unrelated tools.
+- Workflow practices such as PR conventions, merge strategies, and branch naming can be project-wide or personal. Flag ambiguous cases for the user.
+- When unsure, ask rather than guess.
+
+Success criteria: Each reviewed entry has a proposed destination or is flagged as ambiguous.
+
+### 3. Identify cleanup opportunities
+Scan across XMem, XCODE.md, and XCODE.local.md for:
+- Duplicates: XMem entries already captured in XCODE.md or XCODE.local.md.
+- Outdated entries: older instructions contradicted by newer memory or repo files.
+- Conflicts: contradictions between any two layers.
+- Missing durable instructions: useful repeated XMem patterns that should be promoted into XCODE.md or XCODE.local.md.
+
+Success criteria: All visible cross-layer issues are identified.
+
+### 4. Present the report
+Output a structured report grouped by action type:
+1. Promotions - entries to move, with destination and rationale.
+2. Cleanup - duplicates, outdated entries, conflicts to resolve.
+3. Ambiguous - entries where you need the user's input on destination.
+4. No action needed - brief note on entries that should stay put.
+
+If XMem is unavailable or empty, say so and offer to review XCODE.md and XCODE.local.md only.
+
+## Rules
+- Present all proposals before making any changes.
+- Do not modify files without explicit user approval.
+- Do not create new files unless the target does not exist yet and the user approves.
+- Do not save, delete, or overwrite XMem entries during this review.
+- Ask about ambiguous entries; do not guess.
+`;
+  registerBundledSkill({
+    name: "remember",
+    description: "Review XMem memory entries and propose cleanup or promotion into memCode instruction files.",
+    whenToUse: "Use when the user wants to review what is stored in XMem memory or clean up their memory landscape.",
+    allowedTools: ["XMemSearch", "XMemRetrieve", "Read", "Grep"],
+    userInvocable: true,
+    isEnabled: () => true,
+    async getPromptForCommand(args) {
+      let prompt = SKILL_PROMPT;
+      if (args) {
+        prompt += `
+## Additional context from user
+
+${args}`;
+      }
+      return [{ type: "text", text: prompt }];
+    }
+  });
+}
+export {
+  registerRememberSkill
+};

package/dist/skills/bundled/simplify.js

@@ -0,0 +1,74 @@
+import { AGENT_TOOL_NAME } from "../../tools/AgentTool/constants.js";
+import { registerBundledSkill } from "../bundledSkills.js";
+const SIMPLIFY_PROMPT = `# Simplify: Code Review and Cleanup
+
+Review all changed files for reuse, quality, and efficiency. Fix any issues found.
+
+## Phase 1: Identify Changes
+
+Run \`git diff\` (or \`git diff HEAD\` if there are staged changes) to see what changed. If there are no git changes, review the most recently modified files that the user mentioned or that you edited earlier in this conversation.
+
+## Phase 2: Launch Three Review Agents in Parallel
+
+Use the ${AGENT_TOOL_NAME} tool to launch all three agents concurrently in a single message. Pass each agent the full diff so it has the complete context.
+
+### Agent 1: Code Reuse Review
+
+For each change:
+
+1. **Search for existing utilities and helpers** that could replace newly written code. Look for similar patterns elsewhere in the codebase - common locations are utility directories, shared modules, and files adjacent to the changed ones.
+2. **Flag any new function that duplicates existing functionality.** Suggest the existing function to use instead.
+3. **Flag any inline logic that could use an existing utility** - hand-rolled string manipulation, manual path handling, custom environment checks, ad-hoc type guards, and similar patterns are common candidates.
+
+### Agent 2: Code Quality Review
+
+Review the same changes for hacky patterns:
+
+1. **Redundant state**: state that duplicates existing state, cached values that could be derived, observers/effects that could be direct calls
+2. **Parameter sprawl**: adding new parameters to a function instead of generalizing or restructuring existing ones
+3. **Copy-paste with slight variation**: near-duplicate code blocks that should be unified with a shared abstraction
+4. **Leaky abstractions**: exposing internal details that should be encapsulated, or breaking existing abstraction boundaries
+5. **Stringly-typed code**: using raw strings where constants, enums (string unions), or branded types already exist in the codebase
+6. **Unnecessary JSX nesting**: wrapper Boxes/elements that add no layout value - check if inner component props (flexShrink, alignItems, etc.) already provide the needed behavior
+7. **Unnecessary comments**: comments explaining WHAT the code does (well-named identifiers already do that), narrating the change, or referencing the task/caller - delete; keep only non-obvious WHY (hidden constraints, subtle invariants, workarounds)
+
+### Agent 3: Efficiency Review
+
+Review the same changes for efficiency:
+
+1. **Unnecessary work**: redundant computations, repeated file reads, duplicate network/API calls, N+1 patterns
+2. **Missed concurrency**: independent operations run sequentially when they could run in parallel
+3. **Hot-path bloat**: new blocking work added to startup or per-request/per-render hot paths
+4. **Recurring no-op updates**: state/store updates inside polling loops, intervals, or event handlers that fire unconditionally - add a change-detection guard so downstream consumers aren't notified when nothing changed. Also: if a wrapper function takes an updater/reducer callback, verify it honors same-reference returns (or whatever the "no change" signal is) - otherwise callers' early-return no-ops are silently defeated
+5. **Unnecessary existence checks**: pre-checking file/resource existence before operating (TOCTOU anti-pattern) - operate directly and handle the error
+6. **Memory**: unbounded data structures, missing cleanup, event listener leaks
+7. **Overly broad operations**: reading entire files when only a portion is needed, loading all items when filtering for one
+
+## Phase 3: Fix Issues
+
+Wait for all three agents to complete. Aggregate their findings and fix each issue directly. If a finding is a false positive or not worth addressing, note it and move on - do not argue with the finding, just skip it.
+
+When done, briefly summarize what was fixed (or confirm the code was already clean).
+`;
+function registerSimplifySkill() {
+  registerBundledSkill({
+    name: "simplify",
+    description: "Review changed code for reuse, quality, and efficiency, then fix any issues found.",
+    allowedTools: ["Agent", "Read", "Grep", "Glob", "Edit", "Write", "Bash(git:*)"],
+    userInvocable: true,
+    async getPromptForCommand(args) {
+      let prompt = SIMPLIFY_PROMPT;
+      if (args) {
+        prompt += `
+
+## Additional Focus
+
+${args}`;
+      }
+      return [{ type: "text", text: prompt }];
+    }
+  });
+}
+export {
+  registerSimplifySkill
+};

package/dist/skills/bundled/skillify.js

@@ -0,0 +1,178 @@
+import { getSessionMemoryContent } from "../../services/SessionMemory/sessionMemoryUtils.js";
+import { getMessagesAfterCompactBoundary } from "../../utils/messages.js";
+import { registerBundledSkill } from "../bundledSkills.js";
+function extractUserMessages(messages) {
+  return messages.filter((m) => m.type === "user").map((m) => {
+    const content = m.message?.content;
+    if (typeof content === "string") return content;
+    if (!Array.isArray(content)) return "";
+    return content.filter(
+      (b) => typeof b === "object" && b !== null && b.type === "text" && typeof b.text === "string"
+    ).map((b) => b.text).join("\n");
+  }).filter((text) => text.trim().length > 0);
+}
+const SKILLIFY_PROMPT = `# Skillify {{userDescriptionBlock}}
+
+You are capturing this session's repeatable process as a reusable skill.
+
+## Your Session Context
+
+Here is the session memory summary:
+<session_memory>
+{{sessionMemory}}
+</session_memory>
+
+Here are the user's messages during this session. Pay attention to how they steered the process, to help capture their detailed preferences in the skill:
+<user_messages>
+{{userMessages}}
+</user_messages>
+
+## Your Task
+
+### Step 1: Analyze the Session
+
+Before asking any questions, analyze the session to identify:
+- What repeatable process was performed
+- What the inputs/parameters were
+- The distinct steps (in order)
+- The success artifacts/criteria (e.g. not just "writing code," but "an open PR with CI fully passing") for each step
+- Where the user corrected or steered you
+- What tools and permissions were needed
+- What agents were used
+- What the goals and success artifacts were
+
+### Step 2: Interview the User
+
+You will use the AskUserQuestion to understand what the user wants to automate. Important notes:
+- Use AskUserQuestion for ALL questions! Never ask questions via plain text.
+- For each round, iterate as much as needed until the user is happy.
+- The user always has a freeform "Other" option to type edits or feedback -- do NOT add your own "Needs tweaking" or "I'll provide edits" option. Just offer the substantive choices.
+
+**Round 1: High level confirmation**
+- Suggest a name and description for the skill based on your analysis. Ask the user to confirm or rename.
+- Suggest high-level goal(s) and specific success criteria for the skill.
+
+**Round 2: More details**
+- Present the high-level steps you identified as a numbered list. Tell the user you will dig into the detail in the next round.
+- If you think the skill will require arguments, suggest arguments based on what you observed. Make sure you understand what someone would need to provide.
+- If it's not clear, ask if this skill should run inline (in the current conversation) or forked (as a sub-agent with its own context). Forked is better for self-contained tasks that don't need mid-process user input; inline is better when the user wants to steer mid-process.
+- Ask where the skill should be saved. Suggest a default based on context (repo-specific workflows \u2192 repo, cross-repo personal workflows \u2192 user). Options:
+  - **This repo** (\`.memcode/skills/<name>/SKILL.md\`) \u2014 for workflows specific to this project
+  - **Personal** (\`~/.memcode/skills/<name>/SKILL.md\`) \u2014 follows you across all repos
+
+**Round 3: Breaking down each step**
+For each major step, if it's not glaringly obvious, ask:
+- What does this step produce that later steps need? (data, artifacts, IDs)
+- What proves that this step succeeded, and that we can move on?
+- Should the user be asked to confirm before proceeding? (especially for irreversible actions like merging, sending messages, or destructive operations)
+- Are any steps independent and could run in parallel? (e.g., posting to Slack and monitoring CI at the same time)
+- How should the skill be executed? (e.g. always use a Task agent to conduct code review, or invoke an agent team for a set of concurrent steps)
+- What are the hard constraints or hard preferences? Things that must or must not happen?
+
+You may do multiple rounds of AskUserQuestion here, one round per step, especially if there are more than 3 steps or many clarification questions. Iterate as much as needed.
+
+IMPORTANT: Pay special attention to places where the user corrected you during the session, to help inform your design.
+
+**Round 4: Final questions**
+- Confirm when this skill should be invoked, and suggest/confirm trigger phrases too. (e.g. For a cherrypick workflow you could say: Use when the user wants to cherry-pick a PR to a release branch. Examples: 'cherry-pick to release', 'CP this PR', 'hotfix.')
+- You can also ask for any other gotchas or things to watch out for, if it's still unclear.
+
+Stop interviewing once you have enough information. IMPORTANT: Don't over-ask for simple processes!
+
+### Step 3: Write the SKILL.md
+
+Create the skill directory and file at the location the user chose in Round 2.
+
+Use this format:
+
+\`\`\`markdown
+---
+name: {{skill-name}}
+description: {{one-line description}}
+allowed-tools:
+  {{list of tool permission patterns observed during session}}
+when_to_use: {{detailed description of when memCode should automatically invoke this skill, including trigger phrases and example user messages}}
+argument-hint: "{{hint showing argument placeholders}}"
+arguments:
+  {{list of argument names}}
+context: {{inline or fork -- omit for inline}}
+---
+
+# {{Skill Title}}
+Description of skill
+
+## Inputs
+- \`$arg_name\`: Description of this input
+
+## Goal
+Clearly stated goal for this workflow. Best if you have clearly defined artifacts or criteria for completion.
+
+## Steps
+
+### 1. Step Name
+What to do in this step. Be specific and actionable. Include commands when appropriate.
+
+**Success criteria**: ALWAYS include this! This shows that the step is done and we can move on. Can be a list.
+
+IMPORTANT: see the next section below for the per-step annotations you can optionally include for each step.
+
+...
+\`\`\`
+
+**Per-step annotations**:
+- **Success criteria** is REQUIRED on every step. This helps the model understand what the user expects from their workflow, and when it should have the confidence to move on.
+- **Execution**: \`Direct\` (default), \`Task agent\` (straightforward subagents), \`Teammate\` (agent with true parallelism and inter-agent communication), or \`[human]\` (user does it). Only needs specifying if not Direct.
+- **Artifacts**: Data this step produces that later steps need (e.g., PR number, commit SHA). Only include if later steps depend on it.
+- **Human checkpoint**: When to pause and ask the user before proceeding. Include for irreversible actions (merging, sending messages), error judgment (merge conflicts), or output review.
+- **Rules**: Hard rules for the workflow. User corrections during the reference session can be especially useful here.
+
+**Step structure tips:**
+- Steps that can run concurrently use sub-numbers: 3a, 3b
+- Steps requiring the user to act get \`[human]\` in the title
+- Keep simple skills simple -- a 2-step skill doesn't need annotations on every step
+
+**Frontmatter rules:**
+- \`allowed-tools\`: Minimum permissions needed (use patterns like \`Bash(gh:*)\` not \`Bash\`)
+- \`context\`: Only set \`context: fork\` for self-contained skills that don't need mid-process user input.
+- \`when_to_use\` is CRITICAL -- tells the model when to auto-invoke. Start with "Use when..." and include trigger phrases. Example: "Use when the user wants to cherry-pick a PR to a release branch. Examples: 'cherry-pick to release', 'CP this PR', 'hotfix'."
+- \`arguments\` and \`argument-hint\`: Only include if the skill takes parameters. Use \`$name\` in the body for substitution.
+
+### Step 4: Confirm and Save
+
+Before writing the file, output the complete SKILL.md content as a yaml code block in your response so the user can review it with proper syntax highlighting. Then ask for confirmation using AskUserQuestion with a simple question like "Does this SKILL.md look good to save?" \u2014 do NOT use the body field, keep the question concise.
+
+After writing, tell the user:
+- Where the skill was saved
+- How to invoke it: \`/{{skill-name}} [arguments]\`
+- That they can edit the SKILL.md directly to refine it
+`;
+function registerSkillifySkill() {
+  registerBundledSkill({
+    name: "skillify",
+    description: "Capture this session's repeatable process into a skill. Call at end of the process you want to capture with an optional description.",
+    allowedTools: [
+      "Read",
+      "Write",
+      "Edit",
+      "Glob",
+      "Grep",
+      "AskUserQuestion",
+      "Bash(mkdir:*)"
+    ],
+    userInvocable: true,
+    disableModelInvocation: true,
+    argumentHint: "[description of the process you want to capture]",
+    async getPromptForCommand(args, context) {
+      const sessionMemory = await getSessionMemoryContent() ?? "No session memory available.";
+      const userMessages = extractUserMessages(
+        getMessagesAfterCompactBoundary(context.messages)
+      );
+      const userDescriptionBlock = args ? `The user described this process as: "${args}"` : "";
+      const prompt = SKILLIFY_PROMPT.replace("{{sessionMemory}}", sessionMemory).replace("{{userMessages}}", userMessages.join("\n\n---\n\n")).replace("{{userDescriptionBlock}}", userDescriptionBlock);
+      return [{ type: "text", text: prompt }];
+    }
+  });
+}
+export {
+  registerSkillifySkill
+};

package/dist/skills/bundled/stuck.js

@@ -0,0 +1,60 @@
+import { registerBundledSkill } from "../bundledSkills.js";
+const STUCK_PROMPT = `# /stuck - diagnose frozen or slow memCode sessions
+
+The user thinks an memCode session on this machine is frozen, stuck, or very slow. Investigate locally and report what you find. Do not kill or signal processes unless the user explicitly asks.
+
+## What to look for
+
+Scan for other memCode-related processes. Process names may include memcode, node, bun, or cli depending on how the app was started.
+
+Signs of a stuck session:
+- Sustained high CPU over two samples.
+- Very high memory usage.
+- A stopped, zombie, or unresponsive process.
+- A child process such as git, npm, node, bun, or a shell command that appears hung.
+- Repeated errors or no progress in the session debug log.
+
+## Investigation steps
+
+1. List candidate processes for the current platform.
+   - Windows PowerShell: Get-Process | Where-Object { $_.ProcessName -match 'memcode|node|bun|cli' } | Sort-Object CPU -Descending | Select-Object -First 20 Id,ProcessName,CPU,WorkingSet,StartTime
+   - macOS/Linux: ps -axo pid=,pcpu=,rss=,etime=,state=,comm=,command= | grep -Ei '(memcode|node|bun|cli)' | grep -v grep
+2. For suspicious processes, sample again after 1-2 seconds to distinguish sustained load from a transient spike.
+3. Inspect child processes when available.
+   - Windows PowerShell: Get-CimInstance Win32_Process | Where-Object { $_.ParentProcessId -eq <pid> } | Select-Object ProcessId,Name,CommandLine
+   - macOS/Linux: pgrep -lP <pid>
+4. Check recent debug logs under ~/.memcode/debug or the current project if they exist. Read only the tail unless the file is small.
+5. Summarize the likely cause and concrete next steps.
+
+## Report
+
+Return a concise local report with:
+- Suspect process IDs and commands.
+- CPU and memory observations.
+- Hung child processes, if any.
+- Relevant debug-log errors or warnings.
+- Recommended user action, such as wait, restart a specific session, retry a command, or provide a log excerpt.
+
+If every session looks healthy, say that directly and include the process sample that supports it.
+`;
+function registerStuckSkill() {
+  registerBundledSkill({
+    name: "stuck",
+    description: "Investigate frozen, stuck, or slow memCode sessions on this machine and produce a local diagnostic report.",
+    userInvocable: true,
+    async getPromptForCommand(args) {
+      let prompt = STUCK_PROMPT;
+      if (args) {
+        prompt += `
+## User-provided context
+
+${args}
+`;
+      }
+      return [{ type: "text", text: prompt }];
+    }
+  });
+}
+export {
+  registerStuckSkill
+};