codymaster 4.6.0 → 5.2.0

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

@@ -98,6 +98,10 @@ Traditional approach: Load every SKILL.md to decide which skill to use.
 | `cm-execution` | execute, implement, plan, RARV, batch | Execute plans: batch mode, subagent-driven, parallel, or RARV |
 | `cm-continuity` | memory, context, CONTINUITY, learnings | Working memory protocol: read at start, update at end |
 | `cm-skill-mastery` | which skill, skill list, discover, help | Meta-skill: when to invoke skills, how to create new ones |
+| `cm-skill-health` | skill broken, skill drift, missing skill, stale skill, health | Audit a skill using docs drift, retro notes, validation, and gates |
+| `cm-skill-evolution` | repair skill, evolve skill, fix skill, derive skill | Recover a degraded skill with FIX, DERIVED, or CAPTURED mode |
+| `cm-skill-search` | find skill, lookup skill, which skill, search skill | Find the right skill through indexes, suggestions, and repo search |
+| `cm-skill-share` | export skill, import skill, share skill, move skill | Package and transfer skill folders safely across repos and machines |
 | `cm-safe-i18n` | translate, i18n, language, localize | Safe translation with multi-pass batching and audit gates |
 | `cm-skill-chain` | chain, pipeline, workflow, multi-step, full process | Compose skills into automated multi-step pipelines |
 | `cm-deep-search` | semantic search, find docs, large codebase, qmd | Optional power-up for semantic search across large projects |
@@ -127,8 +131,12 @@ Traditional approach: Load every SKILL.md to decide which skill to use.
 
 ### Community Skills Registry 🌐
 
-> **59 pre-indexed community skills** from skills.sh. Install on-demand: `npx skills add {source} --skill {name} -a antigravity`
-> If tech not listed here → fall back to `npx skills find "{keyword}"`
+> **STOP! Zero-Token Discovery Priority:**
+> BEFORE using this registry, check if `.cm/project-skills.md` exists in the local project.
+> It contains the pre-compiled, exact community skills needed for the project's tech stack.
+> If it doesn't exist, run `npx cm index skills` first to build it.
+> 
+> **Only use the registry below if tech is not listed** or if you need to search manually: `npx skills find "{keyword}"`
 
 #### 🖥️ Frontend Frameworks (10)
 
@@ -311,7 +319,7 @@ operations: [cm-safe-deploy, cm-identity-guard, cm-git-worktrees, cm-terminal, c
 security: [cm-secret-shield]
 product: [cm-brainstorm-idea, cm-planning, cm-ux-master, cm-ui-preview, cm-dockit, cm-project-bootstrap, cm-jtbd]
 growth: [cm-content-factory, cm-ads-tracker, cm-cro-methodology]
-orchestration: [cm-execution, cm-continuity, cm-skill-mastery, cm-skill-chain, cm-deep-search, cm-readit, cm-how-it-work]
+orchestration: [cm-execution, cm-continuity, cm-skill-mastery, cm-skill-health, cm-skill-evolution, cm-skill-search, cm-skill-share, cm-skill-chain, cm-deep-search, cm-readit, cm-how-it-work]
 commands: [cm-start, cm-dashboard, cm-status]
 # planned (no SKILL.md yet): mom-test, release-it, medical-research, tailwind-mastery, pandasai-analytics, cm-google-form
 ```

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

@@ -0,0 +1,49 @@
+---
+name: cm-skill-search
+description: "Find the best CodyMaster skill using the shipped indexes, profiles, docs, and contextual suggestions."
+---
+
+# cm-skill-search
+
+Use this skill when you need to find the right CodyMaster skill quickly and avoid loading the wrong `SKILL.md`.
+
+## Search order
+
+1. Fast path
+   - `cm suggest --project .`
+2. Library index
+   - `docs/skills/index.md`
+   - `docs/skills/*.md` category pages
+3. Progressive disclosure
+   - `skills/cm-skill-index/SKILL.md`
+4. Raw filesystem search
+   - `rg -n "<keyword>" skills docs README.md`
+5. Fallback
+   - if nothing matches, use `cm-skill-health` to check whether the missing skill is docs drift or a real gap
+
+## Query workflow
+
+1. Normalize the intent into 2-5 keywords.
+2. Search category pages before opening full skills.
+3. Open only the top 1-3 candidate `SKILL.md` files.
+4. Prefer the skill whose triggers, outputs, and lifecycle placement best match the task.
+5. If two skills overlap:
+   - choose the earlier lifecycle gate first
+   - example: `cm-brainstorm-idea` before `cm-planning`
+
+## Tie-breakers
+
+- Need diagnosis before repair: choose `cm-skill-health`
+- Need to repair a skill: choose `cm-skill-evolution`
+- Need to distribute a skill pack: choose `cm-skill-share`
+- Need the general index first: choose `cm-skill-index`
+
+## Output
+
+```md
+## Skill Search Result
+- Task: ...
+- Best match: cm-...
+- Runner-up: cm-...
+- Why: ...
+```

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

@@ -0,0 +1,58 @@
+---
+name: cm-skill-share
+description: "Package, review, export, and import CodyMaster skill folders safely across machines or teams."
+---
+
+# cm-skill-share
+
+Use this skill when moving a CodyMaster skill between repos, machines, or teammates.
+
+## What to share
+
+Always treat a skill as a folder, not just `SKILL.md`.
+
+Check for:
+- `SKILL.md`
+- templates
+- scripts
+- references
+- assets
+- profile/index entries that must move with it
+
+## Export checklist
+
+1. Validate the source skill.
+   - `npm run validate:skills`
+2. Inspect companion files inside the skill folder.
+3. Note external dependencies the target repo must already have.
+4. Copy the entire folder.
+5. Update destination discovery surfaces if the skill becomes user-facing.
+
+## Import checklist
+
+1. Place the folder under `skills/cm-.../`
+2. Run:
+   - `npm run validate:skills`
+   - `npm run check:skills`
+3. Add it to:
+   - `skills/profiles/full.txt`
+   - docs skill index pages
+   - README only if the skill is part of the public catalog
+4. Verify referenced commands and files exist in the target repo.
+
+## Red flags
+
+- Do not import only the markdown file if the skill depends on scripts or templates.
+- Do not advertise the skill publicly before it is indexed and validated.
+- Do not overwrite an existing skill without comparing behavior and references first.
+
+## Output
+
+```md
+## Skill Share
+- Skill: cm-...
+- Direction: export | import
+- Companion files checked: yes | no
+- Discovery surfaces updated: yes | no
+- Validation: pass | fail
+```

package/skills/cm-sprint-bus/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: cm-sprint-bus
+description: "Use to run the full sprint pipeline: brainstorm → plan → design → tdd → build → review → qa → security → ship → monitor → retro."
+---
+# cm-sprint-bus — opinionated pipeline + artifacts
+
+## Pipeline
+
+`brainstorm → plan → design → tdd → build → review → qa → security → ship → monitor → retro`
+
+## CLI
+
+```bash
+cm sprint init --project .
+cm sprint init --from plan --project .    # jump in mid-pipeline
+cm sprint status --project .
+cm sprint complete plan -m "$(cat plan-notes.md)" --project .
+cm sprint dry-run --project .
+```
+
+## Artifacts
+
+- `.cm/sprint/state.json`
+- `.cm/sprint/artifacts/<step>.md`
+- `.cm/sprint/events.jsonl`
+
+## Skill mapping (hints)
+
+Each step maps to existing CodyMaster skills (see `skillMappingForStep` in `src/sprint-pipeline.ts`). Use `cm sprint status` for the **next** recommended skill.
+
+## Context bus
+
+This complements `.cm/context-bus.json` (skill-chain). Prefer **sprint files** for linear release trains; use **context bus** for ad-hoc chains.

package/skills/cm-start/SKILL.md

@@ -13,16 +13,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
@@ -85,11 +81,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

@@ -16,12 +16,14 @@ Write the test first. Watch it fail. Write minimal code to pass.
 ## When to Use
 
 **Always:**
+
 - New features
 - Bug fixes
 - Refactoring
 - Behavior changes
 
 **Exceptions (ask your human partner):**
+
 - Throwaway prototypes
 - Generated code
 - Configuration files
@@ -37,6 +39,7 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 Write code before the test? Delete it. Start over.
 
 **No exceptions:**
+
 - Don't keep it as "reference"
 - Don't "adapt" it while writing tests
 - Don't look at it
@@ -83,21 +86,14 @@ Before writing ANY test, check `.cm/CONTINUITY.md`:
 
 Write one minimal test showing what should happen.
 
-<Good>
-```typescript
-test('retries failed operations 3 times', async () => {
-  let attempts = 0;
-  const operation = () => {
-    attempts++;
-    if (attempts < 3) throw new Error('fail');
-    return 'success';
-  };
+```typescript test('retries failed operations 3 times', async () => { let attempts = 0; const operation = () => { attempts++; if (attempts < 3) throw new Error('fail'); return 'success'; };
 
   const result = await retryOperation(operation);
 
   expect(result).toBe('success');
   expect(attempts).toBe(3);
 });
+
 ```
 Clear name, tests real behavior, one thing
 </Good>
@@ -113,10 +109,12 @@ test('retry works', async () => {
   expect(mock).toHaveBeenCalledTimes(3);
 });
 ```
+
 Vague name, tests mock not code
-</Bad>
+
 
 **Requirements:**
+
 - One behavior
 - Clear name
 - Real code (no mocks unless unavoidable)
@@ -130,6 +128,7 @@ npm test path/to/test.test.ts
 ```
 
 Confirm:
+
 - Test fails (not errors)
 - Failure message is expected
 - Fails because feature missing (not typos)
@@ -142,37 +141,9 @@ Confirm:
 
 Write simplest code to pass the test.
 
-<Good>
-```typescript
-async function retryOperation<T>(fn: () => Promise<T>): Promise<T> {
-  for (let i = 0; i < 3; i++) {
-    try {
-      return await fn();
-    } catch (e) {
-      if (i === 2) throw e;
-    }
-  }
-  throw new Error('unreachable');
-}
-```
-Just enough to pass
-</Good>
+```typescript async function retryOperation(fn: () => Promise): Promise { for (let i = 0; i < 3; i++) { try { return await fn(); } catch (e) { if (i === 2) throw e; } } throw new Error('unreachable'); } ``` Just enough to pass
 
-<Bad>
-```typescript
-async function retryOperation<T>(
-  fn: () => Promise<T>,
-  options?: {
-    maxRetries?: number;
-    backoff?: 'linear' | 'exponential';
-    onRetry?: (attempt: number) => void;
-  }
-): Promise<T> {
-  // YAGNI
-}
-```
-Over-engineered
-</Bad>
+```typescript async function retryOperation( fn: () => Promise, options?: { maxRetries?: number; backoff?: 'linear' | 'exponential'; onRetry?: (attempt: number) => void; } ): Promise { // YAGNI } ``` Over-engineered
 
 Don't add features, refactor other code, or "improve" beyond the test.
 
@@ -185,6 +156,7 @@ npm test path/to/test.test.ts
 ```
 
 Confirm:
+
 - Test passes
 - Other tests still pass
 - Output pristine (no errors, warnings)
@@ -196,6 +168,7 @@ Confirm:
 ### REFACTOR - Clean Up
 
 After green only:
+
 - Remove duplication
 - Improve names
 - Extract helpers
@@ -208,17 +181,20 @@ Next failing test for next feature.
 
 ## Good Tests
 
-| Quality | Good | Bad |
-|---------|------|-----|
-| **Minimal** | One thing. "and" in name? Split it. | `test('validates email and domain and whitespace')` |
-| **Clear** | Name describes behavior | `test('test1')` |
-| **Shows intent** | Demonstrates desired API | Obscures what code should do |
+
+| Quality          | Good                                | Bad                                                 |
+| ---------------- | ----------------------------------- | --------------------------------------------------- |
+| **Minimal**      | One thing. "and" in name? Split it. | `test('validates email and domain and whitespace')` |
+| **Clear**        | Name describes behavior             | `test('test1')`                                     |
+| **Shows intent** | Demonstrates desired API            | Obscures what code should do                        |
+
 
 ## Why Order Matters
 
 **"I'll write tests after to verify it works"**
 
 Tests written after code pass immediately. Passing immediately proves nothing:
+
 - Might test wrong thing
 - Might test implementation, not behavior
 - Might miss edge cases you forgot
@@ -229,6 +205,7 @@ Test-first forces you to see the test fail, proving it actually tests something.
 **"I already manually tested all the edge cases"**
 
 Manual testing is ad-hoc. You think you tested everything but:
+
 - No record of what you tested
 - Can't re-run when code changes
 - Easy to forget cases under pressure
@@ -239,6 +216,7 @@ Automated tests are systematic. They run the same way every time.
 **"Deleting X hours of work is wasteful"**
 
 Sunk cost fallacy. The time is already gone. Your choice now:
+
 - Delete and rewrite with TDD (X more hours, high confidence)
 - Keep it and add tests after (30 min, low confidence, likely bugs)
 
@@ -247,6 +225,7 @@ The "waste" is keeping code you can't trust. Working code without real tests is
 **"TDD is dogmatic, being pragmatic means adapting"**
 
 TDD IS pragmatic:
+
 - Finds bugs before commit (faster than debugging after)
 - Prevents regressions (tests catch breaks immediately)
 - Documents behavior (tests show how to use code)
@@ -266,19 +245,21 @@ Tests-first force edge case discovery before implementing. Tests-after verify yo
 
 ## Common Rationalizations
 
-| Excuse | Reality |
-|--------|---------|
-| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
-| "I'll test after" | Tests passing immediately prove nothing. |
-| "Tests after achieve same goals" | Tests-after = "what does this do?" Tests-first = "what should this do?" |
-| "Already manually tested" | Ad-hoc ≠ systematic. No record, can't re-run. |
-| "Deleting X hours is wasteful" | Sunk cost fallacy. Keeping unverified code is technical debt. |
-| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete. |
-| "Need to explore first" | Fine. Throw away exploration, start with TDD. |
-| "Test hard = design unclear" | Listen to test. Hard to test = hard to use. |
-| "TDD will slow me down" | TDD faster than debugging. Pragmatic = test-first. |
-| "Manual test faster" | Manual doesn't prove edge cases. You'll re-test every change. |
-| "Existing code has no tests" | You're improving it. Add tests for existing code. |
+
+| Excuse                                 | Reality                                                                 |
+| -------------------------------------- | ----------------------------------------------------------------------- |
+| "Too simple to test"                   | Simple code breaks. Test takes 30 seconds.                              |
+| "I'll test after"                      | Tests passing immediately prove nothing.                                |
+| "Tests after achieve same goals"       | Tests-after = "what does this do?" Tests-first = "what should this do?" |
+| "Already manually tested"              | Ad-hoc ≠ systematic. No record, can't re-run.                           |
+| "Deleting X hours is wasteful"         | Sunk cost fallacy. Keeping unverified code is technical debt.           |
+| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete.             |
+| "Need to explore first"                | Fine. Throw away exploration, start with TDD.                           |
+| "Test hard = design unclear"           | Listen to test. Hard to test = hard to use.                             |
+| "TDD will slow me down"                | TDD faster than debugging. Pragmatic = test-first.                      |
+| "Manual test faster"                   | Manual doesn't prove edge cases. You'll re-test every change.           |
+| "Existing code has no tests"           | You're improving it. Add tests for existing code.                       |
+
 
 ## Red Flags - STOP and Start Over
 
@@ -303,6 +284,7 @@ Tests-first force edge case discovery before implementing. Tests-after verify yo
 **Bug:** Empty email accepted
 
 **RED**
+
 ```typescript
 test('rejects empty email', async () => {
   const result = await submitForm({ email: '' });
@@ -311,12 +293,14 @@ test('rejects empty email', async () => {
 ```
 
 **Verify RED**
+
 ```bash
 $ npm test
 FAIL: expected 'Email required', got undefined
 ```
 
 **GREEN**
+
 ```typescript
 function submitForm(data: FormData) {
   if (!data.email?.trim()) {
@@ -327,6 +311,7 @@ function submitForm(data: FormData) {
 ```
 
 **Verify GREEN**
+
 ```bash
 $ npm test
 PASS
@@ -339,25 +324,27 @@ Extract validation for multiple fields if needed.
 
 Before marking work complete:
 
-- [ ] Every new function/method has a test
-- [ ] Watched each test fail before implementing
-- [ ] Each test failed for expected reason (feature missing, not typo)
-- [ ] Wrote minimal code to pass each test
-- [ ] All tests pass
-- [ ] Output pristine (no errors, warnings)
-- [ ] Tests use real code (mocks only if unavoidable)
-- [ ] Edge cases and errors covered
+- Every new function/method has a test
+- Watched each test fail before implementing
+- Each test failed for expected reason (feature missing, not typo)
+- Wrote minimal code to pass each test
+- All tests pass
+- Output pristine (no errors, warnings)
+- Tests use real code (mocks only if unavoidable)
+- Edge cases and errors covered
 
 Can't check all boxes? You skipped TDD. Start over.
 
 ## When Stuck
 
-| Problem | Solution |
-|---------|----------|
+
+| Problem                | Solution                                                             |
+| ---------------------- | -------------------------------------------------------------------- |
 | Don't know how to test | Write wished-for API. Write assertion first. Ask your human partner. |
-| Test too complicated | Design too complicated. Simplify interface. |
-| Must mock everything | Code too coupled. Use dependency injection. |
-| Test setup huge | Extract helpers. Still complex? Simplify design. |
+| Test too complicated   | Design too complicated. Simplify interface.                          |
+| Must mock everything   | Code too coupled. Use dependency injection.                          |
+| Test setup huge        | Extract helpers. Still complex? Simplify design.                     |
+
 
 ## Debugging Integration
 
@@ -372,4 +359,4 @@ Production code → test exists and failed first
 Otherwise → not TDD
 ```
 
-No exceptions without your human partner's permission.
+No exceptions without your human partner's permission.

package/skills/profiles/README.md

@@ -0,0 +1,21 @@
+# Skill install profiles (Antigravity / Windsurf / token budget)
+
+Use with `install.sh`:
+
+```bash
+bash install.sh --gemini --profile core
+bash install.sh --antigravity --profile core
+bash install.sh --windsurf --profile core
+```
+
+- **core** — Orchestration, TDD, debugging, quality gates, deploy, secrets, identity, terminal (~21 skills). Recommended for global `~/.gemini/antigravity/skills`.
+- **growth** — Ads tracking, CRO, content factory, forms, dashboard, etc. Add on top of core (re-run install to the same target) or install only into a workspace project folder.
+- **design** — UX Master, design system, UI preview, JTBD, brainstorm.
+- **knowledge** — Dockit, NotebookLM skill, deep search, code intelligence, project bootstrap, reactor.
+- **full** — All skills (default when `--profile` is omitted). Same set as [full.txt](full.txt).
+
+**Global vs workspace:** Keep **core** in user global skills; add **growth** / **design** / **knowledge** under the project (e.g. `.gemini/antigravity/skills` in repo) so every session does not load the full catalog.
+
+**MCP:** Disable unused MCP servers in the IDE to avoid retry loops when a server errors; heavy external tools belong in optional profiles, not core.
+
+**Maintainers:** When adding a new `skills/cm-*` folder, update [full.txt](full.txt) and add the skill to the appropriate optional profile (`growth`, `design`, or `knowledge`) if it is not part of `core`.

package/skills/profiles/core.txt

@@ -0,0 +1,23 @@
+# CodyMaster profile: core — Antigravity/Windsurf token budget (orchestration + quality + safety)
+# Install: bash install.sh --gemini --profile core
+cm-skill-index
+cm-how-it-work
+cm-start
+cm-planning
+cm-execution
+cm-continuity
+cm-status
+cm-tdd
+cm-debugging
+cm-code-review
+cm-clean-code
+cm-quality-gate
+cm-test-gate
+cm-safe-deploy
+cm-secret-shield
+cm-identity-guard
+cm-security-gate
+cm-safe-i18n
+cm-skill-chain
+cm-git-worktrees
+cm-terminal

package/skills/profiles/design.txt

@@ -0,0 +1,6 @@
+# UX/UI and product discovery
+cm-design-system
+cm-ux-master
+cm-ui-preview
+cm-brainstorm-idea
+cm-jtbd

package/skills/profiles/full.txt

@@ -0,0 +1,62 @@
+# Complete CodyMaster skill set (same as default install when --profile full or omitted)
+# Kept in sync with skills/cm-*/ — update when adding skills
+cm-ads-tracker
+cm-auto-publisher
+cm-autopilot
+cm-booking-calendar
+cm-brainstorm-idea
+cm-browse
+cm-clean-code
+cm-code-review
+cm-codeintell
+cm-conductor-worktrees
+cm-content-factory
+cm-continuity
+cm-cro-methodology
+cm-dashboard
+cm-debugging
+cm-deep-search
+cm-design-studio
+cm-design-system
+cm-dockit
+cm-ecosystem-roadmap
+cm-engineering-meta
+cm-example
+cm-execution
+cm-git-worktrees
+cm-google-form
+cm-growth-hacking
+cm-guardian-runtime
+cm-how-it-work
+cm-identity-guard
+cm-jtbd
+cm-mcp-engineering
+cm-notebooklm
+cm-planning
+cm-post-deploy-canary
+cm-project-bootstrap
+cm-qa-visual-cli
+cm-quality-gate
+cm-reactor
+cm-readit
+cm-retro-cli
+cm-safe-deploy
+cm-safe-i18n
+cm-second-opinion-cli
+cm-secret-shield
+cm-security-gate
+cm-skill-chain
+cm-skill-evolution
+cm-skill-health
+cm-skill-index
+cm-skill-mastery
+cm-skill-search
+cm-skill-share
+cm-sprint-bus
+cm-start
+cm-status
+cm-tdd
+cm-terminal
+cm-test-gate
+cm-ui-preview
+cm-ux-master

package/skills/profiles/growth.txt

@@ -0,0 +1,10 @@
+# Marketing, CRO, ads tracking, content — use with core or standalone
+cm-ads-tracker
+cm-cro-methodology
+cm-growth-hacking
+cm-booking-calendar
+cm-content-factory
+cm-auto-publisher
+cm-google-form
+cm-readit
+cm-dashboard

package/skills/profiles/knowledge.txt

@@ -0,0 +1,7 @@
+# Docs, codebase intelligence, research (often larger skills / MCP-adjacent)
+cm-notebooklm
+cm-deep-search
+cm-codeintell
+cm-dockit
+cm-project-bootstrap
+cm-reactor