@monoes/monomindcli 2.16.4 → 2.16.5

package/.claude/skills/monodesign/scripts/pin.mjs

@@ -0,0 +1,221 @@
+#!/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 } 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/.claude/skills/monodesign/shape.md

@@ -0,0 +1,71 @@
+---
+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/.claude/skills/monodesign/teach.md

@@ -0,0 +1,18 @@
+---
+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/.claude/skills/monodesign/typeset.md

@@ -0,0 +1,59 @@
+---
+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/.claude/skills/monolean-audit/SKILL.md

@@ -1,21 +1,19 @@
 ---
 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,
+  Whole-repo audit for over-engineering. Scans the entire codebase, not 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.
+An over-engineering 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.

package/.claude/skills/monolean-help/SKILL.md

@@ -26,7 +26,6 @@ Level sticks until changed or session end.
 | 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. |

package/.claude/skills/monoswarm/SKILL.md

@@ -46,7 +46,7 @@ If you need persistent, scheduled, autonomous agent organizations that outlive a
 ### 1. Initialize
 
 ```bash
-npx monomind@latest swarm init \
+npx monomind@latest monoswarm init \
   --topology hierarchical \
   --max-agents 8 \
   --strategy specialized
@@ -67,7 +67,7 @@ Equivalent MCP: `mcp__monomind__monoswarm_agent_add { type: "...", name: "..." }
 ### 3. Start work
 
 ```bash
-npx monomind@latest swarm start \
+npx monomind@latest monoswarm start \
   --objective "Add OAuth2 login with tests" \
   --strategy specialized \
   --agents 4
@@ -76,11 +76,11 @@ npx monomind@latest swarm start \
 ### 4. Monitor, scale, and stop
 
 ```bash
-npx monomind@latest swarm status
+npx monomind@latest monoswarm status
 npx monomind@latest agent list
 npx monomind@latest agent status <id>
-npx monomind@latest swarm scale --agents 12
-npx monomind@latest swarm stop
+npx monomind@latest monoswarm scale --agents 12
+npx monomind@latest monoswarm stop
 ```
 
 Equivalent MCP: `monoswarm_status`, `monoswarm_scale`, `monoswarm_health`, `monoswarm_shutdown { graceful: true, force: false }`.
@@ -112,8 +112,8 @@ These are real agent names (Task `subagent_type`). For a task-specific pick use
 ### Sequential pipeline (design → code → test → review)
 
 ```bash
-npx monomind@latest swarm init --topology hierarchical --strategy development --max-agents 4
-npx monomind@latest swarm start --objective "Build user-profile API with full test coverage"
+npx monomind@latest monoswarm init --topology hierarchical --strategy development --max-agents 4
+npx monomind@latest monoswarm start --objective "Build user-profile API with full test coverage"
 ```
 
 Drive each stage via task assignment — the next stage picks up when the previous completes:
@@ -129,8 +129,8 @@ mcp__monomind__task_assign { task_id: "...", agent_id: "<tester-id>" }
 ### Parallel fan-out (independent subtasks)
 
 ```bash
-npx monomind@latest swarm init --topology mesh --strategy balanced --max-agents 6
-npx monomind@latest swarm start --objective "Audit 6 modules for security issues" --agents 6
+npx monomind@latest monoswarm init --topology mesh --strategy balanced --max-agents 6
+npx monomind@latest monoswarm start --objective "Audit 6 modules for security issues" --agents 6
 ```
 
 Spawn one Task-tool agent per module; each writes findings to the shared namespace.
@@ -167,8 +167,8 @@ mcp__monomind__monoswarm_vote { action: "vote", proposalId: "<id>", vote: true,
 mcp__monomind__monoswarm_memory { action: "set", key: "decision-architecture-v1", value: { summary: "...", proposalId: "<id>" } }
 
 # 5. Execute with a regular swarm run, sharing the decision via memory namespace
-npx monomind@latest swarm init --topology hierarchical --max-agents 6
-npx monomind@latest swarm start --objective "Implement modular monolith per decision-architecture-v1"
+npx monomind@latest monoswarm init --topology hierarchical --max-agents 6
+npx monomind@latest monoswarm start --objective "Implement modular monolith per decision-architecture-v1"
 ```
 
 ## Vote Strategies
@@ -235,8 +235,8 @@ npx monomind@latest memory search --query "auth requirements"
 In-process "load balancing" is task routing, not network LB. Two mechanisms: `hooks_route` (picks the optimal agent type from the routing table) and `strategy` (`balanced` evens work, `specialized` keeps roles fixed). For uneven workloads, scale up and reassign stalled tasks:
 
 ```bash
-npx monomind@latest swarm scale --agents 12
-npx monomind@latest swarm status
+npx monomind@latest monoswarm scale --agents 12
+npx monomind@latest monoswarm status
 ```
 
 ```
@@ -246,7 +246,7 @@ mcp__monomind__task_assign { task_id: "...", agent_id: "<idle-agent-id>" }
 ## Full Example: Feature Build
 
 ```bash
-npx monomind@latest swarm init --topology hierarchical --max-agents 5 --strategy specialized
+npx monomind@latest monoswarm init --topology hierarchical --max-agents 5 --strategy specialized
 
 npx monomind@latest memory store \
   --key "feature-spec" \
@@ -258,9 +258,9 @@ npx monomind@latest agent spawn -t coder       --name impl
 npx monomind@latest agent spawn -t tester      --name qa
 npx monomind@latest agent spawn -t reviewer    --name audit
 
-npx monomind@latest swarm start --objective "Implement CSV import end-to-end" --agents 4
-npx monomind@latest swarm status
-npx monomind@latest swarm stop
+npx monomind@latest monoswarm start --objective "Implement CSV import end-to-end" --agents 4
+npx monomind@latest monoswarm status
+npx monomind@latest monoswarm stop
 ```
 
 Execution happens in Claude Code Task-tool agents. The CLI coordinates; Task agents do the work.