monomind 2.7.12 → 2.7.13

package/packages/@monomind/cli/.claude/skills/monodesign/scripts/pin.mjs

@@ -1,221 +0,0 @@
-#!/usr/bin/env node
-/**
- * Pin/unpin sub-commands as standalone skill shortcuts.
- *
- * Usage:
- *   node <scripts_path>/pin.mjs pin <command>
- *   node <scripts_path>/pin.mjs unpin <command>
- *
- * `pin audit` creates a lightweight audit skill that redirects to Monodesign's audit workflow.
- * `unpin audit` removes that shortcut.
- *
- * The script discovers harness directories (.claude/skills, .cursor/skills, etc.)
- * in the project root and creates/removes the pin in all of them.
- */
-
-import { existsSync, readFileSync, writeFileSync, mkdirSync, rmSync, readdirSync } from 'node:fs';
-import { basename, join, resolve, dirname } from 'node:path';
-import { fileURLToPath } from 'node:url';
-
-const __dirname = dirname(fileURLToPath(import.meta.url));
-
-// All known harness directories
-const HARNESS_DIRS = [
-  '.claude', '.cursor', '.gemini', '.codex', '.agents',
-  '.trae', '.trae-cn', '.pi', '.opencode', '.kiro', '.rovodev',
-];
-
-const CODEX_HARNESSES = new Set(['.codex', '.agents']);
-
-// Valid sub-command names
-const VALID_COMMANDS = [
-  'craft', 'init', 'extract', 'document', 'shape',
-  'critique', 'audit',
-  'polish', 'bolder', 'quieter', 'distill', 'harden', 'onboard', 'live',
-  'animate', 'colorize', 'typeset', 'layout', 'delight', 'overdrive',
-  'clarify', 'adapt', 'optimize',
-];
-
-// Marker to identify pinned skills (so unpin doesn't delete user skills)
-const PIN_MARKER = '<!-- monodesign-pinned-skill -->';
-
-/**
- * Walk up from startDir to find a project root.
- */
-function findProjectRoot(startDir = process.cwd()) {
-  let dir = resolve(startDir);
-  while (dir !== '/') {
-    if (
-      existsSync(join(dir, 'package.json')) ||
-      existsSync(join(dir, '.git')) ||
-      existsSync(join(dir, 'skills-lock.json'))
-    ) {
-      return dir;
-    }
-    const parent = resolve(dir, '..');
-    if (parent === dir) break;
-    dir = parent;
-  }
-  return resolve(startDir);
-}
-
-/**
- * Find harness skill directories that have an monodesign skill installed.
- */
-function findHarnessDirs(projectRoot) {
-  const dirs = [];
-  for (const harness of HARNESS_DIRS) {
-    const skillsDir = join(projectRoot, harness, 'skills');
-    // Only pin in harness dirs that already have monodesign installed
-    const monodesignDir = join(skillsDir, 'monodesign');
-    if (existsSync(monodesignDir) || existsSync(join(skillsDir, 'i-monodesign'))) {
-      dirs.push(skillsDir);
-    }
-  }
-  return dirs;
-}
-
-/**
- * Load command metadata (descriptions for pinned skills).
- */
-function loadCommandMetadata() {
-  const metadataPath = join(__dirname, 'command-metadata.json');
-  if (existsSync(metadataPath)) {
-    return JSON.parse(readFileSync(metadataPath, 'utf-8'));
-  }
-  return {};
-}
-
-/**
- * Generate a pinned skill's SKILL.md content.
- */
-function commandPrefixForSkillsDir(skillsDir) {
-  return CODEX_HARNESSES.has(basename(dirname(skillsDir))) ? '$' : '/';
-}
-
-function generatePinnedSkill(command, metadata, commandPrefix) {
-  const desc = metadata[command]?.description || `Shortcut for ${commandPrefix}monodesign ${command}.`;
-  const hint = metadata[command]?.argumentHint || '[target]';
-
-  return `---
-name: ${command}
-description: "${desc}"
-argument-hint: "${hint}"
-user-invocable: true
----
-
-${PIN_MARKER}
-
-This is a pinned shortcut for \`${commandPrefix}monodesign ${command}\`.
-
-Invoke ${commandPrefix}monodesign ${command}, passing along any arguments provided here, and follow its instructions.
-`;
-}
-
-/**
- * Pin a command: create shortcut skill in all harness dirs.
- */
-function pin(command, projectRoot) {
-  const metadata = loadCommandMetadata();
-  const harnessDirs = findHarnessDirs(projectRoot);
-
-  if (harnessDirs.length === 0) {
-    console.log('No harness directories with monodesign installed found.');
-    return false;
-  }
-
-  let created = 0;
-
-  for (const skillsDir of harnessDirs) {
-    const commandPrefix = commandPrefixForSkillsDir(skillsDir);
-    const content = generatePinnedSkill(command, metadata, commandPrefix);
-    // Check if skill already exists (and isn't a pin)
-    const skillDir = join(skillsDir, command);
-    if (existsSync(skillDir)) {
-      const existingMd = join(skillDir, 'SKILL.md');
-      if (existsSync(existingMd)) {
-        const existing = readFileSync(existingMd, 'utf-8');
-        if (!existing.includes(PIN_MARKER)) {
-          console.log(`  SKIP: ${skillDir} (non-pinned skill already exists)`);
-          continue;
-        }
-      }
-    }
-
-    mkdirSync(skillDir, { recursive: true });
-    writeFileSync(join(skillDir, 'SKILL.md'), content, 'utf-8');
-    console.log(`  + ${skillDir}`);
-    created++;
-  }
-
-  if (created > 0) {
-    console.log(`\nPinned '${command}' as a standalone shortcut in ${created} location(s).`);
-    console.log('Use the pinned command directly in each harness.');
-  }
-
-  return created > 0;
-}
-
-/**
- * Unpin a command: remove shortcut skill from all harness dirs.
- */
-function unpin(command, projectRoot) {
-  const harnessDirs = findHarnessDirs(projectRoot);
-  let removed = 0;
-
-  for (const skillsDir of harnessDirs) {
-    const skillDir = join(skillsDir, command);
-    if (!existsSync(skillDir)) continue;
-
-    const skillMd = join(skillDir, 'SKILL.md');
-    if (!existsSync(skillMd)) continue;
-
-    // Safety: only remove if it's a pinned skill
-    const content = readFileSync(skillMd, 'utf-8');
-    if (!content.includes(PIN_MARKER)) {
-      console.log(`  SKIP: ${skillDir} (not a pinned skill)`);
-      continue;
-    }
-
-    rmSync(skillDir, { recursive: true, force: true });
-    console.log(`  - ${skillDir}`);
-    removed++;
-  }
-
-  if (removed > 0) {
-    console.log(`\nUnpinned '${command}' from ${removed} location(s).`);
-    console.log(`Use Monodesign's '${command}' workflow directly to access it.`);
-  } else {
-    console.log(`No pinned '${command}' shortcut found.`);
-  }
-
-  return removed > 0;
-}
-
-// --- CLI ---
-const [,, action, command] = process.argv;
-
-if (!action || !command) {
-  console.log('Usage: node pin.mjs <pin|unpin> <command>');
-  console.log(`\nAvailable commands: ${VALID_COMMANDS.join(', ')}`);
-  process.exit(1);
-}
-
-if (action !== 'pin' && action !== 'unpin') {
-  console.error(`Unknown action: ${action}. Use 'pin' or 'unpin'.`);
-  process.exit(1);
-}
-
-if (!VALID_COMMANDS.includes(command)) {
-  console.error(`Unknown command: ${command}`);
-  console.error(`Available commands: ${VALID_COMMANDS.join(', ')}`);
-  process.exit(1);
-}
-
-const root = findProjectRoot();
-
-if (action === 'pin') {
-  pin(command, root);
-} else {
-  unpin(command, root);
-}

package/packages/@monomind/cli/.claude/skills/monodesign/shape.md

@@ -1,71 +0,0 @@
----
-name: monodesign-shape
-description: Shape the UX and UI for a feature before any code is written — produces a structured design brief through discovery, not guesswork. Design planning only; no code written. Output is a brief for monodesign:craft.
-type: design-sub-command
-argument-hint: "[feature description]"
-user-invocable: true
----
-
-# Monodesign: Shape
-
-Shape the UX and UI for a feature before any code is written. This command produces a **design brief**: a structured artifact that guides implementation through discovery.
-
-**Scope**: Design planning only. No code written. Output: a design brief for `/monodesign craft`.
-
-## Setup
-Read `PRODUCT.md` and (if present) `DESIGN.md` from the project root before starting. These are required anchors.
-
-Read `reference/shape.md` from the monodesign skill directory for the full command flow.
-
-## Phase 1: Discovery Interview
-
-Do NOT write any code or make design decisions during this phase. Ask 2–3 questions per round, then wait for answers. Have a natural dialogue; don't dump all questions at once.
-
-**Purpose & Context**
-- What is this feature for? What problem does it solve?
-- Who specifically will use it? (Role, context, frequency — not "users")
-- What's the user's state of mind when they reach this? (Rushed? Exploring? Anxious?)
-
-**Content & Data**
-- What content or data does this display or collect?
-- What are the realistic ranges? (0 items, typical, max, edge cases)
-- What are the empty state, error state, first-time use, power-user scenarios?
-
-**Design Direction** — force a visual decision on three fronts:
-- **Color strategy**: Restrained / Committed / Full palette / Drenched
-- **Theme via scene sentence**: one sentence of physical context that forces dark vs. light
-- **Two or three named anchor references** — specific products, brands, objects (not adjectives)
-
-**Scope** — always ask explicitly:
-- Fidelity: Sketch / mid-fi / high-fi / production-ready?
-- Breadth: One screen / a flow / a whole surface?
-- Time intent: Quick exploration or polish until it ships?
-
-## Phase 2: Brief Synthesis
-
-After the discovery round, synthesize and present a structured **Design Brief**:
-
-```
-## Design Brief: [Feature Name]
-
-**User**: [concrete description]
-**Problem**: [one sentence]
-**Success**: [measurable outcome]
-**User state**: [emotional/contextual state]
-
-**Content**: [what's displayed/collected + realistic ranges]
-**Edge cases**: [empty, error, overload, first-use]
-
-**Visual direction**:
-- Color strategy: [Restrained|Committed|Full palette|Drenched]
-- Theme: [dark|light] — [scene sentence]
-- References: [3 named references]
-
-**Scope**: [fidelity] / [breadth] / [time intent]
-```
-
-Stop and wait for explicit user confirmation before advancing to `/monodesign craft`. Do not start coding until the brief is approved.
-
-## Assert-then-confirm
-
-When PRODUCT.md and the prompt make one option obvious, name it and ask the user to confirm or override. Don't present four-option menus when the answer is already clear.

package/packages/@monomind/cli/.claude/skills/monodesign/teach.md

@@ -1,18 +0,0 @@
----
-name: monodesign-teach
-description: Alias of /monodesign init — set up a project for monodesign by producing PRODUCT.md (strategic context), optionally DESIGN.md (visual system), and pre-configuring live mode.
-type: design-sub-command
-argument-hint: "[project path or description]"
-user-invocable: true
----
-
-# Monodesign: Teach (alias of Init)
-
-`teach` is the historical name for the setup command and remains fully supported; it is an alias of `init`. Both invocations behave identically.
-
-Follow `commands/init.md` and the authoritative flow in `reference/init.md` from the monodesign skill directory: one codebase crawl plus a short strategic interview produces **PRODUCT.md** (register, users, purpose, brand personality, anti-references, design principles), offers **DESIGN.md** via `/monodesign document`, and pre-configures `.monodesign/live/config.json` for `/monodesign live`.
-
-Notes preserved from the teach era:
-
-- A legacy `.monodesign.md` at the project root is auto-renamed to `PRODUCT.md` by the context loader; mention this once and merge into that content rather than starting fresh.
-- If teach was invoked as a setup blocker by another monodesign command, complete the init flow, then resume the original task with the fresh context.

package/packages/@monomind/cli/.claude/skills/monodesign/typeset.md

@@ -1,59 +0,0 @@
----
-name: monodesign-typeset
-description: Replace generic type defaults with fonts that reflect the brand and scale with intentional contrast — font selection, hierarchy, scale, and responsive type systems.
-type: design-sub-command
-argument-hint: "[target page, component, or whole site]"
-user-invocable: true
----
-
-# Monodesign: Typeset
-
-Typography carries most of the information on the page. Replace generic defaults (Inter, Roboto, system fallback at flat scale) with type that reflects the brand and scales with intentional contrast.
-
-Read `reference/typeset.md` and `reference/typography.md` from the monodesign skill directory for the full protocol.
-
-## Register
-
-**Brand**: font selection procedure in `reference/brand.md`. Fluid `clamp()` scale, ≥1.25 ratio between steps.
-
-**Product**: system fonts and familiar sans stacks are legitimate. One well-tuned family typically carries the whole UI. Fixed `rem` scale, 1.125–1.2 ratio.
-
-## Assess Current Typography
-
-**Font choices**
-- Are we using invisible defaults? (Inter, Roboto, Arial, Open Sans, system defaults)
-- Does the font match the brand personality?
-- Are there too many families? (More than 2–3 is almost always a mess)
-
-**Hierarchy**
-- Can you tell headings from body from captions at a glance?
-- Are sizes too close together? (14px, 15px, 16px = muddy hierarchy)
-- Are weight contrasts strong enough? (Medium vs Regular is barely visible)
-
-**Sizing & scale**
-- Is there a consistent type scale, or are sizes arbitrary?
-- Body text ≥16px?
-- Fixed `rem` scales for app UIs; fluid `clamp()` for marketing/content page headings
-
-## Typographic Rules (non-negotiable)
-
-- Cap body line length at **65–75ch**
-- Hero/display heading ceiling: `clamp()` max ≤ **6rem (~96px)**
-- Display letter-spacing floor: **≥ -0.04em** (anything tighter makes letters touch)
-- Use `text-wrap: balance` on h1–h3; `text-wrap: pretty` on long prose
-- Pair fonts on a contrast axis (serif + sans, geometric + humanist) — NOT similar families
-- Hierarchy through scale + weight contrast (≥1.25 ratio between steps)
-
-## Font Selection Process
-
-1. Load brand context from PRODUCT.md and DESIGN.md
-2. Identify brand personality from 3 words or the product description
-3. Propose 2–3 Google Fonts / variable font pairings with rationale
-4. Load one via `<link>` and demonstrate it on a real page section
-5. Iterate until the type feels native to the brand
-
-## Output
-
-- Updated CSS custom properties or tokens for `--font-heading`, `--font-body`, `--font-mono`
-- Fluid or fixed type scale as CSS custom properties
-- Applied to all heading levels and body copy on the target

package/packages/@monomind/cli/.claude/skills/monolean/SKILL.md

@@ -1,118 +0,0 @@
----
-name: monolean
-description: >
-  Forces the laziest solution that actually works, simplest, shortest, most
-  minimal. Channels a senior dev who has seen everything: question whether the
-  task needs to exist at all (YAGNI), reach for the standard library before
-  custom code, native platform features before dependencies, one line before
-  fifty. Supports intensity levels: lite, full (default), ultra. Use whenever
-  the user says "monolean", "be lean", "lean mode", "simplest solution",
-  "minimal solution", "yagni", "do less", or "shortest path", and whenever
-  they complain about over-engineering, bloat, boilerplate, or unnecessary
-  dependencies.
-argument-hint: "[lite|full|ultra]"
-license: MIT
----
-
-# Monolean
-
-You are a lazy senior developer. Lazy means efficient, not careless. You have
-seen every over-engineered codebase and been paged at 3am for one. The best
-code is the code never written.
-
-## Persistence
-
-ACTIVE EVERY RESPONSE. No drift back to over-building. Still active if
-unsure. Off only: "stop monolean" / "normal mode". Default: **full**.
-Switch: `/monolean lite|full|ultra`.
-
-## The ladder
-
-Stop at the first rung that holds:
-
-1. **Does this need to exist at all?** Speculative need = skip it, say so in one line. (YAGNI)
-2. **Already in this codebase?** A helper, util, type, or pattern that already lives here → reuse it. Look before you write; re-implementing what's a few files over is the most common slop.
-3. **Stdlib does it?** Use it.
-4. **Native platform feature covers it?** `<input type="date">` over a picker lib, CSS over JS, DB constraint over app code.
-5. **Already-installed dependency solves it?** Use it. Never add a new one for what a few lines can do.
-6. **Can it be one line?** One line.
-7. **Only then:** the minimum code that works.
-
-The ladder is a reflex, not a research project — but it runs *after* you
-understand the problem, not instead of it. Read the task and the code it
-touches first, trace the real flow end to end, then climb. Two rungs work →
-take the higher one and move on. The first lazy solution that works is the
-right one — once you actually know what the change has to touch.
-
-**Bug fix = root cause, not symptom.** A report names a symptom. Before you
-edit, find every caller of the function you're about to touch (use `monograph_neighbors` or `monograph_impact` first; fall back to grep only if monograph returns 0 results). The lazy fix IS
-the root-cause fix: one guard in the shared function is a smaller diff than a
-guard in every caller — and patching only the path the ticket names leaves
-every sibling caller still broken. Fix it once, where all callers route through.
-
-In monomind projects: rung 2 is assisted by the knowledge graph (run monograph_query for the symbol you think already exists before writing); rung 5 is assisted by monograph_query with the package name to confirm it is imported somewhere.
-
-## Rules
-
-- No unrequested abstractions: no interface with one implementation, no factory for one product, no config for a value that never changes.
-- No boilerplate, no scaffolding "for later", later can scaffold for itself.
-- Deletion over addition. Boring over clever, clever is what someone decodes at 3am.
-- Fewest files possible. Shortest working diff wins — but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
-- Complex request? Ship the lazy version and question it in the same response, "Did X; Y covers it. Need full X? Say so." Never stall on an answer you can default.
-- Two stdlib options, same size? Take the one that's correct on edge cases. Lazy means writing less code, not picking the flimsier algorithm.
-- Mark deliberate simplifications with a `monolean:` comment (`// monolean: this exists`), simple reads as intent, not ignorance. Shortcut with a known ceiling (global lock, O(n²) scan, naive heuristic)? The comment names the ceiling and the upgrade path: `# monolean: global lock, per-account locks if throughput matters`.
-
-## Output
-
-Code first. Then at most three short lines: what was skipped, when to add it.
-No essays, no feature tours, no design notes. If the explanation is longer
-than the code, delete the explanation, every paragraph defending a
-simplification is complexity smuggled back in as prose. Explanation the user
-explicitly asked for (a report, a walkthrough, per-phase notes) is not debt,
-give it in full, the rule is only against unrequested prose.
-
-Pattern: `[code] → skipped: [X], add when [Y].`
-
-## Intensity
-
-| Level | What change |
-|-------|------------|
-| **lite** | Build what's asked, but name the lazier alternative in one line. User picks. |
-| **full** | The ladder enforced. Stdlib and native first. Shortest diff, shortest explanation. Default. |
-| **ultra** | YAGNI extremist. Deletion before addition. Ship the one-liner and challenge the rest of the requirement in the same breath. |
-
-Example: "Add a cache for these API responses."
-- lite: "Done, cache added. FYI: `functools.lru_cache` covers this in one line if you'd rather not own a cache class."
-- full: "`@lru_cache(maxsize=1000)` on the fetch function. Skipped custom cache class, add when lru_cache measurably falls short."
-- ultra: "No cache until a profiler says so. When it does: `@lru_cache`. A hand-rolled TTL cache class is a bug farm with a hit rate."
-
-## When NOT to be lazy
-
-Never simplify away: input validation at trust boundaries, error handling
-that prevents data loss, security measures, accessibility basics, anything
-explicitly requested. User insists on the full version → build it, no
-re-arguing.
-
-Never lazy about understanding the problem. The ladder shortens the
-solution, never the reading. Trace the whole thing first — every file the
-change touches, the actual flow — before picking a rung. Laziness that skips
-comprehension to ship a small diff is the dangerous kind: it dresses up as
-efficiency and ships a confident wrong fix. Read fully, then be lean.
-
-Hardware is never the ideal on paper: a real clock drifts, a real sensor
-reads off, a PCA9685 runs a few percent fast. Leave the calibration knob, not
-just less code, the physical world needs tuning a minimal model can't see.
-
-Lean code without its check is unfinished. Non-trivial logic (a branch, a
-loop, a parser, a money/security path) leaves ONE runnable check behind, the
-smallest thing that fails if the logic breaks: an `assert`-based
-`demo()`/`__main__` self-check or one small `test_*.py`. No frameworks, no
-fixtures, no per-function suites unless asked. Trivial one-liners need no
-test, YAGNI applies to tests too.
-
-## Boundaries
-
-Monolean governs what you build, not how you talk. "stop monolean" / "normal mode": revert. Level persists until
-changed or session end.
-
-The shortest path to done is the right path.

package/packages/@monomind/cli/.claude/skills/monolean-audit/SKILL.md

@@ -1,41 +0,0 @@
----
-name: monolean-audit
-description: >
-  Whole-repo audit for over-engineering. Like monolean-review, but scans the
-  entire codebase instead of a diff: a ranked list of what to delete, simplify,
-  or replace with stdlib/native equivalents. Use when the user says "audit this
-  codebase", "audit for over-engineering", "what can I delete from this repo",
-  "find bloat", "monolean-audit", or "/monolean-audit". One-shot report, does
-  not apply fixes.
----
-
-monolean-review, repo-wide. Scan the whole tree instead of a diff. Rank
-findings biggest cut first.
-
-## Tags
-
-Same as monolean-review:
-
-- `delete:` dead code, unused flexibility, speculative feature. Replacement: nothing.
-- `stdlib:` hand-rolled thing the standard library ships. Name the function.
-- `native:` dependency or code doing what the platform already does. Name the feature.
-- `yagni:` abstraction with one implementation, config nobody sets, layer with one caller.
-- `shrink:` same logic, fewer lines. Show the shorter form.
-
-## Hunt
-
-Deps the stdlib or platform already ships, single-implementation interfaces,
-factories with one product, wrappers that only delegate, files exporting one
-thing, dead flags and config, hand-rolled stdlib.
-
-## Output
-
-One line per finding, ranked: `<tag> <what to cut>. <replacement>. [path]`.
-End with `net: -<N> lines, -<M> deps possible.` Nothing to cut: `Lean already. Ship.`
-
-## Boundaries
-
-Scope: over-engineering and complexity only. Correctness bugs, security holes,
-and performance are explicitly out of scope. Route them to a normal review
-pass. Lists findings, applies nothing. One-shot.
-"stop monolean-audit" or "normal mode" to revert.

package/packages/@monomind/cli/.claude/skills/monolean-debt/SKILL.md

@@ -1,46 +0,0 @@
----
-name: monolean-debt
-description: >
-  Harvest every `monolean:` comment in the codebase into a debt ledger, so the
-  deliberate shortcuts and deferrals monolean leaves behind get tracked instead
-  of rotting into "later means never". Use when the user says "monolean debt",
-  "/monolean-debt", "what did monolean defer", "list the shortcuts", "monolean
-  ledger", or "what did we mark to do later". One-shot report, changes nothing.
----
-
-Every deliberate monolean shortcut is marked with a `monolean:` comment naming
-its ceiling and upgrade path. This collects them into one ledger so a deferral
-can't quietly become permanent.
-
-## Scan
-
-Grep the repo for comment markers, skipping `node_modules`, `.git`, and build
-output:
-
-`grep -rnE '(#|//) ?monolean:' .`  (add other comment prefixes if your stack uses them)
-
-Each hit is one ledger row. The comment prefix keeps prose that merely mentions
-the convention out of the ledger.
-
-## Output
-
-One row per marker, grouped by file:
-
-`<file>:<line>, <what was simplified>. ceiling: <the limit named>. upgrade: <the trigger to revisit>.`
-
-The convention is `monolean: <ceiling>, <upgrade path>`, so pull the ceiling
-and the trigger straight from the comment. Want an owner per row too? add
-`git blame -L<line>,<line>`.
-
-Flag the rot risk: any `monolean:` comment that names no upgrade path or
-trigger gets a `no-trigger` tag, those are the ones that silently rot.
-
-End with `<N> markers, <M> with no trigger.` Nothing found: `No monolean: debt. Clean ledger.`
-
-Also writes findings to `.monomind/metrics/monolean-debt.json` when run inside a monomind project.
-
-## Boundaries
-
-Reads and reports only, changes nothing. To persist it, ask and it writes the
-ledger to a file (e.g. `MONOLEAN-DEBT.md`). One-shot. "stop monolean-debt" or
-"normal mode" to revert.

package/packages/@monomind/cli/.claude/skills/monolean-help/SKILL.md

@@ -1,60 +0,0 @@
----
-name: monolean-help
-description: >
-  Quick-reference card for all monolean modes, skills, and commands.
-  One-shot display, not a persistent mode. Trigger: /monolean-help,
-  "monolean help", "what monolean commands", "how do I use monolean".
----
-
-# Monolean Help
-
-Display this reference card when invoked. One-shot, do NOT change mode,
-write flag files, or persist anything.
-
-## Levels
-
-| Level | Trigger | What change |
-|-------|---------|-------------|
-| **Lite** | `/monolean lite` | Build what's asked, name the lazier alternative in one line. |
-| **Full** | `/monolean` | The ladder enforced: YAGNI → stdlib → native → one line → minimum. Default. |
-| **Ultra** | `/monolean ultra` | YAGNI extremist. Deletion before addition. Challenges requirements before building. |
-
-Level sticks until changed or session end.
-
-## Skills
-
-| Skill | Trigger | What it does |
-|-------|---------|--------------|
-| **monolean** | `/monolean` | Lean mode itself. Simplest solution that works. |
-| **monolean-review** | `/monolean-review` | Over-engineering review: `L42: yagni: factory, one product. Inline.` |
-| **monolean-audit** | `/monolean-audit` | Whole-repo audit for over-engineering. Ranked findings. |
-| **monolean-debt** | `/monolean-debt` | Harvest `monolean:` comments into a debt ledger. |
-| **monolean-help** | `/monolean-help` | This card. |
-
-Claude Code uses the slash-command forms above.
-
-## Deactivate
-
-Say "stop monolean" or "normal mode". Resume anytime with `/monolean`.
-`/monolean off` also works.
-
-## Configure Default Mode
-
-Default mode = `full`, auto-active every session. Change it:
-
-**Environment variable** (highest priority):
-```bash
-export MONOLEAN_DEFAULT_MODE=ultra
-```
-
-**State file** (`.monomind/state/monolean-mode`):
-Write the mode name to this file. Monomind reads it on session start.
-
-Set `off` to disable auto-activation on session start, activate manually
-with `/monolean` when wanted.
-
-Resolution: env var > state file > `full`.
-
-## More
-
-Monomind docs: https://github.com/monoes/monomind