codymaster 4.4.4 → 4.5.1

package/skills/cm-continuity/SKILL.md

@@ -29,8 +29,25 @@ cm continuity init
 # Check current state
 cm continuity status
 
-# View captured learnings
+# View captured learnings / decisions
 cm continuity learnings
+cm continuity decisions
+
+# ── Smart Spine v5 commands ──────────────────────────────
+# Regenerate L0 compact indexes (learnings-index.md, skeleton-index.md)
+cm continuity index
+
+# Show token budget allocation + usage per category
+cm continuity budget
+
+# Pretty-print current context bus state (active skill chain)
+cm continuity bus
+
+# Print Claude Desktop MCP config snippet for cm-context server
+cm continuity mcp
+
+# Migrate learnings.json + decisions.json → SQLite (one-time)
+cm continuity migrate
 ```
 
 ## The Protocol
@@ -130,45 +147,84 @@ Project: [project name]
 - [file path]: [what we're changing]
 ```
 
-## 4-Tier Memory System (Brain-Inspired)
+## Memory Architecture (v5 — Smart Spine)
 
 ```
 Tier 1: SENSORY MEMORY (seconds — within current tool call)
   → Internal variables, intermediate results
   → NEVER written to file — discarded when action completes
-  → Example: "File X has 200 lines" — no need to remember next session
 
 Tier 2: WORKING MEMORY (current session → 7 days)
-  → CONTINUITY.md — the active scratchpad
+  → CONTINUITY.md — the active scratchpad (max 500 words / ~400 tokens)
   → Auto-rotates: entries > 7 days promote to Tier 3 or decay
-  → Max 500 words (~400 tokens)
-  
-Tier 3: LONG-TERM MEMORY (30+ days, only if reinforced)
-  → .cm/learnings.json — error patterns with TTL + scope
-  → .cm/decisions.json — architecture decisions with supersedence
-  → Entries MUST be reinforced (same pattern ≥ 2x) to survive
-  → Decay: auto-archive if not relevant after TTL expires
+  → Context bus (.cm/context-bus.json) — live skill chain state
+    · initBus() on chain start, updateBusStep() on each advance
+    · cm://pipeline/current resolves to bus JSON
+    · Read via: cm continuity bus | cm_bus_read MCP tool
 
-Tier 4: EXTERNAL SEMANTIC MEMORY (optional — for large projects)
+Tier 3: LONG-TERM MEMORY (30+ days, only if reinforced)
+  → Primary:  .cm/context.db (SQLite + FTS5) ← v5 default
+      · learnings table + learnings_fts (BM25 keyword search)
+      · decisions table + decisions_fts
+      · skill_outputs per session/chain
+      · indexes table (cached L0/L1 content + staleness hash)
+  → Fallback: .cm/memory/learnings.json + decisions.json (kept for compat)
+  → L0 indexes: .cm/learnings-index.md (~100 tok), .cm/skeleton-index.md (~500 tok)
+      · Auto-regenerated on addLearning() + on demand via cm continuity index
+      · File watcher auto-refreshes learnings L0 on JSON change (300ms debounce)
+  → Token budget: .cm/token-budget.json — 200k window, per-category soft limits
+      · Enforced at load time: checkBudget() → allowed/remaining/suggestion
+      · View: cm continuity budget
+
+Tier 4: EXTERNAL SEMANTIC MEMORY (optional — large projects)
   → tobi/qmd — BM25 + Vector + LLM re-ranking, 100% local
-  → Indexes entire docs/, src/, meeting notes folders
-  → AI queries via MCP: qmd query "keyword" → relevant snippets
-  → See cm-deep-search skill for setup & detection thresholds
-  → ONLY suggested when project >50 docs or >200 source files
+  → See cm-deep-search skill — ONLY when >50 docs or >200 source files
 
-Tier 5: STRUCTURAL CODE MEMORY (optional — for code-heavy projects)
+Tier 5: STRUCTURAL CODE MEMORY (optional — code-heavy projects)
   → CodeGraph — tree-sitter AST → SQLite graph → MCP server
-  → Indexes symbols, call graphs, imports, class hierarchies
-  → AI queries: codegraph_context, codegraph_impact, codegraph_callers
-  → See cm-codeintell skill for setup & integration
-  → ONLY suggested when project >50 source files
+  → See cm-codeintell skill — ONLY when >50 source files
 ```
 
-**CONTINUITY.md = "what am I doing NOW?"**
-**learnings.json = "what mistakes should I avoid?"**  
-**decisions.json = "what architecture rules apply?"**
+**CONTINUITY.md  = "what am I doing NOW?"**
+**context bus    = "what did upstream skills produce in this chain?"**
+**L0 indexes     = "cheapest possible memory load (~600 tokens)"**
+**context.db     = "keyword search across all learnings + decisions"**
 **qmd (optional) = "find what was written across hundreds of docs"**
 
+### MCP Context Server (Claude Desktop integration)
+
+Seven tools exposed over stdio to Claude Desktop and MCP-compatible clients:
+
+| Tool | Purpose |
+|---|---|
+| `cm_query` | FTS5 keyword search — learnings, decisions, or both |
+| `cm_resolve` | Load any `cm://` URI at L0/L1/L2 depth |
+| `cm_bus_read` | Read live context bus state |
+| `cm_bus_write` | Publish skill output to the bus |
+| `cm_budget_check` | Pre-flight token check by category |
+| `cm_memory_decay` | Archive expired learnings (supports dry_run) |
+| `cm_index_refresh` | Regenerate L0 indexes on demand |
+
+```bash
+# Get install snippet for Claude Desktop config
+cm continuity mcp
+```
+
+### cm:// URI Scheme
+
+Reference any memory resource by URI — resolver handles depth + caching:
+
+```
+cm://memory/working              → CONTINUITY.md
+cm://memory/learnings            → learnings-index.md (L0) or SQLite (L1/L2)
+cm://memory/learnings/{id}       → specific learning by ID
+cm://memory/decisions            → decisions index
+cm://skills/{name}               → SKILL.md at depth
+cm://skills/{name}/L0            → front matter + description only (~50 tokens)
+cm://resources/skeleton          → skeleton-index.md (L0) or full
+cm://pipeline/current            → live context bus state
+```
+
 ---
 
 ## Memory Audit Protocol (Auto — Every Session Start)
@@ -383,22 +439,28 @@ WHY: Smaller scope = less noise = AI only reads what's relevant.
 
 ```
 ✅ DO:
-- Read CONTINUITY.md at session start (ALWAYS)
+- Check context bus FIRST at session start (free, ~50 tokens)
+- Load L0 indexes BEFORE full files (learnings-index + skeleton-index)
+- Use cm_query for keyword search — don't scan JSON manually
+- Read CONTINUITY.md after L0 indexes (not before)
 - Run Memory Audit at session start (decay + conflicts + scope filter)
 - Update CONTINUITY.md at session end (ALWAYS)
 - Tag EVERY learning/decision with scope (global/module/file)
 - Reinforce existing learnings instead of creating duplicates
 - Keep CONTINUITY.md under 500 words (rotate to Tier 3)
 - Be specific: "Fixed auth bug in login.ts:42" not "Fixed stuff"
+- Run cm continuity index after bulk learning additions
 
 ❌ DON'T:
+- Load full learnings.json or skeleton.md as first action (use L0 first)
+- Skip context bus check when inside a skill chain
 - Skip Memory Audit ("I'll read everything, it's fine")
 - Write learnings without scope ("it applies everywhere" = almost never true)
 - Create duplicate learnings (reinforce existing ones instead)
-- Let learnings.json grow unbounded (TTL + decay handles this)
-- Read ALL learnings regardless of current module (use scope filter)
+- Let learnings.json grow unbounded (TTL + decay + cm_memory_decay handles this)
+- Read ALL learnings regardless of current module (use scope filter / cm_query)
 - Ignore superseded decisions (they cause conflicting code)
-- Keep stale context that no longer applies to current architecture
+- Inject skeleton.md (20KB) when skeleton-index.md (~2KB) is sufficient
 ```
 
 ## The Bottom Line

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

@@ -186,7 +186,17 @@ After ANY gate fails, **FIRST run Memory Integrity Check:**
 | `cm-identity-guard` | Verify identity before using quality gate to ship |
 | `cm-tdd` | TDD creates the logic for Layer 3 |
 | `cm-safe-i18n` | Leverages Layer 4 for parity checks |
+| `cm-security-gate` | **PRE-REQUISITE for production:** Security scan (Snyk + Aikido) PASS must be in deployment evidence. No production deploy without security clearance. |
+
+## Evidence Requirements for Production Deploy
+
+| Evidence | Command | Required |
+|----------|---------|----------|
+| Test suite passes | `npm run test:gate` | ✅ Always |
+| Build succeeds | `npm run build` | ✅ Always |
+| Security scan passes | `snyk test && aikido-api-client scan-release ...` | ✅ For production / public releases |
+| i18n parity | Included in test:gate | ✅ If multilingual |
 
 ## The Bottom Line
 
-**Test before deploy. Evidence before claims. Safety before shipping. Non-negotiable.**
+**Test before deploy. Scan before release. Evidence before claims. Safety before shipping. Non-negotiable.**

package/skills/cm-safe-deploy/SKILL.md

@@ -31,12 +31,13 @@ SYNTAX CHECK IS GATE 1. IF IT FAILS, NOTHING ELSE RUNS.
 - After a production incident caused by untested code
 - Adding CI/CD to an existing project
 
-## The 7-Gate Pipeline
+## The 8-Gate Pipeline
 
 ```dot
 digraph pipeline {
     rankdir=LR;
     gate0 [label="Gate 0\nSecret\nHygiene", shape=box, style=filled, fillcolor="#ffc0cb"];
+    gate05 [label="Gate 0.5\nSecurity\nScan", shape=box, style=filled, fillcolor="#f0b3ff"];
     gate1 [label="Gate 1\nSyntax", shape=box, style=filled, fillcolor="#ffcccc"];
     gate2 [label="Gate 2\nTest\nSuite", shape=box, style=filled, fillcolor="#ffe0cc"];
     gate3 [label="Gate 3\ni18n\nParity", shape=box, style=filled, fillcolor="#e0ccff"];
@@ -45,8 +46,10 @@ digraph pipeline {
     gate6 [label="Gate 6\nDeploy +\nSmoke", shape=box, style=filled, fillcolor="#cce5ff"];
     fail [label="STOP\nFix first", shape=box, style=filled, fillcolor="#ff9999"];
 
-    gate0 -> gate1 [label="pass"];
+    gate0 -> gate05 [label="pass"];
     gate0 -> fail [label="fail"];
+    gate05 -> gate1 [label="pass"];
+    gate05 -> fail [label="fail"];
     gate1 -> gate2 [label="pass"];
     gate1 -> fail [label="fail"];
     gate2 -> gate3 [label="pass"];
@@ -165,6 +168,39 @@ wrangler secret put SUPABASE_SERVICE_KEY
 
 ---
 
+### Gate 0.5: Security Scan (Snyk + Aikido — Parallel)
+
+> [!IMPORTANT]
+> **CodyMaster internal:** This gate is MANDATORY. Both Snyk and Aikido must pass.
+> **User projects:** This gate is SUGGESTED by default. Becomes MANDATORY if CVEs or risk flags were detected during development.
+
+**Run both scanners in parallel:**
+
+```bash
+# Snyk — dependency vulnerabilities
+snyk test
+
+# Aikido — SAST + dependencies + secrets + IaC
+aikido-api-client scan-release <repo> $(git rev-parse HEAD) \
+  --minimum-severity-level="HIGH"
+```
+
+**For CodyMaster (maximum strictness):**
+```bash
+aikido-api-client scan-release <repo> $(git rev-parse HEAD) \
+  --minimum-severity-level="HIGH" \
+  --fail-on-sast-scan \
+  --fail-on-secrets-scan
+```
+
+**Gate decision:**
+- Both pass → proceed to Gate 1
+- Either fails → **STOP. Fix before continuing.** Invoke `cm-security-gate` for remediation.
+
+> See `cm-security-gate` for full setup, flag reference, and remediation workflow.
+
+---
+
 ### Gate 1: Syntax Validation (FAST FAIL)
 
 > [!IMPORTANT]

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

@@ -1,10 +1,23 @@
 ---
-description: Pre-production security audit. Run vulnerability scans using Snyk and set up automated GitHub security checks with Jules.
+description: Pre-production security audit and vulnerability scanning. Run Snyk + Aikido dependency scans, OWASP analysis, and set up automated GitHub security checks with Jules. Use when asked to 'run security check', 'security audit', 'kiểm tra bảo mật', 'vulnerability scan', 'Snyk', 'OWASP', or before open-sourcing / commercializing a project.
 ---
-# cm-security-gate — Pre-production Vulnerability Audit
+# cm-security-gate — Mandatory Security Audit & Vulnerability Gate
 
 > **No code goes public without a security pass.**
-> This skill is the **SUPPLEMENTARY FINAL GATE** before making a project public, commercializing, or open-sourcing.
+> **No CodyMaster release ships without Snyk + Aikido green.**
+
+## Enforcement Policy
+
+| Context | Level | What Happens |
+|---------|-------|-------------|
+| **CodyMaster internal** | 🔴 MANDATORY | Both Snyk + Aikido MUST pass. No deploy, no PR merge without green. |
+| **User projects (normal)** | 🟡 SUGGESTED | Recommend scanning, provide easy commands. User may skip. |
+| **User projects (risk detected)** | 🔴 ESCALATED MANDATORY | If CVEs found, errors hit, or risk flags raised → block until resolved. |
+
+> [!CAUTION]
+> **The Escalation Rule:** When a user encounters security errors, CVE warnings, or suspicious dependency behavior during development, the agent MUST escalate from "suggested" to "mandatory" — triggering the full Snyk + Aikido scan before any further deploy or push.
+
+---
 
 ## When to Use
 
@@ -13,23 +26,56 @@ description: Pre-production security audit. Run vulnerability scans using Snyk a
 - Preparing to open-source a repository or launch a commercial product
 - Adding major third-party dependencies
 - The project is graduating from alpha/beta to a wider release
+- A user encounters CVE warnings, npm audit alerts, or suspicious dependency behavior
+- Before any CodyMaster release or PR merge
 
 **Skip when:**
-- Doing quick local prototyping
-- Exploring ideas without real user data or production intent
+- Doing quick local prototyping with no real user data
+- Exploring ideas without production intent
 
 ---
 
 ## Core Capabilities
 
-1. **Snyk CLI & Aikido CLI Integration:** Scans for known vulnerabilities in open-source dependencies (e.g., `npm`, `pip`, `yarn`, `cargo`) and performs parallel release/PR scanning (SAST, IaC, Secrets).
-2. **Jules CI/CD Recommendation:** Recommends integrating continuous automated security analysis via GitHub.
+1. **Aikido MCP Server:** Real-time scanning of AI-generated code inside the IDE (vulnerabilities + secrets)
+2. **Snyk CLI:** Dependency vulnerability scanning (`npm`, `pip`, `yarn`, `cargo`)
+3. **Aikido CLI:** SAST, IaC, Secrets, and Dependency scanning with release/PR gating
+4. **Continuous Monitoring:** Snyk dashboard + Aikido dashboard for ongoing protection
+5. **Jules CI/CD:** Automated security analysis via GitHub on every commit
 
 ---
 
 ## The Process
 
-### Phase 1: Preparation (Tooling Check)
+### Phase 0: Aikido MCP Setup (IDE-Level Real-Time Scanning)
+
+> [!IMPORTANT]
+> **One-time setup.** Once configured, every AI coding session automatically scans generated code for vulnerabilities and hardcoded secrets — BEFORE the code is even committed.
+
+**Step 1:** Create a Personal Access Token at [Aikido Settings → IDE → MCP](https://app.aikido.dev/settings/integrations/ide/mcp)
+
+**Step 2:** Install Aikido MCP server:
+```bash
+# For Antigravity / Gemini CLI
+gemini mcp add aikido \
+  --env AIKIDO_API_KEY=YOUR_TOKEN \
+  npx -y @aikidosec/mcp
+```
+
+**Step 3:** Download the Aikido agent rule:
+```bash
+mkdir -p ~/.gemini/skills/
+curl -fsSL "https://gist.githubusercontent.com/kidk/aa48cad6db80ba4a38493016aae67712/raw/3644397b7df43423e3da06434491b40bbb79dd47/aikido-rule.txt" \
+  -o ~/.gemini/skills/aikido-rule.txt
+```
+
+**Step 4:** Restart Antigravity IDE. Aikido MCP is now active.
+
+> **What this gives you:** Deterministic, independent security checks on EVERY AI-generated snippet. Not a replacement for CLI scanning — this is the first line of defense, catching issues at write-time.
+
+---
+
+### Phase 1: Preparation (CLI Tooling Check)
 
 Verify if the Snyk CLI and Aikido CLI are available:
 ```bash
@@ -37,19 +83,24 @@ which snyk
 which aikido-api-client
 ```
 
-**If Snyk is NOT installed**, provide installation instructions before proceeding:
+**If Snyk is NOT installed:**
 - **macOS (Homebrew):** `brew tap snyk/tap && brew install snyk`
 - **npm:** `npm install -g snyk`
-- Ensure the user authenticates via `snyk auth` after installation.
+- Authenticate: `snyk auth`
 
-**If Aikido CLI is NOT installed**, provide installation instructions:
+**If Aikido CLI is NOT installed:**
 - **npm:** `npm install -g @aikidosec/ci-api-client`
-- Tell the user to authenticate globally: `aikido-api-client apikey <API-KEY>`
-- *Note: API keys are found at [Aikido Integration Settings](https://app.aikido.dev/settings/integrations/continuous-integration).*
+- Set API key: `aikido-api-client apikey <API-KEY>`
+- *API keys: [Aikido CI Integration Settings](https://app.aikido.dev/settings/integrations/continuous-integration)*
+
+> [!WARNING]
+> **Two different API keys!** Aikido MCP (real-time IDE scanning) uses a *Personal Access Token*. Aikido CLI (release/PR gating) uses a *CI API key*. Don't mix them.
+
+---
 
 ### Phase 2: Execution (Parallel Vulnerability Scan)
 
-Execute security scanning using both tools. They should be run in parallel to save time.
+Execute both tools **in parallel** to save time:
 
 **1. Snyk Dependency Scan:**
 ```bash
@@ -58,20 +109,66 @@ snyk test
 
 **2. Aikido Release Scan:**
 ```bash
-aikido-api-client scan-release <repository_id or repository_name> <commit_id> --minimum-severity-level="HIGH"
+aikido-api-client scan-release <repository_id_or_name> <commit_id> \
+  --minimum-severity-level="HIGH"
 ```
-*(Tip: You can add `--fail-on-secrets-scan` or `--fail-on-sast-scan` depending on the project type).*
 
-Analyze the output from both tools:
+#### Aikido Scan Flags Reference
+
+| Flag | Purpose |
+|------|---------|
+| `--minimum-severity-level` | `LOW`, `MEDIUM`, `HIGH`, `CRITICAL` — set the minimum severity that triggers a failure |
+| `--fail-on-sast-scan` | Fail if SAST (Static Analysis) issues are found |
+| `--fail-on-iac-scan` | Fail if Infrastructure as Code misconfigurations are found |
+| `--fail-on-secrets-scan` | Fail if hardcoded secrets are detected |
+
+#### CodyMaster Internal (Maximum Strictness)
+```bash
+aikido-api-client scan-release <repo> <commit> \
+  --minimum-severity-level="HIGH" \
+  --fail-on-sast-scan \
+  --fail-on-secrets-scan
+```
+
+#### User Projects (Standard)
+```bash
+aikido-api-client scan-release <repo> <commit> \
+  --minimum-severity-level="HIGH"
+```
+
+#### Analyzing Results
 - **Critical/High:** Must be resolved before making the project public.
 - **Medium/Low:** Document as technical debt or evaluate for false positives.
 - Run `snyk monitor` if the user wants continuous monitoring on the Snyk dashboard.
 
-### Phase 2.5: Vulnerability Remediation (Skill Discovery)
+---
+
+### Phase 2.5: PR Gating (GitHub Integration)
+
+For projects with CI/CD pipelines, add Aikido PR gating to block merging PRs with security issues:
+
+```bash
+# In GitHub Actions or CI script
+aikido-api-client scan-pr <repository_id_or_name> <base_commit_id> <head_commit_id> \
+  --minimum-severity-level="HIGH"
+```
+
+**package.json integration:**
+```json
+{
+  "scripts": {
+    "test:security": "snyk test && aikido-api-client scan-release $npm_package_name $(git rev-parse HEAD) --minimum-severity-level=HIGH",
+    "test:security:strict": "snyk test && aikido-api-client scan-release $npm_package_name $(git rev-parse HEAD) --minimum-severity-level=HIGH --fail-on-dependency-scan --fail-on-sast-scan --fail-on-secrets-scan"
+  }
+}
+```
+
+---
+
+### Phase 3: Vulnerability Remediation (Skill Discovery)
 
-If vulnerabilities are detected (e.g., CSRF, XSS, prototype pollution, outdated dependencies), **DO NOT just list the errors**. CodyMaster must actively search for and suggest specialized remediation skills to the user to fix the vulnerabilities.
+If vulnerabilities are detected, **DO NOT just list errors**. CodyMaster must actively search for remediation skills:
 
-**Message to user:**
 > 🚨 **Vulnerabilities Detected: Initiating Remediation**
 > 
 > Security issues were found. To systematically patch these risks, we need specialized weapons. I suggest finding and installing a dedicated remediation skill for your stack:
@@ -80,26 +177,48 @@ If vulnerabilities are detected (e.g., CSRF, XSS, prototype pollution, outdated
 > ```
 > *(Once you discover and install the appropriate security patch skills, we will use them to eradicate the vulnerabilities and eliminate all security risks).*
 
-### Phase 2.6: Knowledge Retention (Memory Sync)
+---
+
+### Phase 4: Knowledge Retention (Memory Sync)
 
-Once the vulnerabilities have been successfully remediated, the exact root causes and their corresponding fixes **MUST** be memorized so that CodyMaster does not repeat the same mistakes in the future.
+Once vulnerabilities are remediated, the root causes and fixes **MUST** be memorized:
 
 **Action Required:**
-- Trigger the `cm-continuity` skill to log the security flaw and the applied fix into `CONTINUITY.md` under a "Security Lessons" or "Hard Lessons" section. 
-- If the project uses cloud memory, suggest tracking this in `cm-notebooklm` to sync this critical security knowledge to the permanent AI brain.
+- Trigger `cm-continuity` to log flaw + fix into `CONTINUITY.md` → "Security Lessons" section.
+- If cloud memory is available, sync to `cm-notebooklm` for permanent retention.
 
-### Phase 3: Automation Handoff (Jules Integration)
+---
 
-After the manual Snyk scan is complete and the results are presented to the user, **ALWAYS** provide the following suggestion to automate future security checks:
+### Phase 5: Automation Handoff (Jules + Continuous Monitoring)
 
-> 🛡️ **Next Step: Automated Security Checks via Jules**
+> 🛡️ **Next Step: Automated Security Checks**
 > 
-> Once your project is ready for commercial or public release, manual checks aren't enough. It's highly recommended to automate security scanning on every commit and Pull Request.
+> Manual checks aren't enough for production. Automate on every commit and PR:
 >
-> Please use **Google Jules** for automated GitHub security analysis:
+> **Option A — Google Jules** (GitHub automated analysis):
 > 👉 [http://jules.google.com/](http://jules.google.com/)
 >
-> Integrating Jules will automatically catch vulnerabilities in your codebase, ensuring your commercial product remains secure as it scales.
+> **Option B — Snyk Continuous Monitoring:**
+> ```bash
+> snyk monitor
+> ```
+>
+> **Option C — Aikido Dashboard** (full visibility):
+> 👉 [https://app.aikido.dev/](https://app.aikido.dev/)
+
+---
+
+## Escalation Protocol
+
+When the agent detects ANY of these signals, enforcement escalates from SUGGESTED → MANDATORY:
+
+| Signal | Action |
+|--------|--------|
+| `npm audit` reports HIGH/CRITICAL | Trigger full Snyk + Aikido scan |
+| User mentions "security error" or "hack" | Trigger full scan before proceeding |
+| New major dependency added (e.g., new ORM, auth lib) | Suggest scan, escalate if dep has known CVEs |
+| Pre-deploy / pre-PR-merge | Check if scan was run in this session, block if not (CodyMaster only) |
+| `.snyk` policy file has expired ignores | Re-scan and update policy |
 
 ---
 
@@ -107,8 +226,13 @@ After the manual Snyk scan is complete and the results are presented to the user
 
 | Skill | Relationship |
 |-------|-------------|
-| `cm-quality-gate` | PRE-REQUISITE: Code should pass functional tests before security audits. |
-| `cm-secret-shield`| COMPLEMENTARY: Secret Shield catches hardcoded tokens; `cm-security-gate` catches vulnerable dependencies. Both are needed for public releases. |
-| `cm-safe-deploy`  | POST-REQUISITE: Security gates should ideally be part of the automated deployment pipeline. |
-| `cm-continuity`   | MEMORY LOGGING: Records discovered vulnerabilities and their fixes into the local working memory to prevent future recurrences. |
+| `cm-quality-gate` | PRE-REQUISITE: Code should pass functional tests before security audits. Security scan PASS is required evidence for production deploy. |
+| `cm-secret-shield`| COMPLEMENTARY: Secret Shield catches hardcoded tokens at write/commit time; `cm-security-gate` catches vulnerable dependencies and SAST issues. Both are needed. |
+| `cm-safe-deploy`  | INTEGRATED: Security scan is Gate 0.5 in the deploy pipeline (between Secret Hygiene and Syntax). |
+| `cm-test-gate`    | INTEGRATED: `test:security` script pattern uses Snyk + Aikido CLI for automated scanning in the test suite. |
+| `cm-continuity`   | MEMORY: Records discovered vulnerabilities and fixes into working memory. |
 | `cm-notebooklm`   | LONG-TERM MEMORY: Syncs critical security lessons to the permanent cloud AI brain. |
+
+## The Bottom Line
+
+**Scan before deploy. Remediate before release. Memorize before repeating. Non-negotiable.**

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

@@ -65,6 +65,47 @@ Full skill names: `cm-brainstorm-idea`, `cm-planning`, `cm-tdd`, `cm-execution`,
 - **cm-continuity**: Chain progress persists across sessions via CONTINUITY.md working memory
 - **cm-execution**: Each chain step delegates to cm-execution for actual implementation
 - **cm-quality-gate**: Automatically runs at end of each development chain
+- **Context Bus (v5)**: Every chain automatically maintains `.cm/context-bus.json` — shared state across all steps
+
+## Context Bus — Inter-Skill Coordination (v5)
+
+When `chain start` runs, the context bus is initialized automatically:
+
+```
+chain start feature-development "add payment flow"
+→ Creates .cm/context-bus.json with:
+    pipeline: "feature-development"
+    session_id: "<uuid>"
+    current_step: "brainstorm-idea"
+    shared_context: {}
+    resource_state: { skeleton_generated: null, learnings_indexed: null, ... }
+```
+
+When `chain advance` runs after each skill completes:
+
+```
+chain advance <exec-id> "summary of what was done"
+→ Updates context-bus.json:
+    current_step: "planning"   ← moved forward
+    shared_context.brainstorm-idea: { summary, affected_files, output_path }
+```
+
+**What downstream skills gain:**
+- `cm-planning` can read brainstorm output path → no re-read of full filesystem
+- `cm-tdd` can see which files planning created → targeted test generation
+- `cm-quality-gate` knows exactly which files changed → focused review
+
+**Reading the bus:**
+```bash
+cm continuity bus          # terminal pretty-print
+cm_bus_read                # MCP tool (Claude Desktop)
+cm://pipeline/current      # URI resolver (in skill prompts)
+```
+
+**Publishing to the bus (inside a skill):**
+```bash
+cm_bus_write skill=cm-planning summary="tasks.md created" output_path=openspec/...
+```
 
 ## For AI Agents
 
@@ -74,5 +115,10 @@ When dispatching tasks that match a chain pattern:
 1. Check if task matches a chain: suggestChain(taskTitle)
 2. If match found, suggest to user: "This task matches the X chain pipeline"
 3. If user agrees, start the chain and invoke skills in order
-4. After completing each skill, advance the chain
+4. At the START of each skill step:
+   → Read cm://pipeline/current to see upstream skill outputs
+   → Check shared_context to avoid re-doing work
+5. After completing each skill, advance the chain:
+   → chain advance <id> "summary"
+   → This updates context bus + CONTINUITY.md simultaneously
 ```

package/skills/cm-start/SKILL.md

@@ -10,8 +10,15 @@ description: Start the CM Workflow to execute your objective from idea to produc
 When this workflow is called, the AI Assistant should execute the following action sequence in the spirit of the **CodyMaster Kit**:
 
 0. **Load Working Memory:**
-    Per `_shared/helpers.md#Load-Working-Memory`
-    - Update `CONTINUITY.md` → set Active Goal to the new objective
+    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)
+    3. Scope-filter learnings via `cm_query` — only load what matches current objective
+    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.
 
 0.5. **Skill Coverage Check (Adaptive Discovery):**
     - Scan the objective for technologies, frameworks, or patterns mentioned
@@ -73,5 +80,7 @@ When this workflow is called, the AI Assistant should execute the following acti
 4. **Complete:**
     Per `_shared/helpers.md#Update-Continuity`
     - 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)
 
 > **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`).

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

@@ -199,11 +199,14 @@ Wire these tests into `package.json` to make them easily executable by CI or oth
   "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.