codymaster 5.2.0 → 7.0.1

package/skills/cm-terminal/SKILL.md

@@ -85,6 +85,21 @@ ERROR PATTERNS TO DETECT:
 - Warning patterns that indicate real problems
 ```
 
+### Step 4b: Compress Before Quoting
+
+**Before pasting stdout into TaskSummary or model context:**
+
+| Command pattern | Rule |
+|-----------------|------|
+| `git status` | Keep only changed entries + branch line + `(N changed)` count. Drop "use git add…" boilerplate. |
+| `npm test` / `vitest` / `jest` | Keep failing tests + summary line. Drop `PASS` lines. |
+| `npm run build` / `tsc` | Keep `error` / `warning` / final status. Drop incremental progress. |
+| Any output | Collapse runs of ≥ 3 identical lines into `<line>  … (× N)`. |
+
+**Helper:** `src/utils/output-compress.ts` — `compressGitStatus`, `compressNpmTest`, `summarizeBuildLog`, `collapseRepeatedLines`, `compressFor(command, stdout)`.
+
+**Anti-pattern:** Pasting full stdout (> 50 lines) into TaskSummary when only the failing portion matters. Compress first, then quote.
+
 ### Step 5: Stop on Error
 
 **If ANY error is detected:**

package/skills/cm-test-gate/SKILL.archive.md

@@ -0,0 +1,245 @@
+---
+name: cm-test-gate
+description: Complete guide to setting up a reliable test gate for any project — covers stack detection, 4 core test files, script wiring, secret hygiene, and Cloudflare Workers/Pages patterns. Use when starting a new project, adding CI to an existing one, or when "tests pass but production breaks." Companion to cm-safe-deploy and cm-project-bootstrap.
+---
+
+# cm-test-gate: Multi-Layer Test Gate Setup
+
+## Overview
+
+A deployment process without a test gate is just shipping code and praying. The `test:gate` script is your first line of defense before deployment. A test gate MUST verify four things: frontend component safety, backend API behavior, core business logic, and i18n synchronization.
+
+**Core assumption:** The most dangerous errors are syntax flaws, variable shadowing, or import failures that tests often skip if they only check logic.
+
+**Violating the letter of this process is violating the spirit of quality engineering.**
+
+## The Protocol
+
+When setting up a test gate for a project, follow these 5 phases in order.
+
+### Phase 1: Stack Detection and Environment Setup
+
+**Goal:** Identify the framework and install the correct testing dependencies.
+
+1. **Detect Stack:**
+   - Check `package.json` for framework (React, Vue, Svelte, static HTML) and build tool (Vite, Next.js).
+   - Check for `wrangler.json(c)` (Cloudflare Workers/Pages).
+   - Check for Tailwind, PostCSS, or specific UI libraries.
+
+2. **Install Dependencies (Example: Vite/Vitest):**
+   ```bash
+   # Install vitest and related tools
+   npm install -D vitest jsdom @testing-library/react @testing-library/jest-dom
+   # (Adjust based on framework: e.g., @testing-library/svelte)
+   ```
+
+3. **Configure File:**
+   - Create `vitest.config.ts` (or `.js`):
+     ```typescript
+     import { defineConfig } from 'vitest/config'
+     // Import framework plugin (e.g., react(), svelte())
+     
+     export default defineConfig({
+       test: {
+         environment: 'jsdom',
+         globals: true,
+         setupFiles: ['./test/setup.ts'], // Optional
+       },
+     })
+     ```
+
+### Phase 2: The 4 Core Test Files
+
+A complete `test:gate` must cover four distinct layers. Do not combine these files.
+
+#### Layer 1: Frontend Safety (`frontend-safety.test.ts`)
+This layer prevents white screens and catastrophic syntax errors in the browser. Emphasize parsing and template rendering over logical assertions.
+
+*Use the exact implementation from `cm-quality-gate` regarding the 4 corruption checks.*
+
+```typescript
+import { test, expect } from 'vitest';
+import fs from 'fs';
+import path from 'path';
+
+test('app.js does not contain catastrophic syntax corruption', () => {
+    // 1. Read the raw file
+    const content = fs.readFileSync(path.resolve(__dirname, '../public/static/app.js'), 'utf-8');
+    
+    // 2. Syntax Validation (Check for broken template literals)
+    // ❌ Bug #1: Single-quote wrapping template string
+    expect(content).not.toMatch(/=\s*'[^']*\$\{t\(/);
+    
+    // 3. Delimiter consistency
+    // ❌ Bug #4: Mismatched delimiters
+    expect(content).not.toMatch(/t\('[^']*\`/);
+    expect(content).not.toMatch(/t\(\`[^']*'\)/);
+    
+    // 4. HTML structure integrity
+    // ❌ Bug #2: Spaces inside tags or broken closers
+    expect(content).not.toMatch(/<\s+[a-zA-Z]/); // e.g., "< div"
+    expect(content).not.toMatch(/<\/\s+[a-zA-Z]/); // e.g., "</ div"
+    expect(content).not.toMatch(/--\s+>/); // e.g., "text-- >"
+});
+```
+
+#### Layer 2: API Routes (`api-routes.test.ts`)
+This layer ensures backend endpoints respond correctly and handle JSON properly.
+
+*Example for a generic fetch wrapper or specific Next.js/Worker handler:*
+
+```typescript
+import { test, expect } from 'vitest';
+
+test('API mock test', async () => {
+    // Test your server handlers directly
+    // Ensure 200 OK for valid inputs and 400 for errors
+    expect(true).toBe(true);
+});
+```
+
+#### Layer 3: Business Logic (`business-logic.test.ts`)
+This layer tests pure functions: calculations, validations, and data transformations.
+
+```typescript
+import { test, expect } from 'vitest';
+
+test('Calculates score correctly', () => {
+    // const result = calculateScore(input);
+    // expect(result).toBe(expected);
+    expect(true).toBe(true);
+});
+```
+
+#### Layer 4: i18n Synchronization (`i18n-sync.test.ts`)
+This layer guarantees that language files are complete and identical in structure.
+
+```typescript
+import { test, expect } from 'vitest';
+import fs from 'fs';
+import path from 'path';
+
+test('i18n files have identical key counts', () => {
+    const langDir = path.resolve(__dirname, '../public/static/i18n');
+    const langs = ['vi.json', 'en.json', 'th.json', 'ph.json'];
+    
+    const countKeys = (obj: any): number => {
+        let count = 0;
+        for (const k in obj) {
+            if (typeof obj[k] === 'object' && obj[k] !== null) {
+                count += countKeys(obj[k]);
+            } else {
+                count++;
+            }
+        }
+        return count;
+    };
+
+    let baseCount = -1;
+    for (const file of langs) {
+        if (!fs.existsSync(path.join(langDir, file))) continue;
+        
+        const data = JSON.parse(fs.readFileSync(path.join(langDir, file), 'utf-8'));
+        const count = countKeys(data);
+        
+        if (baseCount === -1) {
+            baseCount = count;
+        } else {
+            expect(count, `File ${file} has a different key count`).toBe(baseCount);
+        }
+    }
+});
+```
+
+#### Layer 5: Security Scan (`security-scan.test.ts`)
+This layer prevents secrets from being committed to the repository. Powered by `cm-secret-shield` patterns.
+
+```typescript
+import { test, expect } from 'vitest';
+import fs from 'fs';
+import { execSync } from 'child_process';
+
+test('no secret files tracked by git', () => {
+    const tracked = execSync('git ls-files', { encoding: 'utf-8' });
+    const badFiles = ['.env', '.dev.vars', '.env.local', '.env.production'];
+    const found = badFiles.filter(f => tracked.split('\n').includes(f));
+    expect(found, `Secret files tracked: ${found.join(', ')}`).toEqual([]);
+});
+
+test('.gitignore contains required security patterns', () => {
+    const gitignore = fs.readFileSync('.gitignore', 'utf-8');
+    expect(gitignore).toContain('.env');
+    expect(gitignore).toContain('.dev.vars');
+});
+
+test('no hardcoded secrets in source files', () => {
+    const dangerousPatterns = [
+        /SERVICE_KEY\s*[=:]\s*['"][a-zA-Z0-9/+=]{20,}/g,
+        /PRIVATE_KEY\s*[=:]\s*['"][a-zA-Z0-9/+=]{20,}/g,
+        /-----BEGIN.*PRIVATE KEY-----/g,
+    ];
+    const srcDir = 'src';
+    if (!fs.existsSync(srcDir)) return;
+    const files = fs.readdirSync(srcDir).filter(f => f.endsWith('.ts') || f.endsWith('.js'));
+    for (const file of files) {
+        const content = fs.readFileSync(`${srcDir}/${file}`, 'utf-8');
+        for (const pattern of dangerousPatterns) {
+            expect(content, `${file} contains potential secret`).not.toMatch(pattern);
+        }
+    }
+});
+```
+
+### Phase 3: Script Wiring
+
+Wire these tests into `package.json` to make them easily executable by CI or other skills.
+
+```json
+{
+  "scripts": {
+    "test": "vitest",
+    "test:gate": "vitest run --reporter=verbose",
+    "test:security": "snyk test && aikido-api-client scan-release $npm_package_name $(git rev-parse HEAD) --minimum-severity-level=HIGH",
+    "test:watch": "vitest watch"
+  }
+}
+```
+
+> **Security Gate Check:** The `test:security` script runs the Snyk dependency check and the Aikido release scan in parallel. See `cm-security-gate` for advanced SAST/IaC flags.
+
+### Phase 4: Secret Hygiene and Ignore Configuration
+
+**NEVER commit `.env` or `.dev.vars`.** Ensure tests do not expose actual production secrets.
+
+1.  **Check `.gitignore`:**
+    ```bash
+    grep -E "node_modules|\.env|\.dev\.vars" .gitignore
+    # Must exist, if not, add them.
+    ```
+2.  **Define Mock Env:**
+    Create a `.env.test` file (this CAN be committed) with safe, mock values if needed by the test environment.
+
+### Phase 5: Verification
+
+Run the test gate to prove it works before declaring the task complete.
+
+```bash
+npm run test:gate
+```
+
+## Integration with Other Skills
+
+| Skill | Relationship |
+|---|---|
+| `cm-safe-deploy` | `test:gate` is Gate 2 in the safe deploy pipeline. |
+| `cm-project-bootstrap` | Should invoke `cm-test-gate` during Phase 7 (Infrastructure Setup). |
+| `cm-safe-i18n` | Relies on the i18n tests set up in Phase 2, Layer 4. |
+| `cm-secret-shield` | Layer 5 security scan uses Secret Shield patterns. |
+
+## Red Flags - STOP and Fix
+
+- Setting up tests but not creating the `test:gate` run script.
+- Combining all tests into one massive `app.test.js` file.
+- Skipping the `frontend-safety.test.ts` layer for SPA/monolith projects.
+- Using real production database credentials in the test setup.
+- Ignoring test failures and proceeding anyway.

package/skills/cm-test-gate/SKILL.md

@@ -1,245 +1,26 @@
 ---
 name: cm-test-gate
-description: Complete guide to setting up a reliable test gate for any project — covers stack detection, 4 core test files, script wiring, secret hygiene, and Cloudflare Workers/Pages patterns. Use when starting a new project, adding CI to an existing one, or when "tests pass but production breaks." Companion to cm-safe-deploy and cm-project-bootstrap.
+description: "[Deprecated] quality gate now covers tests + canary. Use `cm-quality-gate` instead."
+deprecated: true
+merged_into: cm-quality-gate
 ---
 
-# cm-test-gate: Multi-Layer Test Gate Setup
+# cm-test-gate — Deprecated
 
-## Overview
+> ⚠️ This skill is deprecated as of CodyMaster v6.0.0 and will be removed in v6.1.0.
+>
+> **Use `cm-quality-gate` instead.** quality gate now covers tests + canary.
+>
+> See [docs/migration-v2.md](../../docs/migration-v2.md) for the full mapping.
 
-A deployment process without a test gate is just shipping code and praying. The `test:gate` script is your first line of defense before deployment. A test gate MUST verify four things: frontend component safety, backend API behavior, core business logic, and i18n synchronization.
+The original content is preserved at [SKILL.archive.md](SKILL.archive.md) for reference.
 
-**Core assumption:** The most dangerous errors are syntax flaws, variable shadowing, or import failures that tests often skip if they only check logic.
-
-**Violating the letter of this process is violating the spirit of quality engineering.**
-
-## The Protocol
-
-When setting up a test gate for a project, follow these 5 phases in order.
-
-### Phase 1: Stack Detection and Environment Setup
-
-**Goal:** Identify the framework and install the correct testing dependencies.
-
-1. **Detect Stack:**
-   - Check `package.json` for framework (React, Vue, Svelte, static HTML) and build tool (Vite, Next.js).
-   - Check for `wrangler.json(c)` (Cloudflare Workers/Pages).
-   - Check for Tailwind, PostCSS, or specific UI libraries.
-
-2. **Install Dependencies (Example: Vite/Vitest):**
-   ```bash
-   # Install vitest and related tools
-   npm install -D vitest jsdom @testing-library/react @testing-library/jest-dom
-   # (Adjust based on framework: e.g., @testing-library/svelte)
-   ```
-
-3. **Configure File:**
-   - Create `vitest.config.ts` (or `.js`):
-     ```typescript
-     import { defineConfig } from 'vitest/config'
-     // Import framework plugin (e.g., react(), svelte())
-     
-     export default defineConfig({
-       test: {
-         environment: 'jsdom',
-         globals: true,
-         setupFiles: ['./test/setup.ts'], // Optional
-       },
-     })
-     ```
-
-### Phase 2: The 4 Core Test Files
-
-A complete `test:gate` must cover four distinct layers. Do not combine these files.
-
-#### Layer 1: Frontend Safety (`frontend-safety.test.ts`)
-This layer prevents white screens and catastrophic syntax errors in the browser. Emphasize parsing and template rendering over logical assertions.
-
-*Use the exact implementation from `cm-quality-gate` regarding the 4 corruption checks.*
-
-```typescript
-import { test, expect } from 'vitest';
-import fs from 'fs';
-import path from 'path';
-
-test('app.js does not contain catastrophic syntax corruption', () => {
-    // 1. Read the raw file
-    const content = fs.readFileSync(path.resolve(__dirname, '../public/static/app.js'), 'utf-8');
-    
-    // 2. Syntax Validation (Check for broken template literals)
-    // ❌ Bug #1: Single-quote wrapping template string
-    expect(content).not.toMatch(/=\s*'[^']*\$\{t\(/);
-    
-    // 3. Delimiter consistency
-    // ❌ Bug #4: Mismatched delimiters
-    expect(content).not.toMatch(/t\('[^']*\`/);
-    expect(content).not.toMatch(/t\(\`[^']*'\)/);
-    
-    // 4. HTML structure integrity
-    // ❌ Bug #2: Spaces inside tags or broken closers
-    expect(content).not.toMatch(/<\s+[a-zA-Z]/); // e.g., "< div"
-    expect(content).not.toMatch(/<\/\s+[a-zA-Z]/); // e.g., "</ div"
-    expect(content).not.toMatch(/--\s+>/); // e.g., "text-- >"
-});
-```
-
-#### Layer 2: API Routes (`api-routes.test.ts`)
-This layer ensures backend endpoints respond correctly and handle JSON properly.
-
-*Example for a generic fetch wrapper or specific Next.js/Worker handler:*
-
-```typescript
-import { test, expect } from 'vitest';
-
-test('API mock test', async () => {
-    // Test your server handlers directly
-    // Ensure 200 OK for valid inputs and 400 for errors
-    expect(true).toBe(true);
-});
-```
-
-#### Layer 3: Business Logic (`business-logic.test.ts`)
-This layer tests pure functions: calculations, validations, and data transformations.
-
-```typescript
-import { test, expect } from 'vitest';
-
-test('Calculates score correctly', () => {
-    // const result = calculateScore(input);
-    // expect(result).toBe(expected);
-    expect(true).toBe(true);
-});
-```
-
-#### Layer 4: i18n Synchronization (`i18n-sync.test.ts`)
-This layer guarantees that language files are complete and identical in structure.
-
-```typescript
-import { test, expect } from 'vitest';
-import fs from 'fs';
-import path from 'path';
-
-test('i18n files have identical key counts', () => {
-    const langDir = path.resolve(__dirname, '../public/static/i18n');
-    const langs = ['vi.json', 'en.json', 'th.json', 'ph.json'];
-    
-    const countKeys = (obj: any): number => {
-        let count = 0;
-        for (const k in obj) {
-            if (typeof obj[k] === 'object' && obj[k] !== null) {
-                count += countKeys(obj[k]);
-            } else {
-                count++;
-            }
-        }
-        return count;
-    };
-
-    let baseCount = -1;
-    for (const file of langs) {
-        if (!fs.existsSync(path.join(langDir, file))) continue;
-        
-        const data = JSON.parse(fs.readFileSync(path.join(langDir, file), 'utf-8'));
-        const count = countKeys(data);
-        
-        if (baseCount === -1) {
-            baseCount = count;
-        } else {
-            expect(count, `File ${file} has a different key count`).toBe(baseCount);
-        }
-    }
-});
-```
-
-#### Layer 5: Security Scan (`security-scan.test.ts`)
-This layer prevents secrets from being committed to the repository. Powered by `cm-secret-shield` patterns.
-
-```typescript
-import { test, expect } from 'vitest';
-import fs from 'fs';
-import { execSync } from 'child_process';
-
-test('no secret files tracked by git', () => {
-    const tracked = execSync('git ls-files', { encoding: 'utf-8' });
-    const badFiles = ['.env', '.dev.vars', '.env.local', '.env.production'];
-    const found = badFiles.filter(f => tracked.split('\n').includes(f));
-    expect(found, `Secret files tracked: ${found.join(', ')}`).toEqual([]);
-});
-
-test('.gitignore contains required security patterns', () => {
-    const gitignore = fs.readFileSync('.gitignore', 'utf-8');
-    expect(gitignore).toContain('.env');
-    expect(gitignore).toContain('.dev.vars');
-});
-
-test('no hardcoded secrets in source files', () => {
-    const dangerousPatterns = [
-        /SERVICE_KEY\s*[=:]\s*['"][a-zA-Z0-9/+=]{20,}/g,
-        /PRIVATE_KEY\s*[=:]\s*['"][a-zA-Z0-9/+=]{20,}/g,
-        /-----BEGIN.*PRIVATE KEY-----/g,
-    ];
-    const srcDir = 'src';
-    if (!fs.existsSync(srcDir)) return;
-    const files = fs.readdirSync(srcDir).filter(f => f.endsWith('.ts') || f.endsWith('.js'));
-    for (const file of files) {
-        const content = fs.readFileSync(`${srcDir}/${file}`, 'utf-8');
-        for (const pattern of dangerousPatterns) {
-            expect(content, `${file} contains potential secret`).not.toMatch(pattern);
-        }
-    }
-});
-```
-
-### Phase 3: Script Wiring
-
-Wire these tests into `package.json` to make them easily executable by CI or other skills.
-
-```json
-{
-  "scripts": {
-    "test": "vitest",
-    "test:gate": "vitest run --reporter=verbose",
-    "test:security": "snyk test && aikido-api-client scan-release $npm_package_name $(git rev-parse HEAD) --minimum-severity-level=HIGH",
-    "test:watch": "vitest watch"
-  }
-}
-```
-
-> **Security Gate Check:** The `test:security` script runs the Snyk dependency check and the Aikido release scan in parallel. See `cm-security-gate` for advanced SAST/IaC flags.
-
-### Phase 4: Secret Hygiene and Ignore Configuration
-
-**NEVER commit `.env` or `.dev.vars`.** Ensure tests do not expose actual production secrets.
-
-1.  **Check `.gitignore`:**
-    ```bash
-    grep -E "node_modules|\.env|\.dev\.vars" .gitignore
-    # Must exist, if not, add them.
-    ```
-2.  **Define Mock Env:**
-    Create a `.env.test` file (this CAN be committed) with safe, mock values if needed by the test environment.
-
-### Phase 5: Verification
-
-Run the test gate to prove it works before declaring the task complete.
+## Migration
 
 ```bash
-npm run test:gate
+# Old:           cm <use this skill>
+# New (v6.0+):   cm quality-gate <equivalent action>
 ```
 
-## Integration with Other Skills
-
-| Skill | Relationship |
-|---|---|
-| `cm-safe-deploy` | `test:gate` is Gate 2 in the safe deploy pipeline. |
-| `cm-project-bootstrap` | Should invoke `cm-test-gate` during Phase 7 (Infrastructure Setup). |
-| `cm-safe-i18n` | Relies on the i18n tests set up in Phase 2, Layer 4. |
-| `cm-secret-shield` | Layer 5 security scan uses Secret Shield patterns. |
-
-## Red Flags - STOP and Fix
-
-- Setting up tests but not creating the `test:gate` run script.
-- Combining all tests into one massive `app.test.js` file.
-- Skipping the `frontend-safety.test.ts` layer for SPA/monolith projects.
-- Using real production database credentials in the test setup.
-- Ignoring test failures and proceeding anyway.
+If you depend on a capability that didn't carry over, please file an issue:
+https://github.com/tody-agent/codymaster/issues

package/skills/cm-ui-preview/SKILL.archive.md

@@ -0,0 +1,153 @@
+---
+name: cm-ui-preview
+description: "Master Design Skill. Orchestrates AI-powered UI generation using Google Stitch MCP, guided by cm-ux-master intelligence and professional prompt enhancement pipelines. Implements the 'Stitch Build Loop', 'Prompt Optimization Structure', and strict design system adherence to generate production-ready UI previews before coding."
+---
+
+# UI Preview — The Master Design Orchestrator
+
+> **See it before you build it.**
+> This skill transforms vague user requests into precise, structured 'Construction Blueprints' for the Google Stitch AI generator, ensuring UI outputs are professional, consistent with project branding, and ergonomically sound.
+
+## When to Use
+
+**ALWAYS trigger when the task involves building, redesigning, or modifying UI:**
+- Creating new pages, screens, or layouts
+- Building components (forms, cards, dashboards)
+- Restyling or beautifying existing UIs
+- Translating a wireframe or concept into high-fidelity UI
+
+**Trigger keywords:** build UI, design page, create screen, landing page, dashboard layout, UI designer, use stitch, stitch me a ui, redesign, restyle
+
+## Architecture & Workflow (End-to-End)
+
+This skill operates as a pipeline. **Do not skip steps.**
+
+```
+  ┌─────────────────────────────────────────────────────────┐
+  │              cm-ui-preview Master Workflow              │
+  ├─────────────────────────────────────────────────────────┤
+  │                                                         │
+  │  Step 1: PREFLIGHT & INTENT                             │
+  │  ├── Detect task: New UI vs. Refine/Beautify            │
+  │  └── Verify Stitch MCP tools availability               │
+  │                                                         │
+  │  Step 2: DESIGN SYSTEM EXTRACTION (The Source of Truth) │
+  │  ├── Check: .stitch/DESIGN.md, css tokens, etc.         │
+  │  └── Fallback: Trigger `cm-ux-master` to generate one   │
+  │                                                         │
+  │  Step 3: PROMPT ENHANCEMENT (The Build Blueprint)       │
+  │  ├── Project Overview (What, who, style vibe)           │
+  │  ├── Design System Specs (Colors, Typography, Layout)   │
+  │  └── Page Structure (Core function + Specific areas)    │
+  │                                                         │
+  │  Step 4: STITCH EXECUTION (The Build Loop)              │
+  │  ├── create_project()                                   │
+  │  ├── generate_screen_from_text()                        │
+  │  ├── Present link + AI insights to user                 │
+  │  └── User Decision: Confirm / Edit / Skip               │
+  │                                                         │
+  │  Step 5: FINALIZATION & BATON PASS                      │
+  │  ├── Save state to .stitch/next-prompt.md               │
+  │  └── Hand off to cm-execution for actual coding         │
+  │                                                         │
+  └─────────────────────────────────────────────────────────┘
+```
+
+## Step 1: Preflight & Intent Classification
+
+1. **Verify Stitch MCP:** Check if `create_project` and `generate_screen_from_text` are available. If not, inform the user they are missing the Stitch tools but proceed with Prompt-Only generation (output the blueprint for them to use manually).
+2. **Classify Intent:**
+   - **New Screen:** Proceed with full generation.
+   - **Refine/Beautify (edit):** Use `edit_screens()` on existing IDs instead of `generate_screen_from_text()`.
+
+## Step 2: Design System Extraction (Source of Truth)
+
+Before assembly, you MUST establish the design constraints.
+
+**Look for:**
+- `.stitch/DESIGN.md` (Primary source for Stitch)
+- `design-system/MASTER.md` (From `cm-ux-master`)
+- `.cm/design-tokens.css` or Tailwind configs
+
+**If no design system exists:**
+*Suggest running `cm-ux-master` or create a `.stitch/DESIGN.md` baseline.*
+A baseline MUST contain:
+- Platform (Web/Mobile)
+- Primary/Secondary Colors (with hex codes)
+- Typography (Font families)
+- Component constraints (Rounded vs Sharp, Shadow levels)
+
+## Step 3: Prompt Enhancement Pipeline (CRITICAL)
+
+**DO NOT send vague prompts to Stitch (e.g., "Make a login page").**
+You must assemble an "Optimized Prompt Structure" — a detailed construction blueprint.
+
+Structure your prompt exactly like this:
+
+```markdown
+[Overall vibe, mood, and purpose of the page: e.g., "A modern fintech dashboard for B2B users. Professional, trustworthy, high data density, light mode."]
+
+**DESIGN SYSTEM (REQUIRED):**
+- Platform: Web Desktop-first
+- Palette: Primary Blue (#0F62FE), Secondary Gray (#F4F4F4), Danger Red (#DA1E28)
+- Typography: Inter for UI, Roboto Mono for numbers
+- Styles: 4px border radius, subtle drop shadows on cards
+
+**PAGE STRUCTURE & FUNCTION:**
+### 1. Dashboard Home
+**Core function**: Overview of recent transactions and account health.
+- **Top Nav**: Brand logo, Global Search input, User Avatar dropdown.
+- **Hero/Header**: Greeting "Welcome back, {User}", Total Balance callout (Large bold text).
+- **Main Function Area**:
+  - Left col: Line chart showing 30-day revenue.
+  - Right col: Vertical list of "Recent Transactions" (Icon, Title, Date, Amount (Green/Red)).
+- **Action Area**: Primary CTA "Send Money" (Blue fill, large), Secondary "Download Statement" (Outline).
+```
+
+*Refine UI terminology:* Replace "nice buttons" with "Primary CTA", replace "boxes" with "Cards". Apply relevant constraints from `cm-ux-master` (e.g., Miller's Law for chunking lists).
+
+## Step 4: Stitch Execution (The Build Loop)
+
+1. **Project Creation:**
+   ```javascript
+   mcp_StitchMCP_create_project({ title: "UI Preview — {Feature}" })
+   ```
+2. **Screen Generation:**
+   ```javascript
+   mcp_StitchMCP_generate_screen_from_text({
+     projectId: "<id>",
+     prompt: "<Your Optimized Prompt Blueprint>",
+     deviceType: "DESKTOP" // or MOBILE
+   })
+   ```
+3. **User Presentation:**
+   Show the output, provide the URL, and present the **AI Insights** (from the tool's `outputComponents` response).
+
+   ```markdown
+   🎨 **UI Preview Generated!**
+
+   - **Stitch Project ID:** `<id>`
+   - **View & Edit:** [Open in Google Stitch](https://stitch.withgoogle.com/projects/<id>)
+   - **AI Insights:** [Any suggestions or notes returned by Stitch]
+
+   What's next?
+   1. ✅ **Confirm** — I will write the code matching this design exactly.
+   2. ✏️ **Edit** — Tell me what to change, I'll update the preview.
+   3. ⏭️ **Skip** — Proceed straight to coding.
+   ```
+
+## Step 5: Finalization & Baton Pass
+
+- **If Confirm:** Proceed to code implementation. You MUST follow the visual layout, spacing, and colors shown in the Stitch preview.
+- **If Edit:** Call `mcp_StitchMCP_edit_screens()` with the specific element changes.
+- **Baton Update (Optional but Recommended):** Maintain a `.stitch/next-prompt.md` to feed into the next agent task or session for continuity.
+
+## Anti-Patterns (Strict Prohibitions)
+
+- ⛔ **NO VAGUE PROMPTS:** Never pass user input straight to Stitch without the Step 3 Enhancement Pipeline.
+- ⛔ **NO FAKE SUCCESS:** If the MCP tool fails or isn't connected, do not hallucinate a success message or URL.
+- ⛔ **NO CODING (Yet):** This phase is purely for DESIGN PREVIEW. Do not write React/Vue code until the user clicks "Confirm" or "Skip".
+- ⛔ **NO APP SCAFFOLDING:** Do not initialize project codebases in this workflow.
+
+## Future: Pencil.dev Support
+*Pencil MCP tools are available and will be integrated as an alternative execution engine in future updates (`batch_design`, `get_editor_state`).*