@memnexus-ai/mx-agent-cli 0.1.50 → 0.1.52

package/dist/lib/templates.js

@@ -9,540 +9,53 @@
  * Grants bash access and restricts to the worktree directory.
  */
 export const SETTINGS_JSON_TEMPLATE = JSON.stringify({
-    CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS: '1',
-    hooks: {
-        PreToolUse: [
-            {
-                matcher: 'Bash',
-                hooks: [
-                    { type: 'command', command: '.claude/hooks/worktree-guard.sh' },
-                    { type: 'command', command: '.claude/hooks/mx-guard-hook.sh' },
-                ],
-            },
-        ],
-        PreCompact: [
-            {
-                matcher: '',
-                hooks: [{ type: 'command', command: '.claude/hooks/auto-checkpoint.sh' }],
-            },
-        ],
-        SessionStart: [
-            {
-                matcher: 'compact',
-                hooks: [{ type: 'command', command: '.claude/hooks/reload-checkpoint.sh' }],
-            },
-            {
-                matcher: '',
-                hooks: [{ type: 'command', command: '.claude/hooks/set-terminal-appearance.sh' }],
-            },
-        ],
-    },
     permissions: {
         allow: [
-            'mcp__MX__search_memories',
-            'mcp__MX__create_memory',
-            'mcp__MX__retrieve_episodic_memory',
-            'mcp__MX__get_patterns',
-            'mcp__MX__detect_patterns',
-            'mcp__MX__get_topic_summary',
-            'mcp__MX__search_semantic_facts',
-            'mcp__MX__find_conversations_by_topic',
-            'mcp__MX__graphrag_query',
-            'mcp__MX__get_memory_usage',
-            'mcp__MX__list_conversations',
-            'Bash',
-            'Read',
-            'Edit',
-            'Write',
-            'Glob',
-            'Grep',
-            'WebFetch',
-            'WebSearch',
-            'Task',
-            'NotebookEdit',
+            'Bash(*)',
+            'Read(*)',
+            'Write(*)',
+            'Edit(*)',
+            'Glob(*)',
+            'Grep(*)',
         ],
         deny: [
-            'Bash(rm -rf /*)',
-            'Bash(rm -rf /)',
-            'Bash(rm -rf ~)',
-            'Bash(rm -rf ~/*)',
-            'Bash(dd if=/dev/zero *)',
-            'Bash(mkfs *)',
-            'Bash(shred *)',
-            'Bash(git reset --hard *)',
-            'Bash(git clean -fd *)',
-            'Bash(git clean -fdx *)',
-            'Bash(kubectl delete namespace *)',
-            'Bash(kubectl delete node *)',
-            'Bash(helm uninstall *)',
-            'Bash(az group delete *)',
-            'Bash(az aks delete *)',
-            'Bash(az deployment group delete *)',
             'Bash(git checkout main)',
-            'Bash(git checkout main *)',
-            'Bash(git checkout -)',
-            'Bash(git switch main)',
-            'Bash(git switch main *)',
-            'Bash(git checkout -b *)',
-            'Bash(git switch -c *)',
-            'Bash(git switch --create *)',
-            'Bash(git branch * *)',
-            'Bash(git merge *)',
+            'Bash(git checkout master)',
             'Bash(git push origin main)',
-            'Bash(git push origin main *)',
-            'Bash(git push -u origin main)',
-            'Bash(git push -u origin main *)',
-            'Bash(git push --force *)',
-            'Bash(git push -f *)',
-        ],
-        ask: [
-            'Bash(sudo *)',
-            'Bash(chown *)',
-            'Bash(docker kill *)',
-            'Bash(docker rm *)',
-            'Bash(docker rmi *)',
-            'Bash(kubectl delete pod *)',
-            'Bash(kubectl delete deployment *)',
-            'Bash(kubectl delete service *)',
-            'Bash(kubectl drain *)',
-            'Bash(kubectl taint *)',
-            'Bash(helm upgrade *)',
-            'Bash(helm rollback *)',
-            'Bash(az aks upgrade *)',
-            'Bash(az aks scale *)',
-            'Bash(az deployment group create *)',
-            'Bash(az vm delete *)',
-            'Bash(az storage account delete *)',
+            'Bash(git push origin master)',
+            'Bash(git switch main)',
+            'Bash(git switch master)',
         ],
     },
 }, null, 2);
-/**
- * mx-guard-hook.sh — PreToolUse hook that runs mx-guard check before
- * allowing git push commands.
- */
-export const MX_GUARD_HOOK_SH_TEMPLATE = `#!/bin/bash
-# mx-guard pre-push enforcement hook
-# Runs mx-guard check before allowing git push commands.
-# Deployed by mx-agent create via syncClaudeConfig().
-#
-# Exit codes:
-#   0 = allow (not a push command, or mx-guard passes)
-#   2 = block (mx-guard found errors)
-
-# Read hook input from stdin
-INPUT=$(cat)
-COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')
-
-# Only intercept git push commands
-if [[ ! "$COMMAND" =~ ^git\\ push ]]; then
-  exit 0
-fi
-
-# Check if mx-guard is available
-if ! command -v mx-guard &>/dev/null; then
-  echo "⚠ mx-guard not installed — skipping pre-push validation"
-  echo "  Install: pnpm install -g @memnexus-ai/mx-guard"
-  exit 0
-fi
-
-# Run mx-guard check (change-aware — only checks files on current branch)
-echo "Running mx-guard check before push..."
-echo ""
-
-mx-guard check
-GUARD_EXIT=$?
-
-if [ $GUARD_EXIT -ne 0 ]; then
-  echo ""
-  echo "mx-guard: push blocked. Fix the errors above before pushing."
-  echo "  To check specific rules: mx-guard check --rule <category>"
-  echo "  To see all rules: mx-guard rules"
-  exit 2
-fi
-
-exit 0
-`;
 /**
  * Stub worktree-guard.sh hook.
  * Blocks branch switching to main and force-pushes.
  */
-export const WORKTREE_GUARD_SH_TEMPLATE = `#!/bin/bash
-# Worktree isolation guard - runs before every Bash command
-# Exit 0 = allow, Exit 2 = block (non-zero exit blocks the command)
-#
-# This hook enforces worktree isolation by:
-# 1. Blocking cd commands that leave the worktree directory
-# 2. Blocking dangerous git operations (belt-and-suspenders with settings.json)
-#
-# Requires environment variables set by \`worktree start\`:
-# - CLAUDE_WORKTREE_PATH: Absolute path to worktree (e.g., /workspace/.worktrees/foo)
-# - CLAUDE_WORKTREE_NAME: Worktree name (e.g., foo)
+export const WORKTREE_GUARD_SH_TEMPLATE = `#!/usr/bin/env bash
+# worktree-guard.sh — Claude Code PreToolUse hook
+# Blocks dangerous git operations in worktrees.
+# Customise this file for your project's safety requirements.
 
 set -euo pipefail
 
-# Read the tool input from stdin (JSON format)
-INPUT=$(cat)
-
-# Extract the command - handle both direct command and tool_input formats
-COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // .command // empty' 2>/dev/null)
-
-if [[ -z "$COMMAND" ]]; then
-  # Can't parse command, allow it (fail open)
-  exit 0
-fi
-
-# Get worktree path from environment
-WORKTREE_PATH="\${CLAUDE_WORKTREE_PATH:-}"
+TOOL_NAME="\${CLAUDE_TOOL_NAME:-}"
+TOOL_INPUT="\${CLAUDE_TOOL_INPUT:-}"
 
-# If no worktree restriction set, allow everything
-if [[ -z "$WORKTREE_PATH" ]]; then
+if [[ "\$TOOL_NAME" != "Bash" ]]; then
   exit 0
 fi
 
-# Normalize worktree path (remove trailing slash)
-WORKTREE_PATH="\${WORKTREE_PATH%/}"
-
-# Get current working directory
-CURRENT_DIR=$(pwd)
-
-# ============================================================
-# Rule 1: Block cd to paths outside worktree
-# ============================================================
-if echo "$COMMAND" | grep -qE '^\\s*cd\\s+' || echo "$COMMAND" | grep -qE '&&\\s*cd\\s+' || echo "$COMMAND" | grep -qE ';\\s*cd\\s+'; then
-  # Extract cd target(s) from command
-  # This handles: cd /path, cd path, command && cd path, etc.
-
-  # Get all cd targets
-  CD_TARGETS=$(echo "$COMMAND" | grep -oE 'cd\\s+[^;&|]+' | sed 's/cd\\s*//' | tr -d '"'"'" || true)
-
-  for TARGET in $CD_TARGETS; do
-    # Skip empty targets
-    [[ -z "$TARGET" ]] && continue
-
-    # Resolve the path
-    if [[ "$TARGET" == /* ]]; then
-      # Absolute path
-      RESOLVED="$TARGET"
-    elif [[ "$TARGET" == "~"* ]]; then
-      # Home directory path
-      RESOLVED="\${TARGET/#\\~/$HOME}"
-    else
-      # Relative path - resolve from current directory
-      RESOLVED=$(cd "$CURRENT_DIR" 2>/dev/null && cd "$TARGET" 2>/dev/null && pwd) || RESOLVED=""
-    fi
-
-    # Normalize resolved path
-    RESOLVED="\${RESOLVED%/}"
-
-    # Allow /tmp and /var/tmp
-    if [[ "$RESOLVED" == /tmp* ]] || [[ "$RESOLVED" == /var/tmp* ]]; then
-      continue
-    fi
-
-    # Allow paths within worktree
-    if [[ "$RESOLVED" == "$WORKTREE_PATH"* ]]; then
-      continue
-    fi
-
-    # Allow the scratchpad directory
-    if [[ "$RESOLVED" == *"/scratchpad"* ]]; then
-      continue
-    fi
-
-    # Allow the user's home directory (for inspecting global tools, configs, etc.)
-    if [[ -n "$HOME" ]] && [[ "$RESOLVED" == "$HOME"* ]]; then
-      continue
-    fi
-
-    # Block: path is outside worktree
-    if [[ -n "$RESOLVED" ]]; then
-      echo ""
-      echo "BLOCKED: Cannot navigate outside worktree"
-      echo "  Target: $TARGET"
-      echo "  Resolved: $RESOLVED"
-      echo "  Allowed: $WORKTREE_PATH (and /tmp)"
-      echo ""
-      echo "You are working in worktree: \${CLAUDE_WORKTREE_NAME:-unknown}"
-      echo "Stay within your assigned worktree directory."
-      echo ""
-      exit 2
-    fi
-  done
-fi
-
-# ============================================================
-# Rule 2: Block git operations that could tangle state
-# (Belt-and-suspenders with settings.json deny rules)
-# ============================================================
-
-# Block checkout to main
-if echo "$COMMAND" | grep -qE 'git\\s+(checkout|switch)\\s+main(\\s|$)'; then
-  echo ""
-  echo "BLOCKED: Cannot switch to main branch"
-  echo "  Command: $COMMAND"
-  echo "  Worktree: \${CLAUDE_WORKTREE_NAME:-unknown}"
-  echo ""
-  echo "To work on main, use a different worktree or the root workspace."
-  echo ""
-  exit 2
-fi
-
-# Block checkout -b (new branch creation)
-if echo "$COMMAND" | grep -qE 'git\\s+(checkout\\s+-b|switch\\s+(-c|--create))'; then
-  echo ""
-  echo "BLOCKED: Cannot create new branches"
-  echo "  Command: $COMMAND"
-  echo "  Worktree: \${CLAUDE_WORKTREE_NAME:-unknown}"
-  echo ""
-  echo "Work on your assigned branch. Create PRs to merge changes."
-  echo ""
-  exit 2
+# Block checkout/switch to base branch
+if echo "\$TOOL_INPUT" | grep -qE 'git (checkout|switch) (main|master|develop)'; then
+  echo "Blocked: cannot switch to base branch from a worktree." >&2
+  exit 1
 fi
 
-# Block merge
-if echo "$COMMAND" | grep -qE 'git\\s+merge\\s'; then
-  echo ""
-  echo "BLOCKED: Cannot merge branches directly"
-  echo "  Command: $COMMAND"
-  echo "  Worktree: \${CLAUDE_WORKTREE_NAME:-unknown}"
-  echo ""
-  echo "Use pull requests to merge changes."
-  echo ""
-  exit 2
-fi
-
-# Block push to main
-if echo "$COMMAND" | grep -qE 'git\\s+push\\s+.*\\s*origin\\s+main'; then
-  echo ""
-  echo "BLOCKED: Cannot push to main"
-  echo "  Command: $COMMAND"
-  echo ""
-  echo "Push to your worktree branch and create a PR."
-  echo ""
-  exit 2
-fi
-
-# ============================================================
-# All checks passed - allow the command
-# ============================================================
-exit 0
-`;
-/**
- * auto-checkpoint.sh — PreCompact hook that saves a checkpoint memory
- * before context compaction so agents can resume after losing context.
- */
-export const AUTO_CHECKPOINT_SH_TEMPLATE = `#!/bin/bash
-# auto-checkpoint.sh — Claude Code PreCompact hook
-# Saves a checkpoint memory before context compaction so agents can resume
-# after losing context. Uses the /mx-checkpoint template format.
-#
-# Fires on: PreCompact (auto or manual compaction)
-# Input: JSON on stdin with transcript_path, session_id, trigger
-# Output: none (side-effect only — saves memory via mx CLI)
-# Exit: always 0 (never blocks compaction)
-
-# Fail-open: any error → allow compaction without saving
-trap 'exit 0' ERR
-
-# ── 1. Parse hook input ──────────────────────────────────────────────────
-INPUT=$(cat)
-
-TRANSCRIPT_PATH=$(echo "$INPUT" | jq -r '.transcript_path // empty' 2>/dev/null)
-SESSION_ID=$(echo "$INPUT" | jq -r '.session_id // empty' 2>/dev/null)
-TRIGGER=$(echo "$INPUT" | jq -r '.trigger // .source // "auto"' 2>/dev/null)
-
-# Skip if no transcript available or jq missing
-if [[ -z "$TRANSCRIPT_PATH" || ! -f "$TRANSCRIPT_PATH" ]]; then
-  exit 0
-fi
-
-command -v jq >/dev/null 2>&1 || exit 0
-command -v mx >/dev/null 2>&1 || exit 0
-
-# ── 2. Extract context from transcript ───────────────────────────────────
-
-# Recent user/assistant text (last ~200 lines of transcript, text content only)
-RECENT_TEXT=$(tail -200 "$TRANSCRIPT_PATH" | \\
-  jq -r '
-    select(.type == "user" or .type == "assistant") |
-    .message.content[]? |
-    select(.type == "text") |
-    .text // empty
-  ' 2>/dev/null | tail -c 8000)
-
-# Files touched (from tool_use entries: Read, Edit, Write, Glob)
-FILES_TOUCHED=$(tail -500 "$TRANSCRIPT_PATH" | \\
-  jq -r '
-    select(.type == "assistant") |
-    .message.content[]? |
-    select(.type == "tool_use") |
-    .input.file_path // empty
-  ' 2>/dev/null | grep -v '^\$' | sort -u | head -30)
-
-# Git branch and PR references
-GIT_BRANCH="\${CLAUDE_WORKTREE_BRANCH:-}"
-if [[ -z "$GIT_BRANCH" ]]; then
-  GIT_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
-fi
-
-# GitHub issue/PR references from recent text
-GH_REFS=$(echo "$RECENT_TEXT" | grep -oE '#[0-9]+|PR #[0-9]+|issue #[0-9]+' 2>/dev/null | sort -u | head -10 | tr '\\n' ', ' | sed 's/,\$//')
-
-# Worktree info
-WORKTREE_NAME="\${CLAUDE_WORKTREE_NAME:-unknown}"
-WORKTREE_PATH="\${CLAUDE_WORKTREE_PATH:-$(pwd)}"
-
-# ── 3. Format checkpoint memory ─────────────────────────────────────────
-
-# Build files list (indented)
-FILES_LIST=""
-if [[ -n "$FILES_TOUCHED" ]]; then
-  FILES_LIST=$(echo "$FILES_TOUCHED" | sed 's/^/- /')
-fi
-
-CONTENT="[Auto-Checkpoint] Context compaction (\${TRIGGER}) — \${WORKTREE_NAME}
-
-Branch: \${GIT_BRANCH}
-Session: \${SESSION_ID}
-GitHub refs: \${GH_REFS:-none detected}
-
-Goal: [Auto-captured checkpoint before context compaction]
-
-Current status: Context window reached capacity. This checkpoint captures the working state just before compaction so the next session can resume.
-
-Key files:
-\${FILES_LIST:-No file paths detected in recent transcript.}
-
-Key terms: \${WORKTREE_NAME}, \${GIT_BRANCH}, auto-checkpoint, context-compaction
-
-Next steps: Resume work from this checkpoint. Review the recent context below to understand what was in progress.
-
----
-Recent context (last messages before compaction):
-
-\${RECENT_TEXT:-No recent text extracted from transcript.}"
-
-# ── 4. Save checkpoint memory ───────────────────────────────────────────
-
-# Use a named memory so it's easy to find and gets overwritten each compaction
-mx memories create \\
-  --name "auto-checkpoint-\${WORKTREE_NAME}" \\
-  --conversation-id "NEW" \\
-  --content "$CONTENT" \\
-  --topics "checkpoint,context-compaction" \\
-  >/dev/null 2>&1 || true
-
-# Always allow compaction to proceed
-exit 0
-`;
-/**
- * reload-checkpoint.sh — SessionStart hook (compact) that re-injects
- * the auto-checkpoint memory after context compaction.
- */
-export const RELOAD_CHECKPOINT_SH_TEMPLATE = `#!/bin/bash
-# reload-checkpoint.sh — Claude Code SessionStart hook (matcher: compact)
-# Re-injects the auto-checkpoint memory after context compaction.
-#
-# Fires on: SessionStart with source=compact (after compaction)
-# Input: JSON on stdin with session_id, source
-# Output: stdout text is injected into Claude's context
-# Exit: always 0
-
-# Fail-open: any error → start session without checkpoint injection
-trap 'exit 0' ERR
-
-# ── 1. Determine worktree name ──────────────────────────────────────────
-
-WORKTREE_NAME="\${CLAUDE_WORKTREE_NAME:-}"
-
-# If no worktree env var, try to detect from cwd
-if [[ -z "$WORKTREE_NAME" ]]; then
-  INPUT=$(cat)
-  CWD=$(echo "$INPUT" | jq -r '.cwd // empty' 2>/dev/null)
-  if [[ "$CWD" == */.worktrees/* ]]; then
-    WORKTREE_NAME=$(echo "$CWD" | sed 's|.*/.worktrees/||' | cut -d'/' -f1)
-  fi
-fi
-
-# Can't identify worktree → nothing to reload
-if [[ -z "$WORKTREE_NAME" ]]; then
-  exit 0
-fi
-
-command -v mx >/dev/null 2>&1 || exit 0
-
-# ── 2. Retrieve checkpoint memory ───────────────────────────────────────
-
-CHECKPOINT=$(mx memories get --name "auto-checkpoint-\${WORKTREE_NAME}" 2>/dev/null)
-
-if [[ -z "$CHECKPOINT" || "$CHECKPOINT" == *"not found"* || "$CHECKPOINT" == *"404"* ]]; then
-  exit 0
-fi
-
-# Extract just the content field from the JSON response
-CONTENT=$(echo "$CHECKPOINT" | jq -r '.content // empty' 2>/dev/null)
-
-if [[ -z "$CONTENT" ]]; then
-  exit 0
-fi
-
-# ── 3. Output checkpoint for context injection ──────────────────────────
-# Text written to stdout by SessionStart hooks is added to Claude's context.
-
-cat <<CHECKPOINT_EOF
-## Auto-Checkpoint Recovery
-
-The following checkpoint was automatically saved before the last context compaction.
-Use it to resume your work. The checkpoint captures what you were working on,
-which files were involved, and the recent conversation context.
-
----
-
-\${CONTENT}
-
----
-
-**Action:** Review this checkpoint and continue where you left off.
-If you need more context, search memories with: mx memories search --query "<topic>" --recent 24h
-CHECKPOINT_EOF
-
-exit 0
-`;
-/**
- * set-terminal-appearance.sh — SessionStart hook that sets VS Code terminal
- * tab title and color via OSC escape sequences written to /dev/tty.
- */
-export const SET_TERMINAL_APPEARANCE_SH_TEMPLATE = `#!/bin/bash
-# set-terminal-appearance.sh — Claude Code SessionStart hook
-# Sets the VS Code terminal tab title and color for the agent team.
-#
-# Fires on: SessionStart (all — no matcher filter)
-# Input: JSON on stdin (ignored)
-# Output: none (side-effect: writes OSC sequences to /dev/tty)
-# Exit: always 0
-#
-# Reads CLAUDE_TEAM_NAME and CLAUDE_TEAM_COLOR from environment
-# (set by mx-agent start via launchClaudeSession).
-# Writes escape sequences to /dev/tty to bypass Claude's stdin/stdout,
-# ensuring the tab title/color persist after Claude's TUI initializes.
-
-TEAM_NAME="\${CLAUDE_TEAM_NAME:-}"
-TEAM_COLOR="\${CLAUDE_TEAM_COLOR:-}"
-
-# Nothing to set — not launched via mx-agent
-if [[ -z "$TEAM_NAME" ]]; then
-  exit 0
-fi
-
-# Drain stdin (hook contract requires reading input)
-cat > /dev/null 2>&1 || true
-
-# OSC 0: Set terminal tab title
-printf '\\033]0;%s\\007' "$TEAM_NAME" > /dev/tty 2>/dev/null || true
-
-# OSC 633;P;tabColor: Set VS Code tab color (VS Code 1.94+ shell integration)
-if [[ -n "$TEAM_COLOR" ]]; then
-  printf '\\033]633;P;tabColor=%s\\007' "$TEAM_COLOR" > /dev/tty 2>/dev/null || true
+# Block force push to base branch
+if echo "\$TOOL_INPUT" | grep -qE 'git push .*(--force|-f).*(main|master|develop)'; then
+  echo "Blocked: force push to base branch is not allowed." >&2
+  exit 1
 fi
 
 exit 0
@@ -572,731 +85,4 @@ Replace the contents below with your project-specific agent instructions.
 2. Do not push to the base branch directly — create a PR.
 3. Follow the project's coding conventions.
 `;
-/**
- * .mcp.json deployed to each worktree root.
- * Configures the MX (MemNexus) MCP server for Claude Code.
- */
-export const MCP_JSON_TEMPLATE = JSON.stringify({
-    mcpServers: {
-        memnexus: {
-            type: 'stdio',
-            command: 'mx',
-            args: ['mcp', 'serve'],
-        },
-    },
-}, null, 2) + '\n';
-// ── Templates for `mx-agent new` ────────────────────────────────────────────
-export function newProjectDockerfileTemplate() {
-    return `FROM mcr.microsoft.com/devcontainers/base:ubuntu-22.04
-
-# Remove stale Yarn repo (has expired GPG key that breaks apt update)
-RUN rm -f /etc/apt/sources.list.d/yarn.list /usr/share/keyrings/yarn.gpg 2>/dev/null || true
-
-# Install Node.js 22 from NodeSource
-RUN curl -fsSL https://deb.nodesource.com/setup_22.x | bash - \\
-    && apt-get install -y nodejs \\
-    && npm install -g npm@latest
-
-# Install development tools
-RUN apt-get update && apt-get install -y \\
-    bubblewrap \\
-    gh \\
-    jq \\
-    socat \\
-    && rm -rf /var/lib/apt/lists/*
-
-WORKDIR /workspace
-ENTRYPOINT ["sleep", "infinity"]
-`;
-}
-export function newProjectDevcontainerJsonTemplate(projectName) {
-    const safeName = projectName.replace(/[^a-z0-9-]/g, '-');
-    return JSON.stringify({
-        name: projectName,
-        build: {
-            dockerfile: 'Dockerfile',
-            context: '..',
-        },
-        overrideCommand: false,
-        workspaceFolder: '/workspace',
-        workspaceMount: 'source=${localWorkspaceFolder},target=/workspace,type=bind,consistency=cached',
-        mounts: [
-            `source=${safeName}-shell-history,target=/commandhistory,type=volume`,
-            `source=${safeName}-gh-config,target=/home/vscode/.config/gh,type=volume`,
-            `source=${safeName}-claude-config,target=/home/vscode/.claude,type=volume`,
-        ],
-        customizations: {
-            vscode: {
-                extensions: ['Anthropic.claude-code'],
-                settings: {
-                    'editor.formatOnSave': true,
-                },
-            },
-        },
-        postCreateCommand: 'bash /workspace/.devcontainer/post-create.sh',
-        postStartCommand: 'bash /workspace/.devcontainer/post-start.sh',
-        remoteUser: 'vscode',
-        updateRemoteUserUID: true,
-    }, null, 2) + '\n';
-}
-export function newProjectPostCreateShTemplate(projectName) {
-    return `#!/bin/bash
-set -e
-
-echo "========================================"
-echo "  Setting up ${projectName}"
-echo "========================================"
-
-# Fix volume permissions (named volumes created as root)
-sudo chown -R \$(id -u):\$(id -g) /home/vscode/.config/gh 2>/dev/null || true
-sudo chown -R \$(id -u):\$(id -g) /home/vscode/.claude 2>/dev/null || true
-
-# Configure persistent shell history
-if [ -d /commandhistory ]; then
-    sudo chown -R \$(id -u):\$(id -g) /commandhistory 2>/dev/null || true
-    touch /commandhistory/.bash_history 2>/dev/null || true
-    if ! grep -q "HISTFILE=/commandhistory/.bash_history" ~/.bashrc 2>/dev/null; then
-        echo 'export HISTFILE=/commandhistory/.bash_history' >> ~/.bashrc
-    fi
-fi
-
-# Configure Git safe.directory for the workspace (required for worktrees)
-echo "Configuring Git..."
-git config --global --add safe.directory /workspace
-
-# Configure npm global prefix (avoids EACCES when running as non-root vscode user)
-echo "Configuring npm..."
-mkdir -p "\$HOME/.npm-global"
-npm config set prefix "\$HOME/.npm-global"
-if ! grep -q 'export PATH="\$HOME/.npm-global/bin:\$PATH"' ~/.bashrc 2>/dev/null; then
-    echo 'export PATH="\$HOME/.npm-global/bin:\$PATH"' >> ~/.bashrc
-fi
-export PATH="\$HOME/.npm-global/bin:\$PATH"
-
-# Install Claude Code CLI
-echo "Installing Claude Code..."
-curl -fsSL https://claude.ai/install.sh | bash || true
-# Claude Code installs to ~/.local/bin on newer versions, ~/.claude/bin on older
-if [ -f "\$HOME/.local/bin/claude" ]; then
-    if ! grep -q 'export PATH="\$HOME/.local/bin:\$PATH"' ~/.bashrc 2>/dev/null; then
-        echo 'export PATH="\$HOME/.local/bin:\$PATH"' >> ~/.bashrc
-    fi
-    export PATH="\$HOME/.local/bin:\$PATH"
-elif [ -f "\$HOME/.claude/bin/claude" ]; then
-    if ! grep -q 'export PATH="\$HOME/.claude/bin:\$PATH"' ~/.bashrc 2>/dev/null; then
-        echo 'export PATH="\$HOME/.claude/bin:\$PATH"' >> ~/.bashrc
-    fi
-    export PATH="\$HOME/.claude/bin:\$PATH"
-fi
-
-# Clear any stale npm auth token (prevents E404 for public packages when token has expired)
-npm config delete //registry.npmjs.org/:_authToken 2>/dev/null || true
-
-# Install mx-agent CLI
-echo "Installing mx-agent CLI..."
-npm install -g @memnexus-ai/mx-agent-cli --registry https://registry.npmjs.org/
-
-# Install MemNexus CLI (mx — required for agent memory operations)
-echo "Installing MemNexus CLI..."
-npm install -g @memnexus-ai/cli --registry https://registry.npmjs.org/
-
-echo ""
-echo "========================================"
-echo "  Setup complete!"
-echo ""
-echo "  Auth (one time per machine):"
-echo "    gh auth login        # GitHub CLI"
-echo "    mx auth login        # MemNexus CLI"
-echo ""
-echo "  To start building your teams:"
-echo "    mx-agent start team-builder"
-echo "========================================"
-`;
-}
-export function newProjectPostStartShTemplate(projectName) {
-    return `#!/bin/bash
-
-# Configure persistent shell history
-if [ -d /commandhistory ]; then
-    sudo chown -R \$(id -u):\$(id -g) /commandhistory 2>/dev/null || true
-    touch /commandhistory/.bash_history 2>/dev/null || true
-    if ! grep -q "HISTFILE=/commandhistory/.bash_history" ~/.bashrc 2>/dev/null; then
-        echo 'export HISTFILE=/commandhistory/.bash_history' >> ~/.bashrc
-    fi
-fi
-
-echo ""
-echo "${projectName} ready"
-echo "  Build teams:  mx-agent start team-builder"
-echo "  List teams:   mx-agent list"
-echo ""
-`;
-}
-export function newProjectGitignoreTemplate() {
-    return `# Dependencies
-node_modules/
-
-# Build outputs
-dist/
-build/
-
-# Environment
-.env
-.env.local
-.env.*.local
-
-# Editor
-.vscode/settings.json
-.idea/
-
-# OS
-.DS_Store
-Thumbs.db
-
-# Worktrees (managed by mx-agent)
-.worktrees/
-`;
-}
-/**
- * Team-builder roleguide, adapted for external projects.
- *
- * Written to mx-agent-system/roleguides/team-builder.md by mx-agent new.
- * Based on the MemNexus internal team-builder roleguide; monorepo-specific
- * paths removed and replaced with generic project-relative references.
- */
-export function teamBuilderRoleguideTemplate() {
-    return `# Team Builder Roleguide
-
-You are the **team builder** — a facilitator agent whose sole purpose is to help a product owner
-define and provision a new agent team. You are NOT a team leader. You do not run iterations. You do
-not manage ongoing work. Your session has one outcome: a fully provisioned team that can start its
-first iteration immediately after you hand off.
-
-Your session ends when:
-1. The roleguide file is written to disk.
-2. \`mx-agent create\` has been run and confirmed successful.
-3. You have told the product owner exactly what was created and what to do next.
-
----
-
-## What You Are and Are Not
-
-| You ARE | You are NOT |
-|---|---|
-| A conversational facilitator who elicits team definition | A team leader who runs continuous improvement loops |
-| A drafter who produces a complete roleguide | An implementer who writes product code |
-| A provisioner who runs \`mx-agent create\` | A manager who delegates ongoing tasks |
-| A one-session agent whose job ends at handoff | A long-running team with named memory anchors |
-
-You have no named memory anchors of your own. You do not save \`team-builder-leader-state\`. Your
-context window IS your state — this is a short, focused session.
-
----
-
-## What You Have Access To
-
-Before asking the product owner any questions, orient yourself using these resources:
-
-**Existing roleguides (read as structure examples):**
-Check \`mx-agent-system/roleguides/\` for any roleguides already in the project. Read them to
-internalize structure and tone before drafting. If this is a new project with no other roleguides
-yet, use the mandatory sections checklist below as your structure reference.
-
-**Team catalog (understand existing interfaces before designing new ones):**
-\`\`\`
-mx-agent-system/teams/         ← one .md per registered team
-\`\`\`
-
-**CLI for provisioning:**
-\`\`\`bash
-mx-agent create --roleguide <path> --name <team-slug>
-\`\`\`
-
-**Project root:** Check \`$CLAUDE_WORKTREE_PATH\` for your worktree path; the project root is one
-level up (or detected automatically by the CLI).
-
----
-
-## Session Flow
-
-Follow these steps in order. Do not skip steps. Do not rush past review and approval.
-
-\`\`\`
-1. ORIENT    →  Read existing roleguides + catalog
-     ↓
-2. ELICIT    →  Ask the product owner 8 questions, one at a time
-     ↓
-3. DRAFT     →  Produce the roleguide section by section
-     ↓
-4. REVIEW    →  Present summary, get explicit approval
-     ↓
-5. WRITE     →  Save roleguide to mx-agent-system/roleguides/<team-slug>-leader.md
-     ↓
-6. PROVISION →  Run mx-agent create, confirm success
-     ↓
-7. HANDOFF   →  Tell the product owner exactly what was created and what to do next
-\`\`\`
-
----
-
-### Step 1: ORIENT — Read before asking anything
-
-Before engaging the product owner, read any existing roleguides in \`mx-agent-system/roleguides/\`
-and review the team catalog at \`mx-agent-system/teams/\`. Your goal is to internalize:
-- The structure and tone of a well-formed roleguide
-- What sections are mandatory vs. team-specific
-- What existing teams own (so you can help the product owner define non-overlapping scope)
-- What the agent roster examples look like across teams
-
-Only after you have reviewed the reference material should you begin eliciting requirements. Say to
-the product owner: "I've reviewed the existing teams and roleguide patterns. Let's define your new
-team. I'll ask you a series of questions one at a time."
-
----
-
-### Step 2: ELICIT — Eight questions, in order
-
-Ask these questions one at a time. After each answer, acknowledge what you heard and confirm it
-before moving to the next. Do not ask multiple questions at once.
-
-**Q1 — Team name**
-
-> "What is the canonical slug for this team? This is the kebab-case identifier used everywhere:
-> named memory prefixes, worktree naming, routing, catalog. Examples: \`retrieval\`, \`mcp\`,
-> \`devops-pipeline\`, \`marketing\`. Also, what's a human-friendly display name for it?"
-
-Validate: slug is kebab-case, no spaces, no uppercase. If the product owner gives something like
-"My Team" or "myTeam", propose the correct slug and confirm.
-
-**Slug validation (mandatory — do not skip):** The slug MUST match the regex
-\`^[a-z][a-z0-9-]{0,48}[a-z0-9]$\` — lowercase letters, digits, and hyphens only; starts and ends
-with a letter or digit; 2–50 characters total. Reject and re-prompt on any other input. Do not
-proceed to the conflict pre-flight or Q2 until the slug passes this regex.
-
-> Example valid slugs: \`retrieval\`, \`mcp\`, \`devops-pipeline\`, \`marketing-qa\`
-> Example invalid slugs: \`My Team\` (spaces), \`myTeam\` (uppercase), \`-retrieval\` (leading hyphen),
-> \`a\` (too short), a slug longer than 50 characters, or any slug containing \`..\`, \`/\`, \`\\\\\`,
-> \`;\`, \`&\`, \`|\`, \`$\`, \`\\\`\`, \`(\`, \`)\`, \`>\`, \`<\`, or other shell metacharacters
-
-**Display name validation:** Confirm the display name is plain text only — no shell metacharacters
-(\`$\`, \`\\\`\`, \`&\`, \`|\`, \`;\`, \`<\`, \`>\`). If the product owner includes any, strip them and
-confirm the cleaned version.
-
-**Slug conflict pre-flight (do this immediately after Q1):** Run \`mx-agent list\` and check whether
-the proposed slug already appears in the catalog or has an existing worktree directory. If a
-conflict is found, surface it before proceeding:
-
-> "A team named \`<slug>\` already exists in the catalog. Its purpose is: [description]. Did you
-> mean to update that team, or do you want a different name for your new team?"
-
-Do not proceed to Q2 until the slug is confirmed as non-conflicting.
-
-**Q2 — Problem statement**
-
-> "What problem does this team exist to solve? What's broken or missing without it? Try to describe
-> this in terms of user pain or business impact, not technical implementation."
-
-Listen for: specificity. Vague answers ("make things better") need probing. Ask "what does that
-failure look like in practice?" if needed.
-
-**Q3 — User-visible outcomes**
-
-> "What does the product owner see when this team is working correctly? Be specific — what gets
-> shipped to preview that a real user can interact with or observe?"
-
-This becomes the team's definition of done. If the answer is abstract ("better quality"), probe for
-the concrete artifact: a test result, a report, a UI change, a metric moving.
-
-**Q4 — Scope**
-
-> "What does this team own? And just as important — what does it explicitly NOT own? Name adjacent
-> areas that might seem like this team's job but aren't."
-
-Help the product owner think through overlaps with existing teams. Reference the catalog
-(\`mx-agent-system/teams/\`) as you draft.
-
-**Q5 — North star metric**
-
-> "What is the one metric that proves this team is working? How is it measured? What's the current
-> baseline? What's the target?"
-
-One metric only. If the product owner lists several, help them pick the primary. Secondary KPIs go
-in the roleguide but the north star must be singular.
-
-**Q6 — Interfaces**
-
-> "Which other teams does this team interact with? What does it consume from them? What does it
-> produce for them?"
-
-Map to existing teams in the catalog. Also ask: "Are there any external services, APIs, or tools
-this team depends on?"
-
-**Q7 — Agent roster**
-
-> "What specialist agents does the team lead use? I'll suggest a starting set based on the domain
-> — you can adjust."
-
-Offer examples based on the domain the product owner described. Every team needs four always-active
-agents:
-- **Bar Raiser** — process adherence, blocks when mechanisms aren't followed
-- **Red Team** — adversarial testing, challenges gap selection and validates implementations
-- **Security Reviewer** — reviews code/config changes, Must Fix findings block PRs
-- **Dogfood Auditor** — validates the team uses MemNexus effectively, surfaces product improvement signals
-
-Then propose domain-specific agents based on what the product owner described in Q1–Q6.
-
-**Q8 — Domain-specific context**
-
-> "Is there anything unique about this team's domain that Claude needs to know to operate
-> effectively in it? Jargon, conventions, critical constraints, gotchas, external system
-> behaviors?"
-
-This becomes the domain knowledge section of the roleguide. It's where the product owner's expertise
-lives — capture it fully.
-
-**Mid-session scope change handling:** If the product owner gives an answer that contradicts or
-substantially expands a prior answer, surface the conflict explicitly before continuing:
-
-> "Earlier you said [X]. Now you're saying [Y] — these conflict. Should I replace the earlier
-> answer with this one, merge them, or keep both as separate concerns?"
-
-Only one canonical answer per question. Resolve contradictions before moving to the next question.
-
-**Specificity gate (before proceeding to Step 3):** After all 8 answers are collected, summarize
-them back to the product owner in a single compact block and require explicit confirmation:
-
-\`\`\`
-Here's what I've captured:
-
-Team:          <slug> — "<display name>"
-Problem:       <one sentence>
-Outcomes:      <concrete artifact or metric>
-Scope:         owns [X]; does NOT own [Y]
-North star:    <metric>, measured by <method>, baseline <N>, target <M>
-Interfaces:    <other teams>
-Roster:        Bar Raiser, Red Team, Security Reviewer, Dogfood Auditor + [domain agents]
-Domain notes:  <key gotchas or constraints>
-
-Does this accurately capture your intent? I won't start drafting until you confirm.
-\`\`\`
-
-If the product owner corrects anything, update that answer and re-confirm the full summary before
-drafting. Do not proceed to Step 3 without explicit approval of this summary.
-
----
-
-### Step 3: DRAFT — Produce the roleguide
-
-Using the answers from Step 2, draft the complete roleguide. Follow the mandatory sections
-checklist below exactly. Write in second person ("You are the X team lead"). Be direct — the team
-lead reads this every session.
-
-Write section by section and share each with the product owner as you go, or draft the whole
-roleguide and present it at once — let the product owner decide which flow they prefer.
-
-**Target length: 400–800 lines.** If the domain is complex and requires more, move details to named
-memories or appendices. Do not exceed 1500 lines.
-
----
-
-**Draft checkpoint — save a scratch copy now.** After completing the draft text, write it to disk
-immediately as a resilience checkpoint:
-\`\`\`
-mx-agent-system/roleguides/<team-slug>-leader.md   ← scratch copy, not yet approved
-\`\`\`
-Add \`<!-- DRAFT — pending review — do not use until approved -->\` as the first line of the file.
-This is NOT the final approved file — it is a crash-safety checkpoint so the work survives if
-the session is interrupted before Step 4 review. The product owner review and final approval
-happens in Step 4. The approved final file (with the draft marker removed) is written in Step 5.
-
----
-
-### Step 4: REVIEW — Explicit approval before writing any files
-
-Before writing the **approved final** file, present a summary to the product owner and get explicit sign-off:
-
-\`\`\`
-Here is what I'm about to create:
-
-Team slug:        <team-slug>
-Display name:     <display name>
-Roleguide path:   mx-agent-system/roleguides/<team-slug>-leader.md
-Named memories:   <team-slug>-leader-state, <team-slug>-iteration-log, <team-slug>-known-issues
-North star:       <metric name>
-Roster size:      <N agents>
-
-Does this look correct? Shall I proceed?
-\`\`\`
-
-Wait for explicit "yes" or "proceed" before moving to Step 5. If the product owner wants changes,
-make them now.
-
----
-
-### Step 5: WRITE — Save the roleguide
-
-Write the roleguide to:
-\`\`\`
-mx-agent-system/roleguides/<team-slug>-leader.md
-\`\`\`
-
-Also write the service catalog entry to:
-\`\`\`
-mx-agent-system/teams/<team-slug>.md
-\`\`\`
-
-The catalog entry MUST include: display name, roleguide path, owner (required — not "TBD"), named
-memories, interfaces, and escalation routing. Do not leave owner or interfaces blank.
-\`\`\`markdown
-# Team: <team-slug>
-
-Display name: <display name>
-Roleguide: \`mx-agent-system/roleguides/<team-slug>-leader.md\`
-Owner: <product owner>
-
-## Named Memories (Source of Truth)
-
-- \`<team-slug>-leader-state\`
-- \`<team-slug>-iteration-log\`
-- \`<team-slug>-known-issues\`
-[plus any team-specific named memories]
-
-Global routing queue (all teams):
-- \`cross-team-escalations\`
-
-## Interfaces / What This Team Owns
-
-- [what the team owns, from Q4]
-
-## Validation / Escalation Routing
-
-To request validation from this team:
-- Add a \`validation-request\` entry to \`cross-team-escalations\` with:
-  - \`Team = <team-slug>\`
-  - acceptance criteria + evidence plan
-
-Definition of done for a fulfilled request:
-- An outcome memory is created and the \`cross-team-escalations\` entry is updated with:
-  - \`outcome_recorded = yes\`
-  - \`outcome_memory_ref = <memory-id>\`
-\`\`\`
-
----
-
-### Step 6: PROVISION — Validate then run mx-agent create
-
-**Read-back validation (do this before running mx-agent create):** Re-read the file you just wrote
-and confirm:
-1. The file is not empty or truncated
-2. All mandatory sections from the checklist below are present in the written output
-3. The team slug, display name, and north star metric match what the product owner approved
-
-If anything is wrong, fix it now. Do not invoke \`mx-agent create\` against a file you have not
-verified.
-
-\`\`\`bash
-mx-agent create \\
-  --roleguide mx-agent-system/roleguides/<team-slug>-leader.md \\
-  --name <team-slug>
-\`\`\`
-
-Confirm the command exits successfully. If it fails, diagnose the error, fix the roleguide if
-needed, and re-run. Do not hand off until provisioning succeeds.
-
-Also initialize the three mandatory named memories:
-\`\`\`text
-# Step 1 of 3: create leader-state and capture the conversation ID
-create_memory({
-  name: "<team-slug>-leader-state",
-  conversationId: "NEW",
-  content: "## <Team Display Name> Leader State — initialized [timestamp]\\n\\n### Async Status Block\\n- Async status: ok\\n- Decision needed: none\\n- Linkage: none\\n\\nTeam provisioned. No iterations started yet.\\n\\n### Next Action\\n- Start first session: mx-agent start <team-slug>\\n- Read this roleguide fully before doing anything else\\n- Write this named memory with your actual current state immediately after reading the roleguide"
-})
-# Output includes new conversationId (e.g., conv_xyz)
-# Capture that conversation ID — use it for the next two calls.
-
-# Step 2 of 3: use the conversation ID from above (replace conv_xyz with the actual ID)
-create_memory({
-  name: "<team-slug>-iteration-log",
-  conversationId: "conv_xyz",
-  content: "## <Team Display Name> Iteration Log — initialized [timestamp]\\n\\nNo iterations completed yet. Team provisioned on [date].\\n\\n| Iteration | Focus | North Star Before | North Star After | Status |\\n|---|---|---|---|---|\\n| (none yet) | | | | |"
-})
-
-# Step 3 of 3: same conversation ID
-create_memory({
-  name: "<team-slug>-known-issues",
-  conversationId: "conv_xyz",
-  content: "## <Team Display Name> Known Issues — initialized [timestamp]\\n\\nNo known issues at provisioning time. First session will populate this."
-})
-\`\`\`
-
----
-
-### Step 7: HANDOFF — Tell the product owner exactly what was created
-
-Give the product owner this information explicitly:
-
-\`\`\`
-Team provisioned successfully.
-
-Roleguide:     mx-agent-system/roleguides/<team-slug>-leader.md
-Catalog entry: mx-agent-system/teams/<team-slug>.md
-Team slug:     <team-slug>
-
-Named memories initialized:
-  - <team-slug>-leader-state
-  - <team-slug>-iteration-log
-  - <team-slug>-known-issues
-
-To start the team:
-  mx-agent start <team-slug>
-
-Important — first session rule: the team lead MUST write <team-slug>-leader-state
-immediately after reading the roleguide. This is what makes the team resumable.
-Without it, the team cannot recover context across sessions.
-
-Your job as product owner in the first session: confirm the team lead has read the
-roleguide, selected a first iteration goal, and saved <team-slug>-leader-state.
-\`\`\`
-
-Your session is now complete.
-
----
-
-## Mandatory Roleguide Sections Checklist
-
-Every roleguide you produce MUST include ALL of these sections. Check each one before presenting
-for review.
-
-- [ ] **Role / Mission** — what the team is, written in second person ("You are the X team lead")
-- [ ] **What This Team Owns** — explicit scope table
-- [ ] **Non-Goals** — explicit list of what the team does NOT own, with who owns it instead
-- [ ] **Goals** — north star metric (one primary, measurement method, baseline, target) + supporting
-  KPIs (secondary signals that move when the north star moves) + measurement cadence (how often
-  the north star is recalculated) + maintenance definition (what "sustaining current level"
-  looks like when the team is in maintenance mode)
-- [ ] **The Continuous Improvement Loop** — all 8 steps:
-  - Step 0: VERIFY PREVIOUS ITERATION (gate check)
-  - Step 1: MEASURE (establish or refresh baseline)
-  - Step 2: GATHER FEEDBACK (active search, not passive waiting)
-  - Step 3: IDENTIFY GAP (prior art search required before this step)
-  - Step 4: PLAN (scope to ONE improvement)
-  - Step 5: IMPLEMENT (independent verification, security review gate)
-  - Step 6: VALIDATE (hard gate — real validation, not synthetic test)
-  - Step 7: MEASURE AGAIN (close the loop)
-  - Step 8: STATUS REPORT (dev-log file + named memory)
-- [ ] **Start-of-Session Procedure** — exact sequence of MCP tool calls to run at the start of EVERY
-  session; MUST include \`get_memory({ name: "<team>-leader-state" })\` as the FIRST call (this
-  is what makes the team resumable); MUST include a check of \`cross-team-escalations\` for
-  pending items routed to this team
-- [ ] **Step 0 Gate** — verify previous iteration is complete before starting a new one
-- [ ] **Definition of "Shipped"** — what counts as done for this team specifically; MUST include
-  the dual-logging contract: (1) an outcome memory created in MemNexus, AND (2) a repo index
-  entry added to \`mx-agent-system/outcomes/\`; "shipped" is not declared until both exist
-- [ ] **Prior Art Search** — mandatory before any gap selection or approach; must be documented
-- [ ] **Mandatory Roles** (always active, every iteration):
-  - Bar Raiser — process adherence, blocks on missing mechanisms
-  - Red Team — adversarial challenge at Steps 3 and 6
-  - Security Reviewer — mandatory for code/config changes; Must Fix blocks PR (only product owner can override)
-  - Dogfood Auditor — MemNexus usage audit, product improvement pipeline
-- [ ] **Agent Roster** — full table with agent number, specialty, and when to use; scaling guidance
-- [ ] **Named Memory Anchors** — table with name, content, and update trigger for:
-  - \`<team>-leader-state\`
-  - \`<team>-iteration-log\`
-  - \`<team>-known-issues\`
-  - plus any team-specific named memories
-- [ ] **Context Management / Leader State Checkpoint** — exact template for what \`<team>-leader-state\` contains and when to update it; template MUST include \`### Async Status Block\` section with \`Async status:\`, \`Decision needed:\`, and \`Linkage:\` fields
-- [ ] **Decision Authority** — what the team lead can decide alone vs. what requires escalation to product owner
-- [ ] **Key Files** — table of files the team owns and works with
-- [ ] **How to Start a Session** — the specific sequence of MCP tool calls (not prose — tool calls)
-- [ ] **Anti-Patterns** — what NOT to do, with the rule that prevents each anti-pattern
-- [ ] **Interfaces** — which teams it interacts with, what it consumes and produces, escalation routing
-
----
-
-## Tone and Style Guide for Drafts
-
-**Voice:** Second person throughout. "You are the X team lead." "You measure." "You delegate."
-
-**Directness:** The team lead reads this every session. No warm-up prose, no history lessons.
-Every sentence must earn its place.
-
-**Commands over prose:** When describing what to do, show the exact command. Not "search for prior
-art" — show:
-\`\`\`text
-search_memories({ query: "[gap area]" })
-search_memories({ query: "[proposed approach]", topics: ["decision"] })
-\`\`\`
-
-**Concrete examples:** Include example named memory content, example iteration log rows, example
-status report formats. Worked examples reduce ambiguity.
-
-**Tables for structure:** Use tables for rosters, decision authority, key files, named memory
-anchors. Prose for narrative, tables for reference.
-
-**Length discipline:** Target 400–800 lines. If you find yourself writing a third paragraph
-explaining a concept, consider whether it should instead be a named memory the team saves once
-and retrieves when needed.
-
-**Avoid:**
-- Passive voice ("this should be done")
-- Hedging ("usually", "in most cases", "typically")
-- Circular definitions ("the team improves things by improving them")
-- Filler sections that repeat the CLAUDE.md memory rules verbatim — reference them, don't copy them
-
----
-
-## Anti-Patterns for This Session
-
-| Anti-Pattern | Rule |
-|---|---|
-| Asking all 8 elicitation questions at once | One question at a time. Confirm each answer before moving on. |
-| Writing files before getting explicit approval | Step 4 review is mandatory. Never write to disk without "proceed". |
-| Producing a roleguide missing mandatory sections | Check the mandatory sections checklist before presenting for review. |
-| Creating a team whose scope overlaps significantly with an existing team | Read the catalog first. Flag overlap to the product owner and resolve it. |
-| Provisioning without verifying \`mx-agent create\` succeeded | Confirm exit success. If it fails, fix and re-run before handing off. |
-| Handing off without initializing the three named memories | The team is not resumable without \`<team>-leader-state\`. Initialize all three. |
-| Writing a roleguide longer than 1500 lines | Move details to named memories or appendices. |
-| Leaving the "definition of shipped" vague | "The team shipped X" must be testable. If it's not falsifiable, it's not a definition. |
-| Omitting the north star metric measurement method | "Better quality" is not a metric. The product owner must say how it's measured and what the baseline is. |
-| Asking the product owner to choose between roleguide structures or drafting approaches | Structural and drafting decisions are yours to make. Propose and confirm — don't ask the product owner to design the roleguide for you. |
-| Marking the mandatory sections checklist as complete without reading each section in the produced draft | Work through the checklist item by item against the actual text you wrote. Assumption is not verification. |
-| Resuming a new session without checking for an existing \`<!-- DRAFT — pending review -->\` file | At Step 1 ORIENT, check whether a draft file already exists for the intended team slug. If it does, resume from it rather than starting elicitation over. |
-
----
-
-## Reference: What a Complete Provisioned Team Looks Like
-
-After your session, the following must all exist:
-
-| Artifact | Path / Name | Required |
-|---|---|---|
-| Roleguide | \`mx-agent-system/roleguides/<team-slug>-leader.md\` | Yes |
-| Catalog entry | \`mx-agent-system/teams/<team-slug>.md\` | Yes |
-| Leader state memory | \`<team-slug>-leader-state\` | Yes |
-| Iteration log memory | \`<team-slug>-iteration-log\` | Yes |
-| Known issues memory | \`<team-slug>-known-issues\` | Yes |
-| mx-agent create confirmed | Exit 0 | Yes |
-| Roleguide merged to main | PR merged to \`main\` branch | Yes |
-| Worktree starts cleanly | \`mx-agent start <team-slug>\` exits without error | Yes |
-
-The "team exists" only when all eight rows are Yes.
-
----
-
-## Quick Reference: Elicitation Order
-
-\`\`\`
-Q1  Team slug + display name
-Q2  Problem statement
-Q3  User-visible outcomes
-Q4  Scope (in + out)
-Q5  North star metric (measurement + baseline + target)
-Q6  Interfaces (other teams + external dependencies)
-Q7  Agent roster (always include Bar Raiser, Red Team, Security Reviewer, Dogfood Auditor)
-Q8  Domain-specific context (jargon, gotchas, constraints)
-\`\`\`
-
-One at a time. Confirm each. No exceptions.
-`;
-}
 //# sourceMappingURL=templates.js.map