@mmnto/cli 0.1.0 → 0.2.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Matt Sutton
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/dist/commands/briefing.js

@@ -9,36 +9,36 @@ const TAG = 'Briefing';
 const MAX_SPEC_RESULTS = 5;
 const MAX_SESSION_RESULTS = 5;
 // ─── System prompt ──────────────────────────────────────
-const SYSTEM_PROMPT = `# Briefing System Prompt — Session Startup Briefing
-
-## Purpose
-Produce a session startup briefing that orients the developer at the start of an AI-assisted work session.
-
-## Role
-You are a technical project assistant producing a quick-start briefing. You have access to the current git state, open pull requests, and project knowledge from Totem. Your job is to synthesize this into an actionable summary so the developer knows exactly where they left off and what to do next.
-
-## Rules
-- Reference PRs by number (#NNN) and branch name
-- Reference issues by number (#NNN) when they appear in Totem knowledge
-- Be opinionated about what the recommended first action should be
-- Be concise — this is a startup briefing, not a project plan
-- If there are uncommitted changes, flag them prominently
-- If there are no open PRs, say so
-
-## Output Format
-Respond with ONLY the sections below. No preamble, no closing remarks.
-
-### Session Context
-[Current branch, uncommitted changes summary. If working tree is clean, say so. If on a feature branch, note what it likely relates to.]
-
-### Open PRs
-[List of open PRs with number, title, and branch. If none, say "No open PRs." Highlight any that are the developer's current branch.]
-
-### Active Priorities
-[Key priorities and recent work context from Totem knowledge — what was recently worked on, what specs are active, what sessions covered. If no relevant knowledge, say "No recent context found in Totem index."]
-
-### Recommended First Action
-[Single clear recommendation for what the developer should do first in this session. Consider: uncommitted work to commit/continue, PRs to review/merge, next issue to pick up.]
+const SYSTEM_PROMPT = `# Briefing System Prompt — Session Startup Briefing
+
+## Purpose
+Produce a session startup briefing that orients the developer at the start of an AI-assisted work session.
+
+## Role
+You are a technical project assistant producing a quick-start briefing. You have access to the current git state, open pull requests, and project knowledge from Totem. Your job is to synthesize this into an actionable summary so the developer knows exactly where they left off and what to do next.
+
+## Rules
+- Reference PRs by number (#NNN) and branch name
+- Reference issues by number (#NNN) when they appear in Totem knowledge
+- Be opinionated about what the recommended first action should be
+- Be concise — this is a startup briefing, not a project plan
+- If there are uncommitted changes, flag them prominently
+- If there are no open PRs, say so
+
+## Output Format
+Respond with ONLY the sections below. No preamble, no closing remarks.
+
+### Session Context
+[Current branch, uncommitted changes summary. If working tree is clean, say so. If on a feature branch, note what it likely relates to.]
+
+### Open PRs
+[List of open PRs with number, title, and branch. If none, say "No open PRs." Highlight any that are the developer's current branch.]
+
+### Active Priorities
+[Key priorities and recent work context from Totem knowledge — what was recently worked on, what specs are active, what sessions covered. If no relevant knowledge, say "No recent context found in Totem index."]
+
+### Recommended First Action
+[Single clear recommendation for what the developer should do first in this session. Consider: uncommitted work to commit/continue, PRs to review/merge, next issue to pick up.]
 `;
 // ─── GitHub helpers ─────────────────────────────────────
 const GhPrListItemSchema = z.object({

package/dist/commands/handoff.js

@@ -7,39 +7,39 @@ const TAG = 'Handoff';
 const MAX_DIFF_CHARS = 50_000;
 const LESSONS_TAIL_LINES = 100;
 // ─── System prompt ──────────────────────────────────────
-const SYSTEM_PROMPT = `# Handoff System Prompt — End-of-Session State Transfer
-
-## Purpose
-Produce an end-of-session handoff snapshot that captures everything the next session (or the next developer) needs to resume work immediately.
-
-## Role
-You are writing a concise, tactical "End of Shift" handoff. You have access to the current git state, uncommitted changes, and lessons learned during this session. Your job is to synthesize this into a snapshot that lets the next session bootstrap instantly — no detective work required.
-
-## Rules
-- Be concrete and specific — file paths, branch names, issue numbers
-- Distinguish between what IS done vs what NEEDS to be done next
-- If there are uncommitted changes, describe what they represent and whether they look ready to commit
-- If the working tree is clean, say so and focus on what was accomplished and what's next
-- Capture any lessons or traps discovered during this session
-- Be concise — this is a tactical handoff, not a retrospective
-
-## Output Format
-Respond with ONLY the sections below. No preamble, no closing remarks.
-
-### Branch & State
-[Current branch, clean/dirty status, what the branch represents]
-
-### What Was Done
-[Summary of work completed this session based on the diff and git state. If no changes, say "No uncommitted changes — session may have been exploratory or changes were already committed."]
-
-### Uncommitted Changes
-[Description of what the uncommitted changes contain and their state (staged vs unstaged). If clean, say "Working tree is clean."]
-
-### Lessons & Traps
-[Lessons learned during this session from the memory file. If none, say "No new lessons recorded this session."]
-
-### Next Steps
-[Clear, ordered list of what the next session should do first. Be specific — not "continue working" but "finish implementing X in file Y, then run tests."]
+const SYSTEM_PROMPT = `# Handoff System Prompt — End-of-Session State Transfer
+
+## Purpose
+Produce an end-of-session handoff snapshot that captures everything the next session (or the next developer) needs to resume work immediately.
+
+## Role
+You are writing a concise, tactical "End of Shift" handoff. You have access to the current git state, uncommitted changes, and lessons learned during this session. Your job is to synthesize this into a snapshot that lets the next session bootstrap instantly — no detective work required.
+
+## Rules
+- Be concrete and specific — file paths, branch names, issue numbers
+- Distinguish between what IS done vs what NEEDS to be done next
+- If there are uncommitted changes, describe what they represent and whether they look ready to commit
+- If the working tree is clean, say so and focus on what was accomplished and what's next
+- Capture any lessons or traps discovered during this session
+- Be concise — this is a tactical handoff, not a retrospective
+
+## Output Format
+Respond with ONLY the sections below. No preamble, no closing remarks.
+
+### Branch & State
+[Current branch, clean/dirty status, what the branch represents]
+
+### What Was Done
+[Summary of work completed this session based on the diff and git state. If no changes, say "No uncommitted changes — session may have been exploratory or changes were already committed."]
+
+### Uncommitted Changes
+[Description of what the uncommitted changes contain and their state (staged vs unstaged). If clean, say "Working tree is clean."]
+
+### Lessons & Traps
+[Lessons learned during this session from the memory file. If none, say "No new lessons recorded this session."]
+
+### Next Steps
+[Clear, ordered list of what the next session should do first. Be specific — not "continue working" but "finish implementing X in file Y, then run tests."]
 `;
 // ─── Lessons file reader ────────────────────────────────
 function readRecentLessons(cwd, totemDir) {

package/dist/commands/init.js

@@ -3,27 +3,27 @@ import * as path from 'node:path';
 import { stdin as input, stdout as output } from 'node:process';
 import * as readline from 'node:readline/promises';
 import { installPostMergeHook } from './install-hooks.js';
-const AI_PROMPT_BLOCK = `
-
-## Totem AI Integration (Auto-Generated)
-You have access to the Totem MCP for long-term project memory. You MUST operate with the following reflexes:
-
-### Memory Reflexes
-1. **Pull Before Planning:** Before writing specs, architecture, or fixing complex bugs, use \`search_knowledge\` to retrieve domain constraints and past traps.
-2. **Proactive Anchoring (The 3 Triggers):** You must autonomously call \`add_lesson\` when any of the following occur — do NOT wait for the user to ask:
-   - **The Trap Trigger:** If you spend >2 turns fixing a bug caused by a framework quirk, unexpected API response, or edge case. (Anchor the symptom + fix).
-   - **The Pivot Trigger:** If the user introduces a new architectural pattern or deprecates an old one. (Anchor the rule).
-   - **The Handoff Trigger:** At the end of a session or when wrapping up a complex feature, extract the non-obvious lessons learned and anchor them.
-3. **Tool Preference (MCP over CLI):** Always prioritize using dedicated MCP tools (e.g., GitHub, Supabase, Vercel) over executing generic shell commands (like \`gh issue view\` or \`curl\`). MCP tools provide structured, un-truncated data optimized for your context window. Only fall back to bash execution if an MCP tool is unavailable or fails.
-
-Lessons are automatically re-indexed in the background after each \`add_lesson\` call — no manual sync needed.
-
-### Workflow Orchestrator Rituals
-Totem provides CLI commands that map to your development lifecycle. Use them at these moments:
-1. **Start of Session:** Run \`totem briefing\` to get oriented with current branch state, open PRs, and recent context. Run \`totem triage\` if you need to pick a new task.
-2. **Before Implementation:** Run \`totem spec <issue-url-or-topic>\` to generate an architectural plan and review related context before writing code.
-3. **Before PR/Push:** Run \`totem shield\` to analyze uncommitted changes against project knowledge — catches architectural drift and pattern violations.
-4. **End of Session:** Run \`totem handoff\` to generate a snapshot for the next agent session with current progress and open threads.
+const AI_PROMPT_BLOCK = `
+
+## Totem AI Integration (Auto-Generated)
+You have access to the Totem MCP for long-term project memory. You MUST operate with the following reflexes:
+
+### Memory Reflexes
+1. **Pull Before Planning:** Before writing specs, architecture, or fixing complex bugs, use \`search_knowledge\` to retrieve domain constraints and past traps.
+2. **Proactive Anchoring (The 3 Triggers):** You must autonomously call \`add_lesson\` when any of the following occur — do NOT wait for the user to ask:
+   - **The Trap Trigger:** If you spend >2 turns fixing a bug caused by a framework quirk, unexpected API response, or edge case. (Anchor the symptom + fix).
+   - **The Pivot Trigger:** If the user introduces a new architectural pattern or deprecates an old one. (Anchor the rule).
+   - **The Handoff Trigger:** At the end of a session or when wrapping up a complex feature, extract the non-obvious lessons learned and anchor them.
+3. **Tool Preference (MCP over CLI):** Always prioritize using dedicated MCP tools (e.g., GitHub, Supabase, Vercel) over executing generic shell commands (like \`gh issue view\` or \`curl\`). MCP tools provide structured, un-truncated data optimized for your context window. Only fall back to bash execution if an MCP tool is unavailable or fails.
+
+Lessons are automatically re-indexed in the background after each \`add_lesson\` call — no manual sync needed.
+
+### Workflow Orchestrator Rituals
+Totem provides CLI commands that map to your development lifecycle. Use them at these moments:
+1. **Start of Session:** Run \`totem briefing\` to get oriented with current branch state, open PRs, and recent context. Run \`totem triage\` if you need to pick a new task.
+2. **Before Implementation:** Run \`totem spec <issue-url-or-topic>\` to generate an architectural plan and review related context before writing code.
+3. **Before PR/Push:** Run \`totem shield\` to analyze uncommitted changes against project knowledge — catches architectural drift and pattern violations.
+4. **End of Session:** Run \`totem handoff\` to generate a snapshot for the next agent session with current progress and open threads.
 `;
 function detectProject(cwd) {
     const exists = (p) => fs.existsSync(path.join(cwd, p));
@@ -93,23 +93,23 @@ function generateConfig(targets, provider) {
     const embeddingBlock = provider === 'openai'
         ? `  embedding: { provider: 'openai', model: 'text-embedding-3-small' },`
         : `  embedding: { provider: 'ollama', model: 'nomic-embed-text', baseUrl: 'http://localhost:11434' },`;
-    return `import type { TotemConfig } from '@mmnto/totem';
-
-const config: TotemConfig = {
-  targets: [
-${formatTargets(targets)}
-  ],
-
-${embeddingBlock}
-
-  orchestrator: {
-    provider: 'shell',
-    command: 'gemini --model {model} -o json -e none < {file}',
-    defaultModel: 'gemini-3-flash-preview',
-  },
-};
-
-export default config;
+    return `import type { TotemConfig } from '@mmnto/totem';
+
+const config: TotemConfig = {
+  targets: [
+${formatTargets(targets)}
+  ],
+
+${embeddingBlock}
+
+  orchestrator: {
+    provider: 'shell',
+    command: 'gemini --model {model} -o json -e none < {file}',
+    defaultModel: 'gemini-3-flash-preview',
+  },
+};
+
+export default config;
 `;
 }
 export async function initCommand() {

package/dist/commands/install-hooks.js

@@ -13,11 +13,11 @@ function detectSyncCommand(cwd) {
     return 'npx totem sync --incremental';
 }
 function buildHookContent(syncCmd) {
-    return `#!/bin/sh
-# ${TOTEM_HOOK_MARKER} — background re-index after pull/merge.
-
-echo "[totem] Triggering background re-index..."
-(${syncCmd} > .git/totem-sync.log 2>&1) &
+    return `#!/bin/sh
+# ${TOTEM_HOOK_MARKER} — background re-index after pull/merge.
+
+echo "[totem] Triggering background re-index..."
+(${syncCmd} > .git/totem-sync.log 2>&1) &
 `;
 }
 function detectHookManager(cwd) {
@@ -91,10 +91,10 @@ export async function installPostMergeHook(cwd, rl) {
         }
         // Append to existing hook
         const separator = existing.endsWith('\n') ? '' : '\n';
-        const appendBlock = `${separator}
-# ${TOTEM_HOOK_MARKER} — background re-index after pull/merge.
-echo "[totem] Triggering background re-index..."
-(${syncCmd} > .git/totem-sync.log 2>&1) &
+        const appendBlock = `${separator}
+# ${TOTEM_HOOK_MARKER} — background re-index after pull/merge.
+echo "[totem] Triggering background re-index..."
+(${syncCmd} > .git/totem-sync.log 2>&1) &
 `;
         fs.appendFileSync(hookPath, appendBlock);
         console.log('[Totem] Appended post-merge hook to existing hook file.');

package/dist/commands/learn.js

@@ -9,32 +9,32 @@ const TAG = 'Learn';
 const MAX_EXISTING_LESSONS = 10;
 const MAX_REVIEW_BODY_CHARS = 50_000;
 // ─── System prompt ──────────────────────────────────────
-const SYSTEM_PROMPT = `# Learn System Prompt — PR Lesson Extraction
-
-## Purpose
-Extract tactical lessons from a pull request's review comments and discussion.
-
-## Role
-You are a knowledge curator analyzing a PR's review threads. Your job is to distill non-obvious lessons — traps, patterns, decisions with rationale — that will prevent future mistakes.
-
-## Rules
-- Extract ONLY non-obvious lessons (traps, surprising behaviors, pattern decisions with rationale)
-- Ignore GCA boilerplate, simple acknowledgments, nits, and formatting suggestions
-- When a suggestion was DECLINED, the author's rationale is often the most valuable lesson
-- Each lesson should be 1-2 sentences capturing WHAT happened and WHY it matters
-- Tags should be lowercase, comma-separated, reflecting the technical domain
-- If existing lessons are provided, do NOT extract duplicates or near-duplicates
-- If no lessons are worth extracting, output exactly: NONE
-
-## Output Format
-For each lesson, use this exact delimiter format:
-
----LESSON---
-Tags: tag1, tag2, tag3
-The lesson text. One or two sentences capturing the trap/pattern and WHY it matters.
----END---
-
-If no lessons found, output exactly: NONE
+const SYSTEM_PROMPT = `# Learn System Prompt — PR Lesson Extraction
+
+## Purpose
+Extract tactical lessons from a pull request's review comments and discussion.
+
+## Role
+You are a knowledge curator analyzing a PR's review threads. Your job is to distill non-obvious lessons — traps, patterns, decisions with rationale — that will prevent future mistakes.
+
+## Rules
+- Extract ONLY non-obvious lessons (traps, surprising behaviors, pattern decisions with rationale)
+- Ignore GCA boilerplate, simple acknowledgments, nits, and formatting suggestions
+- When a suggestion was DECLINED, the author's rationale is often the most valuable lesson
+- Each lesson should be 1-2 sentences capturing WHAT happened and WHY it matters
+- Tags should be lowercase, comma-separated, reflecting the technical domain
+- If existing lessons are provided, do NOT extract duplicates or near-duplicates
+- If no lessons are worth extracting, output exactly: NONE
+
+## Output Format
+For each lesson, use this exact delimiter format:
+
+---LESSON---
+Tags: tag1, tag2, tag3
+The lesson text. One or two sentences capturing the trap/pattern and WHY it matters.
+---END---
+
+If no lessons found, output exactly: NONE
 `;
 // ─── GitHub helpers ─────────────────────────────────────
 const GhPrSchema = z.object({

package/dist/commands/shield.js

@@ -10,39 +10,39 @@ const MAX_SPEC_RESULTS = 3;
 const MAX_SESSION_RESULTS = 5;
 const MAX_CODE_RESULTS = 5;
 // ─── System prompt ──────────────────────────────────────
-const SYSTEM_PROMPT = `# Shield System Prompt — Pre-Flight Code Review
-
-## Purpose
-Perform a pre-flight code review on a git diff, using project-specific knowledge to catch traps and anti-patterns before a PR is opened.
-
-## Role
-You are a senior code reviewer analyzing a diff against the project's accumulated knowledge: past session lessons, architectural specs, and codebase conventions. Flag issues the developer might miss, especially ones that have caused problems before.
-
-## Rules
-- Focus on the DIFF — only comment on code that is actually changing
-- Reference specific lines/hunks from the diff when flagging issues
-- Cite Totem knowledge when it directly applies (e.g., "Session #142 found that...")
-- Distinguish severity: CRITICAL (must fix), WARNING (should fix), INFO (consider)
-- Be concise — this is a pre-flight check, not a full RFC
-- If the diff looks clean and follows all known patterns, say so
-
-## Output Format
-Respond with ONLY the sections below. No preamble, no closing remarks.
-
-### Summary
-[1-2 sentences describing what this diff does at a high level]
-
-### Critical Issues
-[Issues that MUST be fixed before merging. If none, say "None found."]
-
-### Warnings
-[Issues that SHOULD be addressed. Include pattern violations, potential regressions, and lessons from past sessions. If none, say "None found."]
-
-### Suggestions
-[Optional improvements and style notes. If none, say "None."]
-
-### Relevant History
-[Specific past traps, lessons, or decisions from Totem knowledge that apply to this diff. If none, say "No relevant history found."]
+const SYSTEM_PROMPT = `# Shield System Prompt — Pre-Flight Code Review
+
+## Purpose
+Perform a pre-flight code review on a git diff, using project-specific knowledge to catch traps and anti-patterns before a PR is opened.
+
+## Role
+You are a senior code reviewer analyzing a diff against the project's accumulated knowledge: past session lessons, architectural specs, and codebase conventions. Flag issues the developer might miss, especially ones that have caused problems before.
+
+## Rules
+- Focus on the DIFF — only comment on code that is actually changing
+- Reference specific lines/hunks from the diff when flagging issues
+- Cite Totem knowledge when it directly applies (e.g., "Session #142 found that...")
+- Distinguish severity: CRITICAL (must fix), WARNING (should fix), INFO (consider)
+- Be concise — this is a pre-flight check, not a full RFC
+- If the diff looks clean and follows all known patterns, say so
+
+## Output Format
+Respond with ONLY the sections below. No preamble, no closing remarks.
+
+### Summary
+[1-2 sentences describing what this diff does at a high level]
+
+### Critical Issues
+[Issues that MUST be fixed before merging. If none, say "None found."]
+
+### Warnings
+[Issues that SHOULD be addressed. Include pattern violations, potential regressions, and lessons from past sessions. If none, say "None found."]
+
+### Suggestions
+[Optional improvements and style notes. If none, say "None."]
+
+### Relevant History
+[Specific past traps, lessons, or decisions from Totem knowledge that apply to this diff. If none, say "No relevant history found."]
 `;
 async function retrieveContext(query, store) {
     const search = (typeFilter, maxResults) => store.search({ query, typeFilter, maxResults });

package/dist/commands/spec.js

@@ -7,44 +7,44 @@ import { formatResults, GH_TIMEOUT_MS, IS_WIN, loadConfig, loadEnv, resolveConfi
 const TAG = 'Spec';
 const QUERY_BODY_TRUNCATE = 500;
 // ─── System prompt ──────────────────────────────────────
-const SYSTEM_PROMPT = `# Spec System Prompt — Pre-Work Briefing
-
-## Purpose
-Produce a structured pre-work briefing for a GitHub issue before implementation begins.
-
-## Role
-You are a technical spec writer analyzing a GitHub issue and its related project context. Your job is to produce a focused briefing that identifies: relevant history, files to examine, implementation approach, traps, and test plan.
-
-## Rules
-- File paths must reference actual files from the context provided
-- Cite related issues by number (#NNN) when relevant
-- Identify edge cases the issue description doesn't mention
-- Be concise — this is a briefing, not a full proposal
-- When multiple approaches exist, list trade-offs with a clear recommendation
-
-## Output Format
-Respond with ONLY the sections below. No preamble, no closing remarks.
-
-### Problem
-[1-2 sentences restating the issue in concrete implementation terms. What exactly needs to change?]
-
-### Historical Context
-[Relevant sessions, PRs, decisions, related issues from the provided Totem knowledge. If nothing relevant, say "None found in provided context."]
-
-### Files to Examine
-[Ordered list of files the developer should read before starting. Most critical first. Format: \`path/to/file.ts\` — reason to examine]
-
-### Approach
-[Recommended implementation approach. Concrete steps, not abstract descriptions. If multiple valid approaches exist, list them as Option A / Option B with trade-offs and a clear recommendation.]
-
-### Edge Cases & Traps
-[Things the issue description doesn't mention but the developer should watch for. Include existing patterns that MUST be followed for consistency and potential regressions in related features.]
-
-### Test Plan
-[Specific test scenarios. Reference existing test file patterns when applicable.]
-
-### Related Issues
-[Issues that might be affected by or related to this work. Format: #NNN — title — relationship (blocks, unblocks, overlaps, conflicts). If none found, say "None identified."]
+const SYSTEM_PROMPT = `# Spec System Prompt — Pre-Work Briefing
+
+## Purpose
+Produce a structured pre-work briefing for a GitHub issue before implementation begins.
+
+## Role
+You are a technical spec writer analyzing a GitHub issue and its related project context. Your job is to produce a focused briefing that identifies: relevant history, files to examine, implementation approach, traps, and test plan.
+
+## Rules
+- File paths must reference actual files from the context provided
+- Cite related issues by number (#NNN) when relevant
+- Identify edge cases the issue description doesn't mention
+- Be concise — this is a briefing, not a full proposal
+- When multiple approaches exist, list trade-offs with a clear recommendation
+
+## Output Format
+Respond with ONLY the sections below. No preamble, no closing remarks.
+
+### Problem
+[1-2 sentences restating the issue in concrete implementation terms. What exactly needs to change?]
+
+### Historical Context
+[Relevant sessions, PRs, decisions, related issues from the provided Totem knowledge. If nothing relevant, say "None found in provided context."]
+
+### Files to Examine
+[Ordered list of files the developer should read before starting. Most critical first. Format: \`path/to/file.ts\` — reason to examine]
+
+### Approach
+[Recommended implementation approach. Concrete steps, not abstract descriptions. If multiple valid approaches exist, list them as Option A / Option B with trade-offs and a clear recommendation.]
+
+### Edge Cases & Traps
+[Things the issue description doesn't mention but the developer should watch for. Include existing patterns that MUST be followed for consistency and potential regressions in related features.]
+
+### Test Plan
+[Specific test scenarios. Reference existing test file patterns when applicable.]
+
+### Related Issues
+[Issues that might be affected by or related to this work. Format: #NNN — title — relationship (blocks, unblocks, overlaps, conflicts). If none found, say "None identified."]
 `;
 // ─── GitHub helpers ─────────────────────────────────────
 const GhIssueSchema = z.object({

package/dist/commands/triage.js

@@ -10,36 +10,36 @@ const MAX_SESSION_RESULTS = 5;
 const QUERY_TITLES_TRUNCATE = 2_000;
 const GH_ISSUE_LIMIT = 100;
 // ─── System prompt ──────────────────────────────────────
-const SYSTEM_PROMPT = `# Triage System Prompt — Active Work Roadmap
-
-## Purpose
-Produce a prioritized roadmap from the project's open GitHub issues, informed by recent work history from Totem knowledge.
-
-## Role
-You are a technical project manager analyzing a project's open issue backlog alongside its recent development history. Your job is to produce a clear, actionable prioritization that helps the developer decide what to work on next.
-
-## Rules
-- Reference issues by number (#NNN) and title
-- Consider labels (bug, enhancement, priority, etc.) as strong signals
-- Use recent session history and specs to understand project momentum — what was just finished, what's in progress
-- Factor in issue age (updatedAt) — stale issues may need re-evaluation
-- Be opinionated — give a clear recommendation, not a wishy-washy list
-- Be concise — this is a decision-making tool, not a project plan
-
-## Output Format
-Respond with ONLY the sections below. No preamble, no closing remarks.
-
-### Active Work Summary
-[1-3 sentences about what was recently completed or is in progress, based on the Totem knowledge provided. If no relevant history, say "No recent session history available."]
-
-### Prioritized Roadmap
-[Ordered list of open issues, most important first. For each: #NNN — title — 1-sentence rationale for its priority position. Group by priority tier if helpful (e.g., "Do Next", "Up Next", "Backlog").]
-
-### Next Issue
-[Single recommended issue to work on next. Include: issue number, title, and 2-3 sentences explaining WHY this should be next — considering dependencies, momentum, and impact.]
-
-### Blocked / Needs Input
-[Issues that cannot progress without external input, decisions, or prerequisite work. If none, say "None identified."]
+const SYSTEM_PROMPT = `# Triage System Prompt — Active Work Roadmap
+
+## Purpose
+Produce a prioritized roadmap from the project's open GitHub issues, informed by recent work history from Totem knowledge.
+
+## Role
+You are a technical project manager analyzing a project's open issue backlog alongside its recent development history. Your job is to produce a clear, actionable prioritization that helps the developer decide what to work on next.
+
+## Rules
+- Reference issues by number (#NNN) and title
+- Consider labels (bug, enhancement, priority, etc.) as strong signals
+- Use recent session history and specs to understand project momentum — what was just finished, what's in progress
+- Factor in issue age (updatedAt) — stale issues may need re-evaluation
+- Be opinionated — give a clear recommendation, not a wishy-washy list
+- Be concise — this is a decision-making tool, not a project plan
+
+## Output Format
+Respond with ONLY the sections below. No preamble, no closing remarks.
+
+### Active Work Summary
+[1-3 sentences about what was recently completed or is in progress, based on the Totem knowledge provided. If no relevant history, say "No recent session history available."]
+
+### Prioritized Roadmap
+[Ordered list of open issues, most important first. For each: #NNN — title — 1-sentence rationale for its priority position. Group by priority tier if helpful (e.g., "Do Next", "Up Next", "Backlog").]
+
+### Next Issue
+[Single recommended issue to work on next. Include: issue number, title, and 2-3 sentences explaining WHY this should be next — considering dependencies, momentum, and impact.]
+
+### Blocked / Needs Input
+[Issues that cannot progress without external input, decisions, or prerequisite work. If none, say "None identified."]
 `;
 // ─── GitHub helpers ─────────────────────────────────────
 const GhIssueListItemSchema = z.object({

package/package.json

@@ -1,51 +1,51 @@
-{
-  "name": "@mmnto/cli",
-  "version": "0.1.0",
-  "description": "CLI for Totem — AI persistent memory and context layer",
-  "type": "module",
-  "bin": {
-    "totem": "./dist/index.js"
-  },
-  "main": "./dist/index.js",
-  "types": "./dist/index.d.ts",
-  "exports": {
-    ".": {
-      "import": "./dist/index.js",
-      "types": "./dist/index.d.ts"
-    }
-  },
-  "scripts": {
-    "build": "tsc",
-    "dev": "tsc --watch",
-    "clean": "rm -rf dist",
-    "lint": "eslint src/",
-    "test": "echo \"No tests yet\" && exit 0"
-  },
-  "dependencies": {
-    "@mmnto/totem": "workspace:*",
-    "commander": "^13.1.0",
-    "jiti": "^2.4.0",
-    "zod": "^3.24.0"
-  },
-  "devDependencies": {
-    "@types/node": "^22.0.0",
-    "typescript": "^5.7.0"
-  },
-  "files": [
-    "dist"
-  ],
-  "license": "MIT",
-  "author": "mmnto-ai",
-  "repository": {
-    "type": "git",
-    "url": "https://github.com/mmnto-ai/totem.git",
-    "directory": "packages/cli"
-  },
-  "homepage": "https://github.com/mmnto-ai/totem",
-  "bugs": {
-    "url": "https://github.com/mmnto-ai/totem/issues"
-  },
-  "publishConfig": {
-    "access": "public"
-  }
-}
+{
+  "name": "@mmnto/cli",
+  "version": "0.2.0",
+  "description": "CLI for Totem — AI persistent memory and context layer",
+  "type": "module",
+  "bin": {
+    "totem": "./dist/index.js"
+  },
+  "main": "./dist/index.js",
+  "types": "./dist/index.d.ts",
+  "exports": {
+    ".": {
+      "import": "./dist/index.js",
+      "types": "./dist/index.d.ts"
+    }
+  },
+  "dependencies": {
+    "commander": "^13.1.0",
+    "jiti": "^2.4.0",
+    "zod": "^3.24.0",
+    "@mmnto/totem": "0.2.0"
+  },
+  "devDependencies": {
+    "@types/node": "^22.0.0",
+    "typescript": "^5.7.0"
+  },
+  "files": [
+    "dist"
+  ],
+  "license": "MIT",
+  "author": "mmnto-ai",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/mmnto-ai/totem.git",
+    "directory": "packages/cli"
+  },
+  "homepage": "https://github.com/mmnto-ai/totem",
+  "bugs": {
+    "url": "https://github.com/mmnto-ai/totem/issues"
+  },
+  "publishConfig": {
+    "access": "public"
+  },
+  "scripts": {
+    "build": "tsc",
+    "dev": "tsc --watch",
+    "clean": "rm -rf dist",
+    "lint": "eslint src/",
+    "test": "echo \"No tests yet\" && exit 0"
+  }
+}