codymaster 7.0.1 → 7.0.3

package/skills/cm-skill-share/SKILL.md

@@ -1,26 +0,0 @@
----
-name: cm-skill-share
-description: "[Deprecated] skill lifecycle merged. Use `cm-skill-evolution` instead."
-deprecated: true
-merged_into: cm-skill-evolution
----
-
-# cm-skill-share — Deprecated
-
-> ⚠️ This skill is deprecated as of CodyMaster v6.0.0 and will be removed in v6.1.0.
->
-> **Use `cm-skill-evolution` instead.** skill lifecycle merged.
->
-> See [docs/migration-v2.md](../../docs/migration-v2.md) for the full mapping.
-
-The original content is preserved at [SKILL.archive.md](SKILL.archive.md) for reference.
-
-## Migration
-
-```bash
-# Old:           cm <use this skill>
-# New (v6.0+):   cm skill-evolution <equivalent action>
-```
-
-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-test-gate/SKILL.archive.md

@@ -1,245 +0,0 @@
----
-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,26 +0,0 @@
----
-name: cm-test-gate
-description: "[Deprecated] quality gate now covers tests + canary. Use `cm-quality-gate` instead."
-deprecated: true
-merged_into: cm-quality-gate
----
-
-# cm-test-gate — Deprecated
-
-> ⚠️ 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.
-
-The original content is preserved at [SKILL.archive.md](SKILL.archive.md) for reference.
-
-## Migration
-
-```bash
-# Old:           cm <use this skill>
-# New (v6.0+):   cm quality-gate <equivalent action>
-```
-
-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

@@ -1,153 +0,0 @@
----
-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`).*

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

@@ -1,26 +0,0 @@
----
-name: cm-ui-preview
-description: "[Deprecated] UI preview is part of design system. Use `cm-design-system` instead."
-deprecated: true
-merged_into: cm-design-system
----
-
-# cm-ui-preview — Deprecated
-
-> ⚠️ This skill is deprecated as of CodyMaster v6.0.0 and will be removed in v6.1.0.
->
-> **Use `cm-design-system` instead.** UI preview is part of design system.
->
-> See [docs/migration-v2.md](../../docs/migration-v2.md) for the full mapping.
-
-The original content is preserved at [SKILL.archive.md](SKILL.archive.md) for reference.
-
-## Migration
-
-```bash
-# Old:           cm <use this skill>
-# New (v6.0+):   cm design-system <equivalent action>
-```
-
-If you depend on a capability that didn't carry over, please file an issue:
-https://github.com/tody-agent/codymaster/issues