codymaster 4.6.0 → 4.8.0

package/skills/cm-design-studio/SKILL.md

@@ -0,0 +1,30 @@
+# cm-design-studio
+
+> Local design-variant workspace: checklist, named variants, and a handoff stub—no external MCP required.
+
+## When to use
+
+- You want **2–3 UI/UX variants** documented before coding.
+- You need a **repeatable handoff** from design choice to implementation agents.
+- You prefer **files under `.cm/`** over ad-hoc chat-only decisions.
+
+## Steps
+
+1. From the repo root: `cm design-studio init`
+2. Edit `.cm/design-studio/CHECKLIST.md` and `VARIANTS.md` (name options A/B/C).
+3. Pick a variant; complete `.cm/design-studio/HANDOFF.md` (screens, tokens, prompt stub).
+4. Run implementation skills (e.g. `cm-execution`, `cm-tdd`) **using the HANDOFF prompt stub** as the single source of truth.
+
+Optional: `cm design-studio status` — list artifact files.
+
+## Output
+
+- `.cm/design-studio/README.md` — happy path
+- `.cm/design-studio/CHECKLIST.md`
+- `.cm/design-studio/VARIANTS.md`
+- `.cm/design-studio/HANDOFF.md`
+
+## Related
+
+- ADR 003 (`docs/adr/003-skill-distro-and-meta.md`) for pack layout when publishing skills.
+- `cm suggest` may recommend other skills based on git + sprint state.

package/skills/cm-ecosystem-roadmap/SKILL.md

@@ -0,0 +1,11 @@
+# cm-ecosystem-roadmap — marketplace & distros
+
+**In CLI today:** `cm distro validate <dir>` checks skill folder layout; see **ADR 003** (`docs/adr/003-skill-distro-and-meta.md`) for `meta.json` + tmpl rules.
+
+**Backlog** (community scale-out):
+
+- **`cm marketplace`** — starred skills, semver, dependency graph.
+- **`cm install`** / **`cm distro create`** — preset skill packs + branding (SaaS, e-commerce, mobile, agency).
+- **Publish** — npm and/or git tags as distribution channels.
+
+Reuse **meta.json** + `SKILL.md.tmpl` from `scripts/build-skills.mjs` for reproducible skill packages.

package/skills/cm-engineering-meta/SKILL.md

@@ -0,0 +1,69 @@
+# cm-engineering-meta — quick wins + access + voice map
+
+## Search before building
+
+Before adding infrastructure, search in three layers:
+
+1. **Tried-and-true** — patterns already in this repo / sibling services.
+2. **New-and-popular** — current docs for your stack version.
+3. **First-principles** — only when 1–2 don’t apply.
+
+## AskUserQuestion format
+
+When asking the human to choose:
+
+- Short **context** (what you already know).
+- Clear **question**.
+- **RECOMMENDATION** (one option you’d pick and why).
+- Lettered options **A / B / C** (not vague yes/no).
+
+## Review readiness dashboard (ASCII)
+
+Before ship, print a table:
+
+```
+| Gate        | Status | Notes |
+|-------------|--------|-------|
+| Tests       | ?      |       |
+| Lint/Type   | ?      |       |
+| Secrets     | ?      |       |
+| Manual QA   | ?      |       |
+```
+
+## Completeness gap (code review)
+
+Flag when an **80% solution** is chosen but the **100%** path costs **< 30 minutes** (tests, edge case, docs).
+
+## Investigate Iron Law
+
+- Do **not** patch without a **root cause** hypothesis.
+- After **three** failed fix attempts, stop and question architecture or gather more data.
+
+## Access controls (Goose-style)
+
+- Maintain lists: **autonomous_ok** vs **confirm_required** skill groups (see `.cm/config.example.yaml`).
+- Respect “stop suggesting skill X” in session notes.
+
+## Provider abstraction
+
+Prefer interfaces for LLM calls so **cm-second-opinion** can swap `OPENAI_API_KEY` / future providers without rewriting skills.
+
+## Proactive skill suggestion
+
+Infer stage from files touched and git state:
+
+- Many `test/` edits → suggest **cm-test-gate**.
+- `Dockerfile` / deploy scripts → **cm-safe-deploy** + **cm canary**.
+- `rm` / migration scripts → **cm-guardian** + **cm-secret-shield**.
+
+## Voice-friendly triggers (examples)
+
+| Phrase (approx.) | Skill / command |
+|------------------|-----------------|
+| “Run a security check” | cm-secret-shield / cm-security-gate |
+| “Test the website” | cm browse + cm qa-visual |
+| “Code review this” | cm-code-review |
+| “Deploy safely” | cm-safe-deploy |
+| “Log what went wrong” | `cm retro --note "…"` |
+
+Use Whisper / AquaVoice → paste transcript; map keywords to the table above.

package/skills/cm-growth-hacking/SKILL.md

@@ -1,17 +1,6 @@
 ---
 name: cm-growth-hacking
-description: |
-  Growth Hacking Engine — Bottom Sheet + Calendar + Trigger + CRO Tracking.
-  Modular system for booking popups, lead capture, flash sales, surveys, re-engagement.
-  Auto-detect industry → select pattern → generate bottom sheet + calendar CTA + tracking.
-  Zero dependencies, works on any static or dynamic site.
-  
-  Kế thừa và liên kết với: cm-booking-calendar, cm-ads-tracker, cm-google-form, cm-readit, cm-ux-master.
-  
-  ALWAYS trigger for: bottom sheet, popup, đặt lịch, booking popup, lead capture, exit intent,
-  engagement, "tạo popup", "thêm bottom sheet", "popup đặt lịch", "nhắc lịch hẹn",
-  "add to calendar", "google calendar", "apple calendar", flash sale popup, survey popup,
-  "tăng conversion", "giảm bounce", re-engagement, "popup CTA"
+description: "Bottom-sheet and popup growth system: booking CTAs, calendars, lead capture, surveys, re-engagement, with CRO tracking hooks. Zero-deps; works static or dynamic sites. Works with cm-booking-calendar, cm-ads-tracker, cm-google-form, cm-readit, cm-ux-master."
 allowed-tools: Read, Write, Edit, Glob, Grep, Browser
 version: 1.0
 priority: HIGH

package/skills/cm-guardian-runtime/SKILL.md

@@ -0,0 +1,22 @@
+# cm-guardian-runtime — destructive command & freeze checks
+
+## Commands
+
+```bash
+cm guardian check -- git push --force origin main    # exits 1 if blocked
+cm guardian path-check --file ./src/app.ts --roots src,lib
+```
+
+## Behaviour
+
+- Regex set for `rm -rf`, `DROP TABLE`, `git push --force`, `git reset --hard`, pipes to shell, etc.
+- Prefix whitelist includes `npm run build`, `npm test`, `npx vitest`.
+- Violations append to `.cm/guardian.log`.
+
+## Investigate / debug mode
+
+When using **cm-debugging** or root-cause work, treat **freeze roots** as mandatory: only edit inside allowed directories until the hypothesis is proven.
+
+## Config
+
+See `.cm/config.example.yaml` → `guardian:`.

package/skills/cm-mcp-engineering/SKILL.md

@@ -0,0 +1,18 @@
+# cm-mcp-engineering — MCP tools on context server
+
+The same binary as memory MCP (`dist/mcp-context-server.js`) now exposes **engineering bridge** tools:
+
+| Tool | Purpose |
+|------|---------|
+| `cm_plan` | Sprint state + artifact paths + next skill hint |
+| `cm_review` | Preview `.cm/sprint/artifacts/review.md` |
+| `cm_qa` | Pointers to browse daemon + `cm qa-visual` |
+| `cm_deploy` | Hints for safe deploy + canary |
+| `cm_search` | Learnings + decisions search |
+| `cm_memory_query` | Same backing store, alias-style |
+
+Existing tools unchanged: `cm_query`, `cm_resolve`, `cm_bus_read`, `cm_bus_write`, `cm_budget_check`, `cm_memory_decay`, `cm_index_refresh`.
+
+## Config
+
+Point `--project` at the repo root (or `CM_PROJECT_PATH`).

package/skills/cm-notebooklm/SKILL.md

@@ -1,22 +1,6 @@
 ---
 name: cm-notebooklm
-description: |
-  CodyMaster NotebookLM — Cloud-based AI brain/soul engine. Stores the most
-  valuable knowledge (skills, lessons learned, coding experiences, key decisions)
-  into Google NotebookLM for cross-machine sync and AI-powered recall.
-  Combines cm-dockit (codebase → docs) + cm-deep-search (local BM25) +
-  NotebookLM (cloud AI memory + podcast + flashcards).
-
-  Offers LOCAL vs CLOUD choice for large codebases. Auto-sync mechanism.
-  Selective indexing — only high-value content, not everything.
-
-  Use when user says: "notebooklm", "notebook lm", "nlm", "nạp kiến thức",
-  "knowledge base", "create notebook", "sync skills to notebook", "tạo notebook",
-  "knowledge memory", "podcast từ skills", "flashcards từ docs",
-  "add to notebooklm", "query notebooklm", "hỏi notebooklm",
-  "lưu kinh nghiệm", "bộ nhớ AI", "AI memory", "tạo podcast",
-  "codymaster notebook", "skill notebook", "sync knowledge",
-  "cloud brain", "soul sync", "cross-machine sync".
+description: "Sync high-value dev knowledge (skills, decisions, lessons) into Google NotebookLM for cloud recall, podcasts, and flashcards. Pairs with Dockit/deep-search. Use for NotebookLM, nlm, knowledge base, skill sync, or cross-machine AI memory."
 ---
 
 # Goal

package/skills/cm-post-deploy-canary/SKILL.md

@@ -0,0 +1,18 @@
+# cm-post-deploy-canary — smoke + browse tail
+
+## CLI
+
+```bash
+cm canary --url https://app.example.com
+cm canary --url https://app.example.com --browse-port 17395 --token "$CM_BROWSE_TOKEN"
+```
+
+## Flow
+
+1. **HTTP GET** the URL (status < 400).
+2. Optionally pull **browse daemon** `/console` for recent browser errors after deploy.
+
+## Next
+
+- Wire into **cm-safe-deploy** as a final step.
+- Add programmatic CWV (Lighthouse) when you need baselines per PR.

package/skills/cm-qa-visual-cli/SKILL.md

@@ -0,0 +1,18 @@
+# cm-qa-visual-cli — screenshot via browse daemon
+
+## Prerequisites
+
+`cm browse start` running with the same `CM_BROWSE_TOKEN`.
+
+## CLI
+
+```bash
+cm qa-visual --url http://localhost:5173 --port 17395
+```
+
+Writes `cm-qa-visual.png` in the current working directory.
+
+## Next
+
+- Diff against golden images for visual regression.
+- Map `git diff` → affected routes (project-specific heuristics).

package/skills/cm-retro-cli/SKILL.md

@@ -0,0 +1,19 @@
+# cm-retro-cli — operational learnings JSONL
+
+## Append
+
+```bash
+cm retro --project . --tool claude --note "Forgot to run gate before push; CI failed on lint."
+```
+
+Stored in `.cm/operational-learnings.jsonl`.
+
+## Summary
+
+```bash
+cm retro --project . --summary
+```
+
+## Use with skill evolution
+
+Feed highlights into **cm-skill-evolution** / project learnings DB so future sessions avoid repeating mistakes.

package/skills/cm-second-opinion-cli/SKILL.md

@@ -0,0 +1,19 @@
+# cm-second-opinion-cli — cross-model review stub
+
+## CLI
+
+```bash
+cm second-opinion --file /tmp/my.diff
+```
+
+- With `OPENAI_API_KEY`, calls **OpenAI chat completions** (`CM_SECOND_OPINION_MODEL` optional, default `gpt-4o-mini`).
+- Without key, prints a **stub** reminder (no network).
+
+## Safety
+
+- **Never** paste secrets or production credentials into the diff file.
+- Prefer unified diffs of **application code** only.
+
+## Roadmap
+
+Add Anthropic / Google / Ollama providers via shared provider interface (see **cm-engineering-meta**).

package/skills/cm-secret-shield/SKILL.md

@@ -79,8 +79,8 @@ ROTATION is not optional after a leak.
 // ❌ NEVER write code like this:
 const API_KEY = "sk-proj-abc123def456ghi789";
 const SUPABASE_KEY = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...";
-const DB_PASSWORD = "MyP@ssw0rd123!";
-fetch('https://api.example.com', { headers: { Authorization: 'Bearer sk-...' } });
+const DB_PASSWORD = "<YOUR_SECURE_PASSWORD>";
+fetch('https://api.example.com', { headers: { Authorization: 'Bearer <YOUR_TOKEN>' } });
 
 // ✅ ALWAYS write code like this:
 const API_KEY = process.env.API_KEY;

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

@@ -0,0 +1,29 @@
+# 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-tdd/SKILL.md

@@ -1,7 +1,7 @@
 ---
-name: cm-tdd
+
+## name: cm-tdd
 description: Use when implementing any feature or bugfix, before writing implementation code
----
 
 # Test-Driven Development (TDD)
 
@@ -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