codymaster 4.8.0 → 7.0.0

package/skills/cm-start/SKILL.md

@@ -1,10 +1,18 @@
 ---
 name: cm-start
 description: Start the CM Workflow to execute your objective from idea to production code.
+token_budget: 1000
+compressed: true
+deprecated: false
 ---
 
 # Command: `/cm-start [your objective]`
 
+## TL;DR
+- **Use to** kick off a CM session — entry point
+- **Detects**: stack (Phase 2), suggests skills, reads continuity + learnings
+- **Next**: cm-brainstorm-idea or cm-planning
+
 > **Role: Workflow Orchestrator** — You assess complexity, select the right workflow depth, and drive execution from objective to production code.
 
 When this workflow is called, the AI Assistant should execute the following action sequence in the spirit of the **CodyMaster Kit**:
@@ -13,16 +21,12 @@ When this workflow is called, the AI Assistant should execute the following acti
     Per `_shared/helpers.md#Load-Working-Memory` — **use Smart Spine order:**
     1. Check `.cm/context-bus.json` → any active pipeline? any prior skill output to reuse?
     2. Load L0 indexes: `learnings-index.md` (~100 tok) + `skeleton-index.md` (~500 tok)
-       > **If OpenViking backend active:** Skip step 2 — engine auto-serves L0/L1 via `cm_resolve`.
     3. Scope-filter learnings via `cm_query` — only load what matches current objective
-       > **If OpenViking:** `cm_query` uses vector semantic search — broader recall, fewer missed learnings.
     4. Read `CONTINUITY.md` → set Active Goal to the new objective
     5. Run token budget check: `cm continuity budget` → confirm no category is over soft limit
 
     > ⚡ Total context load: ~700 tokens. Full load used to be ~3,200.
     > Only escalate to L2 (full files) if L0 index explicitly flags a match.
-    > With OpenViking: L0 is auto-maintained — no stale index risk.
-
 0.5. **Skill Coverage Check (Adaptive Discovery):**
     - Scan the objective for technologies, frameworks, or patterns mentioned
     - Cross-reference with `cm-skill-index` Layer 1 triggers
@@ -30,6 +34,15 @@ When this workflow is called, the AI Assistant should execute the following acti
       `npx skills find "{keyword}"` → review → ask user → install if approved
     - Log any discovered skills to `.cm-skills-log.json`
 
+0.6. **Stack & Tier Detection (Phase 2):**
+    - `cm stack detect --write` → writes `.cm/project-skills.md` (frameworks + suggested skills)
+    - `cm tier classify --write` → writes `.cm/project-tier.md` (LITE/STANDARD/PROFESSIONAL/ENTERPRISE)
+    - The tier sets the default Vibecoding mode and **adaptive depth**:
+      - LITE/STANDARD → render skill TL;DR only
+      - PROFESSIONAL/ENTERPRISE → render full protocol
+    - Inject the suggested-skills list into the skill chain shortlist
+    - These reports are token-light (~300 tok combined) and skipped if files exist and are <24h old
+
 0.7. **Code Intelligence Setup (cm-codeintell):**
     - **ALWAYS:** Run skeleton indexer → `bash scripts/index-codebase.sh` → `.cm/skeleton.md`
     - Read `.cm/skeleton.md` (~5K tokens) → instant codebase understanding
@@ -85,11 +98,5 @@ When this workflow is called, the AI Assistant should execute the following acti
     - Record any new learnings or decisions made during this workflow
     - If inside a skill chain: `cm continuity bus` → verify context bus reflects completed step
     - Refresh L0 indexes: `cm continuity index` (auto-runs on `addLearning`, manual refresh here)
-      > **If OpenViking:** Skip manual index refresh — engine maintains L0/L1 automatically.
-
 > **Note for AI:** If this is a brand new project, suggest running `cm-project-bootstrap` first.
 > If the working environment has a risk of accidentally switching accounts/projects, remind about `cm-identity-guard` (Per `_shared/helpers.md#Identity-Check`).
->
-> **OpenViking tip:** If the project uses many learnings/decisions (>100 entries) or needs semantic
-> search beyond keyword matching, suggest switching to the Viking backend:
-> `storage.backend: viking` in `.cm/config.yaml` + `pip install openviking && openviking start`

package/skills/cm-tdd/SKILL.md

@@ -1,10 +1,19 @@
 ---
-
-## name: cm-tdd
+name: cm-tdd
 description: Use when implementing any feature or bugfix, before writing implementation code
+token_budget: 1500
+compressed: true
+deprecated: false
+---
 
 # Test-Driven Development (TDD)
 
+## TL;DR
+- **Use when** writing or fixing any feature/bugfix
+- **Cycle**: red (failing test) → green (minimal code) → refactor
+- **No prod code** without a failing test first
+- **Next**: cm-execution or cm-code-review
+
 ## Overview
 
 Write the test first. Watch it fail. Write minimal code to pass.
@@ -352,6 +361,16 @@ Bug found? Write failing test reproducing it. Follow TDD cycle. Test proves fix
 
 Never fix bugs without a test.
 
+## Karpathy Discipline — Goal-Driven Execution
+
+TDD is the canonical form of goal-driven execution. Reinforce it:
+- **Translate vague tasks into verifiable goals before writing code.**
+  - "Add validation" → "Test invalid inputs fail; valid inputs pass."
+  - "Fix the bug" → "Test reproduces it red; fix turns it green."
+  - "Refactor X" → "Same tests green before and after."
+- **Strong success criteria let you loop independently.** Weak criteria ("make it work") force the user to babysit.
+- **Minimum code to pass.** Don't over-implement to "anticipate" the next test — write that test first.
+
 ## Final Rule
 
 ```

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